14

So I understand roles vs permissions. I also understand roles vs claims. In both cases claims and permissions are granular, usually per feature or business operation such as AddPerson permission. I've been learning about claims based authorization and the examples that show how it's "better" and it's usually comparing it against role based authorization. Obviously it is better because that's the wrong way to use roles as you should be using permissions as a mapping between operations and roles.

What is the distinction between claims based and permission based authorization? (note permissions are different from roles, so this is not a duplicate of the Role vs Claim question)

In both it seems you have granular permissions/claims. So far the concrete examples I've seen of claims are really close to what I would conceptualize as permissions. An example I see with claims is the Add/Person claim, and certainly I would have similar with a permission as a AddPerson permission. I find usually I have a business layer with single entry points for things like this and every feature/entry point requires a permission. In both cases the rational for permissions/claims is that over time a particular identity or role might change in terms of what things it is allowed to do. And if you've hardcoded checks for that role within your application, you have to make code changes to accommodate, but if you've used claims/permissions then it is simply an administrative matter of changing what the role is associated with. So both seem to carry the same benefits.

I ask this question not to sound like I'm challenging the idea of claims. Instead I know I will probably have a better concept of claims if I understood more clearly what makes them stand apart from permissions.

Improve this question

2 Answers 2

Reset to default
18

A claim is somewhat more arbitrary than a permission. A claim is 'blue eyes' whereas 'AddPerson' is a permission. It is an assertion from the identity provider that a given characteristic (or more accurately, an attribute) about the identity is true.

You can determine permission based on claim or characteristic because 'all blue-eyed individuals can do xyz' whereas a permission is explicitly calling out what you can and cannot do. With a permission you cannot (easily) determine a characteristic by, say, 'anyone who can do xyz has blue eyes'.

With that being said, a permission is a claim. It just happens that the identity provider is asserting the identity has the characteristic of having permission to do whatever.

In short: a claim is an arbitrary attribute about the identity, whereas a permission is an asserted right to do something.

Improve this answer
3
  • 4
    It seems like claims are a superset of permissions, since you can represent any permission as a claim, and additionally represent other arbitrary assertions that aren't permissions(like 'blue-eyed'). I feel like "blue-eyed can do xyz" is a bit like the roles trap. If 'blue-eyed' is the claim, then the "can do xyz" is my code allowing an action for a claim. Bad: if(Claims.HasClaim('blue-eyed') || Claims.HasClaim('is-CEO') || ...) do xyz now I've eliminated the administrative flexibility of permissions. So it seems like you need to be a bit more disciplined in how you use claims.
    – AaronLS
    Aug 19, 2014 at 5:24
  • 1
    That's a fair way of looking at it. You will always hit that particular issue with authorization decisions. Keep in mind that roles too can be expressed via claims.
    – Steve
    Aug 19, 2014 at 21:14
  • What if you name it CanAddPerson, would it suit to be a claim?
    – Konrad
    Dec 4, 2018 at 10:17
5

See http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language for SAML, which provides claims-based authorization means. As Steve said, claims can map directly to specific permissions if the service provider chooses, or to roles as well. How claims from the identity provider maps to permissions/roles in the service provider is completely up to the service provider. The identity provider simply asserts the claims are true for the authenticated user, and the service provider takes these claims and decides how they relate to permissions and/or roles in the service. The claims are trusted statements about the user from the identity provider, and taken alone have nothing to do with permissions or roles until the service provider decides what the claims mean.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .