SharePoint Authentication using Windows Azure Access Control–Part 1

Recently I wrote a post about my experience setting up Windows Live ID authentication with SharePoint 2010.    This time around I am going to talk about a feature of Windows Azure AppFabric called Access Control.   By using Windows Azure AppFabric Access Control with SharePoint I can allow users to authenticate not only by Windows Live ID and Active Directory but also Google, Yahoo! and Facebook!

Since there are several steps for configuring SharePoint 2010 with Windows Azure Access control I am breaking the post up into two parts.  The first part will cover the Windows Azure configuration and the second part will cover the SharePoint 2010 configuration.

The Windows Azure web site describes Access Control as:

…an easy way to provide identity and access control to web applications and services, while integrating with standards-based identity providers, including enterprise directories such as Active Directory®, and web identities such as Windows Live ID, Google, Yahoo! and Facebook.

The service enables authorization decisions to be pulled out of the application and into a set of declarative rules that can transform incoming security claims into claims that applications understand. These rules are defined using a simple and familiar programming model, resulting in cleaner code. It can also be used to manage users’ permissions, saving the effort and complexity of developing these capabilities

Before you begin it is important to understand that Windows Azure is a subscription service and there are costs associated with using it.   You can, however, get started using the AppFabric Labs which is a way for developers to test out the new technologies without being charged.   You must not use the Labs services for any production system.

Windows Azure provides both subscription and pay-as-you-go offerings which are very affordable.  If you have a Visual Studio Professional, Premium or Ultimate with MSDN subscription you can get up to $3100 in Windows Azure benefits for free.   If you are do not have Visual Studio with MSDN you can still get a free Windows Azure Platform trial.

For this example I am going to use the AppFabrics Labs environment.   At the end of this two part example you should have everything configured in Windows Azure and in SharePoint 2010 so that you visitors will be able to log into your SharePoint test web application using Windows Live ID,Google,or Yahoo! authentication.

Note:  This example is being built upon a SharePoint 2010 development environment running on Windows 7.  These same steps should also work with Windows Server 2008 development environments.  This example assumes you already have a working SharePoint 2010 environment built.

To get started you need to log into the AppFabric Labs portal using a Windows Live ID account and then configure a new service namespace.

  1. Open and log in using your Windows Live ID.
  2. At the bottom of the left menu click on the Service Bus, Access Control & Caching option.
  3. On the AppFabric portal click on the New Namespace option in the ribbon bar menu.
  4. If you have not previously signed up for an AppFabrics Lab subscription you will be presented with the dialog box below.  Click on the OK button.
  5. On the Create a new Service Namespace dialog enter in a Service Namespace.   This can be any string as long as it isn’t already being used by another subscriber.  In this case I used mikehackerdemo.   Click OK when you are done.
  6. Windows Azure will now begin to activate your new Labs Subscription.  During this time you will see a LabsSubscription entry in the Windows Azure portal with a status of activating.  You can press the refresh button in the ribbon bar to update the information in the subscription list.   You will need to wait until the status switches to active before moving on.   This may take several minutes…  time to get a coffee or soda!
  7. Proceed with this step only after the LabsSubscription status changes to Active.  Select the active LabsSubscription and then click on the Manage Access Control Service option in the ribbon bar.   The portal does use pop-up windows so you will need to allow access to all pop-ups for this site.
  8. While in the Access Control Service portal, click on the Identity Providers link along the left menu.  This is where you will select what identity providers we will make available to SharePoint.  We will add Windows Live ID, Google and Yahoo!.   In this example we will not be adding Facebook since it requires additional configuration on the Facebook site.
  9. On the Identity Providers page you will see that Windows Live ID is already selected.  Click on the Add link to add additional providers.
  10. Under the Add preconfigured identity provider section choose Google and then click Next.
  11. On the Login Page Settings page accept the default values and click Save.
  12. Repeat step 10 and 11 but instead choose the Yahoo! provider.
  13. Now you need to add a relying party application to Windows Azure.  This is the first configuration we make that relates to our SharePoint environment.  On the left menu, click on the Relying party applications option.
  14. On the Relying Party Applications page, click on the add link.
  15. Fill in the Add Relying Party Application form using the following guidance and then click save.
    1. Name – This is the top level domain for the SharePoint 2010 web application you are going to create.  Example:
    2. Mode – Choose Enter settings manually
    3. Realm – This is a unique URI used to link this provider to a SharePoint provider definition.  Choose your own value based upon the format of this example:  urn:fabrikamspdemo:spub
    4. Return URL – This will be the URL of the SharePoint web application you are creating with  /_trust/default.aspx appended.  We will use SSL on our SharePoint site so ensure you use https.   Example:
    5. Error URL – This can be left blank
    6. Token Format – Select SAML 1.1
    7. Token Encryption Policy – Select None
    8. Token Lifetime – Leave this at the default value of 600.
    9. Identity Providers – Select all listed
    10. Rule Groups – Check create new rule group
    11. Token Signing – Leave this at the default of Use service namespace certificate.
  16. A rule group defines how claims are passed from the identity providers to SharePoint.  You need to update the default rule group created as a result of step #15 with the proper rules.  Click on the Rule groups option in the left menu.
  17. Click on the Default Rule Group for your Relying party application.
  18. Click on the Generate link located above the rules section.   This will allow you to automatically generate the necessary rules for each of the identity providers.
  19. Select all of the providers and then click on Generate.
  20. Click on Save under the Rule Group Details section.
  21. To allow secure transmission of the SAML token we need a x.509 certificate.  For this example we will generate our own self-signed certificate.   You must install the Microsoft Windows Software Development Kit prior to completing this step. 
    1. If you haven’t already done so, install the Microsoft Windows Software Development Kit on your SharePoint environment.  (Remember, this is a test environment only and not a production SharePoint server)
    2. Open a command prompt as administrator and switch to the BIN directory where you installed the SDK.  The default location is C:Program FilesMicrosoft SDKsWindowsv7.1Bin
    3. Run the following command replacing <service_namespace_name> with your unique service namespace.  Your namespace can be seen in the gray bar at the top of the Access Control Service portal.MakeCert.exe -r -pe -n “CN=<service_namespace_name>” -sky exchange -ss my

      The command above is wrapped due to space limitations.  Type out the command completely without any returns.
  22. You now need to export the certificate that was just created to a file so we can upload it to Windows Azure.   On the SharePoint server perform the following steps:
    1. As an administrator, click Start, type the following into the Search box, and then press Enter:
    2. In the MMC console, click File, and then click Add/Remove Snap-in.
    3. Select Certificates, and then click Add.
    4. Select My user account, and then click Finish.
    5. To close the Add Standalone Snap-in dialog box, click OK.
    6. In the console, double-click Certificates – Current User.
    7. In the console, expand Personal, and then expand Certificates.
    8. Right-click the certificate you created previously. Click All Tasks, and then click Export to start the Certificate Export Wizard.
    9. On the Certificate Export Wizard Welcome page, click Next.
    10. On the Export Private Key page, select Yes, export the private key, and then click Next.
    11. On the Export File Format page, ensure that the option Personal Information Exchange – PKCS #12 (.PFX) is selected.
    12. In the Password fields, enter a password (twice), and then click Next.
    13. In the File name field, enter Azure-Dev, and then click Next.   I recommend that you create a c:temp folder and export the certificate there.  It will make future steps easier.
    14. Click Finish.
  23. We will now import the Azure-Dev certificate into Windows Azure.  In the Windows Azure Access Control Service portal click on the Certificates and keys option in the left menu.
  24. In the Token Signing section click on the Add link.
  25. On the Add Token Signing Certificate or Key page fill out the form using the following guidance and then click save,
    1. Used for –  Select Relying Party Application and choose your application.
    2. Type – Select X.509 Certificate
    3. Certificate – Select the certificate file we exported in step #22.  Enter in the password you specified in step #22.
    4. Primary – Check the Make Primary option.


This completes the Windows Azure AppFabric configuration for this example.  In part 2 you will configure SharePoint 2010 to use Windows Azure AppFabric for authentication and then create your SharePoint web application.

Leave a Reply