How to Get All User Claims at Claims Augmentation Time in SharePoint 2010

A fairly constant hurdle when doing claims augmentation in SharePoint 2010 has been trying to figure out what claims a user has when your custom claims provider is invoked to do claims augmentation.  For example, the claims you want to augment for a person may depend on the value of other claims the user has, e.g. if the person belongs to the role “Domain Admins” then add the role claim “Uber User”, otherwise add the claim “Standard User”.  After being frustrated by this for a long time, my good friend Israel V. and Matt Long finally came up with the solution to this sticky problem (and deserves 100% of the credit for this solution, so thank you guys!).
One of the underlying problems in trying to get to this information outside of the parameters provided when your claim provider is invoked for augmentation is that you don’t have any access to an HttpContext to look at the collection of claims.  Israel and Matt correctly figured this out and figured out the alternative, which is the OperationContext.  So what is that?
Well, OperationContext has a good overview here:  In a nutshell, the thing we care about, is it allows you to access incoming message headers and properties (for SAML users) and the security context (for Windows users).  So how does this help us?  Well, when your custom claims provider is invoked for augmentation, you can get to this incoming message info for SAML users which looks like this:
<s:Envelope xmlns:s="" xmlns:a="">
       <a:Action s:mustUnderstand="1"></a:Action>
       <a:To s:mustUnderstand="1">http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc</a:To>
       <trust:RequestSecurityToken xmlns:trust="">
          <wsp:AppliesTo xmlns:wsp="">
              <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_8f1d7b46-2b71-4263-859b-c3e358d7ea84" Issuer="http://myadfsserver/adfs/services/trust" IssueInstant="2011-03-26T18:51:54.671Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
                 <saml:Conditions NotBefore="2011-03-26T18:51:33.198Z" NotOnOrAfter="2011-03-26T19:51:33.198Z">
                     <saml:Attribute AttributeName="emailaddress" AttributeNamespace="">
                     <saml:Attribute AttributeName="role" AttributeNamespace="">
                        <saml:AttributeValue>pOregon Marketing</saml:AttributeValue>
                        <saml:AttributeValue>Domain Users</saml:AttributeValue>
                        <saml:AttributeValue>Portal People</saml:AttributeValue>
                     <saml:Attribute AttributeName="windowsaccountname" AttributeNamespace="">
                     <saml:Attribute AttributeName="primarysid" AttributeNamespace="">
                 <saml:AuthenticationStatement AuthenticationMethod="urn:federation:authentication:windows" AuthenticationInstant="2011-03-26T18:51:33.069Z">
                 <ds:Signature xmlns:ds="">
                        <ds:CanonicalizationMethod Algorithm="">
                        <ds:SignatureMethod Algorithm="">
                        <ds:Reference URI="#_8f1d7b46-2b71-4263-859b-c3e358d7ea84">
                               <ds:Transform Algorithm="">
                               <ds:Transform Algorithm="">
                           <ds:DigestMethod Algorithm="">
                     <KeyInfo xmlns="">
<<apologies for what I realize is a long chunk of ugly Xml, but I wanted you to see it>>
Now, since we have a chunk of Xml with our claims embedded inside, it’s no big deal to unwrap them and be able to use them during augmentation.  Here’s a quick little sample that I wrote to do just that:
using System.Xml;
private class IncomingClaim
   public string claimType { get; set; }
   public string claimValue { get; set; }
   public IncomingClaim(string claimType, string claimValue)
      this.claimType = claimType;
       this.claimValue = claimValue;
protected override void FillClaimsForEntity(Uri context, SPClaim entity,
            List<SPClaim> claims)
//get the request envelope with the claims information
       string rqst =
       //create a list to store the results
       List<IncomingClaim> incomingClaims = new List<IncomingClaim>();
       //create an Xml document for parsing the results and load the data
       XmlDocument xDoc = new XmlDocument();
       //create a new namespace table so we can query
       XmlNamespaceManager xNS = new XmlNamespaceManager(xDoc.NameTable);
       //add the namespaces we'll be using
       xNS.AddNamespace("s", "");
       xNS.AddNamespace("trust", "");
       xNS.AddNamespace("saml", "urn:oasis:names:tc:SAML:1.0:assertion");
       //get the list of claim nodes
       XmlNodeList xList =
xDoc.SelectNodes("s:Envelope/s:Body/trust:RequestSecurityToken/trust:OnBehalfOf/saml:Assertion/saml:AttributeStatement/saml:Attribute", xNS);
       //get the matches
       if ((xList != null) && (xList.Count > 0))
              //enumerate through the matches to get the claim list
              foreach (XmlNode xNode in xList)
                     //get the claim type first
                     string currentClaimType =
                           xNode.Attributes["AttributeNamespace"].Value +
                           "/" + xNode.Attributes["AttributeName"].Value;
                     //each claim type will have one to many child nodes with the values
                     foreach (XmlNode claimNode in xNode.ChildNodes)
                           incomingClaims.Add(new IncomingClaim(currentClaimType,
//now you can do whatever you want with the list of claims and finish
//your augmentation
That’s pretty much it.  The code is simple enough and commented out so verbosely that I believe if you look at it, and paste the Xml into a nice Xml editor (like the one that comes with Visual Studio .NET) that it should be pretty clear how it works.  No rocket science at this point, just Xml.
There is also an interesting side effect you can implement based on this pattern that blog reader Luis A. points out.  The set of claims you will get in the RequestMessage includes everything that came from your IP-STS, including any claims that the SharePoint STS will be dropping if there isn’t a corresponding claim mapped.  So, if you know which claims SharePoint is going to be dropping and you want to keep them anyways, you can just augment them yourself again with your custom claims provider.  Just pull the claim values and types out of the RequestMessage and add them back in.
Windows claims users won’t have this message associated with their request, but you can get a WindowsIdentity for them by using the SecurityContext of the OperationContext.  From that you can do all the things available with a WindowsIdentity, like getting the list of groups the user belongs to, etc.  Here’s an example of that:
//do windows
WindowsIdentity wid =
//get a reference to the groups to which the user belongs
IdentityReferenceCollection grps = wid.Groups;
//enumerate each group (which will be represented as a SID)
//NOTE that this includes ALL groups – builtin, local, domain, etc.
foreach (IdentityReference grp in grps)
       //get the plain name of the group
       SecurityIdentifier sid = new SecurityIdentifier(grp.Value);
       NTAccount groupAccount = (NTAccount)sid.Translate(typeof(NTAccount));
       string groupName = groupAccount.ToString();
       //for domain groups remove the domain\ prefix from the group
       //name in order to have feature parity with SAML users
       if (groupName.Contains("\\"))
              groupName = groupName.Substring(groupName.IndexOf("\\") + 1);
       //add the claim
You’ll want to make sure you add a using statement for System.Security.Principal to get the WindowsIdentity, IdentityReference, NTAccount, etc. to resolve correctly.  Otherwise the code should again be fairly straightforward.  I’m just getting the list of groups for the user and putting them in my custom collection of claims as  a standard Role claim.
Thanks again Israel and Matt for sharing this super valuable information.

How to Get All User Claims at Claims Augmentation Time in SharePoint 2010.docx

Comments (11)

  1. Sorry, what I meant by my reply is that SharePoint is still going to drop those unmapped claims. You will see all claims that come from your IP-STS, so if you have some unmapped claims come through then you can capture them in this event and augment them yourself.  This is actually an interesting work-around (if you know which ones you need to grab that is) so I will update the blog post with that info too.  Thanks for the question.

  2. alexandrad9x says:


  3. No, that is something different.  What is stated in that post still applies.

  4. Luis Azedo says:

    Hi Steve,

    if i understood correctly, this solution overcomes the problem you mention on your earlier post…/figuring-out-what-claims-you-have-in-sharepoint-2010.aspx

    "If your STS sends back other claims besides what SharePoint is expecting, SharePoint will IGNORE all of those additional claims and it WILL NOT be added to the SPClaim".

    is this correct ?


  5. Luis Azedo says:

    Hi, i thought that the message came from the sts provider. What would be the best aproach to overcome the problem mentioned?


  6. Janu says:

    how can i get custom groups (AD groups in the claims) is see only few groups . how can i get all groups

    associated to the token programticaly.


  7. Prakash says:

    how to get the claims of a different user? Let say as a admin i want to see the claims of other user by passing userID

  8. SDF says:

  9. Anonymous says:

    In Part 1 of this series, we went through how to configure SharePoint to use ACS and Azure Active Directory

  10. Anonymous says:

    Okay, I’m going to preface everything in this post by saying what I’m going to be describing