Is ASP.NET Core claims intended to specify what user can do

Question

ASP.NET Identity creates tables like UserClaims, UserRoleClaims which is exactly what I need. I have set of features inside application that user can or cannot access, for example reservations page, images page. For now, all that permissions are attached to roles, not users so, for example, if I say that all users with role admin can access reservations page all users with role admin will have access to it.

Inside UserClaims I will specify multiple rows "Access images", "Access reservations page" and inside UserRoleClaims I will specify which "claims" each role have.

Alternative is to create similar tables like Permissions and RolePermissions which are very similar to tables created by ASP.NET Identity in structure.

It seems somewhat strange to put my permissions inside claims, but nice thing is that everything is ready. Is ASP.NET Identity UserClaims supposed to handle this permission thing or are they just simple key value pair that "describe" user?

Answer 1

A claim is part of a user's identity. It describes what the user is, not what it can do.

Claims provide more granularity and flexibility than roles. Consider an example where only people above the age of 18 may access a certain feature in your application. You may have a role for this, but this is unwieldy as you need to make sure that users are added to this role when they come of age.

With claims-based authorization, the user will instead have a claim, DateOfBirth, against which you perform a security check when the user tries to access age restricted content.

identity.AddClaim(new Claim("DateOfBirth", user.DateOfBirth));

A good way to do a claim check is with a policy (which can also be used with roles):

services.AddAuthorization(options =>
{
    options.AddPolicy("MustBe18", policy => 
    {
        policy.Requirements.Add(new MinimumAgeRequirement(18));
    });
    options.AddPolicy("MustBeAdmin", policy => policy.RequireRole("Admin");
});

You can apply these policies to your controllers with attributes:

[Authorize(Policy = "MustBe18")]
public class AdultController : Controller
{
    // Age restricted content
}

[Authorize(Policy = "MustBeAdmin")]
public class AdminController : Controller
{
    // Administration panel
}

ASP.NET Identity provides you with the means to extend your user with additional claims with the UserClaims table.

It's worth noting that, at least according to some blogs and SO posts I've read on the subject, roles are considered a legacy feature and mainly included for backwards compatibility. I haven't found a source for this claim, and roles still seem useful to me under certain circumstances, so take from that what you will.

Answer 2

A claim s a statement that one subject, such as a person or organization, makes about itself or another subject. From my experience it should not be specific "CanReadReport", "CanWriteToCustomerDatabase". Instead to get more flexibility I prefer when the claims are:

InManagement: yes/no InEconomny: yes/no Sales: yes/no Employee: yes/no Consultant: yes/no Accountant: yes/no

Then it is up to the application through the policies to evaluate who should access what.

This blog post might help you: Identity vs Permissions

Answer 3

One way to deal with this is to store resource/action pairs in claims and implement some infrastructure (a special attribute, etc.) to require these claims declaratively on controller actions.

In your case these pairs could look like

Resource	Action
Image	access
Image	upload
ReservationsPage	access

Answer 4

Practically treat claims as groups in most cases. Basically it is a claim about what a user is or can do - and that can easily be logically be seen as a group membership, if you are more used to those terms. From those you can then compose (via a table) a list of specific actions (i.e. permissions groups have) and test those in the controllers.

Answer 5

Yes exactly, so Claims ?! Consider claims to be something very distinctly different to the ASP.Net Identity framework implementation you can choose to get in your default projects and which includes the tables you ask about.

Sure identify framework generates tables to handle such but is ultimately it is not all what it is about, the whole claim ting, or the token thing, which is when claims become interesting - it is just an implementation of it, another could be be for instance often be a Json Web token (JWT) used as a bearer token with a REST API, whichever what do you get in either case?

You get a lump of data encrypted and tamper free because it has gotten proof of content from your own server and that carries with and you have a (key, valuebag) type data that will morf to be a (key, value) if you only ever supplied one.

Then asp.net support Policies, which basically enable you to say that this policy requires that said lump of data contains the followingn ... and this can then be used on methods and controllers.

also programmatically you can easily access these claims, so when requests come in from authenticated user to api, any of the api instances presume you have a load balanced setup with many, and the request carry already stuff like userid, some controller or ui meaning_full_name with values ["view", "edit", "add", ... ] e.g.

Bearer tokens with claims is really a way that you can avoid having to authenticate and authorize each request and you can both immediately expire tokens if you wish and let them last as long as you like, really useful especially to web applicaitions if you go for the JWT version because accessing same in ui is pretty streight forward in all web MVVM frameworks like Angular, React, .. etc Tokens decrypting into Json being litterally in javascript the original JavaScriptObjectNotation a first class citizen object ... is just super easy to work with as opposed to anything which is not. And any programming language deserialize json these days so you can quickly populate a model.

So claims solve several things:

1. Authenticate and authorize requests for the backend
2. Deliver permission set (if used like that) and activation deactivation of features/ parts to ui
3. Release getting qualification for whatever really outside of login/ token generation flow
4. An easy way to revoke privileges

then what can you put in claims? anyting! you could serialize an object into a value as long as you base 64 encode or similar, if you like but mostly you shouldn't. Why is that you want to support the object part of a JavaScript object, the JSO in Json as it were so what we have is that each claim is in essence going to be a member property which can be a single value or an array and always only strings to ensure maximum compliance between tiers. obviously you can put anything in a string and treat it accordingly when reading to and from but for efficiency the important takehome is that it is a flat structure not a nested hierachy a list of (key,value) where value is a bit special depending on if there are zero, 1 or seeral values

I bet it will grow on You, and for convenience you can feed such from included database if you scaffold something with that in the new project guide in VS and get a lot of handling for free so to say, and why shouldn't you, beyond having to contend with a lot of code you didn't write yourself - Often this easy way is taken and then that means you will prepare for the next assignment which could be structured in the very same way :)