Claims Based Identity in SharePoint 2010
These are some notes from a conceptual session today at the SharePoint Conference 2009 in Las Vegas delivered by Venke Veeraraghavan from Microsoft. The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be. I’ve decided to err on the side of more information – less polish. There is a later session that focuses on implementation details, so there will be more specific notes to follow.
Claims Based Identity is similar to Kerberos in many respects, but it extends similar benefits (and more) to non-Windows accounts. It involves a trusted authority issuing a token (like a ticket) to a user as they log in. This token can then be used to authorize access to whatever other system trusts the same authority. From a SharePoint perspective, it is basically a way to offload / delegate the management of user accounts, profiles, and authentication for your portal users to a third-party. It is a not a replacement for FBA, but a framework under which FBA can be one of the methods used to authenticate and authorize users. Since Claims Based Identity is a flexible, framework based on standard SAML tokens – SharePoint doesn’t have to write compatibility with external protocols or identity providers.
SharePoint 2010 is also now able to assign access permissions based on claims (roughly parallel to attributes) as read from the token. That’s a lot more flexibility than we used to have. It seems similar to what we found when working with the Audience Targeting features in 2007, where we could dynamically filter items based on profile properties. Those prior features were not truly for security – just filtering. Now, claims allow us to apply actual permissions based on similar criteria instead of strictly using users and groups.
Office client applications are now also able to support non-Windows Integrated Authentication.
There are 2 Important Identity Problems in SharePoint
There are 2 modes for authentication in SharePoint 2010:
- Classic (NT Token) or
- Claims (NT Token | FBA, SAL, LDAP… | SAML Token)
Claims creates a SAML token based on the sign-in, that contains the user’s identity
An IP-STS (Identity Provider Security Token Service) processes logins and manages attributes. It creates a token and passes it to the user for them to present to the SharePoint STS.
The SharePoint STS (Security Token Service) verifies that the IP-STS creating the token (or FBA login) is trusted by SharePoint as configured by the farm administrators. It then issues its own token incorporating the identity information from the first, and also adds whatever SharePoint-specific attributes might be necessary or desired.
How do we use the identity outside of SharePoint?
- LOB systems
- External partner services
- Separate SharePoint farms
Claims allow us to accomplish more portability than Kerberos does. Especially now with the Service Application Architecture, this enables much easier and more efficient ways to share services granularly across farms. The SharePoint STS runs on every WFE and App server, and examines / trusts the STS on other servers as configured.
In Beta2, Claims will be partially supported. Here’s the list of what IS included:
- FBA-Claims + Anonymous
The following modes will NOT be ready yet:
- Windows Claims
These modes should be included in the RTM version.