Lab - DOC

Document Sample
Lab - DOC Powered By Docstoc
					Hands-On Lab
Introduction to the AppFabric Access Control
Service V2
Lab version: 1.0.0

Last updated: 5/14/2011
CONTENTS

OVERVIEW ........................................................................................................................................3

EX ERCISE 1: US E ACCESS CONTROL S ERVICE FOR ACCEPTING US ERS FROM MULTIPLE
IDENTITY PROVI DERS ......................................................................................................................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 .13
      Task 4 – Configuring a Website to Accept Tokens from Access Control Service ..............................23
      Exercise 1: Verification...............................................................................................................28
   Exercise 1: Summary......................................................................................................................30

EX ERCISE 2: US E CLAIMS FOR AUTHORIZI NG USERS .................................................................31
      Task 1 – Visualizing the Claims from the Access Control Service ...................................................31
      Task 2 – Creating Authorization Rules .........................................................................................34
      Task 3 – Authorizing Based on the Claims Provided by Access Control Service ...............................37
      Exercise 2: Verification...............................................................................................................38
   Exercise 2: Summary......................................................................................................................40

EX ERCISE 3: TAKE CONTROL OF THE SIGN-IN EXP ERI ENCE ......................................................40
      Task 1 – Hosting a Login Page as Part of your Application ............................................................41
      Exercise 3: Verification...............................................................................................................47
   Exercise 3: Summary......................................................................................................................48

SUMMARY ......................................................................................................................................48
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


AppFabric Access Control Service (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 authorization 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® Internet Information Services (IIS) 7.0
       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 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. To do this, right-click the WebSiteACS solution and select Add |
       New Web Site, select Visual C# in Installed Templates section and then click ASP.NET Web Site.
       Change the Web location field to use HTTP and set the value with
       https://localhost/WebSiteACS and click OK.
   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 that it works as expected. If an alert about “Debugging
   Not Enabled” appears, select “Modify the Web.config file to enable debugging” and click 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. 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 http://portal.appfabriclabs.com. You will be prompted for your Windows Live ID
       credentials if you are not already signed in.
    2. Click on the Service Bus, Access Control & Caching button on the lower left corner. You will land
       on the page below




        Figure 6
        Portal Appfabricslabs


    3. Select the Access Control item on the Navigation menu
    4. Now you will add a new Access Control Service Namespace. An Access Control Service
       Namespace is the unique component of the addresses at which all your endpoints on the Access
       Control Service will be available. To do this, click the New Namespace button on the top left
       corner.
   Figure 7
   Add Namespace


5. The portal displays a dialog. Type in a name for your 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 8
   Creating New Access Control Service Namespace


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




   Figure 9
   Activating Service Namespace
        Figure 10
        Active Service Namespace



Task 3 – Configuring the Allowed Identity Providers, the Relying Party and the Signing Certificate
    1. With the Namespace selected, click the Access Control Service –Manage button on the top
       toolbar. Make sure that appservices.azure.com is allowed to show popups in your browser.




        Figure 11
        Click the Access ControlService – Manage button


    2. This launches (in another browser window or tab) the Access Control Service Management
       Portal, shown in the figure below.
   Figure 12
   Access Control Service Management Portal


3. The Management Portal, and specifically the left-hand navigation menu, 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. Click the Identity Providers
   link in the Trust Relationships section of the menu. The main area of the management portal
   will display a page which helps you to manage the identity providers from where your
   application users will come from.
   Figure 13
   Identity Providers


4. Click the Add link above the Identity Providers table, choose the identity providers you want to
   add in your Access Control Service namespace and click Next. Windows Live Id is there by
   default. For this exercise please pick Google and Yahoo! as well.
   Figure 14
   Adding Identity Provider


5. Leave the default settings and click Save.
   Figure 15
   The Yahoo Identity Provider configuration page


6. You can follow the same steps to add Google as an Identity Provider. You’ll end up with the
   Identity Providers list shown below.




   Figure 16
   Identity Providers configured


7. Click the Relying Party Applications link on the navigation menu 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.
   Figure 17
   Identity Providers configured


8. Click the Add link on top of the Relying Party Applications table and fill the form with the
   following values:
       ◦    Name: WebSiteACS

       ◦    Mode: Enter settings manually
       ◦    Realm: https://localhost/WebSiteACS/

       ◦    Return URL: https://localhost/WebSiteACS/Default.aspx
       ◦    Error URL: leave the field empty
       ◦    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 (standard)
Figure 18
Add Relying Party Application
9. Click the Save button.
10. In the Trust Relationships section of the navigation menu, click the Rule Groups link in order to
    select the default rule group for your application.




   Figure 19
   The current rule groups list contains just the default rule group




   Figure 20
   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.



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




   Figure 21
   Generating Rules
   Figure 22
   Default Rules Generated


12. Under the Development section of the navigation menu, click the Application Integration link.
    Here there are various URIs that come in handy when configuring your application to take
    advantage of ACS.
13. 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 ne xt step.
        Figure 23
        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 24
   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 15 in STS WS-Federation
   metadata document location field and click Next.
    Figure 25
    Use an Existing STS option


c. On the STS signing certificate chain validation error page select Disable certificate
   chain validation and click Next.
   Figure 26
   Disable certificate chain validation option


d. On the Security token encryption page select No encryption and click Next.
   Figure 27
   Security Token encryption


e. On the Offered claims page click Next.
                 Figure 28
                 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.



            f.   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 29
   Choosing you Favorite Identity Provider


3. In the Windows Live ID website enter your Live ID and password.




   Figure 30
   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 31
        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 32
   Offered Claims



     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 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 33
   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 34
   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). Depending on the Identity Provider you picked in previous step, the
    value of the identityprovider claim might vary.
       Figure 35
       Copying the nameidentifier claim


    11. Close the browser.

Task 2 – Creating Authorization Rules
    1. Navigate to http://portal.appfabriclabs.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 36
       Rule Groups
5. Select the Default Rule Group for Cache.
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:
                      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/2008/06/identity/claims/role
                     Output claim value / Enter value: Administrator

       ◦   Rule information
                     Description: Administrator claim rule
   Figure 37
   Adding Rule


8. Click Save button.

    Note: 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&amp;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" />
    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:
    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 38
   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 39
        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.


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 40
        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 http://portal.appfabriclabs.com. You will be prompted for your Windows Live ID
   credentials if you are not already signed in.
3. Select the Access Control in the navigation pane and click the Service Namespace you created.
   Click the Service Namespace you created in the first exericse. Click the Access Control Service
   button located in the ribbon bar to manage your service.
4. Go to Development section and click the Application Integration link.




   Figure 41
   Application Integration


5. Select your relying part application (WebSiteACS).
   Figure 42
   Login Page Integration


6. In the Option 2: Host the login page as part of your application section, click Download
   Example Login Page.
   Figure 43
   Login Page Integration


7. Save the HTML file in %SystemDrive%\inetpub\wwwroot\WebSiteACS.

    Note: If you don’t have permissions to save the file, proceed to download it into My
    Documents folder instead, and then move it to
    %SystemDrive%\inetpub\wwwroot\WebSiteACS. If Destination Folder Access Denied
    prompt is shown, click the Continue button.
8. 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.
9. Open the WebSiteACS.sln solution file (copied in step 1) located inside the Source\Ex03-
   EasyAuthorizationWithACS\Begin folder of this Lab.
10. 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)
    and click Add.
11. Double-click the HTML file that you downloaded in step 7 (WebSiteACSLoginPageCode.html) to
    open it in Microsoft Visual Studio 2010.
12. 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>



13. 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;
   }



14. Go to the Solution Explorer and open Web.config file.
15. Add the following section inside <configuration> node:
    (Code Snippet – Introduction to AppFabric AC Lab - Ex03 Location - XML)
   XML
   <configuration>
      <configSections>
      ...
      </configSections>
     <location path="WebSiteACSLoginPageCode.html">
       <system.web>
         <authorization>
           <allow users="*"/>
         </authorization>
       </system.web>
          </location>
          <location path="FederationMetadata">
          …
          </location>



    16. Go to microsoft.identityModel/service/federatedAuthentication/wsFederation section and
        update the issuer attribute with
        “https://localhost/WebSiteACS/WebSiteACSLoginPageCode.html”.
           The web.config should look like 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>



    17. 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.

				
DOCUMENT INFO