Hi Adam, we are confronting this issue in the NAPPS effort and are
exploring a model that resembles your Option 2
The Token Agent (TA) obtains an id-token from the first AS1, this
targetted at the second AS2 (the one local to the target RS). The TA
then exchanges that id_token at AS2 for an access token that the RS will
be able to validate
Option 3 is indeed today's default for layering federation onto OAuth
paul
On 3/27/14, 9:06 AM, Lewis Adam-CAL022 wrote:
I am curious it ping the thoughts of others on the list of how OAuth
is going to continue to mature, especially with respect to enterprise
federation scenarios. This is something that I spend a whole lot of
time thinking about. Specifically, consider the following use case:
An end user in domain 1 downloads a native application to access an
API exposed by domain 2, to access a protected resource in domain 2,
under the administrative control of the domain 2 enterprise.
There are in my mind three basic means by which OAuth can federate,
which I know I have discussed with some of you in the past:
1.First option ... End user in domain 1 requests a JWT-structured
access_token from the OAuth provider in domain 1, and sends it in the
HTTP header directly to the RS in domain 2. The JWT access_token
looks a whole lot like a OIDC id_token (maybe it even is one?). The
RS in domain 2 is able to make attributed-based access control
decisions based on the contents of the JWT. This is architecturally
the simplest approach, but enterprises aren't exactly setting up OAuth
providers these days for the intent of accessing protected resources
in foreign domains. Anybody think this might be the case 5 years from
now?
2.Second option ... similar to the first, but the JWT-structured
access_token from domain 1 is sent to the OAuth provider in domain 2,
ala the JWT assertion profile. Domain 1 access token is exchanged for
a domain 2 access token, and the native client uses the domain 2
access token to send to the protected resource in domain 2. I like
this slightly more than the first option, because the resources
servers in domain 2 only need to understand the token format of their
own AS. But it still suffers from the same basic challenge of option
1, that enterprises don't' setup OAuth providers today for the purpose
of federating, the way that setup SAML providers for WebSSO.
3.Third option. Native client contacts the OAuth provider in domain 2
directly. The authorization endpoint is federation enabled (NASCAR or
other) and the user in domain 1 selects their home IdP (SAML or OIDC)
and does WebSSO to federated into the domain 2 OAuth provider. I
believe this is the model that Salesforce supports today, and it the
most tactical, since enterprise that want to federate today run out
and buy a SAML provider.
So option 3 is the most obvious approach today. Does anybody foresee
enterprises setting up an STS in the future to federate to foreign
RS's (the way they setup SAML providers today)? Anybody think we will
see options 1 or 2 in the future?
adam
_______________________________________________
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
