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

   - Alter UI to view the default trust store.
      - Alter keystore management service to support the addition of trust
      - 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

   - 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

   - 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


On Fri, Feb 9, 2018 at 12:34 PM, Hasintha Indrajee <hasin...@wso2.com>

> 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 [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>

Architecture mailing list

Reply via email to