You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: