Created https://github.com/wso2/product-is/issues/3897
Regards, Johann. On Thu, Nov 1, 2018 at 3:01 PM Prabath Siriwardena <[email protected]> wrote: > +1 > > Can you please create a new feature request - so we will not miss this.... > > Thanks & regards > -Prabath > > On Thu, Nov 1, 2018 at 1:24 AM Johann Nallathamby <[email protected]> wrote: > >> *Status Quo* >> >> Let's say there are two legitimate service providers A and B. Both A and >> B are registered in IdP X as SAML2 service providers. The only difference >> is A is enabled to exchange SAML2 assertion with WSO2 IS using SAML2 Bearer >> Assertion grant flow. To do this, WSO2 IS's token endpoint is set as an >> audience and recipient in the SAML2 assertion for A. For B it is not the >> case. >> >> When we validate the SAML2 assertion sent to the token endpoint in IS we >> simply validate whether the list of audience contains the token endpoint >> (or some acceptable alias). We don't validate whether this assertion was in >> fact sent by the intended recipient for the assertion. >> >> This implementation is of course compatible with the specifications. >> >> *Problem* >> >> If B somehow is able to get hold of the assertion intended to A, and send >> it to the token endpoint with B's client credentials, WSO2 IS will still >> issue a valid OAuth2 access token. >> >> *Proposed Solution* >> >> If sharing of SAML2 assertions between OAuth2 clients are not required, >> we can have an option in the token endpoint to validate the client_id >> identified from he basic auth header (or any other means depending on the >> client authentication mechanism), against the client_id in the SAML2 >> assertion. To do this, IdP X has to support adding multiple additional >> audiences into the SAML2 assertion. Also the client_id issued by WSO2 IS >> (which is public info) needs to be configured as an audience in IdP X. I >> don't see any issue with this either. >> >> This will allow us to validate that the intended recipient of the SAML2 >> assertion is the one who is in fact sending it to the OAuth2 token endpoint >> as well, to exchange to an OAuth2 access token. >> >> *Benefit* >> >> This will give us a way to make sure that the OAuth2 client who >> requesting the access token, has obtained it by authorized means (not >> stolen). >> >> Thoughts? >> >> P.S. this is not just for IS service providers where SAML2 and OAuth2 >> inbound configurations can be done for the same service provider. This >> proposal goes beyond that for any OAuth2 authorization server. >> >> Thanks & Regards, >> Johann. >> >> -- >> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | >> WSO2 Inc. >> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected] >> [image: Signature.jpg] >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Blog: http://blog.facilelogin.com > Vlog: http://vlog.facilelogin.com > > > -- *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | WSO2 Inc. (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected] [image: Signature.jpg]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
