Ohh, not "Even". Sorry Eve ! ----- Original Message ----- From: "Pedro Igor Silva" <psilva@redhat.com> To: "Eve Maler" <eve@xmlgrrl.com> Cc: "Michael Schwartz" <mike@gluu.org>, "wg-uma@kantarainitiative.org UMA" <wg-uma@kantarainitiative.org> Sent: Thursday, December 17, 2015 4:50:53 AM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments Hi Even, Thanks for looking this and sorry for the late reply :). Answers inline. ----- Original Message -----
From: "Eve Maler" <eve@xmlgrrl.com> To: "Justin Richer" <jricher@mit.edu> Cc: "Michael Schwartz" <mike@gluu.org>, "wg-uma@kantarainitiative.org UMA" <wg-uma@kantarainitiative.org> Sent: Monday, December 14, 2015 4:04:13 PM Subject: Re: [WG-UMA] Two thoughts for UMA enhancments
Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows.
If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an API security use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.)
Ok, for now on I'll refer to these use cases as API security as well. And yes, I think Mike and I are trying to address similar problems.
API security is like traditional web services security use cases, and it's a situation where a security architect would often reach for vanilla OAuth.
Agree. But we need to also consider that what you did with UMA allow us to leverage OAuth2 authorization capabilities to a new level, being more suitable in cases where you want fine-grained authorization and give to ROs more control over their resources. It should be possible to use vanilla OAuth2 and still support fine-grained authz and a plenty of UMA-like features (like the permission ticket to handle Person-To-Person authz, obligations, claims gathering, etc), but you will end up reinventing the wheel and be stuck in a proprietary solution.
Questions for you guys: What's the "coupling quotient" of the real-life use cases being considered? How often are the AS and RS in the same security domain?
I would say that AS and RS in same security domain are pretty common. Specially if you consider some enterprise use cases where you have a single AS serving different applications, where each RS may also have its own and single client. For instance, a vanilla (HTML5 + AngularJS) + RESTFul design. Here we don't have third-party clients consuming RS's API. In these cases, the client does not need to know the scopes, but just the API. Is up to the RS to discover the scopes and enforce policies based on the relaying party or/and the client accessing the API. For instance: 1) Client (on behalf of an user) tries to access a resource 2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. 3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. 4) RS enforces the authorization decision from AS and gives back the RPT to the client. See, the client is pretty much dumb. It does not know about resource ids or scopes. Just like what the permission ticket does. We are just making client's more simple to implement and avoid additional requests (one to send the ticket to AS and another that sends the RPT back to the RS). It is worthy to mention that UMA already supports the flow above. I can just handle the permission ticket flow within the RS and return back the RPT to the client (or any other result from the AS). But, am I violating any rule by doing this ? The same thing applies if I want to obtain a RPT with everything an user/client is entitled to do (entitlements) once. I can just configure the RS to build a permission ticket asking for every single resource/scopes during a first interaction.
How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human?
Right now, I'm more focused with pre-provisioned clients. Although they can also register themselves using OpenID Connect Dynamic Client Registration. I'm also focused on clients operated by a human. Although I think we can handle autonomous clients using offline tokens to evaluate authorization policies on the AS and enforce them on the RS.
The API security use case overall would normally already be signed up to a smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a person-to-person delegation use case, Alice is likely to give Bob first-order consideration -- he'll get what scopes he'll get, and he'll like it! -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle).
So, based on this analysis, some thoughts and key questions.
Thoughts: As I had noted to Pedro in private email back in October, there is an “ extensibility profile ” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software.
+1. I just want to make sure I'm not violating the rules.
Key questions: What are the actual use cases on the ground so far? Are they such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a loosely coupled RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?
My use cases are all based on the currently native "client-to-RS-first". I think "client-to-AS-first" will kill the benefits brought by UMA, specially from a client perspective. Btw, I like the permission ticket (and the whole idea behind it) and, like I mentioned before, it has a lot of value. Specially for person-to-person delegation use cases. I think my question for all that should be: Am I violating UMA's rules if I change the flow under certain circumstances ? Or am I forced to always use a permission ticket as defined by the specs ? Thanks again for your time !
Eve
*UMA still allows for Alice's policy to constrain clients, of course (because policy doesn't appear on the wire in UMA), and any client involved in an Alice-to-Bob use case that can't handle scope x will never attempt an API call using scope x anyway...
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sat, Dec 12, 2015 at 5:45 PM, Justin Richer < jricher@mit.edu > wrote:
Yes, and the first point is touched on here:
https://github.com/KantaraInitiative/wg-uma/issues/165
— Justin
On Dec 12, 2015, at 8:35 PM, Debbie Bucci < debbucci@gmail.com > wrote:
Is the second issue Mike raises the one Justin said he filed an issue - https://github.com/KantaraInitiative/wg-uma/issues/154 ?
On Thu, Dec 10, 2015 at 10:41 AM, Adrian Gropper < agropper@healthurl.com > wrote:
UMA adds a lot of value over OAuth because it's easier to adopt to a very broad and deep ecosystem when the RS - RO interaction is separated in time from the RS - C interaction. In healthcare, this is called health information exchange and the separation allows for out-of-band RS - C discovery processes. In IoT this enables delegation where my RSs and Cs are layered like an onion around me (the layers in order: implants, wearables, mobile, router, family, cloud services). My AS is the only thing that ties these together and it needs to be as accepting of the different scopes as possible.
Adrian
On Thursday, December 10, 2015, Mike Schwartz < mike@gluu.org > wrote:
Mark,
I still think UMA adds a lot of value over OAuth2 alone! Also, my hope is that we can enable a migration plan to a better architecture.
- Mike
On 2015-12-10 06:57, 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 ?
_______________________________________________ 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