Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the AAT unnecessary? #154

Closed
jricher opened this issue Jul 15, 2015 · 33 comments

Comments

Projects
None yet
7 participants
@jricher
Copy link

commented Jul 15, 2015

The Authorization API Access Token serves only to connect the requesting client to the authorization server over the specialty RPT endpoint (see #153). Why can't client credentials be used here instead, like at a normal token endpoint transaction?

Ostensibly, the authorization server could use the requesting party bound to the AAT to make its token issuance decision -- however, all guidance in the spec indicates that the decisions should be made on the basis of supplied claims which the requesting client has to either gather out of band or provide directly. As such, the AAT doesn't provide any additional value.

Furthermore, issuance of the AAT over a normal OAuth transaction is problematic as the requesting party, Bob, likely doesn't have an account on the authorization server. Supporting this would require the authorization server to either allow all external users to engage in OAuth transactions (unlikely) or to have a special-cased codepath for just the uma_authorization scope. (See mitreid-connect/OpenID-Connect-Java-Spring-Server#852 for an implementation-specific take.)

Suggested fix: remove the AAT alltogether and rely on client credentials and claims for issuing the RPT (as in #153), otherwise be very clearly explicit in the spec about the requirement the requesting party to be able to authorize tokens at the AS, which would likely limit UMA's usefulness to single security domains.

@gffletch

This comment has been minimized.

Copy link

commented Jul 16, 2015

The AAT isn't just about client credentials but also includes the requesting party (i.e. user). In some cases it might be only the client, but in many of the user-to-user sharing cases it requires the RqP. I suppose it might be possible to do this back-channel with client-credentials and an id_token the Client received when the user logged into the Client, but that is an optimization path that has yet to be explored.

@jricher

This comment has been minimized.

Copy link
Author

commented Jul 16, 2015

That's my point though -- the claims required to be presented by the client already cover the RqP, so I'm not seeing that the AAT actually adds anything to the transaction in that case. You don't know that the RqP is present on the connection even if the AAT is valid, you just know that they did the introduction. But why limit client introduction if you're allowing dyanmic registration?

@gffletch

This comment has been minimized.

Copy link

commented Jul 16, 2015

But it isn't required that the claims required to be presented by the client include the RqP, so in that context the RqP in the AAT would be useful.

@jricher

This comment has been minimized.

Copy link
Author

commented Jul 16, 2015

Perhaps, but to me that sounds like an optimization for a specific use case at the cost of the general mechanism.

@gffletch

This comment has been minimized.

Copy link

commented Jul 16, 2015

I believe the thinking was more the along the reverse position... since the RqP will likely be needed in most RPT requests, and the RqP is already part of the AAT, then why not just get the value from there rather than requiring it to be presented again in the "claims negotiation" phase. The case where the RqP is NOT required is the less likely case and that could be defined a slightly different flow.

@jricher

This comment has been minimized.

Copy link
Author

commented Jul 16, 2015

But that case still requires that the RqP be able to mint tokens at the AS. This functionality is currently impossible in our own server unless everyone's in the same domain (ie: everyone has an account at the AS).

@gffletch

This comment has been minimized.

Copy link

commented Jul 16, 2015

Ahh... my expectation here is that an AS could allow a user to create an AAT without establishing an AS "account" by leveraging a external IdP the AS trusts to establish the RqP identity. This may be the important part of this thread.

How does an AS create an AAT with an RqP without requiring the RqP to create an AS "account/identity"?

@jricher

This comment has been minimized.

Copy link
Author

commented Jul 16, 2015

You would need to enable an external identity like you said, but since our AS is also a general-purpose OAuth server, we don't want to allow all external users to mint all tokens. See mitreid-connect/OpenID-Connect-Java-Spring-Server#852 for details of where we're tracking it in our own project.

@xmlgrrl

This comment has been minimized.

Copy link

commented Jul 20, 2015

For reference: In Core Sec 1.3.2 (https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.1.3.2), the AAT represents the tuple AS-client-RqP. Specifically: "An AAT binds a requesting party, a client being used by that party, and an authorization server that protects resources this client is seeking access to on this requesting party's behalf. It is not specific to any resource server or resource owner. The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims, ask for authorization, and perform any other tasks needed for obtaining authorization for access to resources at all resource servers that use this authorization server. The authorization server is able to manage future processes of authorization and claims-caching efficiently for this client/requesting party pair across all resource servers they try to access; however, these management processes are outside the scope of this specification."

@xmlgrrl

This comment has been minimized.

Copy link

commented Jul 20, 2015

Regarding George's question, “How does an AS create an AAT with an RqP without requiring the RqP to create an AS "account/identity”?”:

An AAT is an OAuth token with a scope of uma_authorization, plain and simple, so if it’s “three-legged”, it reflects an authorization relationship that you pretty much assume is based on a user’s account/identity. For different deployment ecosystems, the source could differ. E.g., where RqPs are professionals (health trust frameworks?), maybe it’s from SAML-to-OAuth SSO bridges. The AS need not strictly do its own authentication.

I could imagine that a “dumb client” that is only ever capable of redirecting the RqP (rather than a "smart client" that can push claims), interacting with a type of AS that never caches claims (which means that RqP must be redirected afresh to supply them every time), could build a "two-legged" relationship (based on client credentials alone) and not require the RqP to consent to anything at all. We do already have the concept of an RqP-as-organization that uses a client credentials flow, though I believe this would be a novel application of the flow to the semantic. Not sure of all the implications (in terms of protecting the interests of the RqP or anything else).

@jricher

This comment has been minimized.

Copy link
Author

commented Jul 20, 2015

I understand the intent, but having implemented this myself it's a very real problem. With the claims-based system, I don't think it's even necessary. A "dumb client" could easily present organization-based claims, which is an argument that I've heard for keeping the direct claims presentation system. It's only ever used for this one transaction, and I think that it can be removed without harm to the rest of the protocol.

@xmlgrrl xmlgrrl added the core label Jul 22, 2015

@xmlgrrl xmlgrrl added the critical label Jul 30, 2015

@xmlgrrl xmlgrrl added this to the V1.0.1 milestone Jul 31, 2015

@xmlgrrl

This comment has been minimized.

Copy link

commented Aug 5, 2015

After further research "back at the ranch" (customer use cases and dev team), here is further input from ForgeRock, offered with my participant hat on. Sorry for being prolix here -- just trying to run through the logic carefully.

Just as there is a variety of identity federation topologies possible, there is similarly a variety of access federation topologies possible, on a continuum. At one end ("widest ecosystem"), there are many entities of every type and services run in many domains; resource owners have full choice of which entities they use; and all relationships must be forged dynamically and in a user-directed fashion. At the other end ("narrowest ecosystem"), a single authorization server figures prominently as a trust anchor; relationships radiate from it; and relationships don't extend as far out into the world.

We are currently gaining experience with many use cases in the narrower-ecosystem range. This is not to deny the importance of the wider-ecosystem cases, it's just to establish the requirement. In these narrower cases, there is no question whether requesting parties have have a relationship with the authorization server: they do. The (three-legged) AAT does exactly what it was designed to do in this case: let the requesting party grant authorization for the client and authorization server to engage in using the authorization API. It can be silently granted where (as noted earlier in this thread) an employment relationship, or similar, carries their agreement ahead of them.

As noted in the initial issue report, there are costs in wider-ecosystem use cases to requiring requesting parties to have to authorize tokens at the AS. Effectively, a lot of RqPs will end up having to create some kind of local or federated (say, social) account at the resource owner's authorization server. RqPs could hate the proposition, the UX for them could be ugly, the scale implications could be ugly for the RO's AS, etc.

We agree it's important to offer an alternate option in the spec. The client credentials grant looks like a good possibility (and we note that it's already strictly allowed by the current spec, so it's not technically a breaking change to call this out). We would contribute the following discussion points:

  • Is the client credentials grant typically used for clients that are operated by humans? Is this an acceptable use of this grant flow? http://tools.ietf.org/html/rfc6749#section-4.4 If for some reason it's not, what would an alternative be?
  • In the case of no persistent RqP identity at the RO's AS, we'd expect the client to have to push all the information needed every time (or redirect the RqP), with no AS caching of anything interesting. We're okay with that.
  • In the case of no AAT, there would be nothing on record anywhere of the RqP's consent or authorization to have any claims silently pushed about them. The closest analogue would probably be the client's unilateral (wrt the RqP) promises about its behavior by virtue of an agreement with the AS or membership in an access federation trust framework, probably as captured in issuance and use of client credentials. We would probably need to address this point somehow in the privacy considerations section.
@jricher

This comment has been minimized.

Copy link
Author

commented Aug 5, 2015

In the narrow ecosystem use case, the claims could still easily be gathered interactively by having the RqP log in with their local account at the claims gathering page. The AAT doesn't add anything here, just provides a different mechanism for doing that, but one that is only applicable in certain setups.

The "authorization API" is mis-labeled, since it's just a token gathering flow.

The client credentials grant is meant for clients that are acting on their own behalf. In this case, since all they're accessing is the specialized token endpoint (or the not-so-specialized token endpoint if #153 is resolved in that direction), the extra token roundtrip doesn't buy anything.

The client can't reliably push information that the AS can verify in any case that I've seen demonstrated, see #160 for details, so I consider that a non-starter.

The RqP's consent could be captured during an interactive authorization step. If it's not interactive with the RqP, there's no reliable consent mechanism anyway.

@mrpotes

This comment has been minimized.

Copy link

commented Aug 5, 2015

This is definitely an interesting discussion - actually the AAT just becomes the RPT if we conclude in #153 that the RPT isn't required after all? I think to some degree the discussion here is difficult to continue until the resolution for #153 is known.

@jricher

This comment has been minimized.

Copy link
Author

commented Aug 5, 2015

The RPT is still required -- it's the resulting token from the whole process. It's the RPT endpoint that's not required as per #153.

@xmlgrrl

This comment has been minimized.

Copy link

commented Aug 5, 2015

James and I discussed this offline, and we do definitely find it architecturally attractive -- basically a "two-token" model. In fact, it was looking very familiar to me, and I found it in UMA Core rev 05: https://tools.ietf.org/html/draft-hardjono-oauth-umacore-05#section-3 :-) (The terminology was different then: AM=authorization manager for AS, H=host for RS, R=requester for client, HAT=host access token for PAT, RAT=requester access token for AAT, RPT=requester permission token for the current RPT.)

You can find a concise description of the discussion we had at the time about going from a two-token model to a three-token model: https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/notes$20from$20uma$20ad$20hoc$20meeting$202012$2003$2007/kantara-initiative-uma-wg/LbBesPGRdmc/L2I7C6pn91UJ In a quick search, I couldn't find our discussion of the rationale, but I recall it had to do with a privacy concern about the RPT containing permissions that span the RO's various RS's.

I'm not actually sure that this is a concern, and we probably have a much better perspective on such matters three years later, but if we remove AATs in favor of only RPTs (I don't think we can discuss this issue to the exclusion of #153 any longer, given the additional commentary just above), we have to examine this carefully because we will have changed the "scope" (sorry) of the token that remains quite a bit.

@mmachulak

This comment has been minimized.

Copy link

commented Aug 5, 2015

Hello Eve,

Could you please clarify - "basically a "two-token" model" - AAT+RPT? Or
you mean just PAT + RPT/AAT?

Thanks,
Maciek

On 5 August 2015 at 21:07, Eve Maler notifications@github.com wrote:

James and I discussed this offline, and we do definitely find it
architecturally attractive -- basically a "two-token" model. In fact, it
was looking very familiar to me, and I found it in UMA Core rev 05:
https://tools.ietf.org/html/draft-hardjono-oauth-umacore-05#section-3 :-)
(The terminology was different then: AM=authorization manager for AS,
H=host for RS, R=requester for client, HAT=host access token for PAT,
RAT=requester access token for AAT, RPT=requester permission token for the
current RPT.)

You can concise description of the discussion we had at the time about
going from a two-token model to a three-token model:
https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/notes$20from$20uma$20ad$20hoc$20meeting$202012$2003$2007/kantara-initiative-uma-wg/LbBesPGRdmc/L2I7C6pn91UJ
In a quick search, I couldn't find our discussion of the rationale, but I
recall it had to do with a privacy concern about the RPT containing
permissions that span the RO's various RS's.

I'm not actually sure that this is a concern, and we probably have a much
better perspective on such matters three years later, but if we remove AATs
in favor of only RPTs (I don't think we can discuss this issue to the
exclusion of #153
#153 any longer,
given the additional commentary just above), we have to examine this
carefully because we will have changed the "scope" (sorry) of the token
that remains quite a bit.


Reply to this email directly or view it on GitHub
#154 (comment)
.

Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)

@xmlgrrl

This comment has been minimized.

Copy link

commented Aug 5, 2015

What I think Justin is suggesting is (keep the PAT to protect the AS's protection API) and have a new "UMA-flavored" OAuth grant -- let's call it the "asynchronous grant" like we already sort of do in the spec :-) -- that the AS supports at its plain old OAuth token endpoint (no more special UMA RPT endpoint) at which it issues real OAuth access tokens that are our current RPTs in purpose. (I assume they would still use some species of our already-defined token profile, perhaps not called "bearer" anymore?)

There would no longer be reciprocal PAT and AAT token relationships, just an embedded OAuth flow for the PAT and a "real" OAuth flow of the UMA-flavored grant type.

This is just about identical to what we used to call the HAT (host access token) and RAT (requester access token in rev 05 and previous. If you see my second link above, it was actually Lukasz who proposed the AAT/RPT split...

@mmachulak

This comment has been minimized.

Copy link

commented Aug 5, 2015

Eve, OK thanks for clarifying. Long story short - only PAT + TOKEN for
clients.

On 5 August 2015 at 21:36, Eve Maler notifications@github.com wrote:

What I think Justin is suggesting is (keep the PAT to protect the AS's
protection API) and have a new "UMA-flavored" OAuth grant -- let's call it
the "asynchronous grant" like we already sort of do in the spec :-) -- that
the AS supports at its plain old OAuth token endpoint (no more special UMA
RPT endpoint) at which it issues real OAuth access tokens that are our
current RPTs in purpose. (I assume they would still use some species of our
already-defined token profile, perhaps not called "bearer" anymore?)

There would no longer be reciprocal PAT and AAT token relationships, just
an embedded OAuth flow for the PAT and a "real" OAuth flow of the
UMA-flavored grant type.

This is just about identical to what we used to call the HAT (host access
token) and RAT (requester access token in rev 05 and previous. If you see
my second link above, it was actually Lukasz who proposed the AAT/RPT
split...


Reply to this email directly or view it on GitHub
#154 (comment)
.

Maciej Machulak
email: maciej.machulak@gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)

@jricher

This comment has been minimized.

Copy link
Author

commented Aug 5, 2015

Right, the RS gets a PAT, the Client gets a Token.

@xmlgrrl

This comment has been minimized.

Copy link

commented Aug 5, 2015

@andihindle

This comment has been minimized.

Copy link

commented Aug 6, 2015

As I read the current spec, the purpose of the AAT is to confirm to the AS that it may return claims about the Requesting Party (specifically, whether the RqP has the right to access a particular resource); and - by extension - that it may take whatever action is necessary in order for it to be able to do so.

The spec does not prescribe (or proscribe) what action that might be, although it does call out specifically the potential need to authenticate the RqP

In order to reasonably do any of this, the AS must be reassured that (a) it has permission to act on behalf of the RqP and (b) that the client in question also has permission to act on behalf of the RqP. Hence the AAT.

I suggest that these permissions are required in both the narrow and wide use-cases that @xmlgrrl describes. Irrespective of any relationship the RqP might or might not have with the AS, the AS still needs to be assured that the client is validly making a request; and that it has permission to take the action it needs to take (which, even in the narrow use-case, might require the AS to go and carry out some other authorization, authentication, or claims-gathering flow, involving information about the RqP and/or Client).

I think it's important to note that nothing in the spec says that the AS has to create any kind of account in order to process a permission - even if the RqP is (initially) unknown to it. This is, I think, an implementation decision. And it seems to me a valid (maybe even preferable, for the very wide use-case?) implementation choice to say that the AS can create permissions (hence tokens) for any RqP (and Client) assuming that it is satisfied that that the relevant conditions for doing so are met.

It isn't clear to me how, in a 2-token model, the necessary assurances are being provided.... So what am I missing?

@jricher

This comment has been minimized.

Copy link
Author

commented Aug 6, 2015

In the two token model, the client is identified through its authentication to the token endpoint, just like a standard OAuth token flow. The RqP is identified through the claims, either those that are gathered or those that are presented directly by the client.

Note that the client can easily present the equivalent of the AAT as the "pushed claims" to identify the RqP, if it's able to do that (ie the narrow system usecase: the RqP has an account of some kind at the AS, can get an OAuth token to the client, etc.). This can fairly neatly collapse all of these use cases into a single mechanism.

@andihindle

This comment has been minimized.

Copy link

commented Aug 6, 2015

I may be misunderstanding what you mean by 'standard OAuth token flow'.

It sounds like you're suggesting that (per RFC6749 sec 1.2 & 1.3) the client's request for the authorisation grant request to the UMA AS is used as the mechanism to establish the permissions I described earlier.

But per 1.3:

An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types -- authorization code, implicit, resource owner password credentials, and client credentials -- as well as an extensibility mechanism for defining additional types

I'm not sure how you would represent the permissions required (which I think we agree on?), without some extensibility mechanism, in which case I think we're back to the AAT?

I'm all for simplification of the protocol, BTW - but I do want to make sure we're not missing something critical if we do it. And I also want to be sure we're not adjusting protocol to suit a given implementation decision about account creation requirements.

@jricher

This comment has been minimized.

Copy link
Author

commented Aug 10, 2015

I'm talking about extending it precisely as specified in RFC6749. The client presents two pieces of information in the request:

  • the permissions ticket
  • the client's id/credentials

Optionally, it can send in scope requests and other stuff, but those are sufficient to get things going. If the ticket has had enough of the right claims bound to it (including claims about the RqP), then we're good. If it doesn't, then we say "nope" and the client has to go beef up the ticket and try again. This is all very much in line with both the spirit and technical functionality of the OAuth grant type extension mechanism.

@xmlgrrl xmlgrrl added the V2.0 label Aug 15, 2015

@xmlgrrl

This comment has been minimized.

Copy link

commented Aug 15, 2015

Discussion on 2015-08-13: Since it requires major breaking changes and further extensive discussion, this belongs in a V2.0 release.

@jmandel

This comment has been minimized.

Copy link

commented Aug 20, 2015

@jricher when you say

I'm talking about extending it precisely as specified in RFC6749.

Could you clarify which OAuth2 flow(s) you have in mind, and how the proposed parameters (including permission ticket) would be passed along? Or is the thought that we would define a new flow that the /token endpoint would expose?

@jricher

This comment has been minimized.

Copy link
Author

commented Aug 20, 2015

This is a new flow that the token endpoint would expose. It's roughly analogous to things like the assertions flows, client credentials flow, and refresh token flow; but with the ticket and claims mechanisms. These would all be defined as extensions to either the input parameters (form encoded strings, reasonable for the inputs required) or output format (a JSON object already) with token data. The important part is that would encourage a large amount of code re-use between "implementing UMA" and "implementing OAuth" on the AS and the client.

@jmandel

This comment has been minimized.

Copy link

commented Aug 20, 2015

Gotcha. I suppose it would have to be a two-step flow (similar to the authorization grant flow) to allow for an in-browser, AS-initiated claims gathering step as well as client authentication.

@jricher

This comment has been minimized.

Copy link
Author

commented Aug 20, 2015

It's always a two-step flow regardless of the type of client: go to the RS first to get a ticket, then come back to the AS and trade that for a token. If you can also put in the right set of claims in your request the first time, then that's the last step and you get a token. If you don't, there's another step where you need to either get the claims and send them yourself in another request to the token endpoint, or send the RqP off to the claims gathering endpoint to do something, then come back to the token endpoint and try your ticket again.

Effectively, the gist of #153 is "the RPT Endpoint defines a way for a client to send things to the authorization server in order to get an access token, but OAuth already has that and it's called the Token Endpoint". The gist of this issue (#154) is that the claims mechanism subsumes everything that the AAT originally represented. The two are technically separable (you could drop AAT from the existing endpoint and still have things work just fine) but they make the most sense together because you can then get client authentication and a few other things "for free" at the token endpoint.

@jmandel

This comment has been minimized.

Copy link

commented Aug 20, 2015

Understood -- thanks again for the clear explanation and summary. (I had forgotten that UMA has the client request authz details via backend POST instead of in-browser redirect. The protocol I made up in my head worked differently :-P)

@xmlgrrl

This comment has been minimized.

Copy link

commented Aug 20, 2015

Thanks for waking up this thread, guys, because it reminded me to note here that the WG has taken the discussion forward a bit (on what we're now considering a joint #153/#154 issue). It's tabled for the moment, but there are some artifacts at the following links. Anyone who comes across this and is interested to follow up is encouraged to join us for further discussion there.

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-06
https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/swimlane/kantara-initiative-uma-wg/dHXoif61EUk/x1rEq7zfFQAJ

@xmlgrrl xmlgrrl added the wideeco label Jan 27, 2016

@xmlgrrl xmlgrrl added the simplify label Feb 4, 2016

xmlgrrl added a commit that referenced this issue Aug 15, 2016

Majority of structural and editing work for #153 and #154
Still some discussions to have, and still some editing to do. (And MPD
work not entirely done!) But this edit essentially excises the AAT and
the RPT endpoint, adds a “saved consent token” design as an optional
substitute for gathering RqP consent in-band, and aligns the relevant
other artifacts as necessary.

xmlgrrl added a commit that referenced this issue Aug 18, 2016

Added #153 and #154 queries for WG to consider
Added an incomplete set of queries related to #153 and #154 for the WG
to consider in tomorrow’s call. Also fixed one typo and put in one
reminder to change a client request message from JSON to form-encoded.
@xmlgrrl

This comment has been minimized.

Copy link

commented Jan 4, 2017

The AAT was initially removed in UMA 2.0 Core rev 02, with additional alignment edits made in subsequent revisions, and a related token -- the saved consent token (SCT), later renamed the persisted claims token (PCT) -- was initially added in rev 03:

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-02.html
https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-03.html

@xmlgrrl xmlgrrl closed this Jan 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.