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 –
- A service supporting claims-based protocols and be our token issuer – ACS
- 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.
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) –
- Sign in to Azure https://manage.windowsazure.com
- Select > New > App Services > Active Directory > Create Custom
- 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!
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 –
302 Redirect – localhost to kloudfed.accesscontrol.windows.net:
302 Redirect – kloudfed.accesscontrol.windows.net to login.windows.net service:
302 Redirect – login.windows.net to login.microsoftonline.com:
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:
One example of a claim attribute:
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!).