A while back I wrote an article about using Windows Azure Access Control Services with SharePoint 2010. That configuration enabled a scenario where users could log into SharePoint with a Windows domain, Microsoft , Google , Yahoo! or Facebook account. Since writing that article a lot has changed; the Windows Azure Portal has been updated, a new version of SharePoint has been released, and other related changes have occurred.
One major change is that Microsoft is no longer charging for the use of Windows Azure Access Control Services (ACS). This means you can use one of the external authentication providers with your on-premises SharePoint installation for free! Utilizing Azure ACS with SharePoint 2013 can greatly reduce the support costs for managing accounts in an extranet environment. This will also allow users to utilize an account they already have instead of having to create or manage additional login credentials.
In this post I will outline how to configure Azure ACS with SharePoint 2013. This configuration will be very similar to the SharePoint 2010 configuration I previously documented. I assume that you already have a working and stable SharePoint 2013 server farm configured.
For this demo I have ensured that the Request Management service is not started. In this demo I only have a single SharePoint server in my farm, therefore I do not need request management.
I am also assuming that you have signed-up for access to Azure services at http://www.windowsazure.com. A Windows Azure account is required even though Azure ACS is available free of charge.
To get started, we need to login to the Windows Azure portal and configure a new Azure ACS namespace used for SharePoint 2013 authentication.
- Go to http://www.windowsazure.com and click on the portal link located in the upper right to log into the management portal.
- Management of Windows Azure ACS has not yet been added to the new Windows Azure portal. We need to switch back to the previous version of the portal by clicking on our email address (or username) located in the upper right of the web site and then choosing the previous portal menu option.
- At the bottom of the left menu click on the Service Bus, Access Control & Caching option.
- On the upper left column choose Access Control under the Services heading.
- In the top menu click on the New option in the Service Namespace group.
- In the dialog window that opens, fill in the Namespace field with any string value of your choosing. Click on the Check Availability button to ensure it is available. You will also need to choose the Country/Region for your ACS service and the subscription associated with your account. Although Azure ACS is free you still need to have a Windows Azure subscription. Click on Create Namespace. Note: MSDN users get Windows Azure subscription as one of their benefits.
- Windows Azure will begin to provision and activate your Windows Azure ACS service. In the main window of the portal you should see your namespace listed along with a status of Activating. Once the service status changes to Active you can proceed to step 8. It may take several minutes for the service to activate.
- Select your namespace service from the list and then click on the Access Control Service option in the Manage Access Control grouping in the top menu bar. This will take you to the Access Control Service management console. If the Access Control Service option is not enabled you have either not selected your namespace in the main list or your service is still activating.
- In the Access Control Service console click on the Identity providers option in the left menu. This is where we will select what identity providers we will make available to SharePoint. In this demo I will be add Microsoft Account (Windows Live ID), Google and Yahoo!. I will not be adding Facebook authentication in this example because it requires additional configuration on the Facebook website.
- On the identity provider page you will see that Windows Live ID has already been added. Click on the Add link to add additional providers.
- Under the Add a preconfigured identity provider section choose Google from the list and then click the next button.
- On the Login Page Settings accept the default values and click on the Save button.
- Repeat steps 11 and 12 but instead choose the Yahoo! provider.
- Now that the identity providers have been selected the next step is to configure a relying party application. This is the first configuration we make that relates to our SharePoint environment. On the left menu click on the Relying party applications option.
- On the Relying party applications page click on the Add link.
- Fill in the Add Relying Party Application form using the following guidance and then click on the Save button.
- Name – This is the top level domain for the SharePoint web application you are going to create. Example: Fabrikam.com
- Mode – Choose Enter settings manually
- Realm – This is a unique URI used to link this provider to a SharePoint provider definition. Chose your own value based upon the format of this example: urn:fabrikamspdemo:spub
- 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, the URL is specified with HTTPS as the protocol. Example: https://www.fabrikam.com/_trust/default.aspx
- Error URL – leave this blank
- Token Format – Select SAML 1.1
- Token Encryption Policy – Select None
- Token Lifetime – Set this value to 1200. (Please review this MSDN article on how the SAML token lifetime and the SharePoint TokenLifeTime settings can impact how frequently a users is prompted to log back in when using Windows Azure ACS)
- Identity Providers – Choose all of the providers we configured above.
- Rule Groups – Check create new rule group
- Token Signing – Leave this as the default.
- A rule group defines how claims are passed from the identity provider to SharePoint. You need to update the default rule group created in step 16 with the proper rules. Click on the Rule groups option in the left menu.
- Click on the Default Rule Group for your relying party application.
- 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.
- Select all of the providers and choose Generate.
- Click on the Save button under the Rule Group Details section.
- 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. For a production environment you may want to procure a certificate from a trusted certificate provider. You will need the MakeCert utility to create the certificate. You can download that utility from here.A. Extract the MakeCert utility into a temporary folder. (example c:temp).B. Open a command prompt as an administrator and change to the location where you extracted the MakeCert utility.C. Run the following command, replacing <service_namespace_name> with your unique service namespace. Your namespace can be seen in the top gray bar of the Access Control Service Portal.
makecert.exe –r –pe –n “CN=<service_namespace_name>.accesscontrol.windows.net” –sky exchange –ss my
Note: the above command may have line wrapped due to space limitations. The command should be entered in completely on a single line.
- The certificate created in step 22 needs to be exported so it can be uploaded into Windows Azure. The following steps will export the necessary certificate:
- A. In the command prompt opened in step 22, type MMC and press enter. This will launch the Microsoft Management Console.
- B. In the MMC Console click File and then click Add/Remove Snap-in. Double click on Certificates.
- C. Select My user account and then click finish.
- D. Close the Add Standalone Snap-in dialog by clicking on OK.
- E. In the console double click Certificates – Current User.
- F. Expand Personal and then expand Certificates.
- G. Right click the certificate you created in step 22. Choose All Tasks and then click Export to open the certificate export wizard.
- H. Click Next on the first page of the Certificate Export Wizard.
- I. Select Yes, export the private key and then click Next.
- J. Select Personal Information Exchange format and then click Next.
- K. Enter in a password to secure the key. Confirm the password and then click Next.
- L. Select a location and filename for your certificate. Remember the location of your certificate that you exported. Click Next and then click Finish to export the certificate.
- Return to the Access Control Services portal and click on the Certificate and keys option on the left menu. The next step will import the recently exported certificate into the Windows Azure ACS service.
- In the Token Signing section click on the Add link.
- On the Add Token Signing Certificate or Key page fill out the form using the following guidance and then click on Save.Used for – Select Relying Party Application and then choose your applicationType – Select X.509 CertificateCertificate – Select the certificate file you exported in step 23. Enter in your password for the exported certificate.
Primary – Check the Make Primary option.
This completes the steps necessary to configure Windows Azure ACS for use with SharePoint 2013. In part 2 (coming soon) I will configure SharePoint 2013 to use Windows Azure ACS for authentication.