9

In ASP.Net Core, I find Claims authorization is very not-concrete method. We can add anything as ClaimType and ClaimValue pair; groups, firstname, lastname, brithdate, canAccessThisURI, isEditor, etc.. However, this approach (storing anything that can be stored as claims) will make a huge claims table which includes 50% of my application data.

I am wondering, as a good practice, what are the common data that should be stored as claims?

Mohammed Noureldin
  • 199
  • 1
  • 5
  • 4
    You would store there whatever data you need in order to validate/authorize the user. That almost certainly *does not* include 50% of your application data. – Robert Harvey Dec 02 '17 at 01:00

2 Answers2

3

A claim is simply a fact about a user that can potentially be used to identify or authorize someone in your system. Those two constraints should be enough to limit what you would put as a claim.

Some ideas for claims include:

  • user id
  • user name
  • user email
  • roles
  • group memberships

The user's metadata should be limited to what is needed to personalize the app for the user and to associate the user with their data. The user's id is enough to associate the user with data or provide an audit trail. Don't get greedy.

Roles and group memberships are authorization claims. For example if you have groups in your application then the list of groups the user belongs to lets you quickly check if they can access a private group or not. Roles are a little more fine-grained and speak toward what privileges a user has. These are usually application specific, so only add what you need to enforce.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
0

There are many systems, especially STS/federation systems, that do it this way:

  • one claim that describes the user uniquely
  • assortment of claims describing general conceptual things they (and others) have access to

The user's "profile" data within the app may not translate to/from the authentication source you are using and you may not use the same endpoints at all times or all users.

If you were familiar with the old Forms authentication it is analogous to the username & roles model and a lot of the built-in stuff still looks like that if you use System.Security.Claims.ClaimTypes of name and role appropriately.

Neither the old or new model gave you much out of the box for claim or role inheritance, but that is not particularly difficult to implement and implementing it lets you cut down on the volume of claims or roles that you need to keep in play from request to request.

If your application needs to keep track of a birthday, but does not need to use it in a security mechanism then there really ins't any benefit in keeping it in the claim collection. Put it in a separate profile dataset or something.

If your application needs to get the birthday as a claim from another system then you are looking at something more like customizing the federatedAuthentication or allowing the extra claim to persist.

Bill
  • 8,330
  • 24
  • 52