Thanks for the reply, Mike. Personally, I also like the design of the permission ticket. Like I mentioned, it has a lot of value in certain circumstances. I also liked your proposal, it already simplifies the flow in some situations. And agree about what you said about clients and "scopes creates a tight bundling with the security infrastructure". Just to clarify, my point is basically based on use cases where a distributed application provides both a client (eg.: HTML5 + AJAX) and a RESTFul API. Where each of them is a specific deployment. In this case, once the client is issued with a OAuth2 Access Token (probably with a uma_authorization scope) it can try to access a resource on the RS, which in turn will ask the AS for a RPT based on the resource and its scopes (or even a wider range of scopes and resources). Here the AS will just evaluate the policies associated with the resources and scopes being asked and return back a RPT representing the permissions. For last, the RS check the RPT for any permission granted to the original resource and return back the RPT to the client. The client doesn't know about scopes or resources ids and don't need to access any other endpoint to obtain a RPT (making it more simple). Another scenario that I'm evaluating is to let the client obtain a RPT with all the permissions for a given user (entitlements). Currently, I'm using a standard UMA-flow (using permission tickets) to obtain this RPT. So the client only needs to obtain the RPT once, during the first interaction of the user. This is useful for permissions based on policies that don't require obligations but just evaluation based on the identity of the user or even contextual information. Regards. Pedro Igor ----- Original Message ----- From: "Mike Schwartz" <mike@gluu.org> To: "Pedro Igor Silva" <psilva@redhat.com> Cc: wg-uma@kantarainitiative.org Sent: Thursday, December 10, 2015 12:23:49 AM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments Pedro, It doesn't make sense to me that the RS would obtain the RPT... Personally, I like the design of the permission ticket, because the UMA Client does not need to know the scopes. Forcing the UMA Client to know the scopes creates a tight bundling with the security infrastructure, and may expose too much information to the UMA Client. I equate this to hard coding LDAP schema in your application. It puts the infrastructure team in a bad situation if the schema changes, because you need to re-QA the app. However, some people think that just because Google does something, it must be right, or it must scale. So my interest in supporting this feature has more to do with aligning with an existing (bad) pattern. - Mike On 2015-12-09 19:37, Pedro Igor Silva wrote:
----- Original Message -----
From: "Mike Schwartz" <mike@gluu.org> To: wg-uma@kantarainitiative.org Sent: Wednesday, December 9, 2015 6:36:32 PM Subject: [WG-UMA] Two thoughts for UMA enhancments
UMA-tarians,
Can we discuss two ideas for enhancments:
1) UMA sans permission ticket
Let's say the UMA Client knows the scopes required to call a certain API. For example, Google documents this: http://gluu.co/google-scopes
In this case, perhaps the client can proactively request an RPT providing the scopes. And this RPT might be acceptable a certain RS for certain resource sets.
We might have already discussed this, but wouldn't this make UMA more compatable with existing API access management infrastructures?
2) UMA without the AAT
Inspired by Justin. I think the AAT adds value in many cases where the AS wants to make policies based on client claims (client id, domain specific catagory, etc). So I'm not saying eliminate the AAT. However, if the policy for access is based on network address only, or perhaps some other fraud detection technique that doesn't involve client identification, I could see a case where the AAT is not needed. So maybe the AAT could be optional?
- Mike
What about the case below ? I think it was lost because I was not able to send messages to this list ...
"I think that when you are in NPE scenario, the permission ticket does not make much sense. This is pretty much related with my second round of questions.
Please correct me if I'm wrong. It seems that the permission ticket is mostly intended to perform a transactional authorization flow, where a RqP will ask permissions to access some one resources and the RO will be able to receive some kind of notification and actually approve this permission any time in the future. Or even to support multiple ASs within the same RS, where the user can choose which AS should be used to obtain permissions for his resources. Here I can see a lot of value, like for cloud and IoT authz ...
However, considering NPE use cases, specially when the RO is the RS, a 1:1 relationship between RS and AS and there is no need for a transactional authorization flow given that RS is protecting its own resources, it might be unnecessary to use a permission ticket in this case. But just:
1) Client tries to access protected resource on behalf of an user (no RPT was sent) 2) RS obtain a RPT for the resource (or with additional resources and scopes) from AS 3) RS validates the response from AS, validates the RPT, enforce authorization and returns the RPT to the client (considering that RPT has the right permissions)"
Any thoughts ?
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org