Apr

How to use Windows Azure Access Controls Services Authentication with SharePoint 2010

In this article i am going to explain how we can use windows Azure access controls services authenticaiton with SharePoint 2010. By using windows Azure access control services authentication we can connect to Sharepoint 2010 with federated Live ID, Google ID, and Facebook ID. This is lengthy guide so bear with me, i am going explain all step by step. Configuring Azure ACS First of all you need Windows Azure subscription, it is not free but you can subscribe for free trial and test this scenario or if you have MSDN subscription you can have some discount MSDN Azure benefits. Once you have your subscription open url http://windows.azure.com and sign in with your Live ID. Once you're signed in you are in the Azure Management Portal.

On the left hand side is the navigation and select Service Bus, Access Control & Caching(this is the part that was/is called AppFabric), in the image below. This will load all the AppFabric Services and you will get a new navigation tree on the left hand side and the Ribbon menu will update. To create your Service Namespace, which is like a "container" for the AppFabric services, click on the New button in the Ribbon . This will bring up a dialog where you create your new namespace. First of all select the services you want in this namespace – for this authentication we need the Access Control , specify a unique namespace for your Service Namespace. After that select an appropriate Region and optionally a Subscription if you have multiple ones. Once you are done click Create Namespace to start the creation.

The creation will take a few minutes, wait until it shows service status Active.

Once it has the Active Status, select your newly created Service Namespace and choose Access Control Service in the Ribbon menu . This will open the Access Control Services administration.

Next step is to add couple of identity providers, click on Identity Providers in the menu.

The Identity Providers menu option shows all the Identity Providers that currently is available for this ACS Service Namespace. By default you will only see Windows Live ID. While Windows Live ID might work (if you can live with all the guid based identities) it's very convenient to add other Identity Providers here. Click on Add to add a new identity provider.

Add Google's pre configured identity provider and then click next. The next page gives you some customizations options for the Google Identity Provider. Change anything you want here and click Save to continue.

This should take you back to the Identity Provider page and you should now see both Windows Live ID and Google listed there. Next thing to do is to add a Relying Party Application, that is our SharePoint Web Application. Choose Relying party applications in the left hand menu. You will have no RP's configured by default so click on Add to create a new one.

You will now see a form and it is here things must be written correctly otherwise you will not get the AuthN to work with SharePoint 2010. First of all give your Relaying Party a nice and easy name. Secondly is the realm , if you remember from the Live ID visual guide the Realm is important. Use a URI instead of URL, it's easier to remember and always works. In this case I choose uri:sharepointdemoauthn. Then we also need to fill in the Return URL. The return URL must point to http://server/_trust/default.aspx when dealing with SharePoint 2010 (replace with your server name).

The next things to configure is the tokens. First of all SAML 1.1 must be used as Token Format , SAML 2.0 is default in ACS so make sure to change this. Leave Token encryption policy to None . Then finally an important piece – the Token lifetime. By default this is set to 600 seconds and you need to increase this value. The reason for that is that SharePoint 2010 has the expected token lifetime configured to 600 seconds and when SharePoint validates the token, which is after it's been issued by ACS it will fall outside the lifetime. So you have two options here lower the SharePoint lifetime or increase it in ACS, in this case I've done the latter and set it to 700 seconds.

The rest of the configuration is left intact. If you like you can uncheck Windows Live ID if you do not want Live ID users to sign in with this RP. Click Save when you're done.

You should now see your newly created Relying Party.

We now have two Identity Providers connected to the Relaying Party – each of the Identity Provider has a set of outgoing claims to our Relay Party and we need to make sure that the claims received from the Identity Provider to the RP are passed through to SharePoint as outgoing claims from the RP. This is done through the Rule Groups. Select Rule groups in the left hand menu. You will see a Rule Group called "Default Rule Group for Visual AuthN" – this group was automatically created for us when we created the RP: Now click on the rule group to create the actual rules.

Note that there are no rules by default. To create the default rules, just click on Generate to create them.

Generate Rules

First we need to select for which Identity Provider's to generate the rules, make sure both Live ID and Google (in this case) are selected and click the Generate button.

we're just using all the default settings.

Next thing to do is to create a certificate that we will be using for Token Signing. The Management Portal makes it very easy for us to make a self signed certificate for testing and demo purposes. For production scenarios either purchase an X.509 certificate or request one from your local Certification Authority (CA) (for instance AD Certificate Services). Just make sure it's a certificate for sign and encrypt the payload. Navigate to the Certificates and Keys in the Access Control Service Management Portal. Click on Add next to the Token Signing certificates.

First of all make sure that the correct Relying Party is selected, it should be the one you just created. Access Control Service allows you to have multiple Relay Party Applications so just make an extra check.

Create a self signed certificate using MakeCert utility, which is a part of the Windows SDK. [/caption

] Now you need to export this certificate into two files (with and without the private key). One to upload to ACS and one to import into SharePoint 2010 later. You can export the certificates using the Certificates MMC Snap-In or use PowerShell.

[caption id="attachment_512" align="alignnone" width="613" caption="Certificates MMC Snap-In"]

$cert = @(dir cert: -Recurse | Where-Object { $_.subject -like "CN=vwsharepointdemo*" })[0] $type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert

$bytes = $cert.Export($type)

[System.IO.File]::WriteAllBytes("c:\vwsharepointdemo.cer", $bytes)

$type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pfx

$pass = read-host "Password" -assecurestring

$bytes = $cert.Export($type, $pass)

[System.IO.File]::WriteAllBytes("c:\vwsharepointdemo.pfx", $bytes)

The PowerShell I use to export the certificate to one password protected Pfx file (with key) and a Cer file (without key) are the following: As you can see I grab the certificate with the correct subject and then use the .NET classes to export the certificates and finally save the bytes into files. Replace the exported filenames with your own and also the subject on the first line when doing this for your service, The Pfx file must be uploaded to ACS. You should still be on the Add Token Signing certificate page and now choose to upload the Pfx certificate and then enter the password you used when exporting it. Make sure that you choose to use this certificate as primary certificate and then click Save.

Now have configured Azure Access Control Service. Now we will configure SharePoint 2010.

Configuring SharePoint

First of all you need to have a Web Application that uses Claims Authentication. If your web app is in Classic mode, either create a new one or upgrade from Classic to Claims. in my this post i have explained "How to change SharePoint authentication from classic mode to claims based authentication", you can refer to this post if you need some guide.

Trusted Root Authority Now we need to make sure that the SharePoint farm trusts the certificate used by ACS to sign the tokens. This is done by uploading the other certificate file into SharePoint, using PowerShell. The following code is used to import the .cer file:

asnp microsoft.sharepoint.powershell $cert = Get-PfxCertificate "C:\vwsharepointdemo.cer" New-SPTrustedRootAuthority -Certificate $cert -Name "VWSharePointDemo AuthN ACS"

To verify that the certificate is imported as a trusted certificate in SharePoint, go to Central Administration > Security > Manage Trust. You should see the name of the trust there:

The Trusted Identity Provider Next up is to add the Access Control Service Relaying Party as a Trusted Token Issuer in SharePoint. We will do it by using PowerShell. It is important step that you specify the exact realm as entered when you created the RP in ACS. Then you also need the Sign In URL for your RP. Modify line 2 below to match the URL for your Service Namespace. Next we define a claim mapping for the identity claim that we want to use, in this case the e-mail address. Finally we just add the new trusted identity token issuer

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\vwsharepointdemo.cer")

$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming

$realm = "uri:sharepointdemoauthn"

$signinurl = "https://vwsharepointdemo.accesscontrol.windows.net/v2/wsfederation”

New-SPTrustedIdentityTokenIssuer -Name "Azure ACS" -Description "Windows Azure ACS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

New-SPTrustedRootAuthority -Name "Azure Test Token Signing" -Certificate $cert

SharePoint 2010 Management Shell

NOTE: Be sure that the value for $realm matches the setting in "Relying Party Application" screen (above). Also note that in this example, I'm only defining the "emailaddress" claim. The last line of the PowerShell script is important to ensure SharePoint 2010 will trust the certificate being used to sign the token. Now it's time to modify our Web Application to use this ACS RP. Go to Central Administration and Web Application administration. Choose the Web Application you want to enable the RP for (remember that it has to be a Claims Web App). Choose to modify Authentication Providers from the Ribbon menu and select the correct Zone. Then scroll down to Claims Authentication Types and check the Trusted Identity Provider checkbox and then our own ACS Trusted Identity Provider. Once that's done click Save.

One final thing here before testing it all. Add a User Policy on the web application directly for one of the users that will log in through the ACS RP. You can of course log in using Windows AuthN and then set permissions inside the site if you prefer so. But i did like this way, Select the web application and then click User Policy in the Ribbon. Then click Add User choose All Zones and enter the Google e-mail of the user that you will test with, give the user Full Control on the web application. Make sure that you type the e-mail correct – SharePoint will by default validate anything that you write in in Claims mode.

Now it is time to test all your hard work. Browse to the web application for which you added the Trusted Identity Provider, once it's loaded you will be presented by the default multiple login page. The drop down will show all the available AuthN providers for the web application. To use the ACS login we only need to choose that provider in the list.

Select Google authentication and sign in, you can see username in the upper right corner – it should be the e-mail address of the Google ID you used.

When you now log in using a Live ID you will get an access denied message, which displays this unique name identifier. Copy the identifier and then log in using a Windows account (or the working Google account) and add this identifier to the Members group or any other security group.

Now if you log in with Windows Live ID, you will log in successfully but instead of you email address, unique name identifier will appear on the top right hand corner. This doesn't look nice, maybe in future Microsoft will fix this problem. Here you go guys we have completed this practical. Now it is time for cup of tea