Best Practices for Roles vs. Claims in ASP.NET Identity

Question

I am completely new to the use of claims in ASP.NETIdentity and want to get an idea of best practices in the use of Roles and/or Claims

Answer 1

As @Claies perfectly explained, claims could be a more descriptive and is a deep kind of role. I think about them as your roles ids. I have a gym id, so I belong to the members role. I am also in the kickboxing lessons, so I have a kickboxing id claim for them. My application would need the declaration of a new role to fit my membership rights. Instead, I have ids for each group class that i belong to, instead of lots of new membership types. That is why claims fit better for me.

There is a a great explanation video of Barry Dorrans, talking about the advantage of using claims over roles. He also states that roles, are still in .NET for backward compatibility. The video is very informative about the way claims, roles, policies, authorization and authentication works.

You can find it here: ASP.NET Core Authorization with Barr Dorrans

Answer 2

Having used various authentication and authorisation techniques over decades, my current MVC application uses the following methodology.

Claims are used for all authorisation. Users are assigned one role (multiple roles are possible but I do not need this) - more below.

As is common practice, A ClaimsAuthorize attribute class is used. Since most controller actions are CRUD, I have a routine in the code-first database generation that iterates all controller actions and creates claim types for each controller action attribute of Read/Edit/Create/Delete. E.g. from,

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

For use at in an MVC View, a base controller class presents view bag items

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

For website menus and other non-controller actions, I have other claims. E.g. whether a user can view a particular monetary field.

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

So where do Roles fit in?

I have a table that links a Role to a (default) set of claims. When setting user authorisation, the default is to give the user the claims of their role. Each user can have more or less claims than the default. To make editing simple, the claims list is show by controller and actions (in a row), with other claims then listed. Buttons are used with a bit of Javascript to select a set of actions to minimise the "clicking" required to select claims. On Save, the users claims are deleted and all of the selected claims are added. The web application loads claims only once, so any changes must prompt a reload within this static data.

Managers can therefore select which claims are in each role and which claims a user has after setting them to a role and those default claims. The system has only a small number of users so managing this data is straightforward

Answer 3

A role is a symbolic category that collects together users who share the same levels of security privileges. Role-based authorization requires first identifying the user, then ascertaining the roles to which the user is assigned, and finally comparing those roles to the roles that are authorized to access a resource.

In contrast, a claim is not group based, rather it is identity based.

from Microsoft documentation:

When an identity is created it may be assigned one or more claims issued by a trusted party. A claim is a name value pair that represents what the subject is, not what the subject can do.

A security check can later determine the right to access a resource based on the value of one or more claims.

You can use both in concert, or use one type in some situations and the other in other situations. It mostly depends on the inter-operation with other systems and your management strategy. For example, it might be easier for a manager to manage a list of users assigned to a role than it is to manage who has a specific Claim assigned. Claims can be very useful in a RESTful scenario where you can assign a claim to a client, and the client can then present the claim for authorization rather than passing the Username and Password for every request.

Answer 4

To understand difference between Roles and Claims you mast face the limitation of roles and to feel how claims come over this issues, so lit me give you 2 scenarios to recognize the power of claims where role can't resolve this issues :

1- your site have to two modules (pages, service ..etc) the first module fore child(under 18 years old) the other for adult(over 18 years old) your user identity have birthday claim

you need to create policy on this claim so the authorization for each module will be given on this value and if the age of user come over the 18 years then he can go to adult module and not before this age

Role is Boolean data type you can have or not have the role role didn't have malty values

2- your site have role user and you wan't to prevent access of users to make some maintenance without changing the code

in claims you can create UnderConstrain policy that if true user can't view the page give property authorize for role user.