Claims-Based Federation Service using Microsoft Azure
Rate this post

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:
, , , , , , ,

Leave a Reply

  Subscribe  
newest oldest most voted
Notify of
Patrick Yore (@pyore)
Guest

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

JC
Guest
JC

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

Carl
Guest

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… Read more »

extcon
Guest
Gaurav Singh
Guest
Gaurav Singh

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)

Chaz
Guest

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?

Naved
Guest
Naved

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 ‘nk@xyz.COM’ is not assigned to a role for the application ‘8fb571fb-5f47-4a4e-b090-59423xxxx’.

Can you please help me to fix this.

Thanks

Follow Us!

Kloud Solutions Blog - Follow Us!