I think most people look this similarly to SSO account mapping. Typically someone would have a shadow account that would deal with lining the identities from multiple IdP into the local account and assert the local identifier to the RS. I would personally treat passing the additional external identifiers as extra claims to the RS.
The relationship between the RS and AS also has impacts on what you pass and how. John B. On 2013-07-19, at 10:52 AM, Todd W Lainhart <[email protected]> wrote: > Thanks to Prateek and John for the replies. > > I agree that the required mapping should be done by the AS, and that the user > portion of the identity may not be unique (as John said in a later reply). > I'm still trying to figure out to if the RS should pass a scope that might be > a clue to the AS as to what identity to return, and whether or not the AS can > leverage the schema of the introspection response to return the multiple > mapped identities (I'll start a separate thread on that). We're not using > JWT, so it would have to be introspection. > > But I think the replies are verifying that multiple IdPs per AS is not > unusual, and that the management/mapping those ids is proprietary. > > > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250 > 1-978-899-4705 > 2-276-4705 (T/L) > [email protected] > > > > > > From: Prateek Mishra <[email protected]> > To: Todd W Lainhart/Lexington/IBM@IBMUS, > Cc: IETF oauth WG <[email protected]> > Date: 07/18/2013 09:48 PM > Subject: Re: [OAUTH-WG] AS associated to multiple IdPs > > > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
