What do you mean by?

[chobo2]

Hi

I am a bit confused about what you mean by

Rather than try and store all the “roles” that a user might have (e.g. administrator, user, super user) you can store information about the user as claims.

Blog Post

How does it eliminate the need for roles in your database? How would you know what kind of role that user is(are they super user or an admin?)

p.s

Great articles but you might want to think of allowing comments or some where a place to email you.

[jonhilt]

Hey,

Thanks for the question :-)

So basically claims are an alternative to roles and whether you use them instead of roles will likely depend on what you're trying to achieve.

I think Andrew Lock explains this concept well in this post...

If you scroll down a little you'll get to an image about identities and airport security.

He explains that you might have a passport with your name and country on it and also a boarding pass with a flight number on it.

Now, using "roles" you might just be classed as a "passenger". But that would make it difficult to enforce certain security restrictions. For example, are you a passenger with a valid boarding pass, are you a passenger with access to the VIP area?

In this scenario "passenger" (as a role) is quite a blunt tool and wouldn't really help answer either of those questions.

The claims equivalent would see you have "First Name" and "Last Name" claims on a passport, which could be checked in order to permit you to buy a ticket.

Then (stored on a boarding pass) would be additional claims like "FlightNumber", these would let you past the security system that stops non-flyers getting further into the airport.

Finally you might have a VIP number claim (on a VIP card) which could be used to check whether you have access to the VIP area. Perhaps that might even be on the boarding pass if you only have VIP access for this flight (having never had access to any sort of VIP lounge I have no idea how that actually works ;-)).

So you can see that claims provide information which you can then design policies around. These policies can be quite granular (and specific), only permitting people with a certain combination of claims to access parts of the app (and perform some operations).

In any app where the security is very granular, roles-based security would likely result in coming up with a lot of roles whose names had little relation to the real world (but were necessary to lock parts of the system down) whereas claims can more closely models a real-world domain in your application (like Andrew's Airport example).

HTH

[chobo2]

Hey

Thanks for that write up, When I read about it, it does make sense till I get back to my application again. Where I have a scenario like this.

I have a company that has many branches, I want someone to be able to add/edit/delete/update users to any branch. However there will also be users who can do those same actions but only at the same branch they work at.

So I know that branch id would definitely be a user claim(if we are talking about asp.net identity) but what about the rest? Should I make a role and be like companyAdmin and give them x amount of role claims? But when if I just want someone to add new people but can't delete then I am making a new role to support that.

Should I just have a claim for everything and forget roles all together and just have something like

ClaimType.Permissions : company.add ClaimType.Permissions : company.edit ClaimType.Permissions : company.delete ClaimType.Permissions : company.update ClaimType.Permissions : branch.add ClaimType.Permissions : branch.edit ClaimType.Permissions : branch.delete ClaimType.Permissions : branch.update

But then I guess the draw back is now you really don't have a container of what a group of people can do.

Then throw resource based authorization in and I am all confused on what to use.

[jonhilt]

Hey, really sorry I didn't come back on this, must have missed it somehow!

In the end, this comes down to how granular you need your auth policy to be.

The example you cite there (with claims for everything) gives you really close control over who can do what.

I think I saw a talk by Jimmy Bogard where he had essentially this approach.

Every single controller action was decorated with very specific auth, so you could literally give someone access to just one "action" if you wanted to.

In truth I don't think there's a "right" answer here, just different options based on how complex your auth requirements are.

So, now a few months has passed I'm interested. Have you implemented this in an application? If so, how did you get on with it in the end?

Thanks, Jon