8

Many questions have already been asked about Claims-based authentication and the differences with other approaches: Role-based vs Claims-based Explain claims-based authentication Now, my favorite answer is one given on stackoverflow: Using claims-based authentication.

However, after reading through them, my question is not solved. The question I have is twofold:

  1. Is there a difference between claims and attributes (ABAC)?
  2. If we may look at a 'role' as being a claim, what is the particular advantage of claims-based authorization over role-based authorization? (note: I'm using authorization instead of authentication here, as I feel it is not really about authentication).

To elaborate my question further, I will give three examples of how I see claims-based, role-based, and attribute-based authorization. Disclaimer: I am not sure if these examples are correct, they are just part of my question.

Claims-based example

I have read through an interesting blogpost in which it is explained how we could use claims-based authentication in MVC / Web API. It seems that (in that blogpost) a method is secured (authorized) by looking at the claims that are associated with the user who is trying to access the method. If that user has a claim to 'view' 'streetaddresses', then he is authorized to view that data.

  [ClaimsAuthorize("Read", "SomeData")]
  public string Get()
  { 
      return “somedata”;
  }

Now, the creation of the claims is separated somewhere else, which is not really specified in that blogpost. I'm assuming that hidden method checks whether that user, with that certain role, is allowed to view streetaddresses. Now then what is the difference with role-based authorization?

Role-based example

The difference is not clear to me, let's compare it with the old role-based authorization. I can once again define an attribute for each method, which restricts the execution of that method to certain roles. The 'view streetaddresses' method is for example restricted to users with the role 'admin'. So instead of checking the role in the separate method, we check it right here. Or am I missing something here?

  [RoleAuthorize('admin')]
  public string Get()
     { 
         return “somedata”;
     }

Attribute-based example

I do see the advantage of a more fine-granular authorization control. But I would implement something like this, to define that only a user with the role admin can access 'somedata' during working hours, and only if that admin user has blue eyes.:

  [AttributeAuthorize('role=admin;time=09-17;eyecolor=blue')]
  public string Get()
     { 
         return “somedata”;
     }

This last example really seems advantageous to me, but I'm not sure whether or not it is the same as my first example, which is claims-based authorization.

To end, a last question has popped up:

  1. This means that claims ARE different from attributes, as attributes are used to define which rights a user has, whereas claims are these rights?
Community
  • 1
Michael
  • 5,393
  • 2
  • 32
  • 57

1 Answers1

9

Attributes are claims. A claim is simply a statement by someone/something that a user has a given attribute. That someone is the issuer which could be an IdP or an internal bit of logic that gets data from the database.

This gives you way more flexibility in how you design your systems as you can specify that a given task will always require a user with a given attribute, e.g. a given right, say 'CanTransferMoney'. What role can you create that would properly describe who can do that? How often would it only be that role that can do that?

At a higher level you could configure it such that all users in role 'Money Manager' have the attribute 'CanTransferMoney', but in doing so that wouldn't require you to make code changes, whereas hard coding a role in the code might.

Regarding your last question conceptually a claim defines which rights you have, and an attribute defines which rights you have. In my opinion at some point it really just comes down to semantics over which name you want to use. If you look at how SAML tokens were originally designed you'll see a claim was/is a function of the attributes provided in the assertion.

Steve
  • 15,155
  • 3
  • 37
  • 66
  • You mention _"a given right, say 'CanTransferMoney'. What role can you create that would properly describe who can do that? How often would it only be that role that can do that?"_ It is correct that I would have to create a custom role for that, which I attribute to users who may transfer money. But doesn't the same problem exist with claims? I have to attribute the claim 'CanTransferMoney' to all users who may transfer money.. – Michael Mar 05 '14 at 09:19
  • In that particular example you're right, but the point is that you're dealing with something more abstract than a role. You could do claim:role='Money Transferer' as your attribute. It happens to be a role check, but you're still using a claim for it. – Steve Mar 05 '14 at 17:11
  • ...And that the benefit here is *that* you're using something more abstract than a role. – Steve Mar 05 '14 at 17:18