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<mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
