Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 2
In the first post in this series (https://blogs.technet.com/b/speschka/archive/2011/05/05/federated-saml-authentication-with-sharepoint-2010-and-azure-access-control-service-part-1.aspx) I described how to configure SharePoint to establish a trust directly with the Azure Access Control (ACS) service and use it to federate authentication between ADFS, Yahoo, Google and Windows Live for you and then use that to get into SharePoint. In part 2 I’m going to take a similar scenario, but one which is really implemented almost backwards to part 1 – we’re going to set up a typical trust between SharePoint and ADFS, but we’re going to configure ACS as an identity provider in ADFS and then use that to get redirected to login, and then come back in again to SharePoint. This type of trust, at least between SharePoint and ADFS, is one that I think more SharePoint folks are familiar with and I think for today plugs nicely into a more common scenario that many companies are using.
As I did in part 1, I’m not going to describe the nuts and bolts of setting up and configuring ACS – I’ll leave that to the teams that are responsible for it. So, for part 2, here are the steps to get connected:
1. Set up your SharePoint web application and site collection, configured with ADFS.
-
- First and foremost you should create your SPTrustedIdentityTokenIssuer, a relying party in ADFS, and a SharePoint web application and site collection. Make sure you can log into the site using your ADFS credentials. Extreme details on how this can be done is described in one of my previous postings at https://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx.
2. Open the Access Control Management Page
-
- Log into your Windows Azure management portal. Click on the Service Bus, Access Control and Caching menu in the left pane. Click on Access Control at the top of the left pane (under AppFabric), click on your namespace in the right pane, and click on the Access Control Service button in the Manage portion of the ribbon. That will bring up the Access Control Management page.
3. Create a Trust Between ADFS and ACS
-
- This step is where we will configure ACS as an identity provider in ADFS. To begin, go to your ADFS server and open up the AD FS 2.0 Management console
- Go into the AD FS 2.0…Trust Relationships…Claims Provider Trusts node and click on the Add Claims Provider Trust… link in the right pane
- Click the Start button to begin the wizard
- Use the default option to import data about the relying party published online. The Url you need to use is in the ACS management portal. Go back to your browser that has the portal open, and click on the Application Integration link under the Trust relationships menu in the left pane
- Copy the Url it shows for the WS-Federation Metadata, and paste that into the Federation metadata address (host name or URL): edit box in the ADFS wizard, then click the Next button
- Type in a Display name and optionally some Notes then click the Next button
- Leave the default option of permitting all users to access the identity provider and click the Next button.
- Click the Next button so it creates the identity provider, and leave the box checked to open up the rules editor dialog. The rest of this section is going to be very similar to what I described in this post https://blogs.technet.com/b/speschka/archive/2010/11/24/configuring-adfs-trusts-for-multiple-identity-providers-with-sharepoint-2010.aspx about setting up a trust between two ADFS servers:
You need to create rules to pass through all of the claims that you get from the IP ADFS server. So in the rules dialog, for each claim you want to send to SharePoint you're going to do the following:
- Click on Add Rule.
- Select the Pass Through or Filter an Incoming Claim in the Claim Rule Template drop down and click the Next button.
- Give it a Claim Name - probably including the name of the claim being passed through would be useful. For the Incoming Claim Type drop down, select the claim type you want to pass through, for example E-Mail Address. I usually leave the default option for Pass through all claim values selected, but if you have different business rules then select whatever's appropriate and click the Finish button. Note that if you choose to pass through all claim values ADFS will give you a warning dialog.
Once you've added pass through claims for each claim you need in SharePoint you can close the rules dialog. Now, for the last part of the ADFS configuration, you need to find the SharePoint relying party. Click on the Edit Claim Rules dialog, and for each Pass Through claim rule you made in the previous step, you ALSO need to add a Pass Through claim rule for the SharePoint relying party. That will allow the claims to flow from ACS, to ADFS through the trusted claim provider, and out to SharePoint through the trusted relying party.
Your ADFS configuration is now complete.
4. Add ADFS as a Relying Party in ACS
-
- Go back to your browser that has the portal open, and click on the Relying party applications link under the Trust relationships menu in the left pane
- Click on the Add link
- Fill out the Relying Party Application Settings section
- Enter a display name, like “ADFS to ACS”
- Use the default Mode of Enter settings manually
- In the Realm edit box you need to enter the realm that ADFS will be sending with the request. As it turns out, ADFS has a specific list of realms that it sends when redirecting to another identity provider, so you DO NOT use the realm that was used when creating the SPTrustedIdentityTokenIssuer in SharePoint. Instead, I recommend you use https://yourFullyQualifiedAdfsServerName/adfs/services/trust.
- For the return Url use https:// yourFullyQualifiedAdfsServerName /adfs/ls/.
- The Token format drop down can be SAML 2.0 or 1.1. Since the token is getting sent to ADFS and not SharePoint, and ADFS supports SAML 2.0 tokens, you don’t need to drop down to SAML 1.1 like you would if connecting directly to SharePoint
- You can set the Token lifetime (secs) to whatever you want. It’s 10 minutes by default; I set mine to 3600 which means 1 hour.
- Fill out the Authentication Settings section
- For the identity providers you can select them all, except and unless you have added your same ADFS server previously as an identity provider (as you would have if you followed the steps in the first posting in this series). If you did do that, then you can check everything except for the identity provider that points back to your same ADFS server that you are now setting up as the relying party.
- Under Rule groups, in the interest of time, I’m going to suggest you either follow the guidance for rule groups that I explained in part 1, or if you completed part 1 then just select that rule group from the list.
- In the Token Signing Settings you can leave the default option selected, which is Use service namespace certificate (standard).
Click the Save button to save your changes and create the relying party.
You should be able to login into your SharePoint site now using ADFS or ACS. One thing to remember though is that ADFS will write a cookie to remember what identity provider you last used. From that point forward it won’t prompt you for the identity provider unless you use something like an InPrivate browsing window in IE (I highlight this in extra big font because it is so commonly forgotten and a source of confusion). For example, here’s what it looks like the first time you are redirected to the ADFS server or if you are using an InPrivate browser session:
The rest of it works just as described in part 1 of this series (including the caveat about using an email address for Windows Live ID), so I won’t both posting screenshots again since they look almost identical. With this series complete now you should be able to successfully integrate ADFS, ACS, and all of the identity providers ACS supports into your SharePoint 2010 environment.
Federated Auth with SharePoint and ACS Part 2.docx
Comments
- Anonymous
January 01, 2003
thanks - Anonymous
September 18, 2014
The comment has been removed - Anonymous
December 05, 2014
The comment has been removed