Configuring SharePoint 2010 to accept Google and ADFS identities

In this article we will walk through the process of configuring a SharePoint 2010 application to use claims-based federated identity. This is one of the scenarios that we’ve heard a lot from customers. If you ever did this manually you probably spent at least a week trying to figuring out all the details. So many steps (some of them rather obscure) lead often to errors and a lot of time troubleshooting them. Our goal with Auth10 is to get that down to minutes, instead of days or weeks.

At a high level, these are the steps that we will follow.

  • Configure trust between SharePoint and Windows Azure Active Directory (previously known as Windows Azure Access Control Service).
  • Configure trust between Windows Azure Active Directory and Google.
  • Configure trust between Windows Azure Active Directory and ADFS.
  • Connect SharePoint with Google and ADFS.

We will do all these using Auth10 Dashboard which is a tool that leverages the Windows Azure Active Directory APIs to simplify, accelerate and promote the best practices around federated identity.

Here is a diagram of the scenario

If you are a visual learner, then you can skip all these and watch these two screencasts of about 2-3 minutes each:

Otherwise, keep reading!

1 - Create the application

Signup to Auth10 (no credit card, it’s free).

In the dashboard, create a new application, give it a friendly name and choose “SharePoint 2010” as the application type.

Enter the URL of the SharePoint application (this URL will be used to locate the SharePoint app from the scripts later) and the attribute that will identify the user.

2- Configure SharePoint

Now you have to download a configuration package that will automate the configuration with SharePoint 2010 using PowerShell. The setup page will also show what the script will actually do. This script is generated by Auth10 and is customized with the information you supplied.

Unzip the package and execute the RunMe.cmd in the SharePoint server. It could take 5 minutes at most.

3- Create the Google user group

Go back to the Auth10 dashboard and create a user group. Give it a friendly name like “Google Users”

Notice that here you have the option to restrict the users logging in with this identity provider. This is optional but could be useful as a first level authorization for your applications (no need to touch the app). Windows Azure Active Directory won’t issue a token if the user doesn’t belong to that list.

Example: Let’s say that you have a SharePoint portal or just a simple web application and you want to give access to the group of designers who need to exchange information with your employees. You would create a user group called “Designers” and add the emails to that list. So when you connect that group with an application, only those users will be able to access that application.

4- Connect the SharePoint app with the Google user group

We have created the application and the user group, now it’s time to connect them. To do that, you can click on connect and drag and drop the app and the user group

Choose a Passthrough rule to simply copy all the attributes coming from the identity provider to the application

This is how the dasbhoard will look like after connecting the app and the user group:

5- Login to SharePoint with Google

Now it’s time to test it! Browse to the SharePoint application and you should get a screen like this:

The user gets redirected to Google. Enter the user and password.

The user has been logged in, but doesn’t have permissions to access the site with that identity yet. The portal administrator would have to give access using the People Picker for that Google email.

6- Create the Active Directory Federation Services user group

Now that we have the SharePoint application working with Google users, let’s add another user group. This time we will choose Active Directory Federation Services 2.0 (ADFS) as the authentication type.

When you configure a trust relationship with ADFS, you will need the public key and the ADFS endpoint. ADFS provides a FederationMetadata document containing that information and it’s located at https://[your_adfs_server]/FederationMetadata/2007-06/FederationMetadata.xml

ADFS will only issue tokens to registered applications (formally called Relying Parties). Once the user group has been created Auth10 will show the Setup instructions and a configuration package you can download that will contain a script that uses the ADFS PowerShell CmdLets to create the Relying Party Trust and some additional rules in ADFS. If you click “More information about this configuration package” you can see what this script will do in detail.

7- Connect the SharePoint app with the ADFS user group

As we did with Google, we have to connect SharePoint with this user group that will authenticate with ADFS. To do that, we will click the Connect button, drag and drop SharePoint and Test Company Employees AD user group and create a Passthrough mapping rule. This is how the dashboard looks like after we have the SharePoint app connected with the two groups.

8- Login to SharePoint with ADFS

The final test is to login to SharePoint using ADFS. When browsing to the SharePoint application, we now get Google and ADFS as authentication options. It’s worth mentioning that this login dialog can be customized and even have different options (based on a subdomain, a querystring, etc.)

If we choose Test Company Employees AD we will get redirected to the ADFS.

Finally a token is issued by ADFS and POSTed to Windows Azure Active Directory. WAAD will generate another token that will finally be POSTed to SharePoint and we are logged in (again with a user who doesn’t have access yet).

Conclusion

This walkthtough demonstrates a scenario of a SharePoint application being accessed by users logging in with Google and ADFS. It can be implemented easily and fast with Auth10 within minutes instead of days or weeks and using the best practices.

Author: Matias Woloski

Published: July 04 2012

blog comments powered by Disqus