Archives / 2012 / February
  • Visual guide to Azure Access Controls Services authentication with SharePoint 2010 - part 6 - Facebook integration

    Tags: Windows Azure, SharePoint 2010

    Another post you think! Does this guy have a life? Well, actually I do. But once you get me started , I'm hard to stop...

    This sixth post in the Visual guide to Azure Access Controls Services authentication with SharePoint 2010 is going to show you how to leverage some of the features that Azure ACS provides you with when using Facebook as Identity Provider. I'm going to show you how to use the Facebook Graph API and retrieve information about the user (and possible his/hers friends) - this is of interest if you're going to build a community or something similar on top of SharePoint 2010. For instance we can use the information from Facebook and push into the SharePoint 2010 User Profile service once the user has signed up..

    Sit back and relax, while I show you how to do this...

    Add the Facebook AccessToken claim

    First of all I assume that you have configured Facebook as one of the Identity Providers as detailed in part 3, secondly we're going to use the approach with custom claims that we learnt in part 5. When you configured Facebook as an IP for your Relying Party Application and auto-generated Rules for the IP, then ACS automatically created some output claims for us. Especially the "" is of interest in this case.

    AccessToken in ACS

    This is a claim contains the access token required to do authenticated calls to the Facebook Graph API. And we will add this claim as in incoming claim to the Trusted Identity Provider in SharePoint 2010.

    The AccessToken claim

    There is also another output claim that you should be aware of if building production code (which I'm not doing here) and that is the "" claim that contains the expiration time for the access token. You might need to check that so the user has to re-authenticate to get a new access token.

    Ok, since Azure ACS has everything already in place for us, we only need to fix the Trusted Identity Provider in SharePoint. Just as in part 5 we'll add the claim using this snippet of PowerShell.

    $map = New-SPClaimTypeMapping     -IncomingClaimType ""     -IncomingClaimTypeDisplayName "AccessToken"     -SameAsIncoming $tip = Get-SPTrustedIdentityTokenIssuer "Visual AuthN ACS" $tip.ClaimTypes.Add("") Add-SPClaimTypeMapping -Identity $map -TrustedIdentityTokenIssuer $tip $tip.Update()

    Adding a claim type mapping

    Once this is done, just log out and in again using a Facebook account and we should see the new claim.

    The claim

    Now, we are all set to use this Access Token in some custom code. I know you've been waiting for some code in this series - it's far too much clickety-click and PowerShelling...

    Use the Facebook Graph API in a Web Part

    To show you how to use the Facebook Graph API I'm building a simple Visual Web Part that is going to write the name of the Facebook user, the favorite quotes and show the profile picture. I'm not going into details on the Graph API here and there are a lot of .NET implementations/libraries that you can use, but for this demo this simple method is sufficient:

    private Hashtable callGraphApi(Uri uri, string accessToken) {
        UriBuilder builder = new UriBuilder(uri);
        if (!string.IsNullOrEmpty(builder.Query)) {
            builder.Query += "&";
        builder.Query += "access_token=" + accessToken;
        JavaScriptSerializer jsSerializer = new JavaScriptSerializer();
        using (WebClient client = new WebClient()) {
            string data = client.DownloadString(builder.ToString());
            return jsSerializer.Deserialize(data);

    This method takes a Graph API Url and the access token and returns a HashTable of the data. The implementation of the Visual Web Part is very simple, the Page_Load method is modified as follows:

    protected void Page_Load(object sender, EventArgs e) {
        try {
            IClaimsPrincipal principal = Page.User as IClaimsPrincipal;
            IClaimsIdentity identity = principal.Identity as IClaimsIdentity;
            var accessToken = (from claim in identity.Claims
                                where claim.ClaimType == ""
                                select (string)claim.Value).FirstOrDefault();
            Hashtable me = callGraphApi(new Uri(""), accessToken);
            name.Text = me["name"].ToString();
            quote.Text = me["quotes"].ToString();
            image.ImageUrl = String.Format("{0}/picture", me["id"].ToString());
        catch (Exception ex) {
            error.Text = ex.ToString();

    First of all, I'm using a Linq snippet to get the access token and then I'll do a call to the Graph API and retrieves data for the current user. The info is then just inserted into a few Label controls and an Image control. If you log in using a Facebook account and watch this Web Part it should look something like this:


    What! Why do I get this error! Wictor showed me everything!? Don't be such a cry baby, remember that SharePoint keeps it's own certificate store! And it does only trust certificates in that specific internal SharePoint store. So we need to grab the certificate and add that to SharePoint. To get the certificate I use Firefox (IE9 does not allow me to save the certificate!) and browse to You'll get an error but ignore that and click on the Facebook logo in front of the address, and then click on more information.

    Get the cert

    When the dialog appears, click on View Certificate and then finally on the Details tab use the Export button and save the certificate as a X.509 Certificate (PEM) file.

    Save it

    Copy this file to one of your SharePoint 2010 boxes and run the following PowerShell:

    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\-.facebook.crt") New-SPTrustedRootAuthority -Name "Facebook" -Certificate $cert

    Trust Facebook!!!!

    This will add the Facebook certificate to the SharePoint Certificate store and SharePoint will now trust Facebook! So reload the page with the Facebook Web Part again and voila...

    It's working...

    Imagine what you can do with this. For instance on the first time log in - set the correct user name, upload the user profile picture etc etc. Now we're talking!

    More stuff...

    If you need access to more information in the Graph API, such as statuses, friends etc you need to configure the permissions for the Facebook Identity Provider in Azure ACS. For instance if I would like to read out the status updates for a user I need to add the user_status permission to the Facebook Identity Provider in Azure ACS.


    Then when the user re-authenticates it will be prompted by Facebook to allow these new permissions.

    More permissions needed

    And now your application is allowed to read out status updates using the Graph API. You can find a list of all the available permissions here.

    Tip: If you want to experiment with different Graph API Urls use the followin tool: You can copy and past your access token to the tool to see exactly what you can retrieve using that access token and your Facebook application permissions.


    Now we've gone a long way from configuring Azure ACS and using simple Authentication using Google ID and Facebook to provide deeper integration with the external services. Good luck in building your own community sites!

  • Visual guide to Azure Access Controls Services authentication with SharePoint 2010 - part 5 - Custom Claims

    Tags: Windows Azure, SharePoint 2010

    This is the fifth post in the Visual guide to Azure Access Control Services authentication with SharePoint 2010 and this time it is time to augment some claims using the Azure ACS. We'll do this to prepare for the next exciting part. For this post I assume you have configured at least one Web Application to use Facebook login using Azure ACS - make sure that you've followed post 1 and post 3 and optionally post 4 thoroughly.

    Why augment custom claims?

    Sometimes you need more information from the users than just the e-mail and name. Perhaps you would like to get the phone number, age or other stuff. If you have that data in your identity provider you can augment that information (claim) to SharePoint. With Azure ACS you only have a specific set of data, unless you use a custom Identity Provider in Azure, such as ADFS. The default Identity Providers (Live ID, Google ID, Yahoo and Facebook) in Azure only has a limited set of claims that is sent to SharePoint.

    Using Azure ACS we can augment brand new claims - using the Rules editor in the Azure ACS management UI. You can create new output claims from scratch or new output claims based on values from the other input claims. In this scenario we're going to create a completely custom claim called "Identity Source" which will identify from where the identity is coming (Facebook, Yahoo or Google). We will then be able to use this in SharePoint to target information.

    If we log in to SharePoint using a Facebook account these are the claims that we get by default:

    Claims, claims, claims

    These claims are retrieved through a very simple Visual Web Part containing a DataGrid and the following code behind:

    protected void Page_Load(object sender, EventArgs e) {
        IClaimsPrincipal principal = Page.User as IClaimsPrincipal;
        IClaimsIdentity identity = principal.Identity as IClaimsIdentity;
        var data = from claim in identity.Claims
            select new {
                Claim = claim.ClaimType,
                Value = claim.Value
        GridView1.DataSource = data;

    Adding a custom claim in Azure ACS

    As usual we'll begin with the configuration in Azure. We would like to create a new claim with the following name It will have the value Facebook when logging in using a Facebook account and the value Google when logging in with Google Id.

    In Azure ACS go to Rule Groups and select the Rule Group that you use for your Relying Party Application. Click Add to create a new Rule. In the If section we choose Facebook as Input claim Issuer, and then for Input claim type select Any and leave Input claim value set to Any.


    In the Then section enter our own Output claim type and use the name above. For Output claim value we enter Facebook, since that is the value we want SharePoint to receive for this claim. Finally always write a description on the rule - if you have many it can be a mess finding them otherwise. Once you're done click Save.


    Repeat the procedure for the Google IP. Add a new Rule with Google as Input claim issuer and the Output claim value set to "Google" - the rest should be the same as above. The Rule Group should look like this after these two operations:

    There they are...

    Configure the SharePoint Trusted Identity Provider

    Now we need to configure the Trusted Identity Provider in SharePoint 2010 so that it accepts these incoming claims. And of course this is done in PowerShell. First we create a new claim mapping and then get a handle on our Trusted Identity Provider. After that we add our custom claim type to the trusted IP and finally add a claim mapping, before we persist the values.

    $map = New-SPClaimTypeMapping     -IncomingClaimType ""     -IncomingClaimTypeDisplayName "Identity Source"     -SameAsIncoming $tip = Get-SPTrustedIdentityTokenIssuer "Visual AuthN ACS" $tip.ClaimTypes.Add("") Add-SPClaimTypeMapping -Identity $map -TrustedIdentityTokenIssuer $tip $tip.Update()


    That's it - we should be ready to test it now...

    Validate the the claims

    If we log out and in again (this is required to get the new set of claims) we should see that our new claim is there and with the correct value.

    We got our claim!!!

    If you have configured a separate web application and a secondary trusted identity provider, shown in the previous article, you will also see this claim - without modifying the secondary trusted IP. Cool huh!

    We can now use this claim to set permissions using the people picker:

    People Picker


    I've now shown you how easy it is to augment claims using Azure ACS and to leverage them in SharePoint 2010. There are tons of cases where this is important and very useful. In the next post we'll add another claim for Facebook users - which will allow us to do some really cool stuff.

  • Visual guide to Azure Access Controls Services authentication with SharePoint 2010 - Index Post

    Tags: Security, Windows Live, Windows Azure, SharePoint 2010

    This post serves as an index for all the articles in the Visual guide to Azure Access Controls Services authentication with SharePoint 2010

    This series is a set [not yet determined amount] of articles where I show you how to leverage the Azure Access Controls Services (ACS) in combination with SharePoint 2010 to make it easier for you to use identity providers such as Google ID, Windows Live ID, Facebook AuthN etc.


    • Part 1 - basic setup This article guides you through the basic setup of ACS and SharePoint 2010, from creating the Azure ACS endpoints to configuring the identity providers and relying party to finalizing the setup in SharePoint 2010  and finally log in using Google ID credentials.
    • Part 2 - common problems Even though if you follow all the instructions in part 1 you or more likely your colleague will run into problems. This article discusses the most common problems - and will hopefully be updated as time flies by.
    • Part 3 - Facebook Authentication The third part shows how to enable Facebook Authentication for your Azure ACS namespace and log in using a Facebook account to SharePoint 2010.
    • Part 4 - Multiple Web Applications This post will show you how to handle the case when you have multiple web applications and would like to use the same Azure ACS settings.
    • Part 5 - Custom Claims In this post we'll take a look at how we can add custom claims through Azure ACS and leverage them in SharePoint.
    • Part 6 - Facebook Integration In this post we'll use the features in Azure ACS to do deeper integration with the Facebook Graph API.
    • Part 7 - Customize the login experience
    • ...

    Note: this is what is actually written and planned for now . Any planned posts might change over time...

    Happy reading!

  • Visual guide to Azure Access Controls Services authentication with SharePoint 2010 - part 4 - multiple web applications

    Tags: Security, Windows Azure, SharePoint 2010

    Back with another promised post in the Visual guide to Azure Access Controls Services authentication with SharePoint 2010. This time I'm going to show you how to work with multiple web applications. We're going to use the stuff we configured in part 1 (basic setup) and part 3 (Facebook setup), and hopefully we're avoiding the problems discussed in part 2 (common problems).


    In this article I would like to show you how to use Azure ACS and SharePoint 2010 when we have multiple Web Applications in SharePoint. The sample will assume the same web application as used in the previous posts, but now with a dedicated My Site Host Web Application (called http://my). If we just enable the same Trusted Identity Provider to the "My" Web Application, the user will be redirected to the Azure ACS log in page, but when he/she is redirected back it will redirect back to the other web application (called http://sp2010 in the previous posts), because that's the web application we configured in the Return URL in Azure ACS.

    Only one Return URL

    Since this is a "visual" guide we're only using the Azure ACS management web site to configure the ACS and the UI only supports one Return URL per Relying Party Application. If you're using the ACS management web services you can configure multiple return url's - but that's another story for someone else to write about.

    So, we actually need to create a new Relying Party Application in ACS to handle a different Return URL, and with that also another Trusted Identity Provider in SharePoint.

    Create a new Azure Relying Party

    Let's start with Azure ACS. Log in to the Azure management portal and go to Relying Party Applications, then choose to add a new one. Give it a Name (must be unique), a new Realm (must also be unique within the ACS namespace) and finally the new Return URL for our new web application.


    The next parts are pretty trivial, but important. Make sure you choose SAML 1.1 as token format, increase the Token Lifetime (to the same value as your other/original RP), then choose the same Identity Providers as for your other RP. Do NOT create a new Rule Group, make sure to select the same Rule Group as your original Relying Party. This is to make it easier for us to manage (especially for upcoming posts). Leave the rest as is and click Save.

    The next thing to do is to configure the Token Signing certificate for this guy. Click on Certificates and Keys and choose to add a new Token Signing certificate. Choose the newly created Relying Party Application in the drop down and then choose to upload the SAME certificate that you used for your original RP - this is important, no other certificate will do!

    Add the SAME certificate for the new RP

    Hit Save once you're done and we're done with configuring our new Relying Party Application for the new SharePoint Web Application.

    Create a new SharePoint Trusted Identity Provider

    In SharePoint we need to add a new Trusted Identity Provider that uses the new Realm that was specified in the Relying Party Application. The procedure is basically the same as we did for our first Trusted IP, but with a subtle but important difference - we will not set the ImportTrustCertificate parameter in the cmdlet. We have already imported the certificate once, to the original trusted IP. Adding the same certificate to a new trusted IP will throw an exception. But this is good, you will shortly learn that. So use the following PowerShell to create the new trusted identity provider.

    $realm = "uri:visualauthn-my" $signinurl = "” $map1 = New-SPClaimTypeMapping     ""     -IncomingClaimTypeDisplayName "Email"     –SameAsIncoming New-SPTrustedIdentityTokenIssuer     -Name "Visual AuthN ACS - MY"     -Description "ACS rocks!"     -Realm $realm     -ClaimsMappings $map1     -SignInUrl $signinurl     -IdentifierClaim $map1.InputClaimType

    The important things here to notice is that we're using the new Realm, the same sign in URL, gives the trusted ip a new Name and do not choose to use the ImportTrustCertificate parameter.

    Creating the new trusted ip

    Now we're ready to connect the web application to the new trusted identity provider.

    Configure the secondary Web Application

    In Central Administration go to Web Applications Management, choose the new Web Application (in this case http://my ) and select the Authentication Providers button in the Ribbon. Choose the appropriate zone in the dialog and then scroll down to Trusted Identity Providers and select the newly created one.

    Configure the web app

    Click Save when done and you're ready to test it.

    Test it

    Now when you browse to the secondary web application you can log in using our new Azure ACS Relying Party Application and you will be redirected to the correct web application (and not back to the first one, which is the case if we used the original trusted IP for the secondary web application).

    Now to the really interesting stuff! If you choose My Settings in both web applications you will notice that the account name is exactly the same.

    Personal settings

    This is good! This account will now be same throughout your web applications and you can actually set up a dedicated My Site Web App and have all Notes and Tags from the other web apps.

    Even though we created a new trusted identity provider, the account name is exactly the same! Even the issuer is the same in this identity. The reason behind this is that since we did not add any signing certificate to the secondary trusted IP (and we don't want to). When first trying to sign in SharePoint will redirect to the sign in URL (remember we have the same for both trusted IP's) using the Realm for the web application. We're using the same token signing certificate for both the ACS RP's (and the same rule group, which means that we get the same set of claims back) and when SharePoint retrieves the incoming request from Azure ACS it will locate the trusted identity provider using that token signing certificate. And it will find our original trusted identity provider and use it's settings (including claims mappings - which we'll also see in subsequent posts). Smart huh!

    The image below just shows our trusted IP's and their certificates.



    In this case we're adding a new Relying Party Application and a new Trusted Identity Provider in SharePoint just to get a new Return URL. The Trusted IP is there to send the correct Realm to Azure ACS so that it sends back the request to the correct Return URL. And this is only what the new trusted IP is for - in follow up posts to this one we'll modify the trusted IP and we only need to modify the original one to get effects on both web applications.

    SharePoint is smarter than you think!

  • Visual guide to Azure Access Control Services authentication with SharePoint 2010 - part 3 - Facebook

    Tags: Security, Windows Azure, SharePoint 2010

    Welcome back to a third post in the Visual Guide to Azure Access Control Services authentication with SharePoint 2010. In the first part I showed you how to do the basic configuration of Azure ACS and SharePoint 2010 and log in using a Google Id. The second part discussed the most common problems I've seen so far. In this post we'll continue extending the ACS Relying Party to support another Identity Provider - namely Facebook! Depending on what type of site/community you're trying to build with your SharePoint 2010 site it might be of interest to use Facebook login (they have like a gazillion of users or something). The Facebook AuthN parts are a bit different than the others OOB IP's in Azure ACS - but not complicated at all, so let's get started...

    Create a Facebook application

    The first thing we need to do is to actually create a Facebook application. This is required to allow Azure ACS to convert the Facebook OAuth to outgoing claims, using the Facebook Graph API. And to do this you need a Facebook developer account. You do this by going to Once you have your account you just click Apps in the upper right.

    Apps, apps, apps

    This will take you to all your apps, if you're new you don't have any...but you get the point. Next, click the Create New App button. Give the app a display name and a namespace (as always namespaces must be unique - the UI helps you with that). Agree to the terms (you read those, right!?) and click Continue.

    Create a new app

    You will be asked to fill in the security check - do that and finalize you app creation.

    Now we need to do some configuring, but just one simple thing. We need to tell the app how we integrate with Facebook - we'll do that by checking the Website mark and then entering the URL to Azure ACS - it should be https://[your ACS namespace] (you can also find the URL under Application Integration in the ACS portal). Then save the changes. It says this will take a couple of minutes, but we have some more configuring to do so we'll be okay.

    Connect the app to Azure

    Keep this page open, you'll need the App ID and App Secret in the next step, when we configure Azure ACS.

    Important stuff

    Configure Azure Access Control Services

    I assume that you have already created your Azure ACS Relying Party, but if you have not revert to Part 1 of this series. Choose to add a new Identity Provider and select Facebook application. Click Next when done.

    Add Identity Provider

    Now you need the App ID and App Secret from the Facebook application, input those values.

    Configure the Facebook IP

    Make sure that the checkbox is checked next to your Relying Party under Used By and then click Save.


    Next step is to create Rules for this new IP. Go to the Rule Group that your RP is using and click on Generate. Azure ACS will by default mark those IP's that does not have any rules, so just click the Generate button to create the default rules.

    More rules...

    Once the rules are created, you can verify that an output claim is created for the Facebook IP using the emailaddress claim.

    It has to be there....

    Also check your Relying Party and make sure that it has the correct set of IP's configured.

    Remove that fugly WLID

    That's it with the Azure ACS configuring. Now all that is left to do is test it in SharePoint!

    Login using your Facebook account in SharePoint 2010

    Before logging in you need to give access to your Facebook account in SharePoint. You'll use the e-mail address of the Facebook account - just add it to the Members Group of the site.

    Grant access to the FB account

    Then log out and sign in as a new user and choose to use Azure ACS login. You will now, as usual, be redirected to the ACS Sign in screen and you should see Facebook listed as an IP there. You might have to refresh your browser using Ctrl-F5, since the page might be cached.

    Sign in...

    When you click the Facebook button you will be redirected to Facebook which will prompt you for your credentials. Log in using the account you just gave permissions.


    The first time you will be requested to approve that Facebook sends information to your App, just click Go to App and you'll be authenticated in ACS.


    And voila! You have now logged in to SharePoint 2010 using your Facebook account.

    Houston, we have lift off


    Making SharePoint take advantage of Azure ACS and the Facebook integration you can very easily create a log in experience that users are quite used to by now. As I have shown you it just takes a couple of minutes.

    I just can't stop writing on this topic, so I'll be back with some more awesomeness another day...

  • Visual guide to Azure Access Control Services authentication with SharePoint 2010 - part 2 - common problems

    Tags: Security, Windows Azure, SharePoint 2010

    This is a the second part of the Visual guide to Azure Access Control Services authentication with SharePoint 2010. I hope you've read part 1 which showed you how to configure SharePoint 2010 to use Windows Azure Access Control Services, ACS, as the federated Identity Provider, IP. In this post I'll go through the most common errors that you might stumble upon (most likely due to the fact that you didn't follow part 1 thoroughly). These errors are also applicable to other providers such as ADFS.

    Note: this post is written using Azure ACS as per February 2012 and with SharePoint 2010 Server with SP1 and December 2011 Cumulative Update.

    So let's get started with a very annoying problem - Live ID...

    Windows Live ID and the e-mail claim

    The first error is not an error per see. You will see this one if you followed the instructions in the first part - but instead tried to use Windows Live ID when logging in. What you will see is the classic "An unexpected error occurred".

    An unexpected error occurred

    The key here is to take a look at the URL. You will see a query string parameter called errorCode which has the value TrustedMissingIdentityClaimSource.

    URL reveals it all

    So there is something missing! To understand what happened here we need to get back to the ACS management portal and take a look at the Rule Group that was created for our Relying Party Application. As you can see in the image below only one claim is augmented when using Windows Live ID - the nameidentifier. In part 1 we configured the identity claim (in the PowerShell script) and we configured it to use the e-mail as identity claim ( If you read the last series on Live ID AuthN with SharePoint 2010 you might remember that you could not use the e-mail address of the Live ID user but instead had to use the UUID (basically a GUID that uniquely identified the user). Unfortunately (and this is a real bummer) this UUID (claim type is not available in Azure ACS, for Live ID. Instead the only claim we have access to is the nameidentifier - which is a unique identifier for the specific user on this ACS namespace.

    Rules, rules, rules

    If we add a new Rule in Azure ACS that uses the nameidentifier as input claim and outputs it as the emailaddress identifier claim. Then we at least have something unique for the user to work with.

    Create me a rule

    When you now log in using a Live ID you will get an access denied message, which displays this unique nameidentifier. Copy the identifier and then log in using a Windows account (or the working Google account) and this identifier to the Members group (for instance).

    Who is that!

    Then log in again it will work, but...


    Looks pretty bad! So you better leave Windows Live ID out of the discussion (until Microsoft fixes ACS to give us a decent claim to work with). Edit the Relying Party Application in ACS and remove Windows Live ID as Identity Provider and you will be a much happier person.

    Turn of WLA

    No Rules applied here!

    One problem you might see when setting up the authentication using ACS is that you might be to trigger happy and fast when configuring and just forgets to add any Rules to your Relying Party. When you're trying to log in you will see an error message like this:


    The error message is ACS50000: There was an error issuing a token, with two inner messages ACS60000 and ACS60001 where the last one gives us the clue in plain text: "No output claims were generated during rules processing". This is just because you have no rules applied to that Relying Party which converts the incoming claims from the IP's to outgoing claims. To fix it edit your Rule Group and just use the Generate to create your output claims:

    No rules!

    This might happen if you're adding more Identity Providers to your Relying Party once you have configured it.

    Note: make sure that you're doing it for the correct Rule Group - the one selected in the Relying Party.

    Invalid identifier claim

    Another error, not that common though, that might happen if you start fiddling with the claims is that you do not get any incoming identifier claim to SharePoint. When this error happens you will get the classic An unexpected error has occurred error page.

    The expected unexpected

    The actual error can be find either in the URL or in the trace logs - both explain exactly what has happened. In the URL the error code is written out as TrustedMissingIdentityClaimSource. Exactly the same as in the Windows Live ID dilemma above.

    Check thy URL

    And in the trace logs you will find several entries (depending on your log level):

    ULSViewer FTW!

    To fix this make sure that you have an output claim, from the ACS Relying Party, for each Identity Provider, that matches the exact claim that you specified when configuring the token issuer identity claim (using PowerShell). You can verify your identity claims by running the PowerShell snippet

    Get-SPTrustedIdentityTokenIssuer | ft Name,  @{Label = "Id Claim"; ` Expression={$_.IdentityClaimTypeInformation.InputClaimType}} -autosize


    Then check you ACS rules and that each IP has an output claim of that type (that is unique of course!).

    Token lifetime

    The most common problem with Azure ACS and SharePoint 2010 is that you successfully logs in and then either directly are redirected back to the log in page or you're logged in for a second and then as soon as you click something are requested to log in again. If you have enabled Verbose Trace Logging for Claims Authentication (which definitely is a good thing to do when troubleshooting claims stuff) you will also see this message in the ULS logs: "Token cache entry missing.".

    missing token

    This is most likely due to that you have misconfigured the Token Lifetime, or just let it have the standard value of 600. Most likely you did not read my previous post thoroughly enough!!!

    The STS of SharePoint 2010 has a default lifetime of the logon token set to 10 minutes (600 seconds) and this is also the default value of the ACS RP token lifetime (600 seconds). If you with these default  values can actually log in you have a fast connection/machine, but any subsequent action in SharePoint will force you to re-authenticate. You have to configure the lifetime in ACS larger than the value in SharePoint (either by increasing the ACS token lifetime or lowering the SharePoint 2010 LogonTokenCacheExpirationWindow value of the  STS.

    In my previous post I set the token lifetime to 700 seconds - this will then make your users log in every 100 seconds (700-600). If you set it to 610 seconds in ACS you will have to re-authenticate every 10 seconds. A recommendation is to bump it up to 3.600 seconds, so you don't annoy your users to much!

    Not using correct SAML version

    Another common error is that you get a Runtime Error (Yellow Screen of Death) directly after you have logged in using one of the IP's. The ULS logs does not show any useful information, you just see that a request is going to the /_trust/default.aspx page.


    On the other hand, if you switch to the Windows Event Viewer you will notice an ASP.NET error, with event id 1309. And if you look closer at the details, the answer is there, once again under your fingertips.

    Event Viewer

    The exception message says: "ID4014: A SecurityTokenHandler is not registered to read security token ('Assertion', 'urn:oasis:names:tc:SAML:2.0:assertion').". Once again you've misconfigured the ACS Relying Party - you must use SAML 1.1 to get this working (without setting up an intermediate ADFS server or similar).

    Certificate problems 

    Another issue that might throw the yellow screen of death on the /_trust/default.aspx page is when you have invalid or missing certificates. Again both the trace logs and Windows event logs shows us the error. In the Windows Event Logs you will see a SharePoint error with event id 8311. This error will say that it could not validate the certificate used to sign the incoming claims. The trace logs will show the exact same error, also with id 8311, in the Topology category.


    Fix the error by making sure that you have added the same signing certificate to Azure ACS and as a trusted root authority. See part 1 of this series for more info.


    As you can see it's all about configuration and make it right! I hope this post will help you with the basic problems, and if you get any other errors, please post a comment.

    I'll be back with at least one more post on this topic...

  • Visual guide to Azure Access Controls Services authentication with SharePoint 2010 - part 1

    Tags: Windows Azure, SharePoint 2010

    A year and a half ago I posted the Visual guide to Windows Live ID authentication with SharePoint 2010 series, a post that got a tremendously amount of hits (and still gets) and tons of comments (and new ones still coming in). It showed quite a cumbersome way to Live ID enable your SharePoint 2010 Web Applications using the Microsoft Service Manager, MSM, (which works some times and some times not). Although it did/do work it is not the best way to enable Live ID authentication to your SharePoint 2010 web site. The MSM required you to first test in their INT environment and get approval before putting it into production, and you had to follow a set of guidelines on how to use Live ID logos etc etc, not mentioning all the manual configuration.

    Microsoft has a service in its Windows Azure offering called Access Control Services. This is essentially an Identity Federation Provider, living in Windows Azure. This IP not only allows you to federate Live ID authentication but also Google ID, Facebook ID etc. In this post, and subsequent ones, I'll do a visual guide on how to configure SharePoint 2010 to use Windows Azure Access Control Services, ACS, to handle your authentication.

    Configuring Azure ACS

    First of all let's get acquainted with Windows Azure Access Control Services. But before you start you need to have a Windows Azure subscription. Unfortunately this isn't for free, but if you have an MSDN Subscription you can take advantage of the MSDN Azure benefits. Once you have your subscription you head on over to and sign in with your Live ID. Once you're signed in you are in the Azure Management Portal.

    Windows Azure Portal

    On the left hand side is the navigation and select Service Bus, Access Control & Caching (this is the part that was/is called Azure AppFabric), #1 in the image below. This will load all the AppFabric Services and you will get a new navigation tree on the left hand side and the Ribbon menu will update. To create your Service Namespace, which is like a "container" for the AppFabric services, click on the New button in the Ribbon (#2).


    This will bring up a dialog  where you create your new namespace. First of all select the services you want in this namespace - for this authentication sample we only need the Access Control (#1). Secondly you need to specify a unique namespace for your Service Namespace (#2). After that select an appropriate Region (#3) and optionally a Subscription if you have multiple ones. Once your satisfied click Create Namespace (#4) to start the creation.

    New Service Namespace

    The creation will take a couple of minutes, so now it's a good time to take that coffee you all been waiting for! As always when dealing with AuthN, coffee breaks are good, that's what my good ol' buddy Spence always nagging about. Wait until the service namespace has the status of Active until proceeding further.


    Once it has the Active Status, select your newly created Service Namespace (#1) and  choose Access Control Service in the Ribbon menu (#2). This will open the Access Control Services administration. Note: you will navigate away from the Azure management and reuse the same browser window.

    Configure it...

    The Access Control Service administration site contains a lot of configuration options. You will see a left hand side navigation where you can set up everything from Identity Providers, IP, and Trusted Parties to custom certificates and get details on how to integrate this with your applications. The first thing we will do here is to add a couple of identity providers, click on Identity Providers in the menu.

    Access Control Services Management Portal

    Identity Providers

    The Identity Providers menu option shows all the Identity Providers that currently is available for this ACS Service Namespace. By default you will only see Windows Live ID. While Windows Live ID might work (if you can live with all the guid based identities) it's very convenient to add other IP's here. Click on Add to add a new IP.

    Identity Providers

    I like to add the Google Identity Provider, since all the user identities from Google IP will use the Google login id (e-mail). Select Google amongst the preconfigured IP's and then click Next.

    Add IP

    The next page gives you some customizations options for the Google IP. Change anything you want here and click Save to continue.

    Login Page

    This should take you back to the IP page and you should now see both Windows Live ID and Google listed there.

    The Relying Party

    Next thing to do is to add a Relying Party Application, that is our SharePoint Web Application. Choose Relying party applications in the left hand menu. You will have no RP's configured by default so click on Add to create a new one.

    Relying Parties

    You will now see a form and it is here things must be written correctly otherwise you will not get the AuthN to work with SharePoint 2010. First of all give your RP a nice and easy name (#1). Secondly is the realm (#2), if you remember from the Live ID visual guide the Realm is important. Use a URI instead of URL, it's easier to remember and always works. In this case I choose uri:visualauthn. Then we also need to fill in the Return URL (#3). The return URL must point to http://server/_trust/default.aspx when dealing with SharePoint 2010 (of course replace with your server name, localhost also works in a test environment).

    RP Settings

    The next things to configure is the tokens. First of all SAML 1.1 must be used as Token Format (#1), SAML 2.0 is default in ACS so make sure to change this. Leave Token encryption policy to None (#2). Then finally an important piece - the Token lifetime. By default this is set to 600 seconds and you need to increase this value. The reason for that is that SharePoint 2010 has the expected token lifetime configured to 600 seconds and when SharePoint validates the token, which is after it's been issued by ACS it will fall outside the lifetime. So you have two options here lower the SharePoint lifetime or increase it in ACS, in this case I've done the latter and set it to 700 seconds.

    Token Settings

    The rest of the configuration is left intact. If you like you can uncheck Windows Live ID if you do not want Live ID users to sign in with this RP. Click Save when you're done.


    You should now see your newly created Relying Party.

    The RP

    Some rules!

    We now have two IP's connected to the RP - each of the IP's has a set of outgoing claims to our RP and we need to make sure that the claims received from the IP's to the RP are passed through to SharePoint as outgoing claims from the RP. This is done through the Rule Groups. Select Rule groups in the left hand menu. You will see a Rule Group called "Default Rule Group for Visual AuthN" - this group was automatically created for us when we created the RP: Now click on the rule group to create the actual rules.

    Rule Groups

    Note that there are no rules by default. To create the default rules, just click on Generate to create them.


    First we need to select for which IP's to generate the rules, make sure both Live ID and Google (in this case) are selected and click the Generate button.

    Generate Rules

    Now ACS will generate the default rules for all selected IP's. Click Save to complete the rules setup.

    The Rules

    I will in follow up posts on this one, show you how to fiddle a bit with these rules. But for now we're just using all the default settings.


    Next thing to do is to create a certificate that we will be using for Token Signing. The Management Portal makes it very easy for us to make a self signed certificate for testing and demo purposes. For production scenarios either purchase an X.509 certificate or request one from your local Certification Authority (CA) (for instance AD Certificate Services). Just make sure it's a certificate for sign and encrypt the payload. Navigate to the Certificates and Keys in the ACS Management Portal. Click on Add next to the Token Signing certificates.

    Certificates and Keys

    First of all make sure that the correct Relying Party is selected, it should be the one you just created. ACS allows you to have multiple RP's so just make an extra check.

    Used for

    If you want to create a self signed certificate, take a look at the middle of that page. There is a small snippet that you just can copy and paste to create your own certificate (if you have the MakeCert utility, which is a part of the Windows SDK).


    Copy and paste that into a command window or a PowerShell console. This will create your signing certificate and store in the My store on the box you run the command at.

    MakeCert POSH

    Now you need to export this certificate into two files (with and without the private key). One to upload to ACS and one to import into SharePoint 2010 later. You can export the certificates using the Certificates MMC Snap-In (like in the previous visual Live ID guide) or use PowerShell, which will impress your colleagues more.

    Export Cert POSH

    The PowerShell I use to export the certificate to one password protected Pfx file (with key) and a Cer file (without key) are the following:

    $cert = @(dir cert: -Recurse |   Where-Object { $_.subject -like "CN=visualauthn*" })[0] 
    $type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert 
    $bytes = $cert.Export($type) [System.IO.File]::WriteAllBytes("c:\visualauthn.cer", $bytes) 
    $type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pfx 
    $pass = read-host "Password" -assecurestring 
    $bytes = $cert.Export($type, $pass) [System.IO.File]::WriteAllBytes("c:\visualauthn.pfx", $bytes) 

    As you can see I grab the certificate with the correct subject and then use the .NET classes to export the certificates and finally save the bytes into files. Replace the exported filenames with your own and also the subject on the first line when doing this for your service,

    The Pfx file must be uploaded to ACS. You should still be on the Add Token Signing certificate page and now choose to upload the Pfx certificate and then enter the password you used when exporting it. Make sure that you choose to use this certificate as primary certificate and then click Save.

    Upload cert

    By now we're done with ACS. Let's head on over to configuring SharePoint.

    Configuring SharePoint

    Now it's time for the fun stuff - SharePoint. First of all you need to have a Web Application that uses Claims Authentication. If your web app is in Classic mode, either create a new one or upgrade from Classic to Claims.

    Claims FTW

    Trusted Root Authority

    Now we need to make sure that the SharePoint farm trusts the certificate used by ACS to sign the tokens. This is done by uploading the other certificate file into SharePoint, using PowerShell. The following code is used to import the .cer file:

    asnp microsoft.sharepoint.powershell $cert = Get-PfxCertificate "C:\visualauthn.cer" New-SPTrustedRootAuthority -Certificate $cert -Name "Visual AuthN ACS"

    Trusted Root Authority POSH

    To verify that the certificate is imported as a trusted certificate in SharePoint, go to Central Administration > Security > Manage Trust. You should see the name of the trust there:

    Ok, it's there

    The Trusted Identity Provider

    Next up is to add the ACS RP as a Trusted Token Issuer in SharePoint. Once again we'll do this using PowerShell. Here it is really important that you specify the exact realm as entered when you created the RP in ACS (see line 1 in POSH below). Then you also need the Sign In URL for your RP. Modify line 2 below to match the URL for your Service Namespace (bold and red). Next we define a claim mapping for the identity claim that we want to use, in this case the e-mail address. Finally we just add the new trusted identity token issuer

    $realm = "uri:visualauthn" 
    $signinurl = "” 
    $map1 = New-SPClaimTypeMapping     ""     -IncomingClaimTypeDisplayName "Email" –SameAsIncoming 
    New-SPTrustedIdentityTokenIssuer -Name "Visual AuthN ACS"     -Description "ACS rocks!"     -Realm $realm     -ImportTrustCertificate $cert     -ClaimsMappings $map1     -SignInUrl $signinurl     -IdentifierClaim $map1.InputClaimType

    Magic POSH

    Now it's time to modify our Web Application to use this ACS RP. Go to Central Administration and Web Application administration. Choose the Web Application you want to enable the RP for (remember that it has to be a Claims Web App). Choose to modify Authentication Providers from the Ribbon menu and select the correct Zone (normally Default). Then scroll down to Claims Authentication Types and check the Trusted Identity Provider checkbox and then our own ACS Trusted Identity Provider. Once that's done click Save.

    Web App AuthN

    One final thing here before testing it all. I personally prefer to add a User Policy on the web application directly for one of the users that will log in through the ACS RP. You can of course log in using Windows AuthN and then set permissions inside the site if you prefer so. But this is how I do it. Select the web application and then click User Policy in the Ribbon. Then click Add User choose All Zones and enter the Google e-mail of the user that you will test with, give the user Full Control on the web application. Make sure that you type the e-mail correct - SharePoint will by default validate anything that you write in in Claims mode (more on this in another post).

    User Policy

    With this policy in place all should be set to test drive it all.

    Test it!

    Now all we have to do is test it. Browse to the web application for which you added the Trusted Identity Provider, once it's loaded you will be presented by the default multiple login page. The drop down will show all the available AuthN providers for the web application. To use the ACS login we only need to choose that provider in the list.


    Once the provider is selected you will be redirected to the ACS RP login page. In this case we will see two possible providers to use - Live ID and Google. Click on the Google button and you will be redirected, once again...

    Login 2

    ..this time to the Google log in page which will ask you for username and password. Enter the username (e-mail) that you used when creating the user policy for the web application and log in. In this case, with Google, Google will ask for confirmation that you trust the ACS RP. Choose Allow and you'll be redirected back to the RP which will seamless redirect you to SharePoint.

    Login 3

    ...and voila! You're in! Take a look at the username in the upper right corner - it should be the e-mail address of the Google ID you used.



    That was it - a visual guide on how to configure federated authentication using Windows Azure Access Control Services and SharePoint 2010. It is this easy! Even though this article was quite lengthy you can do it all in a couple of minutes (compare that to the way I previously showed)!

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...