Subject: [OAUTH-WG] AS associated to multiple IdPs

From: Todd W Lainhart <[email-masked]>
Date: Wed, 17 Jul 2013 10:07:59 -0400

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-masked]" (Google).  When a resource server 
performs an introspection on such a token, they're either returned "jdoe" 
or "[email-masked]", 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-masked]" 
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-masked]").  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-masked]

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 18 Jul 2013 21:48:21 -0400

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-masked]" in
the access token? It seems to me that all of the required mapping could 
be completed by the AS.

- prateek

> 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-masked]" (Google). 
>  When a resource server performs an introspection on such a token, 
> they're either returned "jdoe" or "[email-masked]", depending upon 
> what IdP the resource owner chose to authenticate to.  A couple of 
> questions re this setup:
>
> 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-masked]" 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-masked]").  In both 
> cases, there's a mapping between the aliases outside of the 
> participating resource servers.
>
> *
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> [email-masked]*
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 18 Jul 2013 22:19:31 -0400

You could pass the RS's opaque tokens and do introspection or send signed JWT to avoid the introspection step.

There is no guarantee that the user portion of identities used to login to your AS will be globaly unique.

You need to scope the user part to the issuer in the token you issue to the RS, doing something custom per RS will be a headache because the target resource is not identified in the request, unless you overload scope with it in some way.   I have seen Google and others try and use structured scopes to indicate the combination of resource and permissions.

John B.

On 2013-07-17, at 10:07 AM, Todd W Lainhart <[email-masked]> wrote:

> 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-masked]" (Google).  When a resource server performs an introspection on such a token, they're either returned "jdoe" or "[email-masked]", 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? 
> 
> 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-masked]" 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-masked]").  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

---

From: Todd W Lainhart <[email-masked]>
Date: Fri, 19 Jul 2013 10:52:23 -0400

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

From:   Prateek Mishra <[email-masked]>
To:     Todd W Lainhart/Lexington/IBM@IBMUS, 
Cc:     IETF oauth WG <[email-masked]>
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-masked]" in
the access token? It seems to me that all of the required mapping could be 
completed by the AS.

- prateek 

Todd Lainhart
Rational software
IBM Corporation

---

From: John Bradley <[email-masked]>
Date: Fri, 19 Jul 2013 12:21:16 -0400

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-masked]> wrote:

> 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
> 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-masked]" in
> the access token? It seems to me that all of the required mapping could be completed by the AS.
> 
> - prateek   
>

---

From: Todd W Lainhart <[email-masked]>
Date: Fri, 19 Jul 2013 13:22:10 -0400

> 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

From:   John Bradley <[email-masked]>
To:     Todd W Lainhart/Lexington/IBM@IBMUS, 
Cc:     Prateek Mishra <[email-masked]>, IETF oauth WG 
<[email-masked]>
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.

Todd Lainhart
Rational software
IBM Corporation

- prateek 

Todd Lainhart
Rational software
IBM Corporation

---

From: John Bradley <[email-masked]>
Date: Fri, 19 Jul 2013 14:31:45 -0400

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-masked]> 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. 
> 
> >  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
> Cc:        Prateek Mishra <[email-masked]>, IETF oauth WG <[email-masked]>