SharePoint Authentication using Windows Azure Access Control–Part 2

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 have broke the post up into two parts. The first part covered the Windows Azure AppFabric configuration and this part will cover the SharePoint 2010 configuration.

Previously we configured Windows Azure AppFabric and created a self-signed certificate used to encrypt the SAML token that will be passed back to SharePoint.   We now need to configure a trusted provider in SharePoint 2010 that will connect out to our Windows Azure AppFabric service.

  1. First we need to export our self-signed certificate again but this time without the private key included.

    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 No, export the private key, and then click Next.
    11. On the Export File Format page, ensure that the option DER encoded binary X.509 (.CER) 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.
  2. Copy the following PowerShell Script code and paste it into Notepad.  You will be making a few minor changes to this script.
  3. Modify the script you just placed into Notepad using the guidance below:
    1. Ensure that the $certloc path is correctly pointing at the certificate we exported in step #1.
    2. Modify the $ream variable and replace urn:fabrikamspdemo:spub with the realm you specified when creating the Windows Azure AppFabric service.   You can find this value in the Relaying party application settings inside the Windows Azure Access Control Service portal.
    3. Modify the $signInUrl variable.  Replace fabrikam in the URL with your Windows Azure Service Namespace.   You can find the namespace by looking in the silver bar on the top of the Windows Azure Access Control Service portal.
  4. Save the script to your temp directory and name it Azure.ps1
  5. Open up PowerShell as an administrator.
  6. Switch to the temp directory where your Azure.ps1 file is located
  7. Run the script by typing .Azure.ps1 and then pressing enter.   The script should complete without any errors.
  8. You will now create a new SharePoint 2010 web application for use with the Azure ACS authentication.
    1. Open up SharePoint 2010 Central Administration and click on the Manage web applications link.
    2. Click New in the ribbon bar to create a new web application.
    3. Fill out the Create New Web Application using the following guidance below and then click OK.
      1. Authentication –  choose Claims Based Authentication
      2. IIS Website –  choose to create a new IIS web site.  Enter in a name and set the port to 443.    (used for SSL)
      3. Security Configuration –  Set allow anonymous to No and use Secure Socket Layer to Yes.
      4. Claims Authentication Types –  Choose Enable Windows Authentication, Integrated Windows authentication and select NTLM from the drop down.  Also choose Trusted Identity Provider and then select Azure ACS.
      5. Sign In Page URL  – Select Default Sign In Page
      6. Specify appropriate values in the Public URL, Application Pool and Database Name and Authentication sections based upon your preferences.
  9. After the Web Application is created you will need to create your site collection.  Ensure that your personal Windows Account is added as the primary site collection administrator.  This will ensure that you will have full permissions on the site collection.   If your Windows Account does not properly resolve when you type it into the text box, click on the squiggly red line, it should display your Active Directory account.  Choose it.
  10. The final step is to configure the IIS web application we just created with the proper SSL certificate.   In this example we will create a self-signed certificate and use that.
    1. Open IIS manager and select the server node.
    2. Under the IIS grouping double click on Server Certificates
    3. On the right hand side under Actions choose Create Self-Signed Certificate.
    4. Enter a name for your certificate and click OK.
    5. On the left, select your web application you just created in SharePoint.
    6. On the right select bindings… (under the edit site heading)
    7. Select the HTTPS binding and click Edit
    8. In the SSL Certificate drop down box, choose the certificate you just created and then click OK.
    9. Click Close on the Site Bindings dialog box.


This concludes the configuration of SharePoint 2010 for use with the Windows Azure Access Control Service.  Open up a browser and navigate to your new SharePoint web application.  Do not forget to use HTTPS.  If you are using a self-signed certificate for SSL you may see the message shown below.  Just click continue to this website.


You should now see the following authentication selection screen:


Choosing Azure ACS will redirect you to the Windows Azure authentication selection screen.


Here is where your users can choose Windows Live ID, Google or Yahoo!.   Clicking on one of the options will present you with the corresponding log in page.   Once the user enters in their credentials they will be redirected back to your SharePoint site.   If they have been given proper permissions on the site then they will see the site content otherwise they may see the SharePoint access denied message.

Below is a screen shot of a user that has logged in using their Google ID.



In a future post I will provide a few tips on using Windows Azure Access Control Service, including how to give users permissions to your SharePoint sites.

Update 4/7/2012:  Wictor Wilen has created a great series of posts that cover Windows Azure Access Control Services in details check them out:

Visual guide to Azure Access Controls Services authentication with SharePoint 2010 – part 1
Visual guide to Azure Access Control Services authentication with SharePoint 2010 – part 2 – common problems
Visual guide to Azure Access Control Services authentication with SharePoint 2010 – part 3 – Facebook
Visual guide to Azure Access Controls Services authentication with SharePoint 2010 – part 4 – multiple web applications
Visual guide to Azure Access Controls Services authentication with SharePoint 2010 – part 5 – Custom Claims
Visual guide to Azure Access Controls Services authentication with SharePoint 2010 – part 6 – Facebook integration

12 thoughts on “SharePoint Authentication using Windows Azure Access Control–Part 2”

  1. Hello Mike

    Awesome post! every step worked like a charm – thank you.

    I do have an issue where I receive a page not found or Internet Explorer cannot display the web page…
    …when I click on the Azure ACS login option.

    I have performed an IISRESET, went through the entire post to confirm every step was successfully followed, etc.

    I can use Windows Authentication successfully.

    Can you perhaps assist?


    1. Double check the URL you configured in step #3 for $signInUrl. You can verify your sign in URL by logging into the AppFabrics labs portal site, click on Application integration on the left menu and then click on your application name. This should show a link to the ACS-hosted login page. Copy the URL up to the question mark. Do not include the question mark or anything past it. That will be the value for your $signInUrl variable in the PowerShell script.

      1. Hi Mike, thank you for the reply.

        When clicking on the Application Integration page, I do not see a the URL with the question mark.

        [edited to remove script]

      2. managed to access the SignInURL and correct the PSH script…

        I now receive the following…

        An error occurred while processing your request.

        HTTP Error Code: 400
        Message: ACS20000: An error occurred while processing a WS-Federation sign-in request.
        Inner Message: ACS50001: Requested relying party realm ””urn:mydemo”” is unknown
        Trace ID: 4cd51059-33a6-41c3-acde-35c3ac7ce1da
        Timestamp: 2011-04-28 15:29:14Z

    1. You guide has gotten me soo close to competing this. However, it looks like things have changed on the Azure side. My Sign in url has the address: instead of

      When I run through the tutorial the Powershell command is successful but when I access my site I choose the Azure authentication choice and then I get a page not found error instead of the options of Windows LiveID, etc.. This is due to the Sign in URL being different now.

      I have recreated my certs with what looks to be the proper url for accesscontrol but when I run the powershell command is doesn””t like my signin url information.
      The sign in url information must be correct because if I paste it in the browser I am prompted with my Windows LiveID and Google authentication choices.

      Any ideas? Thanks in advance

      1. I wish I had a quick answer for you. I will need to go back and look to see what changes were made to the App Fabric Labs site. I am guessing it is just a minor URL update that is causing the issues in either the powershell or the configuration of the App Fabric access control.

  2. Thanks for these posts, Mike. Sounds like a good direction for software solutions that are already in the cloud to take as they extend into offering their services into SharePoint. Thanks for taking the time to write this up.

  3. Thanks for the great post. Everything worked nicely. Question, I am authenticating with either Yahoo or Google, but when I click on a link in my top level site (e.g. Library or List in quick launch menu) I am redirected to log in again. I am able to see the pages I am clicking on, but it is redirecting me to log in each time I click on any link. Weird behavior. Any ideas?


    1. The issue related to being prompted to log in over and over is a function of the SAML token lifetime and a setting within SharePoint. The following document explains the relationship between SharePoint cookies and SAML tokens and how expiration settings can cause a loop that you are seeing.

      To resolve the issue you can increase the Token Lifetime in Azure ACS for your relying party application or you can modify the default setting within SharePoint by using PowerShell commands noted in the MSDN article linked above.

  4. Very good post Mike. I unfortunately found it after I had gone through the process! You mention at the end

    “In a future post I will provide a few tips on using Windows Azure Access Control Service, including how to give users permissions to your SharePoint sites.”

    Did you ever find time to write this post? I couldn””t find anything on your blog. I Have a situation where I have users coming in from a variety of sources and so need to authorize against a claim and wondered if you had any ideas about what claim could be used/added. I have to allow access to different sites so can””t do a blanket ””all users”” approach. I know I can use the encoded claims string present as the account name/SPUser.LoginName but that is not very user friendly. Are there any name resolution options using a cucstom claims provider that would help?

Leave a Reply