Tutorial–ASP.Net MVC 3, claim-based architecture and Windows Azure ACS (4)

(Previous parts: part 1, part 2, part 3)

In this part we’ll implement the Azure ACS path in our architecture. We’ll temporarily disable the Local STS path. We’ll combine the two paths in part 5 of this post. In this part, our STS project takes over FP responsibility from the MVC 3 app and itself will morph into a combination of STS and FP in part 5. Of course we could have created separate services for the two roles, but for simplicity we’ll keep them together in the STS project.

Part I: Configure trust relationship on ACS

Here I assume you’ve got your Windows Azure account activated, have subscribed to ACS, and have created your ACS namespace. The steps in this section covers necessary settings to be performed on Windows Azure Portal –> Access Control Service page.

1. Click on “Identity providers” link and add Windows Live ID, Google, and Yahoo! as IDPs. Accept all default settings.
2. Click on “Relying party applications” link. Then click “Add” to add our STS project (NOT our web project) as RP.
3. Enter the following settings (accept default settings for unmentioned fields) and save:
   • Name: [name of your choice]
   • Realm: http://localhost:4011/MyWebApp_STS
   • Return URL: http://localhost:4011/MyWebApp_STS/Default.aspx
   • Error URL: (leave empty)
   • Token format: SAML 1.1
   • Token encryption policy: None
   • Token lifetime: 600
4. Click on “Rule groups” and click the auto-generated role group. Click on “Generate” button to generate default set of rules. Note in this set of rules Windows Live ID doesn’t output “name” claim. This will cause problems in our STS, but we’ll leave it for now and come back later to fix.
5. At last, click on “Application integration” link and note done “WS-Federation metadata” URL.

Part II: Establish federation with ACS

1. Right-click on the STS project and select “Add STS Reference…”
2. Same as before, ignore the https warning and continue with the wizard.
3. Select “Use an existing STS” option, and paste in your ACS WS-Federation metadata URL, which you got from the last step in part I:
4. Select “Disable certificate chain validation” and click “Next”:
5. Select “No encryption” and click “Next”:
6. Accept all default settings and finish the wizard.

Part III: Test run

1. Compile and run. You should see the default page as before.
2. Type in http://localhost:81/Portal in address bar.
3. This time you’ll see an IDP selection page instead:
4. Pick either Google or Yahoo! (remember Windows Live ID is not working yet – we’ll fix next) and logon using your credentials.
5. And you’ll be granted access to the portal page with your user name displayed:

Part IV: Fix Windows Live ID logon

We couldn’t use Windows Live ID because it didn’t generate the name claim (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name). Fortunately, ACS, as a FP by itself, allows us to define claim transformation rules. We’ll use a transform rule to translate the nameidentifier claim (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier) into the name claim:

1. On Windows Azure portal, open the rule group we’ve reviewed before and click “Add” to add a new rule.
2. Use the following settings for the rule and save it:
   • Claim issuer: Identity Provider - Windows Live ID
   • Input claim type: Select type – http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
   • Input claim value: Any
   • Out claim type: Select type – http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
   • Output claim value: Pass through input claim value
3. Now re-launch the solution and you should be able to logon with Windows Live ID now – the user name is a weird-looking string because it’s a direct copy of nameidentifer claim.

Part V: Switch between local STS and ACS

Switching back and forth between local STS and ACS only requires a couple of configuration change. To revert back to the scenario in part 3 of this post series, just modify the web.config file or the STS project and change passiveRedirectEnabled to false, and system.web authentication mode to Forms.

What’s next

In the next post we’ll finally complete the original design. Users will have choice to logon using a local id, or using any ids supported by trusted identity providers.