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

Michael Schwartz mike at gluu.org
Mon Aug 25 11:30:32 CDT 2014


I see your point about not requiring an HTTPS connection to the AS for 
every request.

Of course, this fine grain authz decision is normally made in the 
application, and I'm just trying to figure out how to move it up a 



On 2014-08-25 07:46, Mark Dobrinic wrote:
> 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


Michael Schwartz
Founder / CEO
mike at gluu.org

More information about the WG-UMA mailing list