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 offerings is that Microsoft have taken care of all the high availability and load scaling configuration and there is then no need to manage multiple servers in an ADFS farm.
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 providor 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 and send 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) –
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!
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 Redirect – localhost to kloudfed.accesscontrol.windows.net:
#17
302 Redirect – kloudfed.accesscontrol.windows.net to login.windows.net service:
#21
302 Redirect – login.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 the industry that everything must be called by its acronym 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!).