SP2010 Claims Authorization for the rest of us
Purpose: this is not intended to be a comprehensive explanation of claims security; rather, it’s to give a brief outline of claims (with references) and discuss a use case scenario that will leverage the benefits of claims without having to add complexity to your environment.
What is this Claims thing? Claims based security is a standardized (WS-*) approach to handling authentication and authorization. Identities are presented to an application in the form of a ‘security token,’ which is just some xml that is signed with digital certificate. These tokens are issued by a ‘Security Token Service’ (ADFS2, custom code, etc.) and can be used for authentication and authorization by one or more ‘Relying Parties’ (SharePoint, any other application). The token contains one or more ‘claims’ about the identity it represents. A claim can be anything, such as name, email, role, office, permissions, etc. Read more here or here.
What can it do for me?
Flexible Authentication – allows for multiple authentication types to 1 system; also allows mixing Windows based and non-Windows based systems.
Federation and Delegation – perhaps the most significant benefit of this model is the ability to ‘federate’ security across multiple enterprises. In plain English, this means that a user from Organization A can access resources in Organization B without having to have an account in Organization B. For example, suppose these two organizations just went through a corporate merger. They now want to share data, but not people. Someone from A needs to see the SharePoint site on B’s intranet, but organization B does not want to manage an AD account for the people in A. So, claims lets B ‘trust’ the tokens from A, and thereby provides a means to grant access across these boundaries.
Standardization, Simplification – adhering to true web standards is always great and should lead to interoperability and fewer upgrade issues down the road. Plus, the claims model abstracts handling of security logic in code, so developers don’t have to worry at all about the specifics of security implementation when writing code. Very nice.
Really great Authorization! – this is the big one. Most of us are not in a situation that requires federation or anything other than our company’s AD for Windows auth. But claims are still relevant. Look at this:
Notice that this SharePoint People Picker has a special section called “OrionSTS” (my custom Security Token Service) that has claims for EmailAddress, Title, Office, UserLevel. Magically, I can give permissions by selecting a value for one of these claims:
OK, this is a much bigger deal than it appears to be. You see, I just granted permissions on my site to any user whose Office claim has a value of Richmond, but without having to specify a user name! From now on, any user who presents a valid token with an office claim value of Richmond can use this site. Even better, the value for this claim can be managed in AD, PeopleSoft, or any other system. This is different than what we do now, and much better. I mean, does it make sense to give Suzie access to Dept A’s team site because we know (because HR told us) that she is in that department? Or, does it make more sense to simply grant all members of Dept A access to Dept A’s team site one time and be done with it? This is also really great for auditing scenarios (don’t ask me who can access my site, ask HR!) and offboarding scenarios (no we don’t need to purge that user from SharePoint). Another way to think about this is to pretend that you can use Audience Targeting as true security instead of just to trim the UI. Ponder this some more and I promise you will get excited.
So how do I get claims in my people picker without changing my authentication mechanism or building an STS?
Enter the SharePoint custom claims provider. This is custom code (inheriting from a SP base class) that fires during authentication and augments claims. So, you can still use AD and Windows authentication but add in additional claims dynamically. These claims can come from anywhere- SQL, another business system, even a SharePoint list! Once you add the claims, you can do all your authorization without worrying about user names. For info on how to build this custom claims provider, read this.
Enjoy!
