Managing users and roles in the ASP.NET identity framework is a tricky affair, but it can be made easier with the right step-by-step guide. Below is an example of a small use case to illustrate the effectiveness of the ASP.NET Identity framework.
This example will follow ABC Times, a fictitious newspaper that is developing their digital platform in MVC 5 and will implement an identity framework using ASP.NET Identity 2.2.
The key requirements for identity management are that the system should provide authentication of the users and that the system should provide a very flexible way to authorize users.
For the implementation of ASP.NET Identity management, we will refer to this blog on roles-based authorization. However, we will be adding flexibility around authorization in our example.
To build the case, we will assume the following roles:
On the MVC controller side, we have a single ArticleController with the following action methods:
After following the first four parts of the blog, the initial implementation of role based security in ASP.NET Identity should be completed.
However, there are a few flexibility concerns that arise:
The first concern can be managed by breaking down the roles into a more granular level, so instead of broad category of roles we can define granular level roles as:
This allows users to be assigned access to an almost individual level of methods. However, this configuration would be extremely difficult for an administrator to manage because there would be so many users in so many roles. This difficulty brings about a third concern:
To solve this third concern, we must introduce GroupRoles. The earlier broader roles will now collate these granular roles and users will be attached to these GroupRoles instead of the broader Roles.
Below is a mock-up of the system-wide access:
Another example of a good implementation of these processes is available here.
To help with the second concern—how to restrict a user who belongs to the write GroupRole from removing articles—we’ll reference the fifth part of the blog from above and handle the flexibility concerns through Claims.
Claims can be applied on top of GroupRoles to an individual user. So if we wanted to prevent the writer John from deleting articles, we would create a claim in the system with the name “DenyArticleRemover” and attach it to him.
While creating the ClaimSet, we can also reset the ArticleRemover role to “deny” if an individual user has a “DenyArticleRemover” Claim as well. This step will happen during the creation of a claimset for an individual user. This will then prevent John from removing articles, but not any of the other users.
The system-wide access will then look like this:
|Role||John (within the Group “Writer”) with the claim ClaimType:”DenyArticleRemover” ClaimValue:”True”||Other Users within the Group “Writer”|
Tweaking the ASP.NET Identity Framework in these ways has many advantages for creating a flexible identity system.
Addressing our first concern brought about these benefits:
Addressing the second concern then allowed admin to add a new claim directly to a user, meaning that they could explicitly remove a user’s particular function by introducing “Deny Claim.”
Addressing the third concern created a model in which admin could manage GroupRoles without having to manage individual granular roles for each individual user, thus cutting down on the number of formulas to keep track of.