Introduction to the Appfabric Access Control Service (September 2010 Labs Release)

Hands-On Lab

Introduction to the AppFabric Access Control Service (September 2010 Labs Release)

Lab version: 1.0.0

Last updated: 5/9/2019

Contents

Overview

Exercise 1: Use Access Control Service for Accepting Users from Multiple Identity Providers

Task 1 – Creating the Initial Solution

Task 2 – Signing-up for Windows Azure AppFabric Labs Access Control Service and Creating the Service Namespace

Task 3 – Configuring the Allowed Identity Providers, the Relying Party and the Signing Certificate

Task 4 – Configuring a Website to Accept Tokens from Access Control Service

Exercise 1: Verification

Exercise 1: Summary

Exercise 2: Use Claims for Authorizing Users

Task 1 – Visualizing the Claims from the Access Control Service

Task 2 – Creating Authorization Rules

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

Exercise 2: Verification

Exercise 2: Summary

Exercise 3: Take control of the Sign-In experience

Task 1 – Hosting a Login Page as Part of your Application

Exercise 3: Verification

Exercise 3: Summary

Summary

Overview

Connecting one application to its users is one of the most basic requirements of any solution, whether deployed on-premises, in the cloud or on both.

The emergence of standards is helping to break the silos which traditionally isolate accounts stored by different web sites and business entities, however offering application access to users coming from multiple sources can still be a daunting task. As of today, if you want to open your application to users coming from Facebook, Live ID, Google and business directories the brute-force approach demands you to lean and implement four different authentication protocols. Changes in today’s world happen fast and often, forcing you to keep updating your protocol implementations to chase the latest evolutions of the authentication mechanisms of the user repositories. All this can require a disproportionate amount of energy, leaving you with fewer resources to focus on your business.

Figure 1

A functional view of the Access Control Service

Enter the AppFabric Access Control Service (ACS). ACS offers you a way to outsource authentication and decouple your application from all the complexity of maintaining a direct relationship with all the identity providers you want to tap from. ACS takes care of engaging every identity provider with its own authentication protocol, normalizing the authentication results in a protocol supported by the .NET framework tooling (namely the Windows Identity Foundation technology, or WIF) regardless of from where the user is coming from. WIF allows you in just few clicks to elect the ACS as the authentication manager for your application; from that moment on ACS takes care of everything, including providing a UI for the user to choose among all the recognized identity providers.

Furthermore, ACS offers you greater control over which user attributes should be assigned for every authentication event; again in synergy with WIF, those attributes (called claims) can be easily accessed for taking authorization decisions without forcing the developer do understand or even be aware of the lower level mechanisms that the authentication protocols entail.

In this introductory hands-on lab you will learn how to take advantage of the ACS for outsourcing authentication, managing multiple identity sources, performing some basic authorization tasks and take control of the authentication experience. You will discover that it takes less to do it than to describe it!

Objectives

In this Hands-On Lab, you will learn how to:

Configure your application to outsource authentication to ACS
Configure ACS to include the identity providers you want to leverage
Configure ACS to process incoming identities and add new claims
Modify your application to consume claims from ACS and drive authroization decisions
Customize the default authentication user experience provided by ACS

System Requirements

You must have the following items to complete this lab:

Microsoft® Windows® Vista SP2 (32-bits or 64-bits) , Microsoft® Windows Server 2008 SP2 (32-bits or 64-bits), Microsoft® Windows Server 2008 R2, or Microsoft® Windows® 7 RTM (32-bits or 64-bits)
Microsoft® .NET Framework 4
Microsoft® Visual Studio 2010
Microsoft® Windows Identity Foundation Runtime
Microsoft® Windows Identity Foundation SDK
Microsoft® Windows PowerShell

Setup

For convenience, much of the code used in this hands-on lab is available as Visual Studio code snippets. To check the prerequisites of the lab and install the code snippets:

Open a Windows Explorer window and browse to the lab’s Source\Setup folder.
Double-click the Dependencies.dep file in this folder to launch the Dependency Checker tool and install any missing prerequisites and the Visual Studio code snippets.
If the User Account Control dialog is shown, confirm the action to proceed.

Note: This process may require elevation. The .dep extension is associated with the Dependency Checker tool during its installation. For additional information about the setup procedure and how to install the Dependency Checker tool, refer to the Setup.docx document in the Assets folder of the training kit.

Note: If you have never run Visual Studio before on the machine, please make sure to do so before running the setup of this lab.

Note: When you first start Visual Studio, you must select one of the predefined settings collections. Every predefined collection is designed to match a particular development style and determines window layouts, editor behavior, IntelliSense code snippets, and dialog box options. The procedures in this lab describe the actions necessary to accomplish a given task in Visual Studio when using the General Development Settings collection. If you choose a different settings collection for your development environment, there may be differences in these procedures that you need to take into account.

Using the Code Snippets

Throughout the lab document, you will be instructed to insert code blocks. For your convenience, most of that code is provided as Visual Studio Code Snippets, which you can use from within Visual Studio 2010 to avoid having to add it manually.

If you are not familiar with the Visual Studio Code Snippets, and want to learn how to use them, you can refer to the Setup.docx document in the Assets folder of the training kit, which contains a section describing how to use them.

Exercises

The following exercises make up this Hands-On Lab:

Outsource Authentication to multiple Identity Providers
Create claims mapping rules and add claims-driven authorization to an application
Take control of the Sign-In experience

Note: Each exercise is accompanied by a starting solution. These solutions are missing some code sections that are completed through each exercise and therefore will not necessarily work if running them directly.

Inside each exercise you will also find an end folder where you find the resulting solution you should obtain after completing the exercises. You can use this solution as a guide if you need additional help working through the exercises.

Estimated time to complete this lab: 45 minutes

Exercise 1: Use Access Control Service for Accepting Users from Multiple Identity Providers

In the first exercise you will familiarize with ACS’ basic settings and terminology. Your task is to secure access to a newly created ASP.NET Web site. The Web site will accept users from Google, Yahoo! and Windows Live Id. As you will see in a minute, ACS makes it real easy.

Task 1 – Creating the Initial Solution

Open Microsoft Visual Studio 2010 with administrator privileges. From Start | All Programs | Microsoft Visual Studio 2010, right-click on Microsoft Visual Studio 2010 and select Run as administrator.
Open the WebSiteACS.sln empty solution file located inside the Source\Ex01-AcceptUsersFromMultipleIPs\Begin folder of this Lab.
Create a new empty website. From File | Add | New Web Site…, select Visual C# in Installed Templates section and then click on ASP.NET Web Site. Change the Web location field to use HTTP and set the value with .

Figure 2

Add New Web Site

Go to Solution Explorer and delete the following folders from the web site:

◦ Account

◦ Scripts

And the following files:

◦ About.aspx

◦ Global.asax

Figure 3

Solution Explorer

Open Site.master file and remove the DIV with class named “loginDisplay” and the NavigationMenu menu control.

ASP.NET

...

<h1>

My ASP.NET Application

</h1>

</div>

<asp:LoginView ID="HeadLoginView" runat="server" EnableViewState="false">

[ <a href="~/Account/Login.aspx" ID="HeadLoginStatus" runat="server">Log In</a> ]

</AnonymousTemplate>

Welcome <span class="bold"<asp:LoginName ID="HeadLoginName" runat="server" /</span>!

[ <asp:LoginStatus ID="HeadLoginStatus" runat="server" LogoutAction="Redirect" LogoutText="Log Out" LogoutPageUrl="~/"/> ]

</LoggedInTemplate>

</asp:LoginView>

</div>

<asp:Menu ID="NavigationMenu" runat="server" CssClass="menu" EnableViewState="false" IncludeStyleBlock="false" Orientation="Horizontal">

<Items>

<asp:MenuItem NavigateUrl="~/Default.aspx" Text="Home"/>

<asp:MenuItem NavigateUrl="~/About.aspx" Text="About"/>

</Items>

</asp:Menu>

</div>

...

The code should look like the code bellow:

ASP.NET

...

<h1>

My ASP.NET Application

</h1>

</div>

</div>

...

Open Web.config file and remove the following sections:

◦ connectionStrings

◦ system.web/authentication

◦ system.web/membership

◦ system.web/profile

◦ system.web/roleManager

The Web.config should look like the code bellow.

XML

<?xml version="1.0"?>

<!--

For more information on how to configure your ASP.NET application, please visit

-->

<system.web>

</system.web>

<system.webServer>

</system.webServer>

</configuration>

Note: all this cleanup is not strictly necessary, but it helps to keep things simple and highlight the code that will be required for integrating with ACS.

Press F5 to run the Web site and ensure us that it works as expected. If an alert about “Debugging Not Enabled” appears, select “Modify the Web.config file to enable debugging” and click on OK.

Figure 4

“Debugging Not Enabled” Alert

Figure 5

Running Application

The Web site is, as expected, without any access control mechanism. You can close the browser.

Task 2 – Signing-up for Windows Azure AppFabric Labs Access Control Service and Creating the Service Namespace

You are now going to subscribe to ACS. As of today ACS is offered as a preview, in a lab environment, and is available free of charge. As the service moves to production this may change, but for the time being you can freely experiment.

Navigate to You will be prompted for your Windows Live ID credentials if you are not already signed in.

Figure 6

Portal Appfabricslabs

Click create a project link.

Note: If you already have a project, jump to step 7.

Figure 7

Clicking Create a Project

Type a name for your project in the Sign Up page.

Figure 8

Project Signing up

Click OK button to create you project.
In My Projects click on the project name.

Figure 9

Selecting the Project

Now you will add a new Service Namespace to your project. A Service Namespace represents a namespace for the Service Bus and the AppFabric Access Control: in other words, it is the unique component of the addresses at which all your endpoints on the AppFabric service will be available. To do this, click the Add Service Namespace link.

Figure 10

Add Service Namespace

Type in a name for your Service Namespace and click the Create button. Make sure to validate the availability of the name first. Service names must be globally unique as they are in the cloud and accessible by whomever you decide to grant access.

Figure 11

Creating New Service Namespace

Please be patient while your service is activated. It can take a few minutes while all the necessary resources are provisioned.

Figure 12

Activating Service Namespace

You may have to refresh the browser to show the service is active.

Figure 13

Active Service Namespace

Task 3 – Configuring the Allowed Identity Providers, the Relying Party and the Signing Certificate

From the Services Namespaces list, go to the Service Namespace just created and click on Access Control link.

Figure 14

Click on Access Control link

Review the information like the service Status, Project ID, Subscription ID, etc. Click on Manage Access Control button.

Figure 15

Access Control Settings

This launches the Access Control Service Management Portal, shown in the figure below.

Figure 16

Access Control Service Management Portal

The Management Portal offers you a global view of all the settings you can change in ACS. In the typical application development flow, such as the one you are creating in this exercise, there is a natural order you can follow for providing ACS with the information it needs to set up authentication for you. Go to Manage - Trust Relationships section and click on Identity Providers link. You will land on a page which helps you to manage the identity providers from where your application users will come from.

Figure 17

Identity Providers

Click on Add Identity Provider link and choose the identity providers you want to add in your Access Control Service namespace. Windows Live Id is there by default. For this exercise please pick Google and Yahoo! as well.

Figure 18

Adding Identity Provider

Leave the default settings and click Save.

Figure 19

The Yahoo Identity Provider configuration page

You can follow the same steps to add Google as an Identity Provider.
Click on Return to Access Control Services button on the lower right corner to return to the Access Control Service Management Portal home.

Figure 20

Identity Providers configured

Go to Manage - Trust Relationships section and click on Relying Party Applications link (see figure 16) in order to register your Web site with ACS. ”Relying Party” is identity speak for application, the entity which consumes identities, whereas as you already guessed “Identity Provider” indicates one entity which stores identities and is capable of authenticating users.
Click on Add Relying Party Application and fill the form with the following values:

◦ Name: WebSiteACS

◦ Realm:

◦ Return URL:

◦ Token format: SAML 1.1

◦ Token encryption policy: None

◦ Token lifetime (secs): 600

◦ Identity Providers: Google, Windows Live ID, Yahoo!

◦ Rule groups: Create New Rule Group

◦ Token signing: Use service namespace certificate (typical)

Figure 21

Add Relying Party Application

Click on the Save button.
Click on Return to Access Control Services button to Access Control Service Management Portal home, go to Manage - Trust Relationships section and click on Rule Groups link in order to select the default rule group for your application.

Figure 22

An example of how ACS receives a token as proof of authentication (in this case from Google, but it can come from any recognized IP) and can emit for the application a token containing the original claims

Note: When a user successfully authenticates with one identity provider, ACS receives from that identity provider an artifact (called “security token”) which represents the proof that authentication took place. You don’t need to know the details of how a security token looks like: the only information relevant at the moment is that the token contains information about the authenticated user, the so-called claims, which help ACS to establish who the current user is.

ACS can process the incoming claims in various ways: you will see a simple example of that in the next exercise. In the current exercise we will configure ACS to enforce its default behavior, that is to say making sure that your application receives the claims as they came from the original identity providers. How does it do that? The ACS itself emits a token that your application is configured to consume (as you will see in just few steps). All it needs to do is to copy the incoming claims as is into the outgoing token.

Click on Default Rule Group for WebSiteACS and click on Generate Rules button. Then select the identity providers you want to automatically generate rules for, based on available claim types and click Save. Different identity providers offer different claims: ACS knows that and generates the default rules accordingly.

Figure 23

Generating Rules

Figure 24

Rule Generation Options

Figure 25

Default Rules Generated

Click on Return to Access Control Services button to Access Control Service Management Portal home, go to Develop – Application Code section and click on Application Integration link. Here there are various URIs that come in handy when configuring your application to take advantage of ACS.
Go to Endpoint Reference section and copy the value for WS-Federation Metadata. You will discover what that is and what it is used for right at the beginning of the next step.