Hi all, The basic implementation for this feature is completed and we held an initial code review for this. Review notes can be found in . We were able to identify the following key limitations when including this feature in the product.
1. In order to use the client certificate in the authentication request, the certificate needs to be imported to our truststore as a pre-requisite. As a result we will have to ask to restart the server. Even if we add the certificate via Management console it will not be applied unless the server is restarted with the current implementation. In order to overcome this requirement , we need to improve our existing implementation to add certificates at runtime without restarting the server. Part of this improvement is already provided in  which provides the following capabilities. - Alter UI to view the default trust store. - Alter keystore management service to support the addition of trust stores. - Create a X509TrustManager implementation that dynamically reloads any changes made to the trust store. Anyone using this "DynamicX509TrustManager" with SSLContext will not require to restart the server for changes to client trust store to take effect. 2. Since in the current approach of mutual authentication using TLS, we need to add the client certificate to the cient-trustore.jks in order handle mutual TLS at at web container level (tomcat), during TLS handshake. In this scenario all the client certificates will be accessible globally since we cannot override the trustore at SP level. Since our admin services are protected by the Mutual-SSL-authenticator, clients can successfully authenticate from mutual SSL authenticator using their certificates and consume admin services. As a work-around we can specifically ask to disable the mutual-SSL-authenticator if the requirement is to use mutual TLS for client authentication. However, the proper solution would be to find an approach for the web container to dynamically identify the client specific certificates during runtime. 3. Configuring the Tomcat connector for TLS Using the Server Keystore requires to restart Tomcat whenever we change the contents of the keystore since they are cached at launch and are not re-examined until the server process is bounced. We need to investigate an approach to avoid server restart and dynamically load the keystore content. One possible solution would be to implement a custom trustManagerClass and then use it to load the KeyStore on every ssl-session . In order to overcome the above limitations, supplementary features/capabilities are required. Please find the following task break down in order to address these limitations. Task 1 - Capability to upload the client certificate to the trustore.jks from UI and dynamically apply the certificate changes during runtime. - Sub-Task 1 - Merge the changes in  to carbon-identity-framework master branch and test the functionality. - Sub-Task 2 - Implement a mechanism to sync truststore changes in cluster. - Sub-Task 3 - Investigate an approach to avoid tomcat restart and dynamically load the keystore content for the connector. Task 2 - Address the conflicts with existing authenticators (e.g. MutualSSLAuthenticator/X509 Authenticator) when engaging the TLS Mutual Authenticator. - Sub-Task 1: Improve the existing MutualSSLAuthenticator to add a secondary factor of validation. - Sub-Task 2: Improve the existing X509 Authenticator to add a secondary factor of validation. Appreciate your feedback and suggestions.  Invitation: [Review] User Story - Mutual TLS Authentication for Oauth 2.0 clients @ Mon Feb 12, 2018 2pm - 3pm (IST) (WSO2 Engineering Group)  https://github.com/wso2/carbon-identity/pull/1511  https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates Thanks, Sathya On Fri, Feb 9, 2018 at 12:34 PM, Hasintha Indrajee <hasin...@wso2.com> wrote: > Can we also validate these certificates using CRLs and OSCP endpoints > provided in certificate ?. Also better if this validation can be made > optional and can be governed through a configuration. This configuration > will just be a handler property. > > *@Indunil : *Do we have this feature bundled in product (Certificate > validation using OSCP and CRL) ? > > On Fri, Feb 9, 2018 at 12:20 PM, Sathya Bandara <sat...@wso2.com> wrote: > >> Hi all, >> >> Mutual TLS is a widely used, secure, authentication technique in >> enterprise environments to ensure the authenticity of the clients to server >> and vice versa. It facilitates authentication via certificates followed by >> the establishment of an encrypted channel between the parties. >> >> The OAuth 2.0 Authorization Framework allows the use of additional client >> authentication mechanisms. One such is the mechanism of client >> authentication utilizing mutual TLS certificate-based authentication . >> We can add this support for WSO2 Identity Server by providing an additional >> OAuth client authenticator. In order to utilize TLS for OAuth client >> authentication, the TLS connection between the client and the authorization >> server must have been established with mutual X.509 certificate >> authentication (i.e. the Client Certificate and Certificate Verify messages >> are sent during the TLS Handshake). >> >> >> The specification defines two ways of binding a certificate to a client >> as two distinct client authentication methods . >> 1. PKI Mutual TLS OAuth Client Authentication Method >> >> Uses a subject distinguished name (DN) and validated certificate chain to >> identify the client. The client is successfully authenticated if the subject >> information in the certificate matches the expected DN configured or >> registered for that >> particular client. >> >> 2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Method >> Mutual >> >> support client authentication using self-signed certificates. As >> pre-requisite, the client registers an X.509 certificate or a trusted >> source for its X.509 certificates (such as the "jwks_uri"). The client is >> successfully authenticated, if the subject public key info of the >> certificate matches the subject public key info of one of the certificates >> configured or registered for that particular client. >> >> In both approaches, TLS is utilized to validate the client's possession >> of the private key corresponding to the public key presented within the >> certificate in the respective TLS handshake during authentication. >> >> We will follow the approach #2 since it prevents the necessity to >> validate the certificate chain in contrast to the PKI method. >> >> >> Also since the client cert authentication happens as part of the mutual >> TLS handshake, it will happen at the web container level. Hence if the >> authentication is successful, client's public certificate will be available >> as a request attribute at the CXF servlet. Hence the Mutual TLS Client >> Authenticator can be engaged by inferring the existence of the client cert >> as a request attribute. >> >> As we currently have the capability to upload Service Provider specific >> public certificates, clients can register their public certificates during >> service provider configuration. Within the authenticate method of the >> MutualTLSClientAuthenticator, we can compare the registered certificate's >> public key against the public key of the certificate presented in the TLS >> handshake. If these two matches we can successfully authenticate the >> client. >> >> For all requests to the authorization server utilizing mutual TLS client >> authentication, the client MUST include the "client_id" parameter as >> described in OAuth 2.0 specification . With the "client_id" parameter we >> can easily obtain the client's registered certificate for authenticating >> the client. >> >> Highly appreciate your thoughts and suggestions. >> >>  https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >>  https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1 >>  https://tools.ietf.org/html/rfc6749#section-2.2 >> >> Thanks, >> Sathya >> >> -- >> Sathya Bandara >> Software Engineer >> WSO2 Inc. http://wso2.com >> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >> >> > > > -- > Hasintha Indrajee > WSO2, Inc. > Mobile:+94 771892453 <+94%2077%20189%202453> > > -- Sathya Bandara Software Engineer WSO2 Inc. http://wso2.com Mobile: (+94) 715 360 421 <+94%2071%20411%205032> <+94%2071%20411%205032>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture