Authenticate your SharePoint website users with Facebook !!

First of all, thanks to Danny Jessee for tons of information to succeed in this assignment.

If you don’t know, SharePoint 2010/2013 can authenticate against identy providers such as Windows Live ID, Google, Yahoo!, and Facebook like a charm with no coding using Windows Azure Access Control Service (ACS) using Claims Based Authentication.

I see this will drive adoption of websites and therefore makes them successful.

Prerequisites

Facebook App, any app, check the Facebook Developers application
A Facebook account integrated with the app you will do.
A Windows Azure account with an ACS namespace created (these can be created using the Service Bus, Access Control & Caching section of the portal) This will be used to be our host for Claims Identity Providers
SharePoint 2013 Farm. (can work with 2010)
An X.509 certificate to be used by Azure ACS and SharePoint to digitally sign tokens (and explicitly trusted by SharePoint)

Facebook Application Steps

Within the Facebook Developers application, click Create New App.
Give the app a Name and a Namespace. Click Continue.
After passing the Captcha check, select Website with Facebook Login in the next screen and enter the URL to your Azure ACS Service Namespace (e.g., https://{your namespace}.accesscontrol.windows.net). Click Save Changes.
Take note of the App ID and App Secret values that appear at the top of this screen. You will need to use these to configure Azure ACS to leverage this application. That’s all we need to do within Facebook!

Azure ACS Steps

Within Azure ACS, we must configure the following four things:

Facebook as an Identity Provider.
SharePoint as a Relying Party Application.
Claims Rule Groups to determine how Claims are passed from the identity provider to the relying party application.
The Token Signing Certificate that Azure ACS will use to prove that it is indeed the issuer of the SAML token that SharePoint receives.

Identity Provider

From within your Azure ACS management portal (e.g., https://{your namespace}.accesscontrol.windows.net) and select Identity providers from the Trust relationships section in the left navigation. In the next screen, click Add.
In the next screen, choose Facebook application and click Next.
In the next screen, enter the Application ID and Application secret values from the Facebook application you created above. You should also provide a Display name (for use within the ACS management portal) and a comma-separated list of Application permissions (note that email is the only required permission to enable Facebook users to sign in to SharePoint). You can, however, request additional permissions to do lots of fun and exciting things. Those permission strings are defined here.
You do not need to specify values for Login link text or Image URL unless you plan to configure more than one Azure ACS identity provider to use with SharePoint. If you have already configured your Relying party applications within Azure ACS, you may select them at the bottom of this screen. Otherwise, we will configure SharePoint as an RP in the next step.
Press Save to save changes.

Relying Party Application

From within your Azure ACS management portal (e.g., https://{your namespace}.accesscontrol.windows.net) and select Relying party applications from the Trust relationships section in the left navigation. In the next screen, click Add.

In the next screen, provide a name for the relying party application (I often just use the fully-qualified domain name of my SharePoint web application) and choose to Enter settings manually. In the boxes below, enter the following values:

Realm – URL of your SharePoint web application (note that a URN can also be entered here and, in many cases, is the preferred approach)
Return URL – URL of your SharePoint web application + /_trust – this is the endpoint for SharePoint’s STS, which is where Azure ACS will send the SAML token it creates. The " /_trust " is very important, if you put only web application URL, in SharePoint you will have an error that token is not from a trusted issuer.
Token format – SAML 1.1
Token lifetime – enter a value greater than the default 600 seconds, I would say 3600

In the Authentication Settings section, select the Identity provider you configured above and choose to Create a new rule group. Under Token Signing Settings, choose whether to Use service namespace certificate (if you have already configured a certificate within Azure ACS) or Use a dedicated certificate if you would like to use a different X.509 certificate exclusively for this relying party application.

Click Save to save changes.

Rule Group

From within your Azure ACS management portal (e.g., https://{your namespace}.accesscontrol.windows.net) and select Rule groups from the Trust relationships section in the left navigation. In the next screen, click Default Rule Group for {your web application}
Note that no rules are added by default. Click Generate and select the identity provider you created above.
Click Generate to generate Claims rules for the 5 values Azure ACS can obtain from a logged in Facebook user:

AccessToken – the Facebook Graph API access token
emailaddress – the email address associated with the user’s Facebook profile
expiration – the expiration date/time of the AccessToken granted above
name – the Facebook user’s display name
nameidentifier – the Facebook user’s unique profile ID (integer)

Press Save to save the rules.
Upload Token Signing Certificate
If you haven’t already, you will need to configure Azure ACS to utilize an X.509 certificate to digitally sign the tokens it generates. Optionally, you can also specify certificates to use for token encryption and decryption. I generated a self-signed certificate using the makecert utility FOR DEMO. DO NOT DO THIS IN PRODUCTION! I then uploaded this certificate by going to the Certificates and Keys link under Service settings in the ACS management portal.
Click Add to upload your certificate. This page allows you to specify where the certificate should be used, what type of certificate it is, and how to make it the primary token-signing certificate. It even includes the specific makecert command you need to run to generate a self-signed certificate (again, I cannot overemphasize how important it is that you NOT use a self-signed certificate in production!)

SharePoint 2013 Steps

New Web Application

From SharePoint 2013 Central Administration, create a new web application. Should be Claims and Claims is the default.
Make sure the host header matches the host header for the Return URL specified in the Azure ACS relying party application setup. Enable Integrated
Windows Authentication with NTLM at this step. You’ll notice no Trusted Identity providers exist at this point.
Create a new site collection at the root of the web application and choose a Windows identity for the primary Site Collection Administrator.
Configure Azure ACS as a new Trusted Identity Provider
In order to enable us to select Azure ACS as a trusted identity provider for the web application, we need to run some PowerShell. The script to run appears below.

$realm = "http://www.contoso.com"

$signinurl = "https://[your name space].accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=http%3a%2f%2fwww.contoso.com%2f"

$certloc = "C:\contoso.cer"

$rootcert = Get-PfxCertificate $certloc

New-SPTrustedRootAuthority "Facebook Azure ACS" -Certificate $rootcert

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

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

$map2 = 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"

$map3 = New-SPClaimTypeMapping -IncomingClaimType "http://www.facebook.com/claims/AccessToken" -IncomingClaimTypeDisplayName "Access Token" -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "Name Identifier" –LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

$map5 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration" -IncomingClaimTypeDisplayName "Expiration" -SameAsIncoming

New-SPTrustedIdentityTokenIssuer -Name "Facebook" -Description "Facebook" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2,$map3,$map4,$map5 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

Keep in mind:

Ensure the value for $realm matches the realm value used when creating the relying party application within Azure ACS.
Ensure the X.509 certificate used here is the same as the token signing certificate used when creating the Relying Party application within Azure ACS.
Ensure the value for $signinurl is set properly for your SharePoint web application.

Run this PowerShell script from the SharePoint 2013 Management Shell (as an Administrator). If you don’t see red text, then we are good to go

Return to the list of web applications in SharePoint 2013 Central Administration. Select the web application and press Authentication Providers.

Choose the appropriate zone and scroll down. Facebook should now appear in the list of trusted identity providers.

Select Facebook and press Save. You have now configured Azure ACS as a new trusted identity provider, and SharePoint knows it can trust SAML tokens signed with your Azure ACS token-signing certificate.

Set User Access Policy

In order for the users to access your SharePoint 2013 site once they have authenticated via Facebook, we must grant them the appropriate level of authorization. To do this, I recommend setting a “Full Read” policy for all users who authenticate to SharePoint via our “Facebook” trusted identity provider. Start by selecting the web application in Central Administration and go to User Policy.
Choose Add Users, then select the appropriate zone (All zones) and press Next.
Select the address book icon beneath the Users text box to bring up the Select People and Groups dialog.
Select All Users, then choose All Users (Facebook). Press Add to select the group.
Check the box for Full Read in the permissions section and press Finish.
The new policy is now displayed at the bottom of the list.

We are ready to test :)

Sign in to SharePoint 2013 with Facebook

Navigate to the home page of the web application. The default sign in page will appear.
Choose Facebook from the drop down list. The user will be redirected (through the Azure ACS portal) to a Facebook-hosted login page.
Enter your Facebook credentials and press Log In. The first time a user attempts to log in to your SharePoint site with Facebook, he or she will be prompted to grant the Facebook application access to the user’s basic information and email address (this is based on the permissions we set up when we initially defined the Facebook identity provider in the Azure ACS management portal).
Press Go to App. The user should be redirected back to Azure ACS, which then redirects the user back to SharePoint…logged in with Facebook credentials!
Note the user’s display name is the email address associated with the user’s Facebook account. This is because we set EmailAddress as the IdentifierClaim in the PowerShell script we ran to configure Azure ACS as a trusted identity provider.

Brief of Steps

Setting up this integration requires configuration steps to be performed in three different places:

Within Facebook, an application must be created that supports “Website with Facebook Login.”
Within the Azure ACS management portal, a new Identity Provider (IP), Relying Party (RP) application, and Rule Group must be created to inform Azure ACS about: a. The Facebook application created above. b. The SharePoint environment to be configured with Azure ACS integration below.
Within SharePoint, we must create a new web application with Claims (in SharePoint 2013, Claims is the default authentication mechanism) and configure it to point to our Azure ACS setup as a Trusted Identity Provider.

You can use some codeplex webparts that requires this technique , http://facebookwebparts.codeplex.com/

Feel free to post any questions in the comments!