In this post I will discuss how you can setup Microsoft Azure to provide federation services with claims authentication in the same way that an Active Directory Federation Service (ADFS) farm would on-premises. This can be achieved with an Azure subscription, Access Control Services (ACS) and an Azure Active Directory (AAD) instance. The key benefit of using Azure SaaS is that Microsoft have taken care of all the high availability and load scaling configuration, therefor you have no need to manage multiple ADFS servers to gain the same desired functionality.

If you don’t have an Azure subscription then signup for a free trial.

To have this process work in Azure we are going to need 2 functions –

  1. A service supporting claims-based protocols and be our token issuer – ACS
  2. A synchronized directory with connectivity to our claims issuer service – DirSync/AAD.

Azure Access Control Services (ACS) is a cloud based federated identity provider which currently supports tokens issued from social identities such as Windows Live ID, Facebook, Google, Yahoo and also the over-looked feature of enterprise identities like Active Directory. ACS can do some great things with transitions between protocols and transformation of claims as it issues secure tokens from the identity provider to the relying party applications.

Azure Active Directory (AAD) will house the synchronized identities from the on-premises Active Directory and provide claims-based authentication as it sends secure tokens with embedded claims to ACS.

The Solution

This scenario will apply to the majority of organizations whom are wanting to map the identity attributes from a source Active Directory (LDAP) to the outgoing claims type for a single sign on (SSO) experience.

Step 1 – Get the Identity in the Cloud

We need to use either a new directory in Azure or use an existing Office 365 directory if you have a tenant syncing already (skip to step 2) –

  • Turn on Synchronization by selecting Directory Integration > ACTIVATE
  • Create a user account to authenticate from your directory synchronization tool to AAD
  • Download the directory sync tool
  • Install and configure the directory sync tool on a server that is joined to your local Active Directory domain, and then run an initial sync. More information go here
  • Remember to enable password copy in the configuration wizard

Step 2 – Create an ACS Namespace

  • Select > New > App Services > Access Control > Quick Create
  • Give it a useful name prefix example: ‘kloudfed’
  • Once finished creating, Select > Manage
  • Select > Application Integration and see the Endpoint References

Next we need to create the Azure Active Directory as the Identity Provider

Step 3 – Create AAD Endpoint Mapping

Currently we have no way of ACS connecting to the information in AAD. To do this we create an Application Endpoint –

  • Select Active Directory > Federated Identity Instance > Applications > ADD AN APPLICATION
  • Select Add an application my organization is developing
  • Give it a name example: ‘Access Control Services’

  • In APP Properties:
    • Sign-ON URL = < ACS Management Portal >
    • APP ID URI = < ACS Management Portal >

  • In Azure Management Portal > Open your newly created APP
  • Select > View Endpoints

  • Copy Federation Metadata document URL to add to ACS

Step 4 – Add AAD as an Identity Provider in ACS

With the Federation Metadata Endpoint configured this can be the Identity Provider defined in ACS –

  • In ACS Portal Under Trust Relationships Select > Identity Providers
  • Select Add
  • In the Add Identity Provider Page Select > WS-Federation identity provider (e.g. Microsoft AD FS 2.0) > Select Next
  • Give it a name and paste the Federation Metadata URL from the previous step

  • Click Save

Now we are ready to add a claims-aware application in ACS which is requiring federated identity authentication.

Step 5 – Create a Relying Party Application

I’m not a developer, but this is the quickest way I know to make a claims-aware application using my copy of Visual Studio Express –

  • Select File > New Project > Web > ASP .NET Web Application

  • Click OK
  • Click > Change Authentication

  • Select Organization Account > Select On-Premises
  • Enter the ACS WS-Federation Metadata URL and make up an Application Unique ID

Step 6 – Add Relying Party Application information to ACS

The ACS Namespace wont issue tokens till it trusts the application. In the ACS Management Portal –

  • Select Relying Party Applications > New
  • Important – Realm is your App ID URI entered in the above steps

  • Generate a default claim transformation rule

Step 7 – Run a claims aware application

Here is my web application which will redirect from default URL (localhost) which is requiring authentication from Azure Active Directory –

  • The Redirect takes me to Azure Active Directory login

  • Enter Username & Password
  • Then I’m taken to the trusted application redirect URL after successful authenticating and we can already see claims information highlighted in yellow. Success!

     

Fiddler2 Capture

Let’s look at the web requests in a Fiddler2 capture to see what’s happening behind the scenes of my browser. Here are some condensed capture snippets –

#6

302 Redirectlocalhost to kloudfed.accesscontrol.windows.net:


#17

302 Redirectkloudfed.accesscontrol.windows.net to login.windows.net service:


#21

302 Redirectlogin.windows.net to login.microsoftonline.com:

#40

200 Result – Token response with claims returned from kloudfed.accesscontrol.windows.net

Filtering through the above #40 decrypted capture we find claims information. This is where we can validate if the web application is receiving the expected information in the token(I’ve removed the double-encoded values from the capture for readability) –

We can see the token is SAML2.0:

TokenType=http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0

One example of a claim attribute:

Name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname><AttributeValue>Peterson</AttributeValue>

Conclusion

If you’re after a claims-based federation service for SSO and installing a bunch of new servers in your existing infrastructure is something you’re not keen on undertaking, then maybe Azure gets a look. In an industry where everything must be called by its acronym to be thought of as a serious entity, I hereby label Microsoft Azure Federation Services “MAFS”.

Through reading Kloud blog posts you have solutions for creating a claims-based federation service in the cloud (MAFS) or an on-premises ADFS farm with Server 2012 R2 (both of which should only take you about 10 minutes to install!).

Category:
ADFS, Azure Platform, Identity and Access Management
Tags:
, , , , , , ,

Join the conversation! 16 Comments

  1. Hi Arran,
    Thanks for the article. I am a little confused and don’t seem to be able to find any other info out there on this. Are you saying that with this service an Office 365 customer using DirSync to replicate their AD objects to the cloud could use this service for ADFS instead of deploying servers on-premises? If true does that also alleviate the requirement for external DNS address i.e. sts.domain.x, public certs…
    Or am I getting this completely wrong?
    Many thanks
    P

    • Hi Patrick,

      I’ve tried to keep this post generic as possible for any SSO cloud application not necessarily o365. This ‘could’ be used as an ADFS alternative, but I don’t believe that it is the desired solution for SSO when talking about the need for token authentication.

      So it depends what your end game is with o365.

      If you just want o365 sign on to mirror on-premises AD, DirSync & Password Copy is still the simplest solution. DirSync & Password Copy + ACS + AAD is just adding extra services in the login process that aren’t needed when you already have the desired end state.

      If your end game is to use claims token authentication for o365 and share that token for authentication for other applications and vice versa, then it starts getting a bit more in depth. You need to start thinking about factors like where the token issuer location is, in relation to the claims aware application as your token will traverse those networks/firewalls, end user location, user devices and experience for token being issued. If your answer’s are more internal/domain then possibly ADFS or if it’s all internet based then possibly ACS/AAD.

      You may want to test o365 federated login with the model described in this post as a POC before going to ADFS On-Premises as it takes very little time to implement and test.

  2. Hi, now that ACS does not support Google anymore what would you use to add support for Google authentication?

    This is a question I posted on SO without any answers by my own: http://stackoverflow.com/questions/24713363/azure-acs-and-google-as-an-identity-provider

  3. Hi Arran,
    Thanks for a very interesting post! I’m researching options for an enterprise about to implement an IAM platform in a green field scenario. SSO to O365 and HR SaaS are only the first steps. They’re looking to establish a strategy for application development (I’m advocating claims aware development in general). Another company recommends ADFS to which I don’t have any real objections but looking for a more modern option which will have minimial on-prem infrastructure footprint.

    I’m curious about to what extent you can control what claims are being issued to what application and how you would control authentication policies with this kind of solution. I have not been able to find information regarding those specific questions yet. If those two questions can be answered (or point me in the direction of more information) I would be very grateful!

    Thanks,
    Carl

  4. We have developed a website which is deployed in Azure cloud environment(Azure Website). Now we need to authenticate users using on-premises Active Directory . We don’t want to use VPN or Azure Active directory Sync. Is this possible?. If so, what are the security settings required to be done on LDAP server?. If not possible, what are the best options I have.

    Note- I want Azure AD and on-premises AD using federation with AD FS for Single Sign on (SSO)

  5. Hi there, I don’t quite understand why ACS is requried here. The application can be the RP and AAD is the IDP. What value does ACS in the middle add?

  6. Hi,

    After following above step I am able to get login page from ACS but whenever I try to login I get below error

    Correlation ID: 2f362546-a75a-42b3-acb8-29d96de8b738
    Timestamp: 2016-07-13 13:32:39Z
    AADSTS50105: The signed in user ‘[email protected]’ is not assigned to a role for the application ‘8fb571fb-5f47-4a4e-b090-59423xxxx’.

    Can you please help me to fix this.

    Thanks

Comments are closed.