[WG-UMA] New issue? Requester vs. client credentials flow
Eve Maler
One consequence: If R1 goes to H1 to access PR1 protected by AM1, that's token T1. But if the same R1 goes to H1 to access PR2 protected by AM2, it has to get a different token T2. (This is actually the explanatory example currently provided in the spec.)
Another consequence: If R1 goes to H2 to access PR3 protected by AM1, R1 has to get a token that's unique across this tuple, T3.
How is a requester with a singular set of client credentials at any AM supposed to get different tokens with it that are all meant to be "live" at the same time across multiple hosts (and multiple users)? I suspect this is why Jacek was looking for clarity around what a host gets back when it asks for token status, since he was assuming the requester's access token would potentially be associated with interactions at multiple hosts.
Is the client credentials flow just the wrong choice for this purpose, or do we have to profile (or extend?) it to add something like a "token index" (sort of like a SAML session index), or...?
Eve
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
Thomas Hardjono
I think what's missing in your scenario is the user U.
> -----Original Message-----
> From: wg-uma-...@kantarainitiative.org [mailto:wg-uma-
> bou...@kantarainitiative.org] On Behalf Of Eve Maler
> Sent: Wednesday, February 08, 2012 10:37 AM
> To: WG UMA
> Subject: [WG-UMA] New issue? Requester vs. client credentials flow
>
> I had a d'oh moment re-reading the spec yesterday. We say a
requester
> access token has to be unique per requester, authorizing user, host,
> and AM.
>
> One consequence: If R1 goes to H1 to access PR1 protected by AM1,
> that's token T1. But if the same R1 goes to H1 to access PR2
protected
> by AM2, it has to get a different token T2. (This is actually the
> explanatory example currently provided in the spec.)
Well yes, this will be the case if PR1 is owned by User U7 (with
policy set at AM1), while PR2 is owned by User U8 (with policy set at
AM2). It just happens that Users U7 and U8 are hosting their resources
at H1. Or did I misunderstand your scenario?
> Another consequence: If R1 goes to H2 to access PR3 protected by
AM1,
> R1 has to get a token that's unique across this tuple, T3.
Unique across (R, H, PR, AM, U) combination. Unless of course the two
AMs have been introduced by the user and both AMs accept the same
token wielded by R.
>
> How is a requester with a singular set of client credentials at any
AM
> supposed to get different tokens with it that are all meant to be
> "live" at the same time across multiple hosts (and multiple users)?
I
> suspect this is why Jacek was looking for clarity around what a host
> gets back when it asks for token status, since he was assuming the
> requester's access token would potentially be associated with
> interactions at multiple hosts.
>
> Is the client credentials flow just the wrong choice for this
purpose,
> or do we have to profile (or extend?) it to add something like a
"token
> index" (sort of like a SAML session index), or...?
I think we also need to expand further on our notion of User policy
(configured by the User at the AM) over a protected-resource-set PRS
where the PRS contains resources spread over multiple Hosts. So when
initially the requester R gets a reject (due to lack of permission in
his/her token), the AM needs to contact multiple Hosts and issue
several permission tickets to get these Hosts ready for when the
requester R finally comes along with the correct token(s).
/thomas/
Eve Maler
Eve
_______________________________________________
George Fletcher
On 2/8/12 10:37 AM, Eve Maler wrote:
I had a d'oh moment re-reading the spec yesterday. We say a requester access token has to be unique per requester, authorizing user, host, and AM. One consequence: If R1 goes to H1 to access PR1 protected by AM1, that's token T1. But if the same R1 goes to H1 to access PR2 protected by AM2, it has to get a different token T2. (This is actually the explanatory example currently provided in the spec.) Another consequence: If R1 goes to H2 to access PR3 protected by AM1, R1 has to get a token that's unique across this tuple, T3.
How is a requester with a singular set of client credentials at any AM supposed to get different tokens with it that are all meant to be "live" at the same time across multiple hosts (and multiple users)? I suspect this is why Jacek was looking for clarity around what a host gets back when it asks for token status, since he was assuming the requester's access token would potentially be associated with interactions at multiple hosts. Is the client credentials flow just the wrong choice for this purpose, or do we have to profile (or extend?) it to add something like a "token index" (sort of like a SAML session index), or...?
One problem I see with the client credential flow, is that there is no guarantee that the Authorization Server will not just hand back the previous access_token (at least until it expires) which means I'm not sure how the R will get a unique access_token per User at the requestor (RU).
Eve Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl _______________________________________________ WG-UMA mailing list WG-...@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Chief Architect AIM: gffletch Identity Services Engineering Work: george....@teamaol.com AOL Inc. Home: gffl...@aol.com Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch
George Fletcher
At a minimum, the Requester (R) needs to store a unique access_token for the Requesting User (RU) and Authorization Manager (AM) pair. Whether it needs to be unique on a per Host (H) basis we can discuss as it's possible for the AM to manage a single access_token being used at multiple hosts.
This means that the Requester must be able to get unique access_tokens (and probably refresh_tokens) from the AM based on who the Requesting User is. Right now the client_credentials flow does not allow for the passing of any parameters other than the client_credentials. Ideally, the R need to pass it's client_credentials as well as a "user identifier" so that the AM can generate a unique access_token for that user.
But... see below... (Paul this might be what you had originally envisioned)
In digging through the spec a little more... we might have a better option... that is to leverage step 3.5 (Requester-AM: Request Authorization to Add Permission). If step 3.5 always returns a unique/updated token and this is the token used to present to the host... then it is not required for the Requester to have unique access_tokens with the AM. Instead it can have one access token that represents the R<->AM relationship (this is probably why we chose the client_credentials flow).
Then when the AM provides a token to the R, it has to store locally that token against the RU:AM:H set of data. We might need step 3.5 to return a refresh_token as well.
This can work, because the R doesn't really need to propagate to the AM any concept of the user of R (RU). However R does need to manage the tokens correctly. So if R manages the tokens returned in step 3.5 by storing them uniquely against the set of RU:AM:H, on a second access of R by RU, R can find the correct access_token based on the H it is accessing.
Hopefully that makes sense:)
Thanks,
George
Nat Sakimura
comments inline:
(2012/02/09 0:37), Eve Maler wrote:
> I had a d'oh moment re-reading the spec yesterday. We say a requester access token has to be unique per requester, authorizing user, host, and AM.
>
> One consequence: If R1 goes to H1 to access PR1 protected by AM1, that's token T1. But if the same R1 goes to H1 to access PR2 protected by AM2, it has to get a different token T2. (This is actually the explanatory example currently provided in the spec.)
>
> Another consequence: If R1 goes to H2 to access PR3 protected by AM1, R1 has to get a token that's unique across this tuple, T3.
>
> How is a requester with a singular set of client credentials at any AM supposed to get different tokens with it that are all meant to be "live" at the same time across multiple hosts (and multiple users)? I suspect this is why Jacek was looking for clarity around what a host gets back when it asks for token status, since he was assuming the requester's access token would potentially be associated with interactions at multiple hosts.
One way the OpenID Connect deals with it is that the request present the
access_token it got from the initial authorization to the UserInfo
endpoint. UserInfo endpoint actually translates it to multiple
{endpoint, token} pairs for distributed claims.
See the last example in the Section 2.5.2 of the Messages spec of the
Connect:
http://openid.bitbucket.org/openid-connect-messages-1_0.html#anchor18
>
> Is the client credentials flow just the wrong choice for this purpose, or do we have to profile (or extend?) it to add something like a "token index" (sort of like a SAML session index), or...?
>
> Eve
>
> Eve Maler http://www.xmlgrrl.com/blog
> +1 425 345 6756 http://www.twitter.com/xmlgrrl
>
> _______________________________________________
> WG-UMA mailing list
> WG-...@kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
--
Nat Sakimura (n-sak...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
Eve Maler
The trick, in UMA's case, is that the requester has to be present and alive at request-time, but the authorizing user does not! So there isn't an "initial authorization" that's visible to the UMA protocol other than the addition of the relevant permission. So should we be turning the permission-request flow into an explicit "bursting" of an initial token into multiple ones, a la OpenID Connect (but not exactly like it)?...
Eve
Thomas Hardjono
I think UMA already has this notion (at least implicitly) of the AM creating several tokens except that we do not call it tokens (we call it permission-tickets).
If a Requester R asks the AM for an access-token to access a resource-set consisting of resources (eg. files) spread across hosts H1, H2, and H3, the AM could anticipate next move (by R) by (a) creating 3 permission-tickets for H1, H2 & H3, and (b) pushing these 3 permission-tickets to H1, H2 and H3. In other words, the AM is skipping Section 3.4 and creating the tickets before the Hosts asks for them.
Just a thought.
/thomas/
-----------------------------
> -----Original Message-----
> From: wg-uma-...@kantarainitiative.org [mailto:wg-uma-
> bou...@kantarainitiative.org] On Behalf Of Eve Maler