Hi all, I'm currently working on integrating the changes in [1] to provide the capability to upload client certificates to truststore during run time without restart.
As per the implementation in [1] the default trust manager will be replaced with a custom trust manager which will reload the client-truststore.jks whenever there is a SSL validation failure. However in the case where there are many SSL failures it will reload the JKS file for each and every validation failure which will slow the server. With the above mentioned concern, should I proceed with this integration? Appreciate your thoughts. [1] https://github.com/wso2/carbon-identity/pull/1511 Thanks, Sathya On Mon, Feb 19, 2018 at 3:57 PM, Sathya Bandara <[email protected]> wrote: > 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 [1]. 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 [1] 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 [3]. > > 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 [2] 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. > > [1] Invitation: [Review] User Story - Mutual TLS Authentication for Oauth > 2.0 clients @ Mon Feb 12, 2018 2pm - 3pm (IST) (WSO2 Engineering Group) > [2] https://github.com/wso2/carbon-identity/pull/1511 > [3] 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 <[email protected]> > 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 <[email protected]> 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 [1]. >>> 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 [2]. >>> 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 [3]. With the "client_id" parameter we >>> can easily obtain the client's registered certificate for authenticating >>> the client. >>> >>> Highly appreciate your thoughts and suggestions. >>> >>> [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >>> [2] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1 >>> [3] 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> > -- 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
