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.
  • 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”
  • From the list, Choose “Google” and click on “Next” button
  • Click Save button to complete the changes.

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
  • Give it a App Name and App Namespace. Click on “Continue”
  • Provide the Website with Facebook Log-in as: https://{your ACS Namespace}.accesscontrol.windows.net
  • 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:

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: https://extranet.crescent.com”)
  • In Return URL, Just append /_trust , So, in our case, Its:  https://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

3. Rule groups:

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

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: https://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”
  • Browse to the certificate created (.pfx), provide password of it and then click “Save”
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 = "https://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 "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
# Email Field
$Email = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming
#Given Name Field
$GivenName = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Display Name" -LocalClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
$AccessToken = New-SPClaimTypeMapping -IncomingClaimType "https://www.facebook.com/claims/AccessToken" -IncomingClaimTypeDisplayName "Access Token" -SameAsIncoming
$Expiration = New-SPClaimTypeMapping -IncomingClaimType "https://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 "https://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

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 Users
  • Choose All zones and click Next
  • Under Uses section, Browse and select “All Users”
  • Select “Full Read” permission and Click Finish.

Unit Test:

That’s all! We are done!!

  • Hit the SharePoint Web Application URL. Users presented with login page.
  • 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:

Salaudeen Rajack

Salaudeen Rajack - Information Technology Expert with Two-decades of hands-on experience, specializing in SharePoint, PowerShell, Microsoft 365, and related products. He has held various positions including SharePoint Architect, Administrator, Developer and consultant, has helped many organizations to implement and optimize SharePoint solutions. Known for his deep technical expertise, He's passionate about sharing the knowledge and insights to help others, through the real-world articles!

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

  • 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
  • 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
    • NO! It doesn’t give access to SharePoint unless you enable “Anonymous Access”. All Users must be Granted access to SharePoint explicitly.

      Reply
    • 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
  • 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
  • Hi, what should be used instead of MakeCert.exe for production environments?

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

      Reply
  • 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
  • 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
  • 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
    • 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
    • Its a bug.
      Workaround Script by MS.

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

      Reply
  • 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
  • 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
    • 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
    • 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

Your email address will not be published. Required fields are marked *