The additional fields would be passed back from the token introspection endpoint. That is what we do in Ping Federate. We still need to come up with a token introspection standard so implementations are currently doing there own things.
John B. On 2013-07-19, at 1:22 PM, Todd W Lainhart <[email protected]> wrote: > > 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. > > Yes, that where I was going. > > > I would personally treat passing the additional external identifiers as > > extra claims to the RS. > > If the AS isn't issuing JWTs, how do you suggest passing this information to > the RS? I was thinking of reusing or augmenting fields in the response from > token provisioning and introspection. > > > > > 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: John Bradley <[email protected]> > To: Todd W Lainhart/Lexington/IBM@IBMUS, > Cc: Prateek Mishra <[email protected]>, IETF oauth WG > <[email protected]> > Date: 07/19/2013 12:22 PM > Subject: Re: [OAUTH-WG] AS associated to multiple IdPs > > > > 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
