MVPs for SharePoint 2010: Using Azure ACS v2 to Authenticate External Systems Users
Editor's Note: The following is a guest post by SharePoint Server MVP David Martos as part of the MVP Award Program Blog's "MVPs for SharePoint" series. David Martos is Software Architect for Spenta Consulting (https://www.spenta.es) and has been working with Microsoft latest technologies for over 10 years. Since 2003 he has been specializing in the SharePoint platform and in particular on integration, extensibility, development and deployment areas.
David has been also collaborating for the last years with Microsoft Corporation building the architecture for the Citizen Service Platform (https://www.microsoft.com/csp and https://www.codeplex.com/csp). Currently he is leading the development of Beezy (https://www.gobeezy.com), a Social Corporate Networking built on top of SharePoint 2010. You can follow @davidmartos on Twitter or read his articles on https://geeks.ms/blogs/davidmartos.
Introduction
Before explaining how to get SharePoint 2010 to authenticate users with an external system through ACS Azure v2 it is worth explaining the reasons that can push us to do so, so I will try to give my reasons in this introduction without digging too much into technical details.
What options do I have?
By default, SharePoint 2010 allows users to authenticate through Active Directory, but besides this, we can choose a different user repository maintained by ourselves, for example, a SQL Server database or even a completely external system such as Windows Live ID, Google or Facebook. In general, the first option is recommended for corporate environments due to high Office integration needs, while other options are generally recommended for public scenarios. This is not a mathematical formula, but it works in most cases
Why an external system?
If we are in a situation where Active Directory is not an option we can choose to implement our own data repository, or to use an existing one. The main reasons that push us to the second option are:
No need to worry about keeping the information in our own system and ensuring its integrity.
No need to implement mechanisms related to users management as, for example, user registration and password recovery.
Our users do not have to maintain another set of credentials in addition to those already held.
If we are clear that we want to use an external system the next question to ask ourselves is whether we need to use a single system or we want to federate identities of several of them. If we are in the second case there are two alternatives: ADFS 2.0 or Azure ACS v2, which could be translated as ADFS 2.0 in the cloud.
Why using Azure ACS v2 instead of ADFS 2.0?
Everytime we compare an on-premise system with the cloud version, we deal with the same list of elements:
Scalability
Manageability
Cost (TCO)
Performance
Etc.
Each one of the two alternatives will have different value for each element. If we put in the balance these values with the corresponding weight for each element we will have the answer for the question posted above.
Get to work
If, after answering all the questions above, you have come to the conclusion that you want to use multiple systems and want to use external authentication services provided by Azure; you will want to continue reading to learn how to configure SharePoint 2010 to make it work.
Before any configuration, lets think for a while on what we want to implement; for the present example I plan to create a public portal using the url https://www.contoso-acsv2.com with anonymous access enabled and a private area where, in order to access, you will need valid credentials on Windows Live ID or Google. With this information we can begin to prepare our SharePoint 2010 farm to support this scenario.
I assume that you have the skills to perform the high-level tasks that I specify below, but if you have any questions, do not hesitate contact me. In any case, at the end of this article I will post a link where you can access a totally prepared environmentm, which you will be ale to use at your convenience.
Creating a web application for internal access with the following features
Claims based authentication (IMPORTANT! )
SSL not enabled
NTLM Authentication
Anonymous access not enabled
Creating a site collection using the publishing site template. Before continuing reading the article ensure you can browse the site collection you just created. As you will see at the top right zone the user with which you have just connected is an Active Directory user.
Before proceeding to the next task will need to create a digital certificate to sign tokens. Taking advantage of the fact that we also need a certificate for browsing the site over https and bearing in mind that what we do is only for testing, we can proceed as follows:
In the SharePoint server, open a command propmt and navigate to the folder C:\Program Files\Microsoft Office Servers\14.0\Tools.
Run the following command: MakeCert.exe -r -pe -n "CN=www.contoso-acsv2.com" -sky exchange -ss my
Open the Management Console by running the command mmc.exe and add the current user Certificates snap-in.
Locate the certificate for www.contoso-acsv2.com in the personal folder and export it to your hard disk. Take this time to export it with (.PFX), and without private key (.CER) since you wil need both in different parts of this article.
Note: In a real scenario you should use different certificates for signing tokens and for the web server. Also, it is not recommended using self-signed certificates for production environments.
Once you have created the site collection and the digital certificate, the next thing we have to do is creating a namespace on Azure ACS v2 identifying our application and to to this, we must follow the following steps:
Browse to the AppFabricLabs portal (https://portal.appfabriclabs.com)
Note: This article will use the lab version of Azure ACS v2, which is free but cannot be used in actual production environments. The commercial version of Azure ACS v2 is available through the Windows Azure website.
Locate and click on the bottom left of the screen, the Service Bus, Access Control & Caching link.
Select Access Control in the navigation menu on the left and click the New Namespace button in the ribbon.
Fill out the form indicating a namespace that is available and a region (for the moment we can only select United States)
Click the Create Namespace button and wait until service becomes Active.
Once created and activated the namespace, the next task is to configure it to support our needs. To do this, proceed as follows:
Select the namespace and click the Access Control Service button in the ribbon. This will lead you to the namespace’s management portal.
Click on the Identity providers link in the navigation menu on the left. You will see that by default, the system will allow us to use Windows Live ID as authentication provider.
In this article we demonstrate the use of more than one authentication systems and, therefore, press the Add link and add Google to the list of identity providers. Alternatively, if you wish, you can add Facebook or Yahoo.
The next screen will allow you to specify a text and an image to be used in the logon screen when we select the provider you use to log into the system. You can leave the defaults and click the Save button.
Click the Relying Party Applications link on the navigation menu on the left and click the Add button on the next screen.
Complete the form with the following values and click the Save button.
Name: contoso-acsv2.com
Realm: https://www.contoso-acsv2.com/
Return URL: https://www.contoso-acsv2.com/\_trust/
Token format: SAML 1.1
Token Lifetime: 600 secs
Google: option checked
Live ID: option checked
Create new rule group: option checked
Token signing: Use a dedicated certificate (put here the values that you obtained when you exported the digital certificate with its private key)
Click on the Rule groups link in the navigation menu on the left and click the Default rule for contoso-acsv2.com link on the appearing list. Once there, click on the Generate link, leave the Windows Live ID and Google options marked and press the Generate button.
The next screen will show the claims we receive from those systems we integrate with. In our case we will make a small change. Windows Live ID does not send the user email and we want to use this claim later, so we will add a new claim with the following values:
Identity Provider: Windows Live ID
Claim Input Type: https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
Claim Output type: https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Having our Azure ACS v2 namespace and the certificate ready we can proceed to configure the SharePoint 2010 trusted identity provider. To do so, follow these steps:
Copy the text below and save it with ps1 extension on the same folder where you previously exported the digital certificate.
$realm = "https://www.contoso-acsv2.com"
$signinurl = "https://example-acsv2.accesscontrol.appfabriclabs.com/v2/wsfederation"
$certloc = (Get-ChildItem . -Recurse -include www.contoso-acsv2.com.cer).fullname
$rootcert = Get-PfxCertificate $certloc
New-SPTrustedRootAuthority "Azure ACSv2" -Certificate $rootcert
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)
$map1 = New-SPClaimTypeMapping "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming
New-SPTrustedIdentityTokenIssuer -Name "Azure ACSv2" -Description "Windows Azure ACS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
Open the SharePoint 2010 Administration Console and execute the script you previously saved.
We are ready to continue our work in the SharePoint Central Administration. The last thing left is extending the web application you created earlier in this article using, for this purpose, the following configurations.
Port: 443
Host header: www.contoso-acsv2.com
Anonymous Access: Enabled
SSL: Enabled
Authentication Provider: Azure ACSv2
Before you can access the web site you just created will need to perform certain tasks relating to certificates.
Open the Internet Information Services console, select the name of our server in the section on the left and open the Server Certificates feature in the main window.
Import the certificate with private key (.PFX) using the actions menu on the right.
Right click on the website we created for access through SSL and click Edit Bindings.
Edit the binding created by default and assign the certificate you have previously imported.
Once this is done you can navigate to the url https://www.contoso-acsv2.com and, as you will see, the system will just redirect you to a screen where you see get the list of identity providers you have configured on ACS Azure v2 (in our example Windows Live ID and Google). But if you try to log in with your credentials you will receive an error. There is still a final step remaining. You need to go back to the Management Console and copy the generated certificate for www.contoso-acsv2.com to be found in the Personal folder to the following three folders:
SharePoint
Trusted People
Trusted Root Certification Authorities
By now, you can access the site but, obviously, you will get an access denied error. For demonstration purposes we will grant access to every authenticated user. To do this, follow these steps:
Browse to the Manage Web Applications in SharePoint Central Administration and select the web application that we created at the beginning of this article.
Click on the User Policy button in the ribbon.
Select 'All Users [Azure ACSv2]' and assign total read permissions.
In order to fully match the requirements at the beginning of this article, we still need to enable anonymous access at the site collection level, create a new subsite with specific permissions and disable anonymous access on it. I will skip these steps as they are high-level tasks not relateed to Azure ACS v2 but, again, if you have any doubt at this point do not hesitate to leave a comment.
Finally we have our environment prepared. From now on, every time you access the URL https://www.contoso-acsv2.com the system will allow us to provide valid credentials on Windows Live ID or Google to access the system. Obviously this is only the starting point to begin working with Windows Azure ACS v2 as it opens a wide range of possibilities. If you want to start exploring this world and you don’t want to waste time preparing this environment, I posted a permalink with everything I've explained in this article fully configured that can be used at your convenience.