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(“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.


One thought on “How to Get All User Claims at Claims Augmentation Time in SharePoint 2010

  1. Hi There,

    I’m having some trouble implementing this solution:
    When I do the claim aumentation, I give some more claims to the user or to the system.

    When I add claims to the incomingClaims, I can see this same claim in all users.

    It’s like the claim is been add to the system and not to the current user.

    Thank you


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s