Asp.net Core Identity Use AspNetUserClaims or AspNetRoleClaims?

asp.net-core asp.net-identity claims-based-identity role-based

11,291

+------------------+------------------+
|      Table       |   Description    |
+------------------+------------------+
| AspNetUsers      | The users.       |
| AspNetRoles      | The roles.       |
| AspNetUserRoles  | Roles of users.  |
| AspNetUserClaims | Claims by users. |
| AspNetRoleClaims | Claims by roles. |
+------------------+------------------+

A role is something assigned to a user.
- Eg. Jane is an admin.
A claim is something claimed by a user.
- Eg. Jane's date of birth is 1990-10-1.
A role-claim is a claim claimed by a role.
- Eg. Admins have access to the dashboard.

If you find roles and claims confusing, it's probably because roles are a special case of claims i.e. roles are claims.

Role vs Policy

For role based authorization, the authorization system checks if the user has been assigned the roles required to access the given resource.
- Eg: only users with the Admin role can access the dashboard.
For policy based authorization, some business logic is executed to decide if the resource access should be authorized.
- Eg: only Admins with an age above 40 can access financial data.

Say I have this scenario

I have a company that has many branches, in each branch their will be an administrator of that branch, they got full power over the branch and can do anything but nothing at another branch. At the company level there will an administrator who can do anything at the company level and any branch. Finally I have a person in the branch who can just add new employees.

Here's one way of doing it:

2 roles: Admin, TheRoleThatCanAddUsers
A claim called Branch that can take a branch id (or anything else to identify the branch). Company admins can use a value like "CompanyWide" or 0 or -1.

Now create a policy that checks the Role and the Branch claim and decides if the user should be authorized.

11,291

chobo2

Updated on March 25, 2020

Comments

chobo2 about 4 years
I am still confused about all this Identity stuff.

First I am still confused the difference between Roles, Policies/Claims. From what I read roles is the old way of doing stuff and was kept for backward compatibility, so does that mean AspNetRoleClaims is part of this backward compatibility?

I think I understand Claims and Policies when thinking of them individual, like policy is basically a set of rules that must pass and gives the ability to change rules without having to go through out all the code and change roles.

Were a claim, is basically a trusted source is vouching for about that user(ie this is their age, which might come from a government source ).

Now what confuses me is putting it all together.

I generated the Identity tables and see
```
AspNetUsers
AspNetUserRoles
AspNetRoles
AspNetRoleClaims
AspNetUserClaims
AspNetUserLogins
```
I get what the AspNetUsers table does and AspNetUserLogins(seems to be if they use like external login providers).

I get confused on what the difference between AspNetRoleClaims and AspNetUserClaims. Do I just use AspNetUserClaims or do I use everything?

Say I have this secenario

I have a company that has many branches, in each branch their will be an administrator of that branch, they got full power over the branch and can do anything but nothing at another branch. At the company level there will an administrator who can do anything at the company level and any branch. Finally I have a person in the branch who can just add new employees.

What does this all look like? Do I make 3 roles?
```
CompanyAdmin
BranchAdmin
AddUsersAtBranchLevel (or is this some sort of claim??)
What do the tables look like? Is there anything going to be in AspNetRoleClaims? AspNetUserClaims?
```
Now I can make a policy to check if the user is a branch admin and if they are trying to edit their branch?

Or do I just forget all the role stuff and have in the AspNetUserClaims
```
User1   CanAddUserToBranch true
User1 CanDeleteUserBranch true
User1 CanAddUserToCompany true
```
Then in my code make those all different "ClaimTypes" and create a polciy that sees if they have say "CanAddUserToBranch" and then another claim or policy to check what branch they are in to make sure they are trying to add something to the right branch?

Edit

Do you think I Need to use Resource-based authorization?
- Sum None almost 6 years
  
  You had my upvote at "I am still confused about all this Identity stuff..." However, your question is perfect. As you said, according to several credible sources, we aren't supposed to use Roles any more (in a nutshell and there are 2.1.bugs for roles). Yet, the only current answer below recommends Roles. Most questions like your's on SO go unanswered or using Roles again... or antiquated code from older versions of Identity/Core/etc...or scaffolding out Identity and customizing it. I've been watching msdn, etc videos, reading articles and blogs all day and the answer is still not clear.
- galdin over 5 years
  
  @SumNone I'd appreciate links to the credible sources you mention... Nothing wrong with using roles if it does the job. Roles are claims. You may also use IdentityCore, and create your own role claims in the AspNetUserClaims table. Choose whatever solves the problem the best! (please share links though, because I haven't heard a recommendation stating roles shouldn't be used.)
- chobo2 over 5 years
  
  Well the problem is if you don't understand one of the solutions it's hard to choose which solves the problem best. After much research I sort of just gave up and just did "Roles"(no role claims or any claims). Requirements of what was needed allowed me to just use Roles so I got lucky. I am finding the same thing as SunNone everyone recommends to not use Roles(just read it one of core books) but no one really goes into details on how to use them and if they do it is such a limited scenario that when I tried to apply it to my app I ran into issues fast.
- Sum None over 5 years
  
  github.com/aspnet/Docs/issues/7108 That is a link where Rick Anderson pulled my question out of one of their older code examples and made it a work item. When the latest version of Identity came out (at that time... I think 2.1), roles were basically deprecated. There was also a couple "Channel 9" videos (IIRC) that came out with blowdart where he specifically said it. Here's another link about it too: github.com/aspnet/Identity/issues/1813 I wish you asked me back in June, I could have been more exact and probably shown you where blowdart said that in the video.
- Sum None over 5 years
  
  @gldraphael Please see my previous comment (I forgot to reply to you). Also: channel9.msdn.com/Blogs/Seth-Juarez/… Here's the blowdart vid... It's great overall, but start watching at the 34 minute mark to hear about Roles. There is a second video too. Generally speaking, I'm with you. You're preaching to the choir. :) But, when starting new projects, I try to go with the latest standards and whatnot.
- galdin over 5 years
  
  @SumNone thanks for the link to the video. I think I'm going to open an issue to ask about this in the weekend... Of what I understand roles are not not-recommended. They're just trying to streamline things so you get to opt out of things you don't need. Issue #1813 refers to the template using AddDefaultIdentity() that uses IdentityCore rather than the whole thing.
chobo2 almost 6 years

So in your scenario are you using role claims? My understanding is you either use role/role claims or just user claims. How you wrote it, you seem to use all?
galdin almost 6 years

@chobo2 No I haven't used roleclaims here. Roleclaims makes sense when a claim attached to a role and not a user. Also, you may use them all together, depending on the need.
chobo2 almost 6 years

Then I am a bit confused, You made 2 roles, and the Branch is a user claim?
galdin almost 6 years

@chobo2 that's right. Because the branch could be different for each user.
chobo2 almost 6 years

Right, branch makes sense but why did you choose to make roles,instead of just making a whole bunch of claims? Like in your model you will need to add TheRoleTheCanEditUser, TheRoleThatCanDeleteUsers. Or sacrifice that flexibility where if everything was a claim you would not have that problem.
galdin almost 6 years

Oh yes, you may certainly use Claims if that's the case. Roles are a specific case of claims that makes it easy to use. But if the flexibility of claims makes more sense, go for it!
chobo2 almost 6 years

Yea, still leaning towards that, though I don't know if there such a thing as too many claims. I also still not sure if I need something like Resource based auth.
galdin over 5 years

@chobo2, sorry late response. I'd create a policy (that uses claims) and use it to perform resource based authentication -- branch being the resource.
granadaCoder over 5 years

FINALLY! DotNet is doing something besides "just roles".
granadaCoder over 5 years

I'll give my 2 cents. You want to code the "checks" against CLAIMS, not roles. "EmployeeAdd", "EmployeeEdit", "EmployeeDelete", "EmployeeViewReadOnly". do NOT check "roles" for if someone can do something. Now, you create a role for the simple idea of grouping together some claims that made sense. "Human Resources Admin Role" will be a role that combines "EmployeeAdd", "EmployeeEdit", "EmployeeDelete", "EmployeeViewReadOnly". You then assign N number of roles to a user. "Mary" has the role of "Human Resources Admin Role"....The key point is that your code checks claims....
granadaCoder over 5 years

and when you decide you need a new role, you do NOT have to change any of the code that does the checking. By coding your checks against the CLAIMS, you can add new roles like candy withOUT changing any of the code that needs to check for functionality. If you do the wrong thing, and code your checks against roles, then you have to change your code EVERY TIME a new role comes along. Boooooo. So what is the user_to_claims. If you need a "one off" claims for a specific user, than you can put that there.
Eli over 3 years

This youtube tutorial shows using claims with roles side by side: youtube.com/watch?v=LJQBBvJ6tL0
granadaCoder about 2 years

Microsoft has a "Mix Policy and Role" example here: docs.microsoft.com/en-us/aspnet/core/security/authorization/‌… hows that for confusing??
galdin about 2 years

@granadaCoder - it's not if you think of roles as type of claim. In the example above, "Jane is an admin" could be read as "Jane claims to be admin". Have a look at the links at the reference links for roles here for some perspective.