4

VS2013, MVC5

I may get some terminology wrong because I'm new to this topic.

What I've read has led me to conclude that claims can be used for authentication and authorization which are 2 very different concepts. Assuming this thinking is correct, my question relates to claims as they might apply to authorization, not authentication (or identity? - is it accurate to consider identity as a substitute concept for authentication?)

The Wikipedia article seemed as concise as anything else I read saying (1st line last section) the difference between claims and roles is a:

distinction between what the user is/is not and what the user may/may not do

If I use claims to determine what a user may or may not do, I don't see how that is different than what roles do. This article kind of implies it's different, but the example seems the same to me with the claims example merely a better role definition, yes?

This article suggests there's little difference but the explanation seems to suggest an absolutely fundamental difference because it begins to employ a value in the claim. But unless the value allows the claim to composite roles into a single claim, it's still just a role, yes? And if you do composite roles into a single claim value in a large application, while that scheme might be more space efficient wouldn't it also require a method to decode the composited roles later?

This previously linked article stated that while there is a data structure in MVC5 for claims, it's not tied to a data attribute, so wouldn't using claims for authorization require significant extra programming or more complicated references to the claims?

So that's what brings me to ask the question in the title of the post, is there a fundamental difference? Because if not, I don't see why I would use claims for authorization.

I'm not experienced enough yet to fully follow how claims are used for authentication, but I get it there is significant value for using a 3rd party to authenticate and also for things like single sign on, but that's not my focus in this question.

Community
  • 1
  • 1
Alan
  • 1,587
  • 3
  • 23
  • 43

2 Answers2

2

You are digging too deep. There is no fundamental difference between a role and a claim. To the point that roles are stored as claims in the authentication cookie. You can pretty easily create authentication attibute that will work with claims. Only roles have slightly more code around them in the framework. When you call IPrincipal.IsUserInrole("rolename"), the framework actually checks if user has a claims of type ClaimTypes.Role with the value "rolename".

I have played with these concepts for a while and my conculsion was that claims can give you more granular authentication levels. Also you can use claims as a containers for data to add on auth-cookie. Roles are pretty inflexible in this sense.

trailmax
  • 34,305
  • 22
  • 140
  • 234
  • Based on your answer, I think my immediate need will only need roles. But, do you have a favorite page/site that would be helpful to see how claims are operating to provide more granular authentication levels? Even though I'll use roles for now, I'd like to learn the technique for the future. – Alan Mar 01 '15 at 22:55
  • 1
    I've developed a test project where I have tested the concept of granular access to MVC actions based on claims assigned. You can read through sources here: https://github.com/trailmax/ClaimsAuthorisation/ Note that this is only a test project to verify the concepts and the coding style is *ahm* dirty. – trailmax Mar 01 '15 at 23:37
  • Also I've been blogging about Identity: http://tech.trailmax.info/tag/identity/ may look through, some info about internal structure of the framework can be helpful when working with this. – trailmax Mar 01 '15 at 23:38
  • Please check my comment below b/c it depends on both yours and the post below. – Alan Mar 02 '15 at 17:43
  • So, I downloaded your project but won't be able to work w/ it for a while; I can read C# but I think VB :-(. I also perused your site. Thx for both links. I may have misunderstood your comment re the framework checking claims for .IsUserInrole(). I thought you were indicating claims get checked automatically by the attribute, but after working w/ it I'm guessing I misread. You did indicate it's not too hard to create a claims attribute. Can you point somewhere to learn how to do that? – Alan Mar 03 '15 at 01:58
  • See this for the claims Auth filter: https://github.com/trailmax/ClaimsAuthorisation/blob/master/ClaimsAuth/Infrastructure/Identity/ClaimsAuthorisationFilter.cs – trailmax Mar 03 '15 at 09:20
1

There is no fundamental difference. The advantage of claims is it could contains data. For example you may have claim with MaxAllowedOrderSum=1000 and use it for authorizing orders.

With role authorization you will need to invent Role=PriviledgedManager and somehow get the maximum sum of orders. Nothing impossible but more entities involved.

STO
  • 10,390
  • 8
  • 32
  • 32
  • So does yours and the previous answer mean the following: (1) I put my roles into the MVC5 template table AspNetUserClaims (2) I decorate a method or controller with , (3) the framework in its default code will keep users without a claim from executing the method or controller just as if I had put the role into AspNetRoles? (4) Then I can make a check against the claim in code for whatever limit may exist? – Alan Mar 02 '15 at 17:41
  • @Alan You don't need to add roles into Claims table. Add them though `UserManager.AddToRole(user.Id, "MaxAllowedOrderSum")`. And the framework automatically adds them where appropriate - you don't need to think about that one. And will keep everyone without the role from your decorated controller. – trailmax Mar 02 '15 at 20:50