RoleClaims: Usages Designs and Questions

[ghost]

Maybe I am missing something, but I find RoleClaims "badly considered", even neglected.

Whereas Role Claims/Group Claims are essential for intranet Apps (Windows authentication), and "general" group membership—without them, it will lead to some repetitive code, or to write custom Identity— I find that they are not "user friendly".

So I have some questions, and will share some thoughts.

Usages of RoleClaims

What is the purpose of RoleClaims in Identity?

• How to use them accordingly to you?
  • This subject is not documented.
  • I find no sample on github;
• Do you consider to remove them in the future?
  • It seems—badly considered—and that it could be…
  • if yes, how you will replace them? (How??? Knowing that, most of us cannot rely on something "ephemeral")

Design and limitations

If we want to use RoleClaims as it should (in a many-to-many relationship) like AspNetUserRoles table, we find that some pieces are missing…

• No documentation…
• No many-to-many relationship table between Roles and Claims, ready to use;
• Weird property public virtual TKey RoleId { get; set; } in IdentityRoleClaim;
• Not ready to use in AuthorizationHandler as
  • Nothing ready to use in ClaimsIdentity and ClaimsPrincipal classes, to get RoleClaims;
  • If we use DI in AuthorizationHandler, we have to register the AuthorizationHandler as scope to get access to RoleManager/UserManager, etc…

Consequences

• We have to do some choice: singleton vs RoleClaims access;
• Write many-to-many relationship table between Roles and RoleClaims;
• Keeping useless property public virtual TKey RoleId { get; set; } in IdentityRoleClaim;

But If we want to get something nice and simple, particularly with AuthorizationHandler:

• With or without the current RoleClaims Api, we have to dive into Identity Customization, because nothing is ready to use as it should be…

Conclusion

Can you reconsider the importance of RoleClaims in Identity, and provide us "a better design"?

[flatproject]

I would like to see some usage examples as well. Very useful but completely undocumented. Can they be used with the Authorize attribute?

[blowdart]

@Rick-Anderson Documentation required.

@flatproject That is documented at https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles?view=aspnetcore-2.1

[blowdart]

@ckams It's unclear what you're asking for here. Certainly there seems to be a bit of confusion between roles, claims and the role claim itself, which admittedly isn't helped by documentation. Why do you feel roles are many to many? Consider the usual Admin role. It's a 1 to many, 1 Admin role, with many members. Then you authorize on the role. We don't assign claims to a role, the role itself is a claim.

[ghost]

@blowdart Well, as there is no documentation, I see role claim like this ("in much more complex and powerful way"):

• We can use role claim for "Group Policy", in assigning claims.
  • As in Active Directory Groups GPO and access permission, or Linux/Unix groups permissions. (To get a more fine grained access control.)
• Users are in one or more groups, and these groups have permissions set.
• As in Windows/Linux-Unix systems, users can carry claims/permissions as well.

Recap: users can be in several roles/groups. These roles/groups have claims/permissions which give access or not to a resource. (And all this stuff can be mapped with users/groups of a running OS).

For example, for a given role claim table like this (mapping IActionResult):

Id	ClaimType	ClaimValue
1	Create	Add
2	Read	Index
3	Details	Details
4	Update	Update
5	Delete	Delete

If a group has claim 5 | Delete | Delete, every user in this group will be able to delete things that are related to what this group has access to.

Everything is checked in a AuthorizationHandler class (unfortunately, registered as Scope), where Role claims, for the current user, are checked through IdentityDbContext.

Like this, we can give access to area, documents, etc… in a more fined grained, and natural? way.

[flatproject]

@blowdart apologies but I cannot see any documentation regarding the RoleClaims table and how we can use it or if the Authorize attribute uses/can use the claims of the RoleClaims table.

If I add a claim in the RoleClaims table then what? How can i use it?

The quoted link doesn't make any reference to RoleClaims.

Thank you

[blowdart]

So you're right, there's no documentation. You can follow the docs issue at https://github.com/aspnet/Docs/issues/7469

As this is really a docs issue I'm going to close this one, and work on getting the missing docs done.

[ghost]

@blowdart And what about the design? Could it be "revised"?

[blowdart]

Not easily, because it'd be a breaking change and may affect how others are using it.

If you want fine grained you go to claims. Roles are a hold over from NT Domains/Groups, which were extended to be more useful by assigning claims to them as well as the role name, so folks could get claims in an easier to manage manner.

[ghost]

If you want fine grained you go to claims.

For now, I do not see who to get the same result I need, with claims only. Maybe the future documentation will be helpful.

Roles are a hold over from NT Domains/Groups, which were extended to be more useful by assigning claims to them as well as the role name, so folks could get claims in an easier to manage manner.

Unfortunately it is "too simplistic". Too bad, because we could get a powerful ACL system in ASP.NET Core.

[blowdart]

Keep in mind we write frameworks. If what we have meets 95% of our users needs, with enough flexibility for others to go further than that's great for us. And you do have the flexibility with claims and authorization policies. Identity is meant to be simple, not all things to all people.

[ghost]

I agree, but

• it will be better/easier to understand with a doc… for now nothing is easy in the flexibility/customization (even if I succeed to do what I want, it costs me too much time because of the lack of documentation)…
• ACL is not something too much complex for enterprise level app… (I used to code in PHP, and Zend frameworks, Joomla, etc… provide ACL. With all due respect, In comparison, Identity looks like a back to the Past…)
• nothing prevents to suggest some improvements, or do not mention community involvement…
• you should "write" for customers, not for simplicity sake… And I used to think that ASP.NET Core was for writing enterprise level app, not to write simple blogs…

Anyway, while waiting for your documentation, I wish you a good day.