I agree with Justin. In a person-centered real world, like in IoT or healthcare, the UMA Client knows what it needs and what's available from the UMA RS based on out-of-band means OR standards. The person-centered AS, on the other hand may be generic and hardly care. Adrian On Thursday, December 10, 2015, Justin Richer <jricher@mit.edu> wrote:
I've actually filed an issue and am working on the ramifications of allowing the client to specify scopes in addition to the ticket. UMA paints a picture where the client doesn't know anything about the API that it's trying to access, but in the real world the client often has some idea through out of band discovery or configuration. If the client can tell the AS "these are the scopes I'm after" in addition to the ticket saying "these are the scopes recommended for that request" then the AS can make a more informed decision of which scopes to attach to the RPT.
-- Justin
On 12/10/2015 7:57 AM, Mark Dobrinic wrote:
Hi Mike,
Don't forget the as_uri that accompanies the ticket that the RS returns to the UMA Client, in the protocol-step that you're trying to optimize.
Maybe the better question is that if you assume you know which scopes to request, and the AS to make that request, why use UMA and not just plain OAuth?
Mark
On 10/12/15 03:23, Mike Schwartz wrote:
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
_______________________________________________
WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/