> 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) lainh...@us.ibm.com From: John Bradley <ve7...@ve7jtb.com> To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: Prateek Mishra <prateek.mis...@oracle.com>, IETF oauth WG <oauth@ietf.org> 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 <lainh...@us.ibm.com> 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) lainh...@us.ibm.com From: Prateek Mishra <prateek.mis...@oracle.com> To: Todd W Lainhart/Lexington/IBM@IBMUS, Cc: IETF oauth WG <oauth@ietf.org> 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 "j...@gmail.com" 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 "j...@gmail.com" (Google). When a resource server performs an introspection on such a token, they're either returned "jdoe" or "j...@gmail.com", 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 "j...@gmail.com" 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"; "j...@gmail.com"). 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) lainh...@us.ibm.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
