ASP.NET requirements for ClaimTypes

Question

I'm investigating using claims-based authorization in ASP.NET (MVC Core 1.0). When setting up a ClaimsIdentity, I supply a list of key/value string pairs to represent each Claim. Example:

List<Claim> claims = new List<Claim>
{
    new Claim("UserID", user.ID),
    new Claim("Name", user.Name),
    new Claim("Role", "basic")
};

My understanding is that I can use whatever keys/values I want. But I noticed there are some pre-defined keys available via the ClaimsType class. So, I could potentially use some of these pre-defined keys instead:

List<Claim> claims = new List<Claim>
{
    new Claim(ClaimTypes.Sid, user.ID),
    new Claim(ClaimTypes.Name, user.Name),
    new Claim(ClaimTypes.Role, "basic")
};

Questions:

1. If I use the pre-defined keys, are there any rules/restrictions regarding the actual values assigned to each key, or is it application defined? For example, is it OK to stick a database primary key in ClaimTypes.Sid, or does ASP.NET have certain expectations of what ClaimTypes.Sid should contain?

2. Are there any ClaimTypes that are required, or is it completely up to the application to decide what to include or not include? I imagine the answer may depend on specific third-party authentication services I would interact with, but how about the simple case of a self-contained ASP.NET project that does not use any third-party authentication. Does ASP.NET itself have any requirements?

Any links to requirements and/or best practices regarding usage of specific key/values would be appreciated.

Solution 1

If I use the pre-defined keys, are there any rules/restrictions regarding the actual values assigned to each key, or is it application defined? For example, is it OK to stick a database primary key in ClaimTypes.Sid, or does ASP.NET have certain expectations of what ClaimTypes.Sid should contain?

Using one of the pre-defined ClaimTypes will also modify the Type property if your resulting Claim. You can find a list of these types here. As far as I know, you are free to put a database ID into a ClaimTypes.Sid, however I would strongly recommend using your own name that calls it what it is.

Are there any ClaimTypes that are required, or is it completely up to the application to decide what to include or not include? I imagine the answer may depend on specific third-party authentication services I would interact with, but how about the simple case of a self-contained ASP.NET project that does not use any third-party authentication. Does ASP.NET itself have any requirements?

Assuming no third-party, you get to decide what is and is not required. Keep in mind that if you are storing claims in a cookie (not a third-party source), your space is somewhat limited; cookies cannot be larger than 4096 bytes in total.

The best articles I have found so far for ASP.NET Core claims authentication are here and here. As of this posting, we are still in RC1, so some details may change prior to the final release.

Solution 2

1. If I use the pre-defined keys, are there any rules/restrictions regarding the actual values assigned to each key, or is it application defined? For example, is it OK to stick a database primary key in ClaimTypes.Sid, or does ASP.NET have certain expectations of what ClaimTypes.Sid should contain?

Basically no rules resstrictions, but it depends on the consumer of the tokens. Asp.Net Identity by default expects user name to be as ClaimTypes.Name (either users display name or mail, whatever you use), role as ClaimTypes.Role and user id (not necessary the row ID, just unique to identify the user i.e. a Guid or email address) as ClaimTypes.NameIdentifier. The defaults can also be seen here on GitHub.

That being said, if you use custom claim types you need to tell it so in the ClaimsIdentityOptions when you configure Asp.Net Identity.

The claim type set in UserNameClaimType is the one used, when you do User.Identity.Name to access it in your controller. If your claim type do not match the one in ClaimsIdentityOptions it will just simply return null.

Comments

[cbranch]

Thanks for the info about Identity. I'm not currently using Identity, but that may change down the road. I'm using EF6 with MVC Core 1 right now (because EF7 is too incomplete), and Identity seems to be intertwined with EF7 and requires jumping through some hoops to work with EF6, so I'm holding off for now.