Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
Hands-On Lab
Introduction to the AppFabric Access Control Service (September 2010 Labs Release)
Lab version: 1.0.0 Last updated: 11/16/2010
CONTENTS
OVERVIEW ................................................................................................................................................... 3
EXERCISE 1: USE ACCESS CONTROL SERVICE FOR ACCEPTING USERS FROM MULTIPLE
IDENTITY PROVIDERS ................................................................................................................................ 6 Task 1 – Creating the Initial Solution .................................................................................................... 6
Task 2 – Signing-up for Windows Azure AppFabric Labs Access Control Service and Creating the
Service Namespace ............................................................................................................................. 11
Task 3 – Configuring the Allowed Identity Providers, the Relying Party and the Signing Certificate . 14
Task 4 – Configuring a Website to Accept Tokens from Access Control Service ................................ 23
Exercise 1: Verification ........................................................................................................................ 27
Exercise 1: Summary ............................................................................................................................... 29
EXERCISE 2: USE CLAIMS FOR AUTHORIZING USERS ...................................................................... 30 Task 1 – Visualizing the Claims from the Access Control Service ....................................................... 30
Task 2 – Creating Authorization Rules ................................................................................................ 32
Task 3 – Authorizing Based on the Claims Provided by Access Control Service ................................. 35
Exercise 2: Verification ........................................................................................................................ 36
Exercise 2: Summary ............................................................................................................................... 38
EXERCISE 3: TAKE CONTROL OF THE SIGN-IN EXPERIENCE ........................................................... 38 Task 1 – Hosting a Login Page as Part of your Application ................................................................. 39
Exercise 3: Verification ........................................................................................................................ 44
Exercise 3: Summary ............................................................................................................................... 44
SUMMARY .................................................................................................................................................. 45
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:
1. Open a Windows Explorer window and browse to the lab’s Source\Setup folder.
2. 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.
3. 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:
1. Outsource Authentication to multiple Identity Providers
2. Create claims mapping rules and add claims-driven authorization to an application
3. 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
1. 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.
2. Open the WebSiteACS.sln empty solution file located inside the Source\Ex01-
AcceptUsersFromMultipleIPs\Begin folder of this Lab.
3. 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 https://localhost/WebSiteACS.
Figure 2
Add New Web Site
4. 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
5. Open Site.master file and remove the DIV with class named “loginDisplay” and the
NavigationMenu menu control.
ASP.NET
...
<div class="page">
<div class="header">
<div class="title">
<h1>
My ASP.NET Application
</h1>
</div>
<div class="loginDisplay">
<asp:LoginView ID="HeadLoginView" runat="server" EnableViewState="false">
<AnonymousTemplate>
[ <a href="~/Account/Login.aspx" ID="HeadLoginStatus"
runat="server">Log In</a> ]
</AnonymousTemplate>
<LoggedInTemplate>
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>
<div class="clear hideSkiplink">
<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>
</div>
...
The code should look like the code bellow:
ASP.NET
...
<div class="page">
<div class="header">
<div class="title">
<h1>
My ASP.NET Application
</h1>
</div>
<div class="clear hideSkiplink">
</div>
</div>
...
6. 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
http://go.microsoft.com/fwlink/?LinkId=169433
-->
<configuration>
<system.web>
<compilation debug="false" targetFramework="4.0" />
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</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.
7. 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
8. 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.
1. Navigate to https://appservices.int2.azure.com. You will be prompted for your Windows Live
ID credentials if you are not already signed in.
Figure 6
Portal Appfabricslabs
2. Click create a project link.
Note: If you already have a project, jump to step 7.
Figure 7
Clicking Create a Project
3. Type a name for your project in the Sign Up page.
Figure 8
Project Signing up
4. Click OK button to create you project.
5. In My Projects click on the project name.
Figure 9
Selecting the Project
6. 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
7. 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
1. 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
2. Review the information like the service Status, Project ID, Subscription ID, etc. Click on
Manage Access Control button.
Figure 15
Access Control Settings
3. This launches the Access Control Service Management Portal, shown in the figure below.
Figure 16
Access Control Service Management Portal
4. 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
5. 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
6. Leave the default settings and click Save.
Figure 19
The Yahoo Identity Provider configuration page
7. You can follow the same steps to add Google as an Identity Provider.
8. 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
9. 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.
10. Click on Add Relying Party Application and fill the form with the following values:
◦ Name: WebSiteACS
◦ Realm: https://localhost/WebSiteACS/
◦ Return URL: https://localhost/WebSiteACS/Default.aspx
◦ 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
11. Click on the Save button.
12. 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.
13. 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
14. 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.
15. 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.
Figure 26
Copying WS-Federation Metadata
Task 4 – Configuring a Website to Accept Tokens from Access Control Service
By now you know that ACS takes care of accepting tokens in different formats via different protocols
from a number of possible identity providers, and normalizes the incoming information in a different
token that your Web site will consume. ACS can emit different token types on various protocols. For
Web sites, the default protocol is WS-Federation. There’s no need to go in the fine details: suffice to say
that WS-Federation is a protocol that is natively understood by Windows Identity Foundation (WIF), an
extension to the .NET framework that allows you to easily outsource application authentication to
tokens sources such as the ACS itself. In particular, WIF extends Visual Studio with a wizard which can
automatically configure your application to outsource authentication without requiring you to write a
single line of code. All it needs is the address of a machine-readable description of the token source to
be used: in our case, that description is the WS-Federation Metadata address you saved at the end of
Task 3.
In this task you will use the WIF wizard to outsource authentication to ACS.
1. Back to Visual Studio and in the Solution Explorer, right-click the
https://localhost/WebSiteACS/ project and select Add STS reference….
2. When the Federation Utility window shows up, please go through the following tasks for
each step in the wizard.
a. On the Welcome page click Next to continue using the pre-populated fields.
Figure 27
Welcome
b. On the STS options page select the third radio button "Use an existing STS" option,
paste the endpoint address taken from Task 3 – Step 13 in STS WS-Federation
metadata document location field and click Next.
Figure 28
Use an Existing STS option
c. On the Security token encryption page select No encryption and click Next.
Figure 29
Security Token encryption
d. On the Offered claims page click Next.
Figure 30
Offered Claims
Note: The WS-Federation Metadata can contain descriptions of the claims that the
endpoint offers. The wizard shows those to you so that you will know what
information about incoming users you will be able to process in your application. In
this case ACS declares that it can release information about which identity provider
was actually used for authentication and a user identifier.
e. On the Summary page review the changes that will be made and click Finish.
Exercise 1: Verification
It’s time to give your newly secured Web site a spin. In order to verify that you have correctly performed
all steps in exercise one, 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. Choose an Identity Provider; you will be redirected to the identity provider’s Web site where
you will be prompted for entering your credentials. In this example we will use Windows Live
Id: choosing other options will lead to comparable experiences.
Figure 31
Choosing you Favorite Identity Provider
3. In the Windows Live ID website enter your Live ID and password.
Figure 32
Login with Windows Live ID
4. Upon successful authentication you will be redirected to ACS (observe the address bar)
which will briefly process and redirect back to your Web site.
5. The process is entirely transparent to the user, but the Web site is now configured to verify
that a valid token from the ACS is present in the call: that is the case, hence you are granted
access and the default page finally appears in the browser.
Figure 33
User Authenticated
6. Close the browser.
Exercise 1: Summary
In the first exercise you learned the ropes of using ACS for handling authentication for you. At the same
time, you learned how to use WIF for automatically configure a Web site to outsource authentication to
external entities. The process is exactly the same whether you point your application to ACS, an internal
identity provider such as ADFS2, and any product complying with WS-Federation.
Once you outsourced authentication to ACS, you can start changing settings (such as which identity
providers should be used) directly at the ACS portal without the need to touch the application code.
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 34
Copying the completed solution from the previous exercise
Note: 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 on 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 35
Security Token Visualizer Control in Toolbox
ASP.NET
<cc1:SecurityTokenVisualizerControl ID="SecurityTokenVisualizerControl1"
runat="server" />
Note: 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 inside
microsoft.identityModel section:
XML
<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 36
Security Token Visualizer Control
Note: 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). Type depending on the Identity Provider you picked in previous step.
11. Close browser.
Task 2 – Creating Authorization Rules
1. Navigate to https://appservices.int2.azure.com. You will be prompted for your Windows Live ID
credentials if you are not already signed in.
2. Click the project where you created your Service Namespace (Ex01 – Task 2 – Step 3).
3. From the Services Namespaces list, go to the Service Namespace you created on Ex01 – Task 2
– Step 3, click on Access Control link and review the information like the service status, Project
ID, Subscription ID, etc..
4. Click on Manage Access Control button to launch the Access Control Service Management
Portal.
Figure 37
Access Control Settings
5. Go to Manage - Trust Relationships section and click on Rule Groups link.
6. Click on the rule group associated with your Relying Party: “Default Rule Group for
WebSiteACS” and then click Add Rule.
7. Fill the form with the following values:
◦ If…
Claim issuer / Identity Provider: Windows Live ID
(And) Input claim type / Select type:
http://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:
http://schemas.microsoft.com/ws/2005/05/identity/claims/role
Output claim value / Enter value: Administrator
◦ Rule information
Description: Administrator claim rule
Figure 38
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:
CSS
.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:
ASP.NET
<p>
You can also find <a
href="http://go.microsoft.com/fwlink/?LinkID=152368&clcid=0x409"
title="MSDN ASP.NET Docs">documentation on ASP.NET at MSDN</a>.
</p>
<asp:Panel Visible="false" CssClass="secretContent" runat="server"
ID="SecretContent">
Secret Content (Only administrators can access this section)
</asp:Panel>
<cc1:SecurityTokenVisualizerControl ID="SecurityTokenVisualizerControl1"
runat="server"></cc1:SecurityTokenVisualizerControl>
4. Open Default.aspx.cs and add the following using statement:
(Code Snippet – Introduction to AppFabric AC Lab - Ex02 Default.aspx.cs Usings – C#)
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 - Ex02 Page_Load – C#)
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:
6. Start debugging by pressing F5. The relying party application (https://localhost/WebSiteACS/)
will redirect to the Access Control Service to authenticate.
7. Select the Windows Live ID Identity Provider and put your credentials. The usual sequence of
redirects occurs, and the user is authenticated.
8. The secret content section shows up, as the current user is in the administrator role.
Figure 39
Administrator Role Seeing Secret Content
9. Close the browser.
10. Start debugging again by pressing F5.
11. Select another Identity Provider or use a different Windows Live Id account.
12. The secret content section is no longer visible.
Figure 40
Other Role not Seeing Secret Content
13. 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.
Exercise 3: Take control of the Sign-In
experience
Using the WIF wizard for outsourcing authentication to ACS creates what is often referred to as “blanket
protection”: from that moment on, any attempt from an unauthenticated user to access any page in the
Web site triggers a redirection to the ACS. There are various scenarios in which that is not the effect you
want to achieve: for example you may want to leave some pages available also to unauthenticated
users, or you may want to take finer control on the authentication experience.
ACS makes it easy for you to craft your own authentication pages if you choose to, by providing you with
boilerplate HTML code already geared to use the endpoints in your own namespace. You can just cut
and paste the code in your app and integrate it with whatever UI elements you see fit. The last exercise
of this introductory lab shows you precisely how to do that.
Task 1 – Hosting a Login Page as Part of your Application
1. Copy the completed solution of the Ex02 to Source\Ex03-CustomSignInExperience\Begin.
Figure 41
Copying the completed solution from the previous exercise
Note: 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 3.
2. Navigate to https://appservices.int2.azure.com. You will be prompted for your Windows Live ID
credentials if you are not already signed in.
3. Click the project where you created your Service Namespace (Ex01 – Task 2 – Step 3).
4. From the Services Namespaces list, go to the Service Namespace created on Ex01 – Task 2 –
Step 3 and click on Access Control link.
5. Click on Manage… button to launch the Access Control Service Management Portal.
6. Go to Develop – Application Code section and click on Application Integration link.
Figure 42
Application Integration
7. Click on Login Pages and select your relying party application (WebSiteACS).
Figure 43
Login Page Integration
8. Go to Option 2: Host the login page as part of your application and click on Download Example
Login Page.
9. Save the HTML file in %SystemDrive%\inetpub\wwwroot\WebSiteACS \WebSiteACS folder
of this Lab.
10. 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.
11. Open the WebSiteACS.sln solution file (copied in step 1) located inside the Source\ Ex03-
EasyAuthorizationWithACS\Begin folder of this Lab.
12. Go to the Solution Explorer and right-click https://localhost/WebSiteACS/ and Add Existing
Item, select the HTML file that you downloaded in step 7 (WebSiteACSLoginPageCode.html).
13. Open the HTML file that you downloaded in step 9 (WebSiteACSLoginPageCode.html).
14. Go to the DIV tag with ID=“Banner” and replace the text “Sign in to WebSiteACS” with “My
custom login page for WebSiteACS”.
HTML
<div id="Main" style="display:none">
<div id="Banner" class="Banner"><b>My custom login page for
WebSiteACS</b></div>
15. Go to <style> section and update the following CSS classes:
◦ div.SignInContent
width: 1020px;
height: 170px;
◦ div.Banner
width: 1020px;
background: none repeat scroll 0 0 #4B6C9E;
color: #F9F9F9;
◦ div.LeftArea
width: 960px;
The CSS classes should look like:
CSS
div.SignInContent
{
text-align: center;
margin-left: auto;
margin-right: auto;
border: solid 1px #BBBBBB;
position: relative;
width: 1020px;
height: 170px;
}
div.Banner
{
padding-top:10px;
padding-bottom:10px;
text-align: center;
margin-left: auto;
margin-right: auto;
background: none repeat scroll 0 0 #4B6C9E;
color: #F9F9F9;
border-top: solid 1px #BBBBBB;
border-left: solid 1px #BBBBBB;
border-right: solid 1px #BBBBBB;
width: 1020px;
}
div.LeftArea
{
padding:15px 15px;
width: 960px;
height: 100%;
position: absolute;
top: 0px;
left: 0px;
}
16. Go to the Solution Explorer and open Web.config file.
17. Add the following section inside <configurations> node:
(Code Snippet – Introduction to AppFabric AC Lab - Ex03 Location - XML)
XML
<configuration>
...
<location path="WebSiteACSLoginPageCode.html">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
18. Go to microsoft.identityModel/service/federatedAuthentication/wsFederation section and
update the issuer attribute with
“https://localhost/WebSiteACS/WebSiteACSLoginPageCode.html”.
The web.config should look look the code bellow.
XML
<microsoft.identityModel>
<service saveBootstrapTokens="true">
...
<federatedAuthentication>
<wsFederation passiveRedirectEnabled="true"
issuer="https://localhost/WebSiteACS/WebSiteACSLoginPageCode.html"
realm="https://localhost/WebSiteACS/" requireHttps="true"/>
<cookieHandler requireSsl="true"/>
</federatedAuthentication>
19. Save and close Web.config file.
Exercise 3: Verification
In order to verify that you have correctly performed all steps in exercise three, 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. Choose your favorite Identity Provider (i.e.: Live ID) from your custom login page and put your
credentials.
Figure 44
Custom Login Page
3. Access Control sent to our application the claims it was expecting and we are now
authenticated.
4. Close the browser.
Exercise 3: Summary
The last exercise of the lab showed you how you can seamlessly integrate ACS authentication elements
in your Web site, demonstrating that you can take advantage of ACS’ advanced capabilities without
having to break the experience and style you want for your web applications.
Summary
By completing this Hands-On Lab you have learned 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 authorization decisions
Customize the default authentication user experience provided by ACS
The notion of outsourcing authentication to an external entity, instead of taking care of the details
yourself, is an extremely powerful one. Windows Identity Foundation makes it easy to configure .NET
applications to trust their authentication needs to external authorities.
The AppFabric Access Control Service is a great service to outsource authentication to, as it can easily
abstract away the complexity of dealing with mutiple identity providers such as Windows Live Id,
Facebook, Google, Yahoo! and even business providers such as directories enhanced by Active Directory
Federation Services or equivalent. Furthermore, ACS offers powerful tools for manipulating the way in
which the user’s identity is processed before reaching your application.
This introductory lab barely begun to explore the capabilities of ACS. Here we focused on Web sites, but
ACS can handle just as well SOAP and REST web services; we used the portal, but ACS offers a rich
management API which can be used to automate provisioning tasks; we focused on Web identities, but
ACS offers comprehensive support for business identity providers and processing capabilites for the
richer claims set they generate. If you are interested in knowing more about those capabilites, please
refer to the upcoming intermerdiate and advanced hands-on labs.