ADFS 2.0 By Example - Part2: ADFS and ACS

Table of Contents

ADFS and Azure Access Control Service

• What is ACS?
• ASP.NET and ACS
• ACS and ADFS

ADFS and Azure Access Control Service

Part 1 of this article is posted here

What is ACS?

Azure Access Control Service (ACS) plays two roles; it is used to authorize access to the Azure Service Bus and Caching, and it also serves as a Federation Provider (R-STS) for your applications on the cloud.

In the context of this article, I am concerned with the second role: how ACS serves as an R-STS.

The below sketch shows the conceptual model of ACS in action:

Just as ADFS was your R-STS (or IP-STS depensing on the context) on premise, ACS is your R-STS on the cloud.

Note that ADFS is itself one kind of providers that can be trusted by ACS; this will be shows in a separate section.

ASP.NET and ACS

In this example, I will show you how to outsource authentication of your ASP.NET application to ACS.

Step1: Create a Service Bus namespace and get the Access Key

Navigate to your Azure portal and create a namespace:

Click on Access Key and copy the Default Key value:

Step2: Add Identity Providers in the ACS Portal

The ACS portal address can be reached using the following format:
https://[namespace].accesscontrol.windows.net/v2/mgmt/web
So in my case it will be: https://mvpdemons.accesscontrol.windows.net/v2/mgmt/web

Click on Identity Providers and Click Add:

As you can see, Windows Live ID is a default IP for ACS. In the next screen you will get to add the IPs that you want. You can add other IPs such as Google and Yahoo! (who rely on OpenID), Facebook (which provides authentication via its Graph API and authorization using OAuth 2.0), and any WS-Federation IP one of which is ADFS. In this case add Google (ADFS will wait for the next section):

Step3: Create an ASP.NET application in VS 2012

The steps are the same regardless of whether you are using an MVC or Web Forms application. I will use web forms and will call my application:
http://localhost/TestACS

Next right click on the project and fire the good old Identity and Access wizard. Here are the familiar 3 options:

Note: the approach I am following now will automatically configure the RP in ACS. Another approach is to select “Use a business identity provider (e.g. ADFS2)” in which case you will have to get the federation metadata file URL of ACS from the Application Integration option in ACS portal.

Once the wizard is completed, the application will be configured as a trusted RP for ACS; as always you can check the updates in web.config and the newly created file \FederationMetadata\2007-06\FederationMetadata.xml.

Step4: Check ACS configuration

In the ACS portal click Relying party applications and you will see that the RP is automatically configured via the wizard you ran at step3.

Next click on Rule groups. Rule groups are the set of rules that ACS shall apply on claims coming from IPs; these rules can transform, copy, and insert additional claims. You can think of Rule groups as the equivalent to claims engine of ADFS in the context of claim manipulation. The default Rule group generated just passes through the claims offered by Live ID and Google to the RP:

Step5: Run the RP

Browse to http://localhost/TestACS. You will be presented with the home realm page to select which IP you want to authenticate with:

Assuming you selected Google, ACS will just pass through Google claims and hand them to your application in a SAML 2.0 token that it trusts (review “What is ACS section?” for a description of the full interaction). Here is the final page:

Note that each provider issue by default a set of claims; of these claims offered by Google are the nameidentifier and name claims, which is how the RP (actually WIF at the RP) managed to identify my name in the welcome message.

ACS and ADFS

In this section, we’ll use ADFS as an IP for ACS.

Step1: Grab the FederationMetadata.xml file of ADFS

Since ADFS is installed on my local network, ACS cannot extract ADFS metadata via a URL so we need to give ACS the metadata file in order to set up WS-Federation. Open https://win2012.lab.local/FederationMetadata/2007-06/FederationMetadata.xml in the browser, and save the result XML in a file.

Step2: Add ADFS as an IP for ACS

We will continue using the same service bus namespace we used before. So again navigate to https://mvpdemons.accesscontrol.windows.net/v2/mgmt/web.

Add a new Identity Provider and select ADFS:

Next, you supply the federation metadata XML file you saved in step1:

Note that we will use the same TestACS application we used in section “ASP.NET and ADFS”.

Step3: Add ACS as a trusted relying party for ADFS

As you should know by now, ADFS is an IP for ACS, which makes ACS an RP for ADFS (if that did not make sense, then I failed horribly in this non-ending publication :)).

So back to ADFS management console and establish a relying party trust with ACS:

Step4: Configure claim rules

Now we configure which claims we want ADFS to pass to ACS. For this sample I will simply pass over Active Directory UPN and Email address as claims:

Step5: Configure Rule Groups for ACS

Recall that ACS uses Rule Groups to set how claims are passed over to relying applications (ASP.NET application), so we need to configure Rule Groups to handle the new claims to be sent from the new IP (ADFS) the same way we did to handle claims from Live ID and Google.

So back to ACS portal, and go to the Rule Group we created before for the TestACS application:

As you can see we already have the rules Live ID and Google from the previous excersice. Now click on Generate and add the claims for the new ADFS IP:

Now do not get scared! I know that when we configured Claim Rules in ADFS we only configured Email Address and UPN, so what are all these claims? These are all the claims configured for ADFS, but not necessarily all what ACS will get from ADFS. We have told ADFS to pass Email and UPN (the above claims list is a grid with paging, UPN is on another page), and that is what ACS will get.
Can you see our good old “birthplace” claim? This is the claim we configured long time ago using a SQL Attribute Store, see how it appears here; it’s all adding up, isn’t it?

Step6: Running the application

Finally we’re ready to re-run TestACS on localhost and see how the ADFS has been added as an authentication option via ACS.

First, re-run the Identity and Access wizard to get the updated metadata from ACS, this metadata now shows the new IP:

Now browse to http://localhost/TestADFS. ACS will give you the new IP as a login option:

Select “Login using ADFS” and you will find yourself back into ADFS domain to login (recall one more time that we customized this page in a previous demo and we are using forms authentication instead of integrated windows):

After you login, you will be redirected back to localhost as a logged in user.