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 protected]> 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 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
