Todd - doesnt the AS have adequate "scope" information to guess which
resource server the token might get delivered to? I am afraid thats
about as far as the OAuth flows go in capturing the "target" of the
final request.
Couldn't the "scope" information be used by the AS to decide between
including "jdoe" or "[email protected]" in
the access token? It seems to me that all of the required mapping could
be completed by the AS.
- prateek
This is not specifically an OAuth question per se, but there's enough
experience here from multiple domains (e.g. OIDC, UMA, SCIM) that
someone might be able to give me a pointer.
I'm considering the case where an authorization server is associated
to multiple IdPs, such that identity could come from LDAP or (say)
Google. In such a set-up, the identity that the AS associates to a
bearer token might be "jdoe" (LDAP) or "[email protected]" (Google).
When a resource server performs an introspection on such a token,
they're either returned "jdoe" or "[email protected]", depending upon
what IdP the resource owner chose to authenticate to. A couple of
questions re this setup:
1) First, is the cardinality between AS and IdP reasonable (AS(*) <==>
IdP(1-n)), and if so, is there precedent and best practice that I can
study?
2) Assuming "true" for "1" above...
In the case where the AS is performing the role of SSO provider to
multiple resource servers, I'm imagining a setup where it is
desireable that all resource servers associated to that AS see the
user principal identifier that makes sense to them. E.G. Resource
Server "A" prefers the "jdoe" identity; Resource Server "B" prefers
the "[email protected]" identity. When "A" or "B" receives a bearer
token via back channels, provisioned by the AS to "John Doe",
introspection reveals, directly or indirectly, the identity "A" and
"B" prefer. That suggests that either there's a user registry where
"A" and "B" can ask for the identity aliases associated to the
generalized token-identity that they received (e.g. mapped to
"john.doe"), or the response from introspection widens (perhaps in a
proprietary way) to include these aliases (e.g. authenticated
principal: "john.doe"; aliases: "jdoe"; "[email protected]"). In both
cases, there's a mapping between the aliases outside of the
participating resource servers.
If this second question made sense, I'm looking for precedents and
insights (or better practice). I'm wondering if SCIM plays a role here.
*
Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250**
1-978-899-4705
2-276-4705 (T/L)
[email protected]*
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
