2

Using Windows Identity Foundation (WIF) in tandem with a Security Token Service (STS), is it possible to create complex claims that could satisfy a question such as:

For a user with a claim to a role "Support", that user:

  • Can only view and use resource1
  • CAN NOT update, create, or delete resource2
  • CAN NOT create, or delete resource3
  • Can only use and update resources with a "resource" tag.

It's a necessarily contrived example but is this possible? I'm thinking I want to authorize the authenticated user with basic claims and then add the relevant complex claims in the application (where those claims will be stored in a database and under control of application users).

Thanks, Richard

Richard
  • 603
  • 5
  • 14

1 Answers1

2

You can definitely model it like that - they are just strings - whatever you can do to strings you can do to claims ;)

But it would be definitely an anti-pattern. Claims describe the identity of a user - which might include coarse grained authorization information. There's a fine line here.

But for your use case you would rather implement your authorization policy in a ClaimsAuthorizationManager and use the identity claims as input to "calculate" your fine grained authorization decisions.

leastprivilege
  • 18,196
  • 1
  • 34
  • 50
  • How would you handle a situation where, for instance, a user had access to multiple resources, so perhaps those resources are claims. However, for each resource he had different roles (e.g. Reader for resource X and Writer for resource Y). In this case you couldn't just put "Reader" as a role claim because it would need to be qualified against a resource. Even using a ClaimsAuthorizationManager it would still need to know which Role applied to which resource. How would you handle this scenario? – ChrisC Jun 03 '15 at 12:42
  • Perhaps a way of handling this in claims would be to have a new claimtype called "ReaderForResource", and then the value would be "X", etc.? It seems workable, but this could certainly result in a lot of new claimtypes in a system with lots of roles/permissions. Guidance would be appreciated! – ChrisC Jun 03 '15 at 12:59
  • 1
    Claims are for describing the user's identity - not the fine grained authZ rules and permission. Leave that to some dedicated authZ logic. Or do you really want to build a dependency on a huge list of name/value pairs? – leastprivilege Jun 08 '15 at 07:39
  • Understood that claims are for identity. I intend to use an AuthorizationManager to remove the logic and dependencies from the code, but as a result it seems that the Claims would be a logical place to put this information to be accessible from the AuthMgr. How else would we access this information for a user in an efficient manner? Am I missing something about complex permissions scenarios? Unfortunately, every example out there of CBAC is always trivial and never details how one would approach a more complex scenario. – ChrisC Jun 08 '15 at 11:10