Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable to upload a separate transport cert through sign up flow and authenticate against that #179

Open
kasundharmadasa opened this issue Jul 28, 2021 · 0 comments

Comments

@kasundharmadasa
Copy link

kasundharmadasa commented Jul 28, 2021

When Mutual TLS is used as the client authentication mechanism, we will have to match the client certificate sent by TPP against the certificates stored in the TPP application. For DCR, we use the JWKS to get the certificates of the client and there both signing certificates and transport certs can be expressed separately. Hence, when we conduct MTLS authentication, we match the TPP certificate with the tls certificates provided by the JWKS of the TPP [1][2] .

However, for signup flow, we do not have the capability to store a separate transport cert during registration. Only a transport cert is stored (as our IS has capability to store only one certificate). Hence we do not have a direct certificate to match the client certificate during MTLS authentication.

However, when eIDAS certificates are used, the organization ID present in the certificate is common to both transport and signing certs. Hence, even if we do not have the separate transport certificate, we can extract the organization ID from the transport certificate. Therefore during registration, when the TPP uploads an eIDAS signing certificate through the dev portal, we extract the organizational ID and store it as a metadata in IS. This organization ID is used to match with the TPP client certificate during MTLS authentication [3].

But this can cause a security concern if the bank has only one APIM gateway that has a single trustore serving both sandbox and production clients. Let's consider a scenario where a TPP already has a valid production application created using a valid production certificate. Since the sandbox root certs are also in the truststore, the TPP has the ability to invoke the production application using a sandbox certificate having the same organization ID as the applications production certificate. 

Hence as a solution for the customers who are using sign up flow along with single GW for sandbox and production, we would require to enable uploading transport cert as well so that we do not need to rely on the organization ID and directly do authentication with the uploaded transport cert itself.

[1] https://github.com/wso2-support/financial-open-banking/blob/support-2.0.0.x-full/artifacts/mutual-tls/components/com.wso2.finance.open.banking.mtls.authenticator/src/main/java/com/wso2/finance/open/banking/mtls/authenticator/OBMutualTLSClientAuthenticator.java[2] https://github.com/wso2-support/financial-open-banking/blob/support-2.0.0.x-full/artifacts/mutual-tls/components/com.wso2.finance.open.banking.mtls.validator/src/main/java/com/wso2/finance/open/banking/mtls/validator/handler/MTLSClientTokenValidationHandler.java#L145[3] https://github.com/wso2-support/financial-open-banking/blob/support-2.0.0.x-full/artifacts/mutual-tls/components/com.wso2.finance.open.banking.mtls.authenticator/src/main/java/com/wso2/finance/open/banking/mtls/authenticator/OBMutualTLSClientAuthenticator.java#L122

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants