[WG-UMA] Extend Register Permission to include requested URL and HTTP Method

Mark Dobrinic mdobrinic at cozmanova.com
Mon Aug 25 07:46:30 CDT 2014


Hi Mike,

On 21/08/14 17:57, Michael Schwartz wrote:
> We are working on an enhancement to OX that may be of interest to UMA in
> general:
>   http://ox.gluu.org/doku.php?id=uma:uma_request_info
> 
> The Idea is to provide information about request info from client to the
> RS, so it's possible to map policies decision based on that information.
> For example, consider a DELETE request to:
>     http://example.com/api/v1/addThing/1234
> The AS may want to make an access decision based on the item. For
> example, a policy may specify that only the owner of the item can delete
> it.

As far as I can tell, in UMA the AS does not make the Access Decision,
instead the RS ultimately authorizes the request.

You can do a couple of things:
1) If you want to let access policies at the AS be responsible for
making authorization decisions on contextual information of every
request (Request Info like IP-address, time of day, etc), you could have
- short-lived (one time use?) RPT-authorization data for the
resource/operation, and
- include the request information as claims in the Client->*AS*
negotiation for adding authorization data to the RPT

This way, the AS can pretty much authorize every operation/resource. Not
very efficient though, as it involves (C->RS ; C->AS ; C->RS) 3
roundtrips to get the job done.

Advantage is that C->RS does not convey any authorization related
information outside the RPT, and *all* authorization related information
is offered and evaluated only by the AS.


2) Solve outside UMA; when the RS establishes the authorization data
(based on the provided RPT), it applies its application logic on making
interpretations on what the authorization data should mean in the request.


Your example is not the best, as you could have registered the actual
resource with its resource ID, and gathered a "delete" authorization for
the particular user (RPT<AAT), thereby ensuring that that particular
user has the appropriate rights for the operation. The user could have a
policy at the AS that immediately authorizes all authorization data
requests for resources owned by itself, or something to that effect. So
in this case, there is no need to do anything custom... ;)


Does this all make sense? :) I'm currently working on specifying the
same kind of problem, wrapping "Expiration" and "Purpose" in a request
for access to a resource, and this is what comes up in my mind.



Cheers!

Mark


> 
> thx,
> 
> Mike
> 
> 
> -------------------------------------
> Michael Schwartz
> Gluu
> Founder / CEO
> 
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma



More information about the WG-UMA mailing list