Exercise 2: Use Claims for Authorizing Users

The first exercise focused on granting access to users from multiple identity providers, but didn’t do much with the incoming claims. In this exercise you will get a taste of what you can do with ACS for enriching the information you have about users for driving authorization decisions, without having to store any permanent information in the application itself.

Your task is simple: you will assign a role to a specific user, and you will authorize certain actions on the Web site according to it.

Task 1 – Visualizing the Claims from the Access Control Service

WIF does an excellent job at hiding the details of the underlying protocol negotiations. Before creating rules for processing claims, it is useful to take a peek behind the curtain and see exactly what the application receives from ACS. To that purpose, you will use a debug component which is capable of visualizing the incoming tokens directly on the Web site pages.

  1. Copy the completed solution of the Ex01 to Source\Ex02-EasyAuthorizationWithACS\Begin.

    Figure 31

    Offered Claims

    Although exercises in our hands-on labs are normally independent from each other, in this case there are shared settings in the cloud that would not make much sense to duplicate here. If you didn’t go through the first exercise and you didn’t set up the ACS account, namespaces and similar you will need to follow the instructions of tasks 2, 3 and 4 from exercise 1 before going further with exercise 2.

  2. Open Microsoft Visual Studio 2010 with administrator privileges. From Start | All Programs | Microsoft Visual Studio 2010, right-click Microsoft Visual Studio 2010 and select Run as administrator.
  3. Open the WebSiteACS.sln solution file (copied in step 1) located inside the Source\Ex02-EasyAuthorizationWithACS\Begin folder of this Lab.
  4. Go to the Solution Explorer and open Default.aspx file.
  5. From the Visual Studio Toolbox drag and drop a Security Token Visualizer Control at the bottom of the main content control:

    Figure 32

    Security Token Visualizer Control in Toolbox


    <cc1:SecurityTokenVisualizerControl ID="SecurityTokenVisualizerControl1" runat="server" />

    In case no code appears when you drop the control on the page, please close Visual Studio, run the Configuration Wizard again and restart Visual Studio.

  6. Open Web.config file and add the saveBootstrapTokens attribute to the service element inside microsoft.identityModel section:


    <microsoft.identityModel> <service saveBootstrapTokens="true"> <audienceUris>

  7. Start debugging by pressing F5. The application will go through the same authentication routine enabled by the steps in exercise 1.
  8. Choose Windows Live ID and authenticate as shown in the first exercise.
  9. Expand the Security Token Visualizer Control.

    Figure 33

    Security Token Visualizer Control

    The Security Token Visualizer Control is showing the content of the security token issued by ACS. For the purposes of this exercise you can ignore most of that: the only thing that needs your attention is the first table on top, the one labeled Issued Identity. That table contains the claims carried by the incoming token, as established by the default rules. In the case of Windows Live ID, those claims are identity provider (which indicates from which identity provider the ACS received the authentication token from) and nameidentifier (which provides an identified which is unique for that user in the context of the ACS namespace).

    The nameidentifier value is very important, as we can use it for telling one user from another. More specifically, the nameidentifier value can be used as the input claim for transformation rules which will assign new claims to specific users.

  10. Go to Issued Identity section and save the value of the nameidentifier claim in Notepad (Claim type and Claims value). Depending on the Identity Provider you picked in previous step, the value of the identityprovider claim might vary.

    Figure 34

    Copying the nameidentifier claim

  11. Close the browser.

Task 2 – Creating Authorization Rules

  1. Navigate to https://windows.azure.com/. You will be prompted for your Windows Live ID credentials if you are not already signed in.
  2. Select the Access Control in the navigation pane and click the Service Namespace you have created in the first exercise.
  3. Click the Access Control Service button located in the ribbon bar to manage your service.
  4. In the Trust Relationships section of the navigation menu, click the Rule Groups link.

    Figure 35

    Rule Groups

  5. Select the Default Rule Group for WebSiteACS.
  6. Click the Add link under the Rules table to configure a new rule.
  7. Fill the form with the following values:

    • If…
      • Claim issuer / Identity Provider: Windows Live ID
      • (And) Input claim type / Select type: https://schemas.microsoft.com/ws/2005/05/identity/claims/nameidentifier
      • (And) Input claim value / Enter value: Claim value taken from Task 1 – Step 10
    • Then…
      • Output claim type / Enter type: https://schemas.microsoft.com/ws/2008/06/identity/claims/role
      • Output claim value / Enter value: Administrator
    • Rule information
      • Description: Administrator claim rule

    Figure 36

    Adding Rule

  8. Click Save button.
    The rule you just entered assigns the role claim “administrator” to the Windows Live ID account you used for signing in the application earlier in the exercise. The specific claim type used for indicating role is automatically mapped by WIF into traditional Windows roles, as you will see in the next task.

    Note that you could create analogous rules for other identity providers as well. In this lab we picked Windows Live ID because you are already required to have an account with it for signing up with ACS, but there’s really nothing special about ACS and Windows Live ID: you can obtain the exact same result with any other identity provider, as long as a unique user identifier claim is available.

Task 3 – Authorizing Based on the Claims Provided by Access Control Service

Now that the new rule has been added, the Web site will receive a token with the extra role claim in it. Let’s leverage the role information for granting or denying access to some Web site function, such as access to special areas of one page.

  1. Back to Visual Studio and on the Solution Explorer open Styles\Site.css file.
  2. Add the following CSS class:


    .secretContent { border-style: solid; background-color: Red; padding: 5px; color: White; }

  3. Open Default.aspx and add the following ASP.NET Panel control at the bottom of the main content control:


    FakePre-02cdceb785aa4c859d687175696257c8-61c1da019c0d4b43b8927d34ee2fb959FakePre-b2afa37c1ad84defa2ebe97ac8493d62-200f19cce67042a4b6dc42a6d42f17ebFakePre-9b6269c6749a428e9f1bd888dfa3c97b-57e660cf73bf48188c74a20b7405d15b<asp:Panel Visible="false" CssClass="secretContent" runat="server" ID="SecretContent"> Secret Content (Only administrators can access this section) </asp:Panel>FakePre-5af24bc58c064754b978de8c570f6b9e-0f4e1d1151e44f5eb158d34852cc1e90FakePre-988abd3170cb49ef926b2e5346548ebe-c6e818995f6d4f3d9181a940b8c3b681

  4. Open Default.aspx.cs and add the following using statement:

    (Code Snippet – Introduction to AppFabric AC Lab - Ex02Default.aspx.cs Usings C#)


    using System.Threading;

  5. Now that we added some extra UI elements, let’s make sure that only administrators will be able to see it. Add the following validation inside Page_Load method:

    (Code Snippet – Introduction to AppFabric AC Lab - Ex02Page_Load C#)


    if (Thread.CurrentPrincipal.IsInRole("Administrator")) { this.SecretContent.Visible = true; }

Exercise 2: Verification

In order to verify that you have correctly performed all steps in exercise two, proceed as follows:

  1. Start debugging by pressing F5. The relying party application (https://localhost/WebSiteACS/) will redirect to the Access Control Service to authenticate.
  2. Select the Windows Live ID Identity Provider and put your credentials. The usual sequence of redirects occurs, and the user is authenticated.
  3. The secret content section shows up, as the current user is in the administrator role.

    Figure 37

    Administrator Role Seeing Secret Content

  4. Close the browser.
  5. Start debugging again by pressing F5.
  6. Select another Identity Provider or use a different Windows Live ID account.
  7. The secret content section is no longer visible.

    Figure 38

    Other Role not Seeing Secret Content

  8. Close the browser.

Exercise 2: Summary

In the second exercise you learned how to manipulate the claims issued by ACS for your application, and how to use that information for driving authorization decisions. The exercise was very simple, assigning a role to a specific user; however it shows the power of the claims transformation rules approach and can be easily extended to more sophisticated cases.