23 January 2017
In moving to ASP.NET Core, one of the things which puzzled us was making sense of the Identity features for roles and claims.
We kept finding ourselves asking "what's the difference anyway - aren't they both just things which you give to a user to show their permissions?".
Before we could decide whether these features added value to the membership systems that we build for our clients, we had to decide what Microsoft intended us to do with them in the first place.
It didn't help that Identity still has an impenetrable soup of IThis, IThat, ISomethingElse interfaces to extend User and Role stores with, which can be mixed and matched with no sense of how they actually fit together.
What we found
The key for us was understanding that a claim is something which a user says is true about themselves - hopefully secured to make sure that it came from the application to begin with. ASP.NET bundles up a user's current collection of claims with their authentication cookie.
It follows that you can authorize users based on the claims they have.
A role, however, is just an arbitrary group of users. In essence, a role is a placeholder for one or more hidden characteristics of a user - their claims.
Up until now the membership systems we've built for our clients have been based just on roles, with whoever assigns a role to a user implicitly making judgements about who they are.
But knowing that a role is actually just a convenient way to group claims let us see what Microsoft were trying to do.
If you consider that:
- A Role store can implement IRoleClaimStore, which has methods for CRUD operations that imply a one-to-many relationship between roles and claims.
- A User store can implement IUserRoleStore, which has methods that imply a one-to-many relationship between users and roles.
What we've got now is a way to assign a role to a user, as a proxy for a specific set of claims that can be controlled by the application.
Our Conclusion
So all that this boils down to is that we've just got an extra layer of flexibility.
We can implement very fine-grained permissions models using claims, but hide the admin work of having to repetitively assign sets of claims to every user.
Our clients can keep using the simpler role-based systems which they are already familiar with, but which can now even better reflect their specific needs.
Read other insights