I’ve been working through the different frameworks Microsoft has used in Dot Net for Authentication and Authorization of users. I’ve worked my way forward into the Dot Net 4.5 consolidated implementation of Claims Based Identity.
The move to using Claims for Identity was a strategy shift from managing a set of fixed scalar values to managing a set of claims that may be managed for a securable object. A user could have a set of claims of many different types.
- What is my Email address?
- What is my Name
- Where is my Office?
- Am I and Administrator?
- Am I a User of Application XYZ.?
In previous models, these would normally be implemented using scalar properties for things like names, Email or Office. Roles or group assignments would determine my permissions. All of these different things are rolled together into a single collection of Claims for a user.
Microsoft built a Single Sign on Authentication service called Active Directory Federation Service (ADFS) which utilizes this newer Claims based model, allowing authentication from different authorities to be captured from a centralized service. This runs on Windows Server, starting in 2008.
The coolest thing is that the Claims Based objects are implemented in a generic fashion. This allows your application to handle all of the logic necessary, without having to be concerned with the details of gathering claims tokens from different authorities. This is especially true when combining the claims library with ADFS.
The best part about the Claims implementation, in my opinion, is the separation of your business logic from authorization. You can decorate a method with the necessary claims to be used for authorization, and your claims manager code is responsible for determining if the current credential has the appropriate claim. Methods in your business logic controller don’t parse the current user’s claims for the necessary credentials. This is a great separation of concerns.
Next up for me is the further expansion of claims, and the integration of OAuth.