[WG-UMA] UMA token validation models

Skip to first unread message

Maciej Machulak

Mar 28, 2010, 5:43:07 PM3/28/10

As I was assigned to discuss one of the protocol issues (Token Validation Models) here are some of my thoughts:

1) Local token validation

Not mentioned on the Wiki, is the local token validation which is currently used in OAuth WRAP. In this model there needs to be an agreement between a host and an authorization manager with regards to what tokens are issued by AM. A host needs to understand the syntax and semantics of such tokens in order to be able to validate them locally without the use of AM.

This is very scalable and does not introduce any performance problems. However, it may prevent a host from being lightweight - i.e. a host needs to implement an evaluation engine that will check whether an issued token is sufficient and needs to understand the token.

If we have only few ways (or ideally a single way) of generating secure tokens then a host can implement evaluation functionality and only needs a certificate (public key, to be exact) from AM to verify tokens. My concern, however, is that we now choose to depend on the token type as a Host really needs to understand what the token represents (the format needs to be agreed between a host and AM). This is totally fine, as long as this is our conscious decision.

I guess a Host, when receiving the metadata document from AM, can look at available UMA Token Formats and provide AM with the information about the format it wishes to use (i.e. because it understands this format). If it does not understand any format (e.g. a very basic host library) then a host may choose to use real-time remote token validation.

In local validation, AM is not aware of all access requests that are issued by a Requester to a Host, i.e. data analytics on AM cannot be accurate. This problem can be alleviated by allowing a host to expose access logs to AM (as discussed on the Wiki). My opinion is that this should stay out of the (core) protocol and may be implementation specific. It would be really nice to have a host which exposes access logs as a Web resource that can be retrieved by AM every time and Authorizing User wishes to examine these logs on AM.

2) Real-time remote validation:

This model has the disadvantage of Internet-scale performance issues as each access request needs to be validated by AM (i.e. the requester sends a token to a host and hosts checks with AM whether the token is sufficient to execute a specific method on a specific protected resource). In order to address this problem, a host can choose to cache decisions on its side and use these decisions for subsequent requests from Requesters. This, however, introduces the problem of revoking authorization to protected resources. There's a tradeoff between scalability and performance (decisions cached for a long time) and security (the cached decision is inconsistent with the newly created access control policy).

This model should be used in case a host decides that it is not capable of validating a token locally (e.g. does not have the required functionality implemented). It allows for accurate data analytics to be performed on AM (i.e. an Authorizing User can use AM to see what access requests are being issued by what requesters to which protected resources).

3) Hybrid validation.

In the hybrid validation, a Host learns how to evaluate tokens issued by AM - i.e. if it understands the access token syntax then it may ask for a certificate (public key) in order to validate tokens. If it does not understand then a Host could possibly provide rules (or even code-on-demand) for the validation process. I do not predict, however, that we could go this far as I don't see this approach (code on demand) practical. Any thoughts on that? :)

In general:

I guess it would be best for a Host to decide which token type it wishes to receive from AM. This step could be introduced in the protocol when a host receives a metadata document from AM, learns about available token types and replies back with the token type that it wishes to use indicating that it might validate the token locally.

The token itself cannot just consist of a signed representation of the allowed scope and access type (which a Host may check locally). This would prevent various use cases - e.g. one-time access to a resource could not be expressed within such a token. A token needs to be expressive enough for local token validation or simple (even opaque to a Host) for a real-time remote validation.

Looking forward to some comments and further discussion on token validation models.


WG-UMA mailing list

Eve Maler

Mar 28, 2010, 6:03:40 PM3/28/10
to Maciej Machulak, WG UMA
Thanks, Maciej!

For context, yesterday I completed my action item to flesh out the protocol issues list, and doled out assignments of issues to the various spec editors. Check out all the issues here, including #6, token validation:


-- and please comment given the analysis below...


Eve Maler

Reply all
Reply to author
0 new messages