Hi Adam, Thx for this interresting information. Did you consider, just using OIDC for both, authentication and authorization?
As the JWT-based id_token can contain self-defined claims and as the current spec gives us a way to exchange one token for another, which allows us for (SAML/WS-Trust-like) delegation-scenarios, I'm wondering, if I still need OAuth2-based authorization for enterprise-scenarios. What do you think about this? Wishes, Manfred Von meinem iPhone gesendet Anfang der weitergeleiteten E‑Mail: > Von: Lewis Adam-CAL022 <adam.le...@motorolasolutions.com> > Datum: 24. Juli 2013 04:31:13 MESZ > An: Brian Campbell <bcampb...@pingidentity.com>, Pedro Felix > <pmhsfe...@gmail.com> > Kopie: oauth <oauth@ietf.org> > Betreff: Re: [OAUTH-WG] Using SAML for authentication *and* as Authorization > Grants > > Hi Pedro … for what it’s worth I am looking at something almost the same, > except using JWT with OIDC. > > 1. OIDC client (web app) requests an id_token from OIDC provider, > including a request object specifying that the audience of the JWT id_token > should include both the client_id and the AS in the audience field > 2. OIDC client (web app) uses the id_token received in the response in > the OAuth JWT assertion profile as a grant to request additional OAuth access > tokens > > This was made possible relatively recently by updates to the > draft-ietf-oauth-json-web-token spec and in conjunction with the OIDC > messages spec. The draft-ietf-oauth-json-web-token spec was updated to allow > the audience claim to be an array of values. OIDC allows for a request > object to be communicated in the authorization request and hence specify the > desired audiences. > > I understand you’re looking to use SAML and not OIDC, but I believe the flow > is nearly identical. As Brian mentions it might be more of an implementation > issue than anything else. But it seems acceptable from a security vantage > anyway. > > -adam > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Brian Campbell > Sent: Tuesday, July 23, 2013 9:14 AM > To: Pedro Felix > Cc: oauth > Subject: Re: [OAUTH-WG] Using SAML for authentication *and* as Authorization > Grants > > Seems legitimate to me. In fact, initial versions of the draft sought to > simplify things by restricting the audience restriction and subject > confirmation to single elements but was expanded to allow for this kind of > scenario. > > In my (somewhat limited) experience, however, support in SAML products for > producing assertions targeted at multiple audiences and with multiple subject > confirmations isn't very good. So while the standards allow for it, you may > run into issues trying to do this in practice. Maybe. > > From a security perspective I think it's okay. Though anytime you have a > bearer assertion targeted at multiple audiences, you do effectively allow any > of them to use the assertion. Which isn't always wrong but worth considering. > In this case though, I don't think that's an issue. > > Another potential approach to consider for this particular case is to send > the OAuth access token with the SSO assertion (included as an attribute). I > believe some deployments are taking that approach today. > > > > > > > On Mon, Jul 22, 2013 at 7:39 AM, Pedro Felix <pmhsfe...@gmail.com> wrote: > Hi, > > I'm considering a scenario where a Web App plays two roles: > 1) As a SAML Service Provider/Relying Party, the Web App wants to > authenticate it's Users, via a third-party SAML Identity Provider > 2) As an OAuth 2.0 Client, the Web App wants to use an API on the User's > behalf. > > Both the IdP and the API (the Resource Server) belong to the same > organization. > > Is it possible to use the *same* SAML assertion for both purposes, assuming > that both the SAML IdP and the OAuth AS are controlled by the same > organization. The sequence would be something like this: > > 1) The Client Web App uses the SAML protocol (e.g. Redirect Binding/POST > Binding) to request a SAML assertion from the IdP/AS. > 2) The Client Web App uses the received SAML assertion to authenticate the > User, as defined by the SAML specs. > 3) The Client Web App also uses the *same* received SAML assertion to access > the IdP/AS token endpoint and obtain an access token. For this, it uses the > SAML assertion as an authorization Grant (as defined by the "OAuth SAML > Assertion Profiles"). > > One possible problem that I've identified in this scenario is the Audience > restriction: > > 1) For the SAML assertion to be used by the Web App to authenticate the User, > then it's AudienceRestriction should include the Web App Audience > 2) For the SAML assertion to be used as a Authorization Grant, then it's > AudienceRestriction should include the Authorization Server > > However, the SAML assertion spec allow for multiple Audience elements on the > AudienceRestriction, allowing for the above scenario. > > A complementary idea would be for the Authorization Server to check if the > OAuth client ID is also contained in the audience, before issuing an access > token. > > Is this a legitimate use of the "OAuth SAML Assertion Profiles"? Are there > any security problems due to using the same SAML for both authentication and > authorization grant, given that the AudienceRestriction is properly assigned > and handled? > > Thanks > Pedro > > _______________________________________________ > 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
