Thanks for the reply! No worries at all on timing, as everyone's a volunteer here (and it took me long enough to reply anyway). (And I get "Even" a lot. :-)

Below...

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Wed, Dec 16, 2015 at 10:50 PM, Pedro Igor Silva <psilva@redhat.com> wrote:

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.

In Thursday's call/notes, I tried some terminology to bifurcate two sub-use cases: plain "API security" where the AS and RS reside in the same domain, and "federated authorization" where it can be useful to decouple the AS and RS. I'm seeing the latter in a bunch of cases, e.g. when it comes to RS's that are partners (SaaS or otherwise) vs. internal -- analogously to "federated authentication".

>
> 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.

Yep. A person as unambiguous RO is a new step.

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.

Indeed, the UMA flows so far have a single (relatively simple) pattern with complex effect. This is where I was sort of going with the ideas that Alice has direct say over Bob's access, and that we have to satisfy a requirement for AS-RS loose coupling; these are the big reasons that the a permission ticket flow popped out of the design process. OAuth, having only one "user" and colocated AS and RS, didn't have (or even think of?) that.

>
> 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.

Meaning that RS=client (a la Google Apps, where the only app that operates on a GDoc file is the GDoc app)? I'm guessing not, if you'd prefer for the client to be as "dumb" as possible. (But note that there's an extensibility profile for RS = client too.)

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).

Right, this sounds like straight UMA, with a client that can remain dumb wrt scopes but of course needs to know the API. Of course, the RS has the capacity to own/invent/control the scopes, not "just" discover them, because the scopes are essentially a part of the API's design.

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 flow looks sort of similar to today's UMA, but it's not totally accurate for off-the-shelf UMA. If you're suggesting changes in order to remove the permission ticket, making the RS do all that work to get the RPT on behalf of the client (step 2), ending with it giving the resulting RPT to the client along with giving access (step 4), then I have some questions...

To be super-clear, here's an annotated version of your flow with the delta from UMA V1.0.1:

1) Client (on behalf of an user) tries to access a resource (that's the same as now -- Core Sec 3.1.1)

2) RS knows both ID and scope(s) related with the request and asks the AS for a RPT with the required permissions. (today, Core Sec 3.2, the RS would register a requested permission: a resource set by ID, with as many scopes as desired; we've also floated an extension spec that allows the RS to register multiple resource sets, each with as many scopes as desired)

3) AS evaluates the policies based on the authorization request from the RS and issues a RPT. (today that only happens after the RS gives the permission ticket to the client (Core Sec 3.3.1) and when the client -- not the RS -- shows up at the RPT endpoint with the permission ticket (Core Sec 3.5.1))

4) RS enforces the authorization decision from AS and gives back the RPT to the client. (today that only happens when the client retries access with the RPT -- Core Sec 3.1.2)

Why bother giving the RPT to the client if the RS could just give access directly? The whole thing would then look really close to an XACML flow, including the PEP/RS (vs. the client, what XACML would call the "application") making the request of the PDP/AS. Another similarity would be AS-RS tight coupling. In these circumstances, it also seems like scopes would be "internal" to the AS-RS, and you could move to getting a simple Permit/Deny answer from the AS instead of the permissions data structure, which could make the RS even simpler than it is now. If there's no RPT, though, then it wouldn't be around to collect/cache a bunch of decisions for later use by the client, but maybe that makes sense to me since the client would never go straight to the AS itself. However, then you could stop using UMA and start using XACML. :-)

In cases where the entities do need loose coupling or other UMA/OAuth benefits (scale, dynamic client registration, lighter weight, RESTful, RS wanting to use its right to perform extra authorization against the client and requesting party...), can we assume that this flow wouldn't apply?

Is the value of removing the ticket (and possibly change these other things for full optimization) for this glued-together API security flow valuable enough to pursue in UMA vs. sticking with the usual flow? How much optimization can really be achieved, vs. getting other marginal benefits out of using the flow that's already there (if you already are getting benefit out of "dumb" clients, scopes, etc.)?

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.

This is a relatively common thing to do in other use cases outside of API security as well.

> 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 for weighing in! I would love to get your thoughts on my questions above. To summarize my observations, your proposed flow would be more direct, but also doesn't "go all the way" in optimizing the direction you're heading. In your current thinking about your use case, is it more important to optimize fully (get more "XACML-ish"), or optimize a little (roughly your current midway point), or use UMA's other benefits fully (keep something like the current ticket flow)?