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>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
