The SAML IdP issuing the assertion would need to collect the authorization. Given that something approximating 0 SAML IdP do this out of the box you are going to wind up with something relatively custom.
In general if you want to collect consent use a regular code flow and have the AS use whatever federated Authentication you need. Having the client be the SAML SP (or possibly (ECP) in a web SSO flow is not ideal. There is also no standard way of indicating the scopes granted in the SAML assertion, so in general you are limited to a fixed set. If user consent is required the simple solution is to use the code flow, rather than the assertion flow. If you are crossing security domains without additional user interaction then the assertion flow is more appropriate. John B. On 2013-07-24, at 10:31 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > On 24/07/13 15:04, Sergey Beryozkin wrote: >> Hi >> On 24/07/13 03:31, Lewis Adam-CAL022 wrote: >>> 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. >>> >> That would interest us too. >> What concerns me is this: a client web app is effectively impersonating >> a user to get a grant. > Well, I was wrong, the client app would still use its own credentials to > request a grant using this SAML/JWT token representing the end user > authentication. I'm just curious how the end user can be still kept in > 'control', the pre-authorization seems like the only option, but may be it is > not true > > Cheers, Sergey > >> >> So the user is there but what happens to the user approving or denying >> the client application (as in a typical authorization code flow for >> example where a user is physically present), the user only knows that a >> log-on has happened ? >> >> I guess a client application needs to tell the user upfront somehow ? Or >> the end user should go and pre-authorize a given client-application first ? >> >> Cheers, Sergey >> >>> -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 >>> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
