Share-n-dipity

SharePoint serendipity is the effect by which one accidentally discovers something fortunate, especially while looking for something else entirely. In this case, it is the occassional musings, observations, and Ouija board readings about the phabulously

Planning Considerations for Claims Based Authentication in SharePoint 2010

Planning Considerations for Claims Based Authentication in SharePoint 2010

  • Comments 7
  • Likes

As part of some claims based authentication work I've been doing recently, I've come across two very important constraints.  They are manageable constraints, but they are things that you need to know about in advance of setting up and configuring your claims infrastructure in SharePoint 2010.  The big items to be aware of:

  • Certificate Uniqueness Required for SPTrustedIdentityTokenIssuer - when you create a new SPTrustedIdentityTokenIssuer, one of the parameters that you provide is the ImportTrustCertificate.  This parameter is an X509Certificate2 object, and is the certificate that you export from your STS (like Geneva, AKA as ADFS v2, Server).  Once you use that certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it again to create another one.  If you want to use that certificate in another SPTrustedIdentityTokenIssuer, you will have to delete the existing one first.  And before you can delete an existing one, you would have to disassociate it with any web applications that may be using it.  I bring this up because if you try to create another SPTrustedIdentityTokenIssuer with the same certificate it will fail, but the error message really isn't going to tell you that the certificate is the problem.
  • Claim Mappings are Immutable - when you create your SPTrustedIdentityTokenIssuer you identify the claims that you want that SPTrustedIdentityTokenIssuer to accept.  If your STS sends over additional claims they will be dropped by SharePoint when the SPClaim is created.  The important thing here is that after you have created your SPTrustedIdentityTokenIssuer, you cannot change the set of claims it accepts.  PowerShell will let you make changes and call update, but under the covers we don't do anything.  Hopefully this behavior will be changed by RTM to at least throw an exception when you try this, but it's not clear if that will happen or not.  From an implementation perspective the fact that you're locked into a set of claims after you create your SPTrustedIdentityTokenIssuer is pretty manageable.  At the end of the day, pretty much everything we do in SharePoint can be wrapped in an identity and role claim.  The beauty of the role claim is that if you have other attributes that become interesting over time, you can plug it into the role claim.  It simply expands or contracts depending on your group memberships.  To see how to add both an identity and role claim to an SPTrustedIdentityTokenIssuer, see my posting at http://blogs.technet.com/speschka/archive/2010/02/17/creating-both-an-identity-and-role-claim-for-a-sharepoint-2010-claims-auth-application.aspx.

** UPDATE **

There has been some scripts that have shown in some cases they can seemingly update the list of claim mappings associated with the SPTrustedIdentityTokenIssuer after the fact.  After discussing with some folks on the claims test team, the advice is to not use those - you should consider the claim mappings immutable with the RTM release of the product.  That may change in the future, but for the RTM release this is how we're going to address it.

So, these are important constraints to be aware of, but they can definitely be managed without too much fuss as long as you are aware of them up front.

Comments
  • <p>I like your posts on claims very informative.</p> <p>One thing I have discovered with claims and BCS is that the certificate used to sign the claim in the oob installation i.e. &quot;SharePoint Security Token Service&quot; is not compatible with Java's metro web services Metro requires the cert to be a CA. &nbsp;I wonder if you have come accross aa way of changing the signing cert. &nbsp;I have tried creating a new cert and calling this command Set-SPSecurityTokenServiceConfig -SigningCertificateThumbprint &quot;413cdbb21c861fcb19c1ee71b9ed2cae748ae10f&quot; which works but the n the entire trust for SP is blown out the window. &nbsp;I imagine there are more steps to be performed but I can't find any documentation.</p> <p>FYI I am using TAP builds</p>

  • <p>Great article, and extremelly useful! By the way, do you know if there is any LiveID provider for Claims-Based authentication to be used on SharePoint 2010? I&#39;ve seen we can still use classic mode and 2007 developments to achieve this but I wonder if there is any improvement in this area.</p> <p>Thanks!</p>

  • <p>Great article, and extremelly useful! By the way, do you know if there is any LiveID provider for Claims-Based authentication to be used on SharePoint 2010? I&#39;ve seen we can still use classic mode and 2007 developments to achieve this but I wonder if there is any improvement in this area.</p> <p>Thanks!</p>

  • <p>Hi vikas</p> <p>Check following link if you look for a OpenID or Live ID provider for SharePoint 2010 with Claims Based Authentication</p> <p><a rel="nofollow" target="_new" href="http://www.shetabtech.com/english/SharePointLiveAuth">www.shetabtech.com/.../SharePointLiveAuth</a></p>

  • <p>Is there a way to implement &nbsp;claim based auth in MOSS 2007. Can we get it customised.</p> <p>Any help is appreatiated.</p> <p>Thanks In Advance.</p>

  • <p>Should the immutable nature of claims mappings be taken into account when choosing hub vs direct for multiple Partner IdPs/STSes? Hub model implies that you could not change claims mappings for any IdP without deleting and recreating the Hub SPTrustedIdentityTokenIssuer - which could be epic. With direct you would only affect the individual IdP/Partner. I guess you could handle it all with transformations at Hub STS, but only if there were sufficient existing mappings defined for the Hub STS. Seems to indicate careful consideration of claims mappings would be sensible when using Hub model.</p>

  • <p>Is this still true for SP2013 RTM? I found this article which seems to work fine... <a rel="nofollow" target="_new" href="http://sharepintblog.com/2011/10/26/adding-additional-claims-to-a-trusted-identity-token-issuer/">sharepintblog.com/.../adding-additional-claims-to-a-trusted-identity-token-issuer</a></p>

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment