Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1

Artigo
05/05/2011

I had been looking at Windows Azure Access Control Service (ACS) with an interesting eye recently, thinking about some of the different integration options. There’s always lots of chatter about claims authentication with SharePoint 2010, and how to integrate ADFS, Windows Live, Facebook, etc. ACS (also known as AppFabric ACS to you Azure purists / marketing people) is rather cool because it includes “connectors” for these common identity providers out of the box. When you set up an ACS namespace (think of it like an account with connectors and configuration settings), you have simplified and streamlined connectivity to ADFS 2.0, Windows Live, Yahoo, Google and Facebook. The lazy programmer in me thinks hey, there must be something goin’ on there so I decided to look into it from a couple of different angles. I’m going to describe the first one in this post.

For this scenario I really just wanted to establish a trust directly between SharePoint 2010 and ACS. I wanted to be able to use ADFS, Windows Live, Yahoo and Google accounts to authenticate and get into my SharePoint site. I didn’t include Facebook because social computing is really not my thing (this blog’s as close as I get) so I don’t have a Facebook or Twitter account because I’m really not interested in frequently sharing pointless information with the world at large (“Puffy just had 3 kittens – Adorable!! ”). I will NOT be explaining how to get a Windows Azure account, create an Access Control Service namespace, how to manage ACS, etc. – there should be reams of info out there from the Windows Azure folks so I’m not going to try and reinvent that.

What I am going to describe is the process of setting up the various trusts, certificates, and configuration necessary to get all this stuff working together. At the end I’ll include some screenshots of me logged in with identities from each of those providers. Here are the steps to get connected:

Open the Access Control Management Page
1. 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.
Add An Identity Provider for ADFS
1. Click on Identity providers in the Trust relationships menu in the left pane.
2. Click on the Add link
3. The WS-Federation identity provider radio button should be selected by default; check it if it is not. It is what’s used for ADFS 2.0. Click the Next button.
4. Fill out the Identity Provider Settings section
  1. Fill out the Display name, such as “My ADFS Server”
  2. For the WS-Federation metadata, if your ADFS server is exposed via the Internet then you just put in the Url to the federation metadata endpoint. By default it’s at https://yourAdfsServer.com/FederationMetadata/2007-06/FederationMetadata.xml. If your ADFS server is not exposed to the Internet, then open the Url to the endpoint in your local browser. Go to your browser and save the page to the local file system as an .XML file. Then in the Identity Provider Settings in ACS click the radio button next to the File edit box and use the Browse button to find the federation metadata xml file you just saved.

That’s pretty much all you need to do to create your Identity Provider in ACS.

3. Add A Relying Party for SharePoint

1. Now you need to add SharePoint as a relying party of ACS, just like you do when you configure SharePoint and ADFS together. Start by clicking the Relying party applications link under the Trust relationships menu in the left pane
2. Click on the Add link.
3. Fill out the Relying Party Application Settings section
  1. Enter a display name, like “SharePoint 2010”
  2. Use the default Mode of Enter settings manually
  3. In the Realm edit box enter a realm, and save that because you will use it again when you create your SPTrustedIdentityTokenIssuer in SharePoint. For purposes of this example let’s say the realm is “urn:sharepoint:acs”.
  4. For the return Url use the same format as you do when setting up SharePoint as a relying party in ADFS: https://yourSiteName/_trust/.
  5. The Token format drop down should be SAML 1.1
  6. 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.
4. Fill out the Authentication Settings section
  1. Check every box under the Identity providers; it should show you the ADFS identity provider you created in the previous step
  2. Under Rule groups leave the default checked, which is Create new rule group.
5. In the Token Signing Settings you can leave the default option selected, which is Use service namespace certificate (standard).
6. Click the Save button to save your changes and create the relying party

4. Create the rules for the Relying Party

1. I’m assuming here that you have not already created a set of rules in ACS before so we’re creating a new group of them. If you had a group you wanted to reuse then in the previous step you would have just placed a check next to the group(s) you want to use with the relying party instead of taking the default of Create new rule group. But since we’re creating a new one, click on the Rule groups link under the Trust relationships menu in the left pane
2. You should see a rule group that has a name like “Default Rule Group for whatever your relying party name was”. Click on that link for that rule group name
3. Really the easiest thing to do at this point is just to click on the Generate link. It will automatically create a set of rules for you that basically enumerates all of the claims you’ll be getting from each identity provider, and then creates a rule for each one that passes through that claim value with the same claim type to the relying party
4. On the Generate Rules page, just check the box next to each identity provider and click the Generate button. This creates the rules as I’ve described previously. When it’s complete you are redirected to the Edit Rule Group page, where you will see all the rules listed. In many cases this would be enough, but we have one anomaly here that we need to account for. In SharePoint, we’re going to use the email address as the identity claim. Ironically, all the identity providers send the email address along (and have rules created for them to do so) except for Windows Live. So for now, for this example, I am faking the Windows Live piece of it. What I mean by that is that I am going to take the one claim it does provide – nameidentifier – and I’m going to create a rule that passes that back, but it’s going to pass it back as an email claim. This is not the time to hate on Steve, this is just a way to get this demo environment running with the fewest moving parts (and there are several already). Now we’ll add this final rule
5. Click on the Add link
6. In the Identity Provider drop down, select Windows Live I
7. In the Input claim type section, click the radio button next to Select type:. There’s only one claim type that Windows Live ID supports so it is already selected (nameidentifier)
8. Scroll down to the Output claim type section and click the radio button next to Select type:
9. In the drop down list find https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress and select it
10. Enter a description if you’d like, then click the Save button to save your changes and create the rule
11. You’ll be redirected to the Edit Rule Group page, then click the Save button to save all your changes. You’re now done with the ACS configuration, but don’t close the browser yet because you will need to get some additional information from there when you create and configure the other components.

5. Create a Relying Party for ACS in ADFS

1. While ADFS is an identity provider to ACS, ACS is a relying party to ADFS. That means we need to configure a relying party in ADFS so that when ACS redirects an authentication request to ADFS a trust has been established that allows ADFS to respond. Begin by going to your ADFS server and opening up the AD FS 2.0 Management console
2. Go into the AD FS 2.0…Trust Relationships…Relying Party Trusts node and click on the Add Relying Party Trust… link in the right pane
3. Click the Start button to begin the wizard
4. 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
5. 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
6. Type in a Display name and optionally some Notes then click the Next button
7. Leave the default option of permitting all users to access the relying party and click the Next button
8. Click the Next button so it creates the relying party
9. Once the relying party is created, you and open the Rules Editor in ADFS to create new rules for passing claim values to ACS
10. With the Issuance Transform Rules tab selected, click on the Add Rule… button
11. Leave the default template of Send LDAP Attributes as Claims selected and click the Next button.
12. Fill out the rest of the rule details:
  1. Type in a claim rule name
  2. From the Attribute store: drop down select Active Director
  3. In the Mapping of LDAP attributes section, map
    1. LDAP attribute E-Mail-Addresses to Outgoing Claim Type E-Mail Address
    2. LDAP attribute Token-Groups – Unqualified Names to Outgoing Claim Type Role
  4. Click the Finish button to save your rule. ADFS configuration is now complete.

6. Configure the SharePoint Trust with ACS

1. This is a multi-step process that begins with getting the token signing certificate from ACS. Fortunately the certificate is included in the FederationMetadata.xml file, so we will retrieve it from there and save it locally to the SharePoint server. On the SharePoint Server, open a browser and open the Access Control Management page as described above
2. 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 it into your browser. The ACS FederationMetadata.xml file will be displayed in the browser.
3. Find the section that looks like this (it's about the second major section down from the top of the page):

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

Copy the data out of the X509Certificate element and paste it into notepad. Save it with a .CER file extension (the encoding should be ANSI); for purposes of this post let’s assume you call the file C:\AcsTokenSigning.cer. This is the token signing certificate for ACS.

1. Add the ACS token signing certificate to the list of trusted root authorities in SharePoint. You can do that as described at https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx or you can add it with PowerShell like this:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\AcsTokenSigning.cer")

New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert

1. The next step is to create your new SPTrustedIdentityTokenIssuer. I've described this in various places; you can use https://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspxas a starting point (just scroll down to the information that comes AFTER setting up ADFS). Some things to remember:
  1. Both name and nameidentifier are reserved claim types in SharePoint, so even though nameidentifier is the only common claim across the standard identity providers in ACS it isn't an option for your identity claim. Instead I recommend for now just falling back on email address and adding the appropriate rules in ACS as I’ve described above
  2. The SignInUrl parameter for the New-SPTrustedIdentityTokenIssuer should point to your ACS instance. For example, https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation. You can find this by looking at the Relying Party you set up in ADFS for ACS. Open up the Relying Party properties dialog, click on the Endpoints tab, and use the Url it displays for the WS-Federation Passive Endpoint for the POST binding (it should be the only one there).
2. The last step is just to create your web application, configure it to use claims authentication and the SPTrustedIdentityTokenIssuer you created for ACS, and finally create a site collection in the web application and begin testing.

At this point you should be ready to hit the site and give it a try. Remember that you’ll need to configure the site collection administrator to be one of the email addresses that one of the identity providers will return so you can log into the site. Once in there you can add email addresses or role claims from providers to SharePoint groups just as you would normally expect to do.

The one caveat to remember again, for now, is Windows Live ID. As stated previously in this post, you won’t really have a valid email address for Windows Live so you will need to add what they call the PUID to your SharePoint group. For testing purposes, the easiest way to get this is to log in using Windows Live ID, and then you will reach the page in SharePoint that says you are logged in as “foo” and access is denied. From there you can copy the PUID, login as an admin user, add the PUID to a SharePoint group and you should be good to go. I haven’t even looked at what kind of directory options, if any, are available for Windows Live ID (I’m guessing probably none). But it’s a start so we can move this proof of concept along. Now that we’ve done that, here’s what it looks like logging into my site using each of these identity providers:

Login Page

ADFS

Google

Yahoo

Windows Live ID

Federated Auth with SharePoint and ACS Part 1.docx

Comments

Anonymous
January 01, 2003
Steve, I know you're leaving the Azure stuff up to the Azure team, but I'm struggling to understand why you would do this. Does ACS provide a better way to use LiveID and ADFS or is it just needed for Yahoo and Google? What does the login screen look like? Thanks, Tom
Anonymous
January 01, 2003
hi steve we used this blog to create our claims based sharepoint application but when we run it selecting adfs 2.0 for sign in it gives the error as : the token issuer is not a trusted issuer can u please help me in this thanks , seema sharma
Anonymous
January 01, 2003
thanks
Anonymous
January 01, 2003
Hey Darin, I've never tried...I'm sure it's possible, although I'm not entirely sure I follow the use case for UAG in this scenario. Not diggin' on what you're saying, I'm just not following the need. Steve
Anonymous
May 11, 2011
Steve, this is tasty stuff and I think based on this we're going to use ACS with our in-the-works SharePoint deployment. What's your take on the use of Forefront UAG in there? (technet.microsoft.com/.../dd861393.aspx) Can you tie UAG to ACS just like UAG to ADFS? SharePoint <--> UAG <--> ACS <--> ADFS / WLID / Google / Yahoo / Facebook Cheers.
Anonymous
May 24, 2011
Hi In this example, when Sharepoint is using ACS as Identity Provider only, why do I need to "Add A Relying Party for SharePoint" in ADFS? The chain is like Sharepoint --> ACS --> Windows Live, Facebook, ADFS. Since we dont need to do something special for Windows Live and Facebook in this scenario, why an exception for ADFS? I would appreciate if you can reply to my question on my mail akshayakrsh@hotmail.com Thanks
Anonymous
November 15, 2011
The comment has been removed
Anonymous
November 22, 2011
Hi steve this is absolutely working fine ,but i was trying to customize the acs default login page and access through the sharepoint application,It works for asp.net application but does'nt work for sharepoint. Can you please help me in this. Thanks, Seema Sharma.
Anonymous
January 08, 2014
Pingback from SharePoint 2010 and Windows Azure App Fabric Access Control (ACS) | David McWee
Anonymous
May 21, 2014
The comment has been removed
Anonymous
May 23, 2014
I tried it in Firefox and it worked. however, i didn't search for any config issues in IE yet.
Anonymous
September 18, 2014
The comment has been removed
Anonymous
December 05, 2014
The comment has been removed
Anonymous
March 01, 2015
In the first post in this series ( http://blogs.technet.com/b/speschka/archive/2011/05/05/federated-saml
Anonymous
March 02, 2015
NOTE: I updated this 10/9/2013 because some of the Url references I had below had changed between when

Partilhar via

Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1

Comments

Recursos adicionais