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

Da Cruz Pinto, Marcelo marcelo.da.cruz.pinto at intel.com
Tue Aug 26 12:06:48 CDT 2014

Couldn’t possibly agree more... having to deal with scope versioning is a nightmare even in plain OAuth. Actually, it’s even worse because in OAuth the developer needs to understand the internals of the scopes, etc. So, if you fall into the situation where you really need to change your scopes (because of poor initial design…speaking from experience here), then UMA will at least help you shield your developers from the complexity of the scopes behind a more chatty protocol.

From: wg-uma-bounces at kantarainitiative.org [mailto:wg-uma-bounces at kantarainitiative.org] On Behalf Of Maciej Machulak
Sent: Monday, August 25, 2014 11:04 AM
To: Eve Maler
Cc: Michael Schwartz; UMA WG WG
Subject: Re: [WG-UMA] Extend Register Permission to include requested URL and HTTP Method

Tiny comment below:

On 25 August 2014 18:38, Eve Maler <eve at xmlgrrl.com<mailto:eve at xmlgrrl.com>> wrote:
A couple of thoughts...


Chattiness could also come from the client coming back over and over to access slightly different scopes or resources within some larger desired set, and needing to return to the AS over and over to get the authorization data added. This is something the RS can mitigate itself, through careful resource set and scope design and also by initially registering a permission that is "wider" than the initial client request would suggest. For example, if the client tries to view tiny resource A, but it's known that typically what a client/user will want to do is view *and edit* resources A, B, and C in a big chunk, then the RS can design a resource set that encompasses all three, and register a permission that encompasses both viewing and editing of them all.

I think this chattiness here, however, is necessary. It clearly separates the roles allowing the client to have little knowledge about the internals of
the RS application. Therefore, the client is only concerned with referring to the AS once access at the RS cannot be granted immediately. And it's not only about a "tiny resource A" but any resource (as long as there is more than 1 resource on the server). The suggested solution mentioned above (i.e. careful design on the RS) seems like the best option.

Cheers, Maciej


*Hat tip to Allan Foster, who gave me this example when we were talking about ABAC writ large -- attribute-based access control isn't just about identity claims of the requesting party, but also about attributes coming from the rest of the environment too!

On 25 Aug 2014, at 9:30 AM, Michael Schwartz <mike at gluu.org<mailto:mike at gluu.org>> wrote:

> Mark,
> 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 level.
> thx,
> Mike
> 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
>>> _______________________________________________

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756<tel:%2B1%20425%20345%206756>                         http://www.twitter.com/xmlgrrl

WG-UMA mailing list
WG-UMA at kantarainitiative.org<mailto:WG-UMA at kantarainitiative.org>

Maciej Machulak
email: maciej.machulak at gmail.com<mailto:maciej.machulak at gmail.com>
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140826/a3e136b7/attachment.html>

More information about the WG-UMA mailing list