Google Id/Windows Authentication in SharePoint 2010 using Windows Azure

In this article I will describe how to enable signing in using Google Id, Windows Open Id, Facebook or Yahoo account to a SharePoint 2010 site collection. As authentication provider I will use Windows Azure Platform.
Here are the steps you have to do:

Configure the Azure platform

  1. Create an account on Windows Azure Platform using your Windows Live Id. There is 90 days evaluation period available on Windows Azure that is free, additionaly the Access Control Services I will use as authnetication provider are free at least until December 2012. During the registration process you will be however asked to fill in you credit card number. For more information about pricing see this.
  2. After you created your azure account go to the Windows Azure management portal
  3. In the portal click “Services Bus, Access Control & Caching ” and then “Access Control”. See following picture
  4. Click new to create a new namespace and select a unique name for the namespace and the region where your server exists and click “Create namespace” button
  5. Wait until the namespace is activated. It takes several minutes
  6. Click the newly created namespace and then “Access Control Service”
  7. Click “Identity providers” and add the providers that should be used in your SharePoint site collection for the authentication. See folllowing image.
  8. Click Relying party application button in the left tab and add a new Relying application and fill the form as marked in the following image. The url should be the url of your sharepoint web application.
  9. Also check the “Create new rule group”
  10. Now click the “Rule groups” and click Generate. The form should look like this afterwards:
  11. Click save.
  12. Click  “Application Integration” under “Development” tab. Then “Login pages” and then your relying service application.
  13. Copy the content of the textbox und option 1. It should look like this
  14. For now you are done with the azure platform configuration. Now go to your SharePoint server where should be the claims authentication enabled.

Create and export new certificate

  1. Run following command “MakeCert.exe -r -pe -n “CN=<yournamespace>” -sky exchange -ss my”. The Makecert.exe can you find in this folder: C:\Program Files\Microsoft Office Servers\14.0\Tools
  2. Here  you can find a description how to export the newly created certificate for the communication betwen SharePoint and Azure.
  3. Once you have the file go back to Azure platform to your namespace and click “Certificates and keys” and click “Add” button in the “Token signing” section.
  4. Upload the exported certificate and leave the other setings to default

Configure SharePoint to use claims
Run following script. Replace following things:

  1. Path to the certificate
  2. Password of the certificate
  3. $realm (it is the Url you gave in the Relying Application Settings as Realm). Mind the slashes.
  4. $signinurl It is the url from step 17
  5. The names of the providers.

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("yourcertificatename.pfx","yourpassword")

$map1 = New-SPClaimTypeMapping "" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming

$realm = "http://sharepoint2010/"

$signinurl = ""

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

$issuer = Get-SPTrustedIdentityTokenIssuer
$authority = Get-SPTrustedRootAuthority
$issuer.ProviderUri = $signinurl

Check if the things work:

  1. Open central administration and open Web application
  2. Click Create new Web application
  3. Switch to claims authentication
  4. Check the “Azure ACS”
  5. Create new web application
  6. Create new site collection
  7. Set the permissions on the site collection that the users have access to the site collection
  8. Log in with your Google Id to the site collection

References:  Travis Nielsen blog

Tags: , , ,

9 Responses to “Google Id/Windows Authentication in SharePoint 2010 using Windows Azure”

  1. Carlo Giuliani Says:

    This is a nice, clear, explanation that is a lot more concise than others I have found….but I am puzzled by the last few lines of the script, which seems to be deleting what was just created. I am assuming that part was included by error?

  2. Carlo Giuliani Says:

    That makes more sense….but I am still wondering about the last four lines….setting the sign-in URL was already done usining -SignInUrl parameter of the New-SPTrustedIdentityTokenIssuer cmdlet. Is there some reason to set it again?

  3. Carlo Giuliani Says:

    I have this working now…but only after I dropped the query part (everything after &) of the -SignInUrl parameter. SharePoint was constructing the query part itself, and appending it to the SignInUrl, so it was generating a redirect with the query part duplicated….which, of course, did not work.

    Now I can authenticate…but I get “access denied” on the site. I can’t figure out how to grant permissions to a user from ACS. All the blog posts (and technet articles) I have read give the example of granting permissions to all authenticated users, but that is not acceptable in most cases. So before I can use this, I have to figure out how to grant permission to a specific user.

  4. Carlo Giuliani Says:

    Finally got the last piece working. The Azure ACS trusted provider only appears in the people picker when connected to a zone in which that trusted provider has been enabled. I set up two zone…one internal using NTLM and one external using Azure ACS. Then I made the mistake of trying to grant permissions for claims users while logged on via NTLM. I resolved the problem by enabling *both* NTLM and Azure ACS for the internal (Default) zone. Then I could login with integrated auth (after selecting that provider) and grant permissions to Azure ACS users.

  5. Spark Says:

    Hello…I recently configured this for Windows Live, and I am wondering if there is an easier way to on board users in SharePoint. The current process is that users can sign in with their Live ID’s, but they have to wait for someone to add them in SharePoint, and then send them a notification (manually) that they’ve been added. Is there a way to automate this? thanks!

    • vojtan Says:

      I have following ideas:
      1. You can allow all users to a specific area in SharePoint. A link will be shared to the new users. When a user logs in for the first time a SharePoint user will be created for this user. Then this user can request access to the other areas of the website. The site admins can then manage the acccess requests with standard sharepoint functionality.
      2. If you have a list of users that should have access to SharePoint, you can create an additional custom claim. In this claim there will be true if the current user is in the list of allowed users. Then you can authorize users according to this claim. This is just an idea never done this before.

  6. bronyx Says:

    I have set up my system in that I One Web Application, which is extended.
    I have set up the extended web application to use the Azure Authentication Provider.

    When I log onto the extended web application, it prompts me for my Google ID, I enter it, then I get the following error.

    ID4220: The SAML Assertion is either not signed or the signature’s KeyIdentifier cannot be resolved to a SecurityToken. Ensure that the appropriate issuer tokens are present on the token resolver. To handle advanced token resolution requirements, extend Saml11TokenSerializer and override ReadToken.

    I have not a clue what this mean.
    Please can you help.

    Many thanks.

  7. bronyx Says:

    Hi, to add to my comment above, the stack trace is reporting the below:

    [SecurityTokenValidationException: ID4220: The SAML Assertion is either not signed or the signature’s KeyIdentifier cannot be resolved to a SecurityToken. Ensure that the appropriate issuer tokens are present on the token resolver. To handle advanced token resolution requirements, extend Saml11TokenSerializer and override ReadToken.]
    Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token) +1443
    Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token) +113
    Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri) +147
    Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request) +602
    Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) +522
    Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs) +204
    System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +182
    System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +165


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: