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
