Comments inline...
On 6/29/16 10:03 AM, Justin Richer
wrote:
So, hang on a minute here.
If the IdP is the AS, that means that the IdP is
authenticating the RqP … to itself. That makes absolutely no
sense, as the RqP would have a “local” account at the IdP/AS
anyway and wouldn’t need or use OIDC to carry identity
information to itself. So that’s particularly pointless.
I don't think this is pointless. Let's say Bob is using a Photo Site
(photos.example.com) and the Photo Site uses an OpenID Connect
Provider as it's Idp (umaas.example.com). When Bob shows up at
photos.example.com and clicks the login button, photos.example.com
starts an OpenID Connect flow with umaas.example.com when Bob logs
in and at the completion of the flow, photos.example.com has an
id_token, access_token and possibly a refresh_token.
If then photos.example.com were to send the id_token as a bearer
token to printme.example.com and printme.example.com is using
umaas.example.com as it's UMA AS, then this would all work.
Hence my comment about this being a constrained environment. Or
maybe a "close eco-system" is a better term.
Now if you’re talking about the AS being an IdP to
the Client or the RS, that’s another story. However, those are
separate flows entirely. The data carried on each branch of that
network is quite different and it would be dangerous to conflate
them. You could definitely do the id-token-as-claims bit that
George mentions below in this use case, but this is NOT the same
as the RqP logging into the AS using OIDC. The client is passing
along an incidental artifact of authentication to prove that the
RqP was at one point present at the client.
Yes, I was not suggesting that the RqP was logging into the AS using
OIDC... sorry for that confusion.
And quite frankly if you’ve got the case where the
RqP has an account at the AS and you can go straight to the AS
to start the flow … you don’t need UMA. Seriously, take away the
claims system (because you don’t need it with a local account)
and the permission ticket (which you don’t need if you strip out
the AS discovery and claims systems), and you’re not doing UMA
anymore. At that point, you’re much better off doing vanilla
OAuth.
Not sure I've totally reached this conclusion, though I do agree
that it's a very special deployment case and there are probably lots
of optimizations that can be applied.
"But wait!”, you may say, “There’s still an RqP who
is different from the RO!” To which I say: “So what?”. In any
OAuth system, Alice could be given the capability to share her
resources with any other identified party. If that party has a
local account (is already known well by the AS) and the client
doesn’t need to look up the AS at runtime, then there’s nothing
that’s preventing you from building this out in a plain OAuth
server’s policy engine. OAuth never states or presumes a 1:1
mapping between RO and protected resource, so it’s perfectly
reasonable to use some kind of internal mechanism allowing Alice
to delegate access to Bob. Bob then become the RO in the OAuth
process, even if he’s been seconded the responsibility by Alice
he’s playing that role now because the AS knows who Bob is
already and knows Bob is allowed access. You don’t need an
interoperable protocol to do that, and as we’re seeing in this
conversation, the protocol is actually getting in the way.
While from the syntax perspective OAuth2 would work fine, I do think
there is a semantic difference. Most OAuth2 Authorization Service
don't allow the RO to add policy around access. Not impossible and
not out of scope of OAuth2, just not something I've seen often.
The part of UMA that makes sense in this use case is the policy
engine that allows Alice to say if a token shows up trying to access
my resource and that token happens to be Bob, then it's ok.
So I think James’s use case definitely has a point,
but it’s already been specified in RFC6749.
— Justin
There are lots of interesting ways
to consider passing claims to the AS about the user. One
we've talked about in the past is if the client
authenticated the RqP with via an OpenID Connect flow,
could it pass the id_token it received from the IdP to
the UMA AS as a claim. The issue with this is that if we
are being strict about audience checking the UMA AS has
to reject the passed in id_token. What needs to happen
is that the client needs to request from the IdP a token
(id_token or otherwise) that is audience restricted to
the UMA AS. This is viable from a flow and tech
perspective, but if we want this token to be another
form of "RPT" then it seems like it should have it's own
token profile written to cover the use case.
Now in Jame's case, the OpenID Connect
provider for the client that authenticates the RqP is
the UMA AS. This is a very constrained use case though
perfectly viable and maybe commonly deployed. I still
think this kind of a flow should have it's own token
profile as the token to the RS does not carry the same
semantics as the current RPT. The current RPT binds
the client, the RS and the AS together and sometimes
the RqP as well. If all that's being presented is
effectively an id_token, then the semantic of that
token is just the RqP.
Thanks,
George
There could be a reason for an
id_token to be passed back around to the same
AS/IdP: There are "stateful" models for deriving
identity information about the user in front of you,
and alternatively "stateless" models where the
information shows up with the user. There are pros
and cons to each method.
--
Distinguished Engineer
Identity Services Engineering Work: george.fletcher@teamaol.com
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography