Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com 

March, 2011

  • Alik Levin's

    Windows Azure Web Role ASP.NET Application Federated Authentication Using AppFabric Access Control Service (ACS) v2 – Part 1

    • 0 Comments
    Programming Windows Identity Foundation Programming Windows Azure - Programming the Microsoft CloudNote: this is work in progress. In this post I will show how to create Windows Azure Web Role ASP.NET web application configured for federated authentication with Live ID and Google using Windows Azure AppFabric Access Control Service (ACS) v2. In the next posts I will show you how to modify the application so it can be deployed to actually run in Windows Azure environment. For the scenario overview refer to Securing Windows Azure Distributed Application Using AppFabric Access Control Service (ACS) v2 – Scenario and Solution Approach.

    Summary of steps

    • Step 1 – Create Windows Azure Web Role ASP.NET application project in Visual Studio 2010
    • Step 2 – Create and configure ASP.NET web application as relying party in ACS v2 Management Portal
    • Step 3 – Configure Windows Azure Web Role ASP.NET project for federation with ACS v2
    • Step 4 – Make modifications related to specifically to Azure/ACS v2 (not covered here)
    • Step 5 – Implement authorization access checks (not covered here)
    • Step 6 – Deploy your solution to Windows Azure (not covered here)
    • Step 7 – Test your solution (not covered here)

    Step 1 – Create Windows Azure Web Role ASP.NET application project in Visual Studio 2010

    Content in this step adopted and adapted from Code Quick Launch: Create and deploy an ASP.NET application in Windows Azure.

    To create and run an ASP.NET service for Windows Azure

    1. Launch Microsoft Visual Studio 2010 with administrator privileges. To launch Visual Studio with administrator privileges, right-click Microsoft Visual Studio 2010 and then click Run as administrator.

    2. On the File menu, click New, and then click Project.

    3. Within the New Project dialog, navigate to Installed Templates, Visual C#, and click Cloud.

    4. Click Windows Azure Project. If needed, modify the Location: field, which indicates where your solution will be stored. Click OK to close the New Project dialog.

    5. Within the New Windows Azure Project dialog, navigate to Visual C#, click the ASP.NET Web Role, and then click the > symbol. This will add a web role to your Windows Azure solution. A web role provides an environment for running web sites or applications as supported by Internet Information Services (IIS) 7.0. Click OK to close the New Windows Azure Project dialog.

    6. [Optional] At this point you could compile and run the application. However, you could also customize the text displayed in the web page by modifying Default.aspx. This won’t fundamentally change the application, but it will show you how similar this application is to a traditional (non-cloud) ASP.NET application. To modify Default.aspx, open Solution Explorer. If Solution Explorer is not visible, from the View menu click Solution Explorer. Within Solution Explorer, expand WebRole1 and double-click Default.aspx. Modify the Welcome to ASP.NET! text to become Welcome to ASP.NET in Windows Azure!. Save and close Default.aspx.

    7. Compile and run the service by clicking Debug from the menu and then clicking Start Without Debugging.

    Assuming no compile errors or client machine errors, at this point you should have the service successfully running in the local development environment.

    Step 2 – Create and configure ASP.NET web application as relying party in ACS v2 Management Portal

    Content in this step adopted and adapted from How To: Create My First Claims Aware ASP.NET application Integrated with ACS v2

    If you have not created Windows Azure AppFabric project follow the steps below. If you already created Windows Azure AppFabric Project you can skip to creating a namespace which is next.

    To create a Windows Azure AppFabric project

    1. Navigate to https://portal.appfabriclabs.com. [this is lab environment and will change when shipped to production]
    2. If you were not authenticated using Windows Live ID you will be required to do so.
    3. After being authenticated with your Windows Live ID you are redirected to My Projects page on the Windows Azure AppFabric portal.
    4. Click the create a project link.
    5. On the Sign Up page type your project name in the text box, and the click OK. The project name is a logical container that will hold your namespaces. The project name will not appear publically in any way.
    6. You should be redirected back to My Projects page.
    7. You should see your project created and listed, and its status should be Active.

    If you have not created Windows Azure AppFabric namespace follow the steps below. If you already created Windows Azure AppFabric namespace you can skip to launching Access Control management portal which is next.

    To create namespace within your Windows Azure AppFabric project

    1. Navigate to https://portal.appfabriclabs.com. [this is lab environment and will change when shipped to production]
    2. If you were not authenticated using Windows Live ID you will be required to do so.
    3. After being authenticated with your Windows Live ID you are redirected to My Projects page on the Windows Azure AppFabric portal.
    4. Click the desired project name on the My Project page.
    5. Click the Add Service Namespace link.
    6. Type the desired namespace name in the text box, and click the Validate Name link. The namespace will appear as a subdomain names in the list of URLs. It should be unique and it is publically visible.
    7. If the name space is available—click the Create button.
    8. You should be redirected to the project’s details page
    9. Note that your new namespace shows under Service Namespace and its status is Active.

    To launch the ACS v2.0 Management Portal

    1. On the Project page, once the service namespace you created in Step 2 is active, click Access Control.

      You are redirected to the page that displays your project ID, allows you to delete the Service Namespace, or launch the ACS v2.0 Management Portal.

    2. To launch the ACS v2.0 Management Portal, click Manage Access Control.

    This section describes how to add identity providers to use with your relying party application for authentication. Identity Provider is a service that lets end users authenticate themselves to your application. For more information about identity providers, see Identity Providers.

    To add identity provider

    1. On the ACS v2.0 Management Portal, click Identity Providers.

    2. On Identity Providers page, click Add Identity Provider, and then click Add button next to Google, doing so your users will be able to authenticate to your Web Application using their Google credentials. You can optionally choose other Identity Providers such as Live ID, Facebook, Yahoo!

    3. The Add Google Identity Provider page prompts you to enter a login link text (the default is Google) and an image URL. This URL points to a file of an image that can be used as the login link for this identity provider (in this case, Google). Editing these fields is optional. For this demo, do not edit them, and click Save.

    4. On Identity Providers page, click Return to Access Control Service to go back to the ACS v2.0 management portal main page.

    This section describes how to setup a Relying Party Application. In ACS v2.0, a Relying Party Application is a projection of your web application into the system. It defines the URLs for your application, token format preference, token timeout, token signing options, and token encryption options. For more information about relying party applications, see Relying Party Applications

    To setup a relying party application

    1. On the ACS v2.0 Management Portal, click Relying Party Applications.
    2. On Relying Party Applications page, click Add Relying Party Application.
    3. On Add Relying Party Application page, do the following:

      1. In Name, type the name of the relying party application. For example, type Azure Web App.
      2. In Mode, select either Enter settings manually.
      3. In Realm, type the URI that the security token issued by ACS v2.0 applies to. It should be the URL of your Azure Web Application. Return to your cloud project in Visual Studio 2010. Run the application using Ctrl+F5 (not right click, Browse on the Default.aspx page). When the application appears in the browser, copy the URL and paste to the Realm filed. Similar to this: http://127.0.0.1:81/. This should work for Compute Emulator – your desktop cloud dev environment - but it would change when moving to Windows Azure environment.
      4. In Return URL, type the URL that ACS v2.0 returns the security token to. Use same URL as for Realm field.
      5. In Token format, select a token format for ACS v2.0 to use when issuing security tokens to this relying party application. For this demo, select SAML 2.0. For more information about SAML tokens, see Token Formats Supported in ACS v 2.0.
      6. In Token encryption policy, select an encryption policy for tokens issued by ACS v2.0 for this relying party application. For this walkthrough, accept the default value of None. For more information about token encryption policy, see Certificates and Keys.
      7. In Token lifetime (secs):, specify the amount of time for a security token issued by ACS v2.0 to remain valid. For this walkthrough, accept the default value of 600. For more information about tokens, see Token Formats Supported in ACS v 2.0.
      8. In Identity providers, Select the identity providers to use with this relying party application. For this demo, accept the checked defaults (Google and Windows Live ID). For more information about relying party applications, see Identity Providers.
      9. In Rule groups, select rule groups for this relying party application to use when processing claims. For this demo, accept Create New Rule Group that is checked by default. For more information about rule groups, see Rules, Rule Groups, and Token Transformation.
      10. In Token signing, select whether to sign SAML tokens using the default service namespace certificate, or using a custom certificate specific to this application. For this demo, accept the default value of Use service namespace certificate (standard). For more information about token signing, see Certificates and Keys.
    4. Click Save.

    5. On Relying Party Applications page, click Return to Access Control Service to go back to the ACS v2.0 management portal main page.

    This section describes how to define rules that drive how claims are passed from identity providers to your relying party application. For more information about rules and rule groups, see Rules and rule groups.

    To create rules

    1. On the ACS v2.0 Management Portal main page, click Rule Groups.
    2. On Rule Groups page, click Default Rule Group for Azure Web App (since you named your relying party application Azure Web App).
    3. On Edit Rule Group page, click Generate Rules.
    4. On Generate Rules: Default Rule Group for Azure Web App page, accept the identity providers selected by default (in this walkthrough, Google and Windows Live ID), and then click Generate.
    5. On Edit Rule Group page, click Save.
    6. On Rule Groups page, click Return to Access Control Service to return to the main page of the ACS v2.0 management portal.

    You can find all the information and code necessary to modify your relying party application to work with ACS v2.0 on the Application Integration page. You will use this information when configuring your cloud web application for federated authentication.

    To view the Application Integration page

    1. On the ACS v2.0 Management portal main page, click Application Integration.
    2. The ACS URIs that are displayed on the Application Integration page are unique to your service namespace.
    3. For this walkthrough, it is recommended to keep this page open in order to perform future steps quickly.
    4. Copy the URI next to WS-Federation Metadata. You will using it in your cloud web project when adding STS (Security Token Service) Reference in the next step. It should look similar to the following:

    https://YOURNAMESPACE.accesscontrol.appfabriclabs.com/FederationMetadata/2007-06/FederationMetadata.xml

    Step 3 – Configure Windows Azure Web Role ASP.NET project for federation with ACS v2

    Content in this step adopted and adapted from How To: Create My First Claims Aware ASP.NET application Integrated with ACS v2

    This section describes how to integrate ACS v2.0 with the Windows Azure Web Role ASP.NET cloud application that you created in step 1. The essence of the step is configuring trust between the ASP.NET application (Relying Party) and ACS v2.0.

    To configure trust between the ASP.NET Relying Party Application and ACS v2.0

    1. In Visual Studio 2010, in Solution Explorer for Azure Web App, right-click Azure Web App and select Add STS Reference.
    2. In Federation Utility wizard, do the following:

      1. On Welcome to the Federation Utility Wizard page, in Application URI, enter the application URI and then click Next. In this walkthrough, the application URI is http://127.0.0.1:81/. Yours will be different, Compute Emulator assigns dynamic ports you cannot control, and “it is not possible to allocate unique IP address.”
      2. Note: The trailing slash is important because it matches the value you entered in ACS v2.0 Management Portal for your relying party application in previous step.
      3. A warning pops up: ID 1007: The Application is not hosted on a secure https connection. Do you wish to continue? For this walkthrough, click Yes.
      4. Note: In a production environment, this warning about using SSL is valid and should not be dismissed.
      5. On Security Token Service page, select Use Existing STS, enter the WS-Federation Metadata URL published by ACS v2, and then click Next. This is the URL you copied last in the previous step, it should look similar to the following:"

        https://YOURNAMESPACE.accesscontrol.appfabriclabs.com/FederationMetadata/2007-06/FederationMetadata.xml

      6. On STS signing certificate chain validation error page, click Next.
      7. On Security token encryption page, click Next.
      8. On Offered claims page, click Next.
      9. On Summary page, click Finish.
    3. Once you successfully finish running the Federation Utility wizard, it adds a reference to the Microsoft.IdentityModel.dll assembly and writes values to your Web.config file that configures the Windows Identity Foundation in your ASP.NET MVC 2 Web Application (TestApp).

    4. Open Web.config and locate the main system.web element. It should look like the following:
      <system.web>
          <authorization>
            <deny users="?" />
          </authorization>
    5. Modify Web.config to enable request validation by adding the following code under the main system.web element:
          <!--set this value-->
          <httpRuntime requestValidationMode="2.0"/>
       
    6. After you perform the update, this is what the above code fragment must look like:

         <system.web>
          <!--set this value-->
          <httpRuntime requestValidationMode="2.0"/>
          <authorization>
          <deny users="?" />
          </authorization>
    7. Test your work using Ctrl+F5 to run the application using Compute Emulator. Here is what you should expect:
      1. The browser opens and you are navigated to a Home Realm Discovery (HRD) page which displays Windows Live ID and Google as and options for your authentication.
      2. Click on any of these, you will be redirected to a familiar for your authentication page. Either Google or Live.com.
      3. After successful authentication you will be automatically redirected to your ASP.NET Web application’s default page.
      4. Note: If you have chosen Google for authentication you will be presented with additional page that requires your consent – agree by clicking on allow button.

    Related materials

  • Alik Levin's

    Securing Windows Azure Distributed Application Using AppFabric Access Control Service (ACS) v2 – Scenario and Solution Approach

    • 0 Comments
    Programming Windows Identity Foundation Programming Windows Azure - Programming the Microsoft Cloud

    This post is a continuation of How To: Configure Windows Azure Web Role ASP.NET Web application for Federation with Access Control Service (ACS) v2

    Scenario

    Consider the following canonical scenario for distributed applications deployed to Windows Azure:

     Windows Azure Application Scenario

    Key characteristics:

    • End users access the the ASP.NET web app via browser.
    • ASP.NET web app is deployed to Windows Azure Web Role.
    • WCF Service is deployed to another Windows Azure Web Role.
    • ASP.NET web access the WCF service as a downstream service.

    Challenges:

    • How to authenticate end users to ASP.NET web app?
    • How to implement authorization access checks at the ASP.NET web app?
    • How to authenticate web app’s calls to WCF service?
    • How to implement authorization access checks at the WCF service?
    • How to manage identities and their credentials outside the application?

    Solution

    Solution summary:

    • Use ACSv2 to implement federated authentication for end users – reusing existing authentication and identity management mechanisms
    • Use ACSv2 to manage identities for accessing WCF service
    • Use Windows Identity Foundation (WIF) to implement authorization access checks at ASP.NET web application
    • Use Windows Identity Foundation (WIF) to implement authorization access checks at WCF service

    Authenticaiton and Authorization w/ACSv2 in Azure apps

    Related materials

  • Alik Levin's

    Windows Azure AppFabric Access Control Service (ACS) v2 As A Cloud Single Sing On (SSO) Service – Scenarios and Solution Approaches

    • 0 Comments
    Programming Windows Identity Foundation

    Here are couple of scenarios that could resonate with you depending how you run your business.

    I am an ISV or entrepreneur

    • I developed multitenant SaaS app.
    • It can be deployed either on Windows Azure or on-perm.
    • I want to let each tenant to authenticate his users with either/and/or Google, Facebook, LiveID, OpenID, ADFS/AD.

     Multitenant SaaS app deployed to Azure

    I am a business owner and in order to run my business ...

    • I developed web apps running on Amazon, Google, Azure (PaaS)
    • I want customers sign in to each app using one set of credentials managed by any of the Internet Identity providers such as LiveID, Google, FB, OpenID, Yahoo!

     Different PaaS cloud providers - customers

    I am a business owner and in order to run my business ...

    • I developed web apps running on Amazon, Google, Azure (PaaS)
    • I want my employees sign in to each app using one set of credentials managed in corporate AD

    Different PaaS cloud providers - employees

    I am a business owner and in order to run my business…

    • I use packaged offerings like Salesforce.com, office 365, Google apps (SaaS)
    • I want to let my employees access these apps with single set of credentials

    Packaged SaaS scenarios

     

    Related Info

Page 5 of 8 (23 items) «34567»