Tool to Get Token Signing Certificate Out of ACS

I continue to be regularly annoyed when I want to go snag the token signing certificate out ACS for use with federating to my various projects, like SharePoint sites.  I’ve written in a couple or more blog postings about how you go to your tenant, find your federation metadata xml endpoint, retrieve the Xml from the browser, paste it in notepad, find the cert, copy it out, paste it in a new notepad instance, and save it as a certificate.  In a word, ridiculous.  So I finally just wrote a stupid little app to do all that for you.  All you have to do is give it your ACS instance name – like if your ACS instance is at contoso.accesscontrol.windows.net then you just give it “contoso”.  You tell it where you want the token signing certificate saved, click a button, and that’s it – all done.

I’ve attached it here along with the source code, so hope you find it useful.

You can download the attachment here:

Troubleshooting Blank Response Pages When Using Federation with ACS and Facebook

I’ve had this scenario come up a few times now when working through various federation scenarios.  These cases always involve using Facebook as an oAuth source for login, or Azure’s AppFabric ACS as a federated identity provider.  The common behavior is that you are doing something either interactively through the browser or programmatically by making a POST to ACS.  In either case, you get an error in the response, but the error is generally nondescript.  For example, when using Facebook’s oAuth feature you get redirected to their site to login, you enter your credentials, and then you get redirected back to your application.  When there is a problem though, in most cases the browser will just say you got a 400 response and the server encountered an error.  That’s it.  Same thing when programmatically posting to ACS – when there’s a problem you will often get a 400 type response back that often says “page not found” or something similar.  How does that help you?  It doesn’t!

Sadly, what I’ve discovered is the best thing to do when you see these pages is to use Fiddler (www.fiddler2.com).  You will find signifcantly more details in the Fiddler response then the browser will ever show you.  For example, with one of the ACS issues I saw in Fiddler that the response included details that said the POST message was incorrectly formatted.  Ah, yeah, that’s a lot more useful than “page not found’, which doesn’t make sense to begin with.  Or with Facebook, we discovered that in Fiddler the response actually said you’re redirecting back to an invalid or untrusted URI.  Yeah, that’s a lot more useful than just giving me a 400 error and saying bad request.

So that’s the point – when you get to these apparent dead ends, fire up Fiddler and look at the details of the responses to try and find actual useful details about what has happened. 

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

In the first post in this series (http://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.

  1.  
    1. 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 http://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

  1.  
    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.

3.       Create a Trust Between ADFS and ACS

  1.  
    1. 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
    2. 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
    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 identity provider and click the Next button.
    8. 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 http://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:

  1. Click on Add Rule.
  2. Select the Pass Through or Filter an Incoming Claim in the Claim Rule Template drop down and click the Next button.
  3. 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

  1.  
    1. 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
    2. Click on the Add link
    3. Fill out the Relying Party Application Settings section
      1.  Enter a display name, like “ADFS to ACS”
      2. Use the default Mode of Enter settings manually
      3. 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 http://yourFullyQualifiedAdfsServerName/adfs/services/trust.
      4. For the return Url use https:// yourFullyQualifiedAdfsServerName /adfs/ls/.
      5. 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
      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. 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.
      2. 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.
    5. 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 SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1

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:

  1. 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.
  2. 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.  
    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.  
    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 http://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.  
    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.  
    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):

<RoleDescriptor xsi:type=”fed:SecurityTokenServiceType” protocolSupportEnumeration=”http://docs.oasis-open.org/wsfed/federation/200706&#8243; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xmlns:fed=”http://docs.oasis-open.org/wsfed/federation/200706″&gt;

<KeyDescriptor use=”signing”>

<KeyInfo xmlns=”http://www.w3.org/2000/09/xmldsig#”&gt;

<X509Data>

<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.  
    1. Add the ACS token signing certificate to the list of trusted root authorities in SharePoint.  You can do that as described at http://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.  
    1. The next step is to create your new SPTrustedIdentityTokenIssuer.  I’ve described this in various places; you can use http://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.&nbsp; 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