Integrating Windows Live ID, Google and Facebook Authentications with SharePoint 2013

The federated authentication mechanism handles authentication by external providers which send the token back to SharePoint. So, Instead of creating accounts internally (in AD, SQL Server) for external users and partners, We can make use of external authentication providers like Microsoft Live ID Accounts, Google, Yahoo, Facebook accounts (or even external Active Directory – ADFS ) to manage authentication. It’s extremely useful with public-facing SharePoint sites, isn’t it?

This article walks through step by step on integrating Windows Live ID, Google and Facebook account authentications with SharePoint 2013.

To start with, Here are the steps in summary:

  1. We need Windows Azure ACS (Access Control Service) as our Trusted Identity provider. Subscribe and get one.
  2. Add new Identity Provider for SharePoint 2013 with PowerShell.
  3. Authorize users by granting them access to the web application.

Step 1: Configure Azure ACS with required Providers:

Create a Windows Azure Account
We need Windows Azure Access Control Service (ACS) to handle authentication from external entities. From ACS we can choose Providers like Microsoft Live ID, Google, etc. Create a Windows Azure Account – Subscribe for Azure (you must have a Microsoft Live ID & may need a credit card). Go to: https://www.windowsazure.com/en-us/ and register a new account.

Integrating Windows Live ID accounts with with SharePoint 2013

I registered a Trial account with Azure. If you are part of any Windows Azure user groups, you can obtain a free coupon and get Windows Azure 30 days free pass at: https://azure.microsoft.com/en-us/free/

Create New Azure Access Control Service

  • Login to Windows Azure Portal, Click on “New” link from the footer pane >> App Services >> Active Directory >> Access Control >> Quick Create. Provide Namespace and location for your ACS service.
    create new azure acs service
  • Once the service is created and activated, Select the ACS and Click on “Manage” link from the footer pane. This takes us to the ACS configuration page.
    Integrating Google Authentications with SharePoint 2013

Configure Azure ACS

There are four settings we got to configure in ACS.

  1. Identity providers
  2. Relying party applications
  3. Rule groups
  4. Certificates and keys

Proceed to the below configurations one by one.

1. Identity Providers:

  • To start with, click on “Identity Providers” link – You’ll notice “Windows Live ID” already listed there. You can add additional providers by clicking “Add” link in Identity Providers Tab. Lets Add “Google”
    add new identity provider
  • From the list, Choose “Google” and click on “Next” button
    add google identity provider
  • Click Save button to complete the changes.
    add gmail accounts in sharepoint 2013

Integrate Facebook Authentication with SharePoint 2013:

For Facebook accounts integration with SharePoint 2013, We need to do one more step: Create New Application in Facebook and then add the provider as Facebook in ACS.

  • Go to Facebook Apps, https://developers.facebook.com/apps
  • Create new Facebook Application
    create new app
  • Give it a App Name and App Namespace. Click on “Continue”
    create facebook application for sharepoint 2013 login
  • Provide the Website with Facebook Log-in as: https://{your ACS Namespace}.accesscontrol.windows.net
    configure facebook app settings
  • Click Save Changes.

Now, in ACS:

  • Add new “Facebook Application” identity provider and Click Next
    sharepoint 2013 facebook authentication
  • Enter Application ID, Application Secret values from Facebook application.sharepoint 2013 facebook integration
  • Click on Save to complete your changes. Now our identity providers page contains these three identity providers:
    identity providers

2. Relying party applications:
Relying party application is generally a web site or application that uses ACS for Authentication. Here in our case, Its our SharePoint site. So, Lets create a Relying party Application.

  • Go to Relying Party Applications Tab, Click on “Add”
  • Enter the below parameters: Give it a Name (can be anything)
  • Specify the “Realm” as your SharePoint Web Application’s URL (Say: http://extranet.crescent.com”)
  • In Return URL, Just append /_trust , So, in our case, Its:  http://extranet.crescent.com/_trust
  • Token format should be SAML 1.1
  • Set the Token timeout value to 3600
  • Make sure “Create new rule Group” is checked and click “Save” button
    relying party applications settings

3. Rule groups:

  • Click on “Default Rule Group for http://extranet.crescent.com”
    edit default rule group
  • Under rules, You’ll get a message: “No rules have been added. Click on “Generate” link just above “Rules” sectiongenerate rule group
  • Select the providers, Hit Generate button again on the apps presented. Click on “Save”generate rule group 2
  • If you visit the default Rule group again, You will see the mapping fields used by these providers.edit rule groups

You can also map additional properties from providers.

4. Certificates and keys:
We have to Encrypt the traffic between ACS and our SharePoint environment by exchanging certificate between Azure ACS and SharePoint. So, we need a Digital certificate. You can create SSL certificate from development environments with MakeCert.exe.

MakeCert.exe is part of Windows SDK. You can download it from: http://go.microsoft.com/fwlink/p/?linkid=84091 .MakeCert lives under: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\BinSo, in command prompt: enter:

C:\>cd “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin”

MakeCert.exe -r -pe -n “CN=crescent.accesscontrol.windows.net” -sky exchange -ss my -len 2048 -e 11/15/2014

This will generate the certificate and install it automatically to the trusted certificate store. Or you can use:
MakeCert.exe -r -pe -n “CN=crescent.accesscontrol.windows.net” -sky exchange -ss my -len 2048 -e 11/15/2014 -sv “c:\Extranet.pvk” “c:\Extranet.cer “

If makecert.exe is not available, Use IIS self signed certificate creation with the specified common name, and the export the .CER & PFX files from Certificates Snap-in through MMC.


Import the Certificate to ACS:

  • Once certificate is generate, on the certificates and keys tab, Click on “Add link”
    add certificates and keys
  • Browse to the certificate created (.pfx), provide password of it and then click “Save”assign certificate
Warning: MakeCert.exe is not recommended for Production environments!


Step 2: Add a new Trusted identity Provider as Azure ACS

We’ve our authentication providers ready now! We’ve make SharePoint aware by creating a new “Trusted Authentication Provider”. Here is the PowerShell script to create new trusted authentication provider.

Add-PSSnapin Microsoft.SharePoint.PowerShell
#Realm we created in Azure
$realm = "http://extranet.crescent.com"

#Replace "crescent.accesscontrol.windows.net" and "extranet.crescent.com" with yours here!
$signinurl = "https://crescent.accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=http%3a%2f%2fextranet.crescent.com%2f"

#Location of the certificate generated with Makecert.exe
$certloc = "C:\extranet.crescent.com.cer"
$rootcert = Get-PfxCertificate $certloc
New-SPTrustedRootAuthority "Windows Azure ACS" -Certificate $rootcert

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)

#Map the Fields from Rules Created for All Providers: Facebook , Google & Live ID
# NameIdentifier Field
$NameIdentifier = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
# Email Field
$Email = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming
#Given Name Field
$GivenName = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Display Name" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
$AccessToken = New-SPClaimTypeMapping -IncomingClaimType "http://www.facebook.com/claims/AccessToken" -IncomingClaimTypeDisplayName "Access Token" -SameAsIncoming
$Expiration = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration" -IncomingClaimTypeDisplayName "Expiration" -SameAsIncoming

#Create New Trusted Identity Provider
New-SPTrustedIdentityTokenIssuer -Name "Live ID/Google/Facebook" -Description "Live ID/Google/Facebook" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $NameIdentifier, $Email, $GivenName, $AccessToken, $Expiration -SignInUrl $signinurl -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"

# IdentifierClaim defines the Field to display on User Name
# E.g. If you use only Google: New-SPTrustedIdentityTokenIssuer -Name "Google Account" -Description "Google Account" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $NameIdentifier,$Email,$GivenName  -SignInUrl $signinurl -IdentifierClaim $Email.InputClaimType
# Make sure that the IdentifierClaim is common for all providers, if you are using more than one!

Step 3: Authorize users by granting them access to the web application.

Associate Authentication provider to the target web Application:

  • Go to Central Admin >> Application Management >> Manage Web Applications
  • Select the web application you want to enable Federated Authentication
  • Click on “Authentication Providers” from Ribbon >> Click on ‘the “Default” link >> Scroll down
  • Enable “Live ID/Google/Facebook” under “Trusted Identity Provider section
    edit authentication provider

Grant Users Access:
So the authentication part is over. we’ve to handle authorization from the SharePoint side, as we do for Windows AD accounts. Let us create a user policy to grant all users of the trusted identity provider to Read access to all sites in the web application (Otherwise, They’ll get an “Access denied” error message.

  • Go back to Manage web applications page, Click on “User Policy” button from the ribbon.
  • Click on Add Userssharepoint web app policy policy
  • Choose All zones and click Nextadd users to all zone
  • Under Uses section, Browse and select “All Users” grant access to all users
  • Select “Full Read” permission and Click Finish.
    add all users in web application policy

Unit Test:

That’s all! We are done!!

  • Hit the SharePoint Web Application URL. Users presented with login page.sign in screen
  • From the list, choose “Windows Live ID/Google/Facebook”Integrating Windows Live ID, Google and Facebook Authentications with SharePoint 2013
  • Choose the appropriate login provider which takes us to the appropriate login screens.

Verify users are able to access SharePoint site with Google & Facebook accounts. Here are some screen shots:
sharepoint 2013 login with google account

Salaudeen Rajack

Salaudeen Rajack is a SharePoint Architect with Two decades of SharePoint Experience. He loves sharing his knowledge and experiences with the SharePoint community, through his real-world articles!

17 thoughts on “Integrating Windows Live ID, Google and Facebook Authentications with SharePoint 2013

  • June 11, 2015 at 3:55 PM

    Hello, I have created google authentication but everytime I try to login I run into this error
    HTTP Error Code: 400
    Message: ACS40101: An error occurred while attempting to get an access token from Google.
    Trace ID: fd4c0341-12bf-4853-adb1-7b4820076bd4

    Anyone knows what this is?

    Reply
  • June 9, 2015 at 12:17 PM

    Hello, one question: IS there a way to choose who can access sharepoint with Windows LiveID and who can’t. If I understand good it will give access to everyone who knows Sharepoints URL and I don’t want that.

    Reply
    • June 9, 2015 at 1:22 PM

      NO! It doesn’t give access to SharePoint unless you enable “Anonymous Access”. All Users must be Granted access to SharePoint explicitly.

      Reply
    • July 25, 2016 at 8:31 PM

      Dear Salaudeen, isn’t it true that by granting all users (Live ID/Google/Facebook) full read permmissions, everyone with such an account and knowledge of the sharepoint url will have access to the sharepoint portal? How could you grant individual permissions in such scenario?

      Reply
  • May 7, 2015 at 7:28 PM

    Hi, thanks for the great tutorial. I’ve set up everything correctly, however after the user logs in with a Google account, they get an error:

    400 Error: redirect_uri_mismatch
    The redirect URI in the request: https://mysite.accesscontrol.windows.net:443/v2/openid did not match a registered redirect URI.

    I’ve check that the Google Developers console and the Azure relying party applications both have the correct and same return URL. Yet I still keep getting these errors. I’ve also played with having different fields as the identifierclaim but still get the same result everytime. Would you know what’s the issue?

    Reply
  • March 25, 2015 at 5:04 PM

    Hi, what should be used instead of MakeCert.exe for production environments?

    Reply
    • March 26, 2015 at 4:33 AM

      You have to get the certificate from Trusted Certificate Authorities like: Verisign, DigiCert, Godaddy, etc.

      Reply
  • January 7, 2015 at 1:14 PM

    Hi Salaudeen,

    I’ve followed these steps get Facebook as Provider for my Sharepoint Application , Now i want if some one login using as facebook authentication then i want to display Profile data of that person in my SharePoint Application can have any suggestion on that .

    Reply
  • May 17, 2014 at 6:52 PM

    Hi, After _trust fails.;
    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.

    Reply
  • March 26, 2014 at 8:30 AM

    I’ve set up a Trusted Identity Provider. This works well so far with no problems.
    Now I have the problem that no new MySites for domain users created any more. Appears on the page only “We’re almost ready!”
    If I now the Trusted Identity Provider disable it again, everything works as usual.
    Why might that be? Have an idea?

    Reply
    • March 27, 2014 at 10:40 AM

      Well, First of all, Check your Event Log and ULS log for clues.
      1. Go to User Profile Service >> select Manage User Permissions under people section >> Make sure the permissions are set correctly. (Create Personal site must be enabled!)
      2. Set Personal Site Naming Format: Go to User Profile Service Application >> Set up my Site >> Site Naming Format >> 3. Change the setting to “User name (resolve conflicts by using domain_username)
      4. Make sure, Managed Path for the MySite web application includes wildcard inclusion “personal”
      5. Self-Service Site Creation is enabled for MySite web application
      6. Make sure In User Profile Service Application, My Site Host URL is configured.

      Reply
    • April 17, 2014 at 11:52 AM

      Its a bug.
      Workaround Script by MS.

      Reply
    • January 8, 2015 at 7:39 AM

      Are you able to populate facebook properties in mysite? With FaceBook as identity provider?

      Reply
  • March 18, 2014 at 8:37 PM

    Did any of you, who implemented Live or Google account integration using ACS with SharePoint 2013 got any search related issue? I am using Google Account. Normal browsing works fine for me. But search does not get any result for Google user whereas NTLM user gets result with same level of permission. I am not using any custom claims provider and given permission to All Users (Google Account) read permission on Site Collection

    Reply
  • December 4, 2013 at 8:20 PM

    Salaudeen, I’ve followed these steps here and have two issues:
    – the Users name is not showing up but rather their claim token. The username for example on the top right of the SP page is not displaying the email or the users name but a nasty claim token
    – All users seem to have read only access, yet they incorrectly also have access to the Site Settings page- effectively giving them Site Collection admin privileges

    Any ideas?

    Reply
    • December 5, 2013 at 7:56 AM

      Hi Keith,

      1. User Name shows Claims token – Only when you use “Windows Live ID” because, Live ID does exposes only “NameIdentifier” field which is a token rather E-Mail ID or Name. If you use Google, it has Name, E-mail fields to map. (In one of my screenshot, I’ve only used Google!)

      2. Make sure, No web application policy created to grant more than Read-only access to “All Users”

      Reply
    • July 7, 2016 at 6:40 PM

      I’ve had the same problem, Google works fine, but Facebook and Windows Live Id return a nasty number as user name.

      any ideia?

      Reply

Leave a Reply