On Fri, Sep 27, 2019 at 5:47 PM Hasintha Indrajee <[email protected]> wrote:
> The original problem is we can't execute client authenticators per > application. As per our current implementation we never can have a both > MTLS and Basic Auth client authentication supported in the server while > different clients using Basic auth + MTLS and BasicAuth or MTLS alone. > > Hence I think, the best solution is to make client authenticators > configurable per oauth app. This should be an easy implementation. (Store > engaged authenticators as oauth app property and honour them through an > abstract logic in ClientAuthenticators). > I don't think supporting client authenticators per application would solve this problem either. What the spec tries to limit is using multiple authentication mechanisms in the *same request*. That does not mean that the application should be limited to one authentication mechanism. Are we suggesting to limit an application to allow only one authentication mechanism? > > However It's rationale to turn this MTLS client authenticator off for OB > since it's one of their OOTB use cases. > > On Fri, Sep 27, 2019 at 5:08 PM Harsha Kumara <[email protected]> wrote: > >> Hi All, >> >> When I configured the IS as KM, same issue occured during the token >> generation as our client initialize using the required keystores. Client >> will set the javax.servlet.request.X509Certificate by default. Our products >> support http verify clent as option which means client can authenticate >> with one or two way SSL. Also there are clients who secure their token >> endpoint with mutual authentication along with the default authentication >> used in the grant types. AFAIK, in OB usecases it require token endpoint to >> secured with MutualTLS. I believe this authenticator should be disabled by >> default. @Hasintha Indrajee <[email protected]> WDYT? >> >> Thanks, >> Harsha >> >> On Sat, Sep 21, 2019 at 10:12 AM Harsha Kumara <[email protected]> wrote: >> >>> Thank you for the information. Since I'm using the alpha4 update, it >>> should have that fix. I'll check further >>> >>> On Sat, Sep 21, 2019 at 12:20 AM Sathya Bandara <[email protected]> wrote: >>> >>>> That PR was not merged. Instead the missing registry configs were >>>> re-added [1] >>>> >>>> [1] https://github.com/wso2/product-is/pull/6076 >>>> >>>> On Fri, Sep 20, 2019 at 8:35 PM Harsha Kumara <[email protected]> wrote: >>>> >>>>> Since this either should handle at client side and mandate not to send >>>>> the certificate or we have to disable the handler. Looks like we have >>>>> disabled the handler by default in >>>>> https://github.com/wso2/carbon-identity-framework/pull/2336/files >>>>> >>>>> But I don't see it in the wso2is-5.9.0-alpha4-SNAPSHOT. Was it revert >>>>> again? >>>>> >>>>> Thanks, >>>>> Harsha >>>>> >>>>> On Fri, Sep 20, 2019 at 7:53 PM Harsha Kumara <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks a lot @Sathya Bandara <[email protected]> That should be the >>>>>> issue. I will check and update the thread. >>>>>> >>>>>> Thanks, >>>>>> Harsha >>>>>> >>>>>> On Fri, Sep 20, 2019 at 7:14 PM Sathya Bandara <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> We came across a similar issue where the OIDC federated >>>>>>> authenticator sets the certificate by default to the request [1]. This >>>>>>> has >>>>>>> occurred due to a change to registry.xml with new config model. When the >>>>>>> changes were reverted it worked as expected [2]. Maybe the same issue >>>>>>> exists with APIM? >>>>>>> >>>>>>> [1] "Error when invoking OIDC federated Authenticator in IS 5.9.0-m5" >>>>>>> [2] https://github.com/wso2/product-is/issues/6013 >>>>>>> >>>>>>> On Fri, Sep 20, 2019 at 6:50 PM Harsha Kumara <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Yes that's correct. I'm using the openid authenticator, so it sets >>>>>>>> the certificate by default to the header, hence multiple authenticators >>>>>>>> getting triggered..But mutual SSL is handled at the transport layer and >>>>>>>> even with mutual authentication, client id and secret will be present >>>>>>>> in >>>>>>>> the request. I feel there is something wrong with the logic. >>>>>>>> >>>>>>>> On Fri, Sep 20, 2019 at 6:39 PM Sathya Bandara <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> If client secret is used for client authentication with POST >>>>>>>>> request to the token endpoint, then its not required to send the >>>>>>>>> certificate. >>>>>>>>> >>>>>>>>> On Fri, Sep 20, 2019 at 6:35 PM Harsha Kumara <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> So if so our OpenIDConnectAuthenticator shouldn't set certificate >>>>>>>>>> in the request during the authorization code exchange? >>>>>>>>>> >>>>>>>>>> On Fri, Sep 20, 2019 at 6:30 PM Sathya Bandara <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Harsha, >>>>>>>>>>> >>>>>>>>>>> In the oauth spec [1], it mandates that client should not use >>>>>>>>>>> more than one authentication mechanism per request. Hence, we have >>>>>>>>>>> that >>>>>>>>>>> validation here. >>>>>>>>>>> >>>>>>>>>>> [1] https://tools.ietf.org/html/rfc6749#section-2.3 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 20, 2019 at 6:25 PM Harsha Kumara <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> As we can configure multiple authenticators, and add them based >>>>>>>>>>>> on canAuthenticate method response, why we need to return above >>>>>>>>>>>> error if >>>>>>>>>>>> multiple authenticators engaged? >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Sep 20, 2019 at 6:22 PM Harsha Kumara <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> It seems the logic of checking authenticator list greater than >>>>>>>>>>>>> 1 should be correct? >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Sep 20, 2019 at 5:30 PM Harsha Kumara < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> With the API Manager 3.0.0 release, we are going to add OIDC >>>>>>>>>>>>>> authenticator to the API Manager as we already had that >>>>>>>>>>>>>> capability in >>>>>>>>>>>>>> directly through the site.json configuration. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However to try the scenario, I have followed the document[1]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Setup would be APIM 3.0.0 and IS-5.9.0-Alpha4-SNAPSHOT. I got >>>>>>>>>>>>>> below error during the authorization code exchange. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [2019-09-20 15:33:38,428] ERROR - DefaultStepHandler >>>>>>>>>>>>>> Authentication failed exception! >>>>>>>>>>>>>> org.wso2.carbon.identity.application.authentication.framework.exception.AuthenticationFailedException: >>>>>>>>>>>>>> invalid_request, The client MUST NOT use more than one >>>>>>>>>>>>>> authentication >>>>>>>>>>>>>> method in each >>>>>>>>>>>>>> at >>>>>>>>>>>>>> org.wso2.carbon.identity.application.authenticator.oidc.OpenIDConnectAuthenticator.getOauthResponse(OpenIDConnectAuthenticator.java:615) >>>>>>>>>>>>>> ~[org.wso2.carbon.identity.application.authenticator.oidc-5.3.2.jar:?] >>>>>>>>>>>>>> at >>>>>>>>>>>>>> >>>>>>>>>>>>>> This error occurred due to engaging the >>>>>>>>>>>>>> MutualTLSAuthenticator in the token exchange flow. Below check >>>>>>>>>>>>>> returns list >>>>>>>>>>>>>> of authenticators greater than one due to engaging this >>>>>>>>>>>>>> authenticator. It >>>>>>>>>>>>>> seems during the token exchange flow, we send the certificate in >>>>>>>>>>>>>> the header >>>>>>>>>>>>>> which lead to trigger the MutualTLSAuthenticator enable checks >>>>>>>>>>>>>> and add to >>>>>>>>>>>>>> the authenticator list. If I removed the mutual authenticator >>>>>>>>>>>>>> jar, this >>>>>>>>>>>>>> started to work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> // Will return an invalid request response if multiple >>>>>>>>>>>>>> authentication mechanisms are engaged irrespective of >>>>>>>>>>>>>> // whether the grant type is confidential or not. >>>>>>>>>>>>>> if (oAuthClientAuthnContext.isMultipleAuthenticatorsEngaged()) { >>>>>>>>>>>>>> tokenRespDTO = handleError(OAuth2ErrorCodes.INVALID_REQUEST, >>>>>>>>>>>>>> "The client MUST NOT use more than one " + >>>>>>>>>>>>>> "authentication method in each", tokenReqDTO); >>>>>>>>>>>>>> setResponseHeaders(tokReqMsgCtx, tokenRespDTO); >>>>>>>>>>>>>> triggerPostListeners(tokenReqDTO, tokenRespDTO, >>>>>>>>>>>>>> tokReqMsgCtx, isRefreshRequest); >>>>>>>>>>>>>> return tokenRespDTO; >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Generally people will configure ODIC with external provider >>>>>>>>>>>>>> and won't encounter this kind of problem. For testing if tried >>>>>>>>>>>>>> with our IS >>>>>>>>>>>>>> as OIDC provider, this will leads to trigger the above error. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it required to engage mutual tls authenticator when >>>>>>>>>>>>>> certificate present? Can't we ship it by default setting to >>>>>>>>>>>>>> false? >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> https://docs.wso2.com/display/AM260/Configuring+Single+Sign-on+with+OpenID+Connect >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Harsha >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Harsha Kumara* >>>>>>>>>>>>>> >>>>>>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>>> Email: [email protected] >>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> GET INTEGRATION AGILE >>>>>>>>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> *Harsha Kumara* >>>>>>>>>>>>> >>>>>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>> Email: [email protected] >>>>>>>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>>>>>>> >>>>>>>>>>>>> GET INTEGRATION AGILE >>>>>>>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *Harsha Kumara* >>>>>>>>>>>> >>>>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>> Email: [email protected] >>>>>>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>>>>>> >>>>>>>>>>>> GET INTEGRATION AGILE >>>>>>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Sathya Bandara >>>>>>>>>>> Senior Software Engineer >>>>>>>>>>> Blog: https://medium.com/@technospace >>>>>>>>>>> WSO2 Inc. http://wso2.com >>>>>>>>>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >>>>>>>>>>> >>>>>>>>>>> <+94%2071%20411%205032> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Harsha Kumara* >>>>>>>>>> >>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>> Mobile: +94775505618 >>>>>>>>>> Email: [email protected] >>>>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>>>> >>>>>>>>>> GET INTEGRATION AGILE >>>>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sathya Bandara >>>>>>>>> Senior Software Engineer >>>>>>>>> Blog: https://medium.com/@technospace >>>>>>>>> WSO2 Inc. http://wso2.com >>>>>>>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >>>>>>>>> >>>>>>>>> <+94%2071%20411%205032> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Harsha Kumara* >>>>>>>> >>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>> Mobile: +94775505618 >>>>>>>> Email: [email protected] >>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>> >>>>>>>> GET INTEGRATION AGILE >>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sathya Bandara >>>>>>> Senior Software Engineer >>>>>>> Blog: https://medium.com/@technospace >>>>>>> WSO2 Inc. http://wso2.com >>>>>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >>>>>>> >>>>>>> <+94%2071%20411%205032> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Harsha Kumara* >>>>>> >>>>>> Technical Lead, WSO2 Inc. >>>>>> Mobile: +94775505618 >>>>>> Email: [email protected] >>>>>> Blog: harshcreationz.blogspot.com >>>>>> >>>>>> GET INTEGRATION AGILE >>>>>> Integration Agility for Digitally Driven Business >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Harsha Kumara* >>>>> >>>>> Technical Lead, WSO2 Inc. >>>>> Mobile: +94775505618 >>>>> Email: [email protected] >>>>> Blog: harshcreationz.blogspot.com >>>>> >>>>> GET INTEGRATION AGILE >>>>> Integration Agility for Digitally Driven Business >>>>> >>>> -- >>>> Sathya Bandara >>>> Senior Software Engineer >>>> Blog: https://medium.com/@technospace >>>> WSO2 Inc. http://wso2.com >>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >>>> >>>> <+94%2071%20411%205032> >>>> >>> >>> >>> -- >>> >>> *Harsha Kumara* >>> >>> Technical Lead, WSO2 Inc. >>> Mobile: +94775505618 >>> Email: [email protected] >>> Blog: harshcreationz.blogspot.com >>> >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> >> >> >> -- >> >> *Harsha Kumara* >> >> Technical Lead, WSO2 Inc. >> Mobile: +94775505618 >> Email: [email protected] >> Blog: harshcreationz.blogspot.com >> >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> > > > -- > Hasintha Indrajee > WSO2, Inc. > Mobile:+94 771892453 > > -- Farasath Ahamed Associate Technical Lead, WSO2 Inc.: http://wso2.com Mobile: +94777603866 Blog: https://farasath.blogspot.com / https://medium.com/@farasath Twitter: @farazath619 <https://twitter.com/farazath619> <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
