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?
CodePudding user response：
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
CodePudding user response：
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 |
CodePudding user response：
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.