Wednesday, April 06, 2011

From Properties to Capabilities

Hal Lockhart has an interesting post on different authorization models, distinguished by the nature of the claims/attributes made within some token/assertion. Hal argues that there is a spectrum between 'properties' (where the attributescontain information about who/what the Subject is) and 'capabilities' (where the attributes contain information about what the Subject is allowed to do).

Coincidentally, I was working at my 'drawings' this morning - sketching out something similar for OAuth.

The diagram below shows three different models for the interaction between OAuth Client, Authorization Server, and Resource Server.

In the top model, the Client requests of the OAuth AS a token, but does not specify any particular RS target. Consequently, the AS can issue a token with claims that contain only generic attributes of the Client/Subject.  This is Hal's properties model. The AS authenticates, the RS authorizes.



In the bottom model, the Client includes in its request to the AS the scope of what actions it desires to perform at the RS. The token that the AS subsequently issues reflects a positive authorization decision and not some generic attribute of the Client. This is Hal's capabilities model. The AS makes an authorization decision and tells the RS about it. Makes for simple RSs.

Reflecting the delegated authorization use case that originally motivated OAuth - it is the capabilities model that gets the most attention. The assumption is that the OAuth access token issued to the Client reflects a set of capabilities assigned to it by the Resource Owner. But there are lots of applications of OAuth where the access token wont reflect capabilities but simply Client properties.

Note: The middle model  has the respponsibility for the complete authorization decision shared amongst the AS & RS. It is there because any good taxonomy has at least 3 permutations - I have nothing more to say about it.

1 comment:

Eve M. said...

Hopefully UMA will have some juicy specifics to share soon on our preferences for the division of labor you and Hal are discussing, since we're hard at work on our "scoped-access" model. It involves a client having to cough up "properties" (which we do call "claims") to an AS in order to win a capability* (which we call a "scope") that can be presented to an RS.** A neat effect of dividing things this way is that it offers a natural way to do scope upgrading.

These recent meeting minutes describe what we're going for:

http://groups.google.com/group/kantara-initiative-uma-wg/browse_frm/thread/55aa58de4d33b846

*It's not a "capability" in the strict technical-literature sense, but I think it meets Hal's general definition...

**We actually arrange for the RS to "validate" a presented token at an AS, but the RS is ultimately responsible for mapping the nature of attempted access on the resource to the actual scopes associated with the token.