Implementation of cert based authentication with a custom SSLContext and associated elements
Article ID: 294403
Updated On:
Products
VMware Tanzu Gemfire
Issue/Introduction
Some Gemfire customers might have requirements on Gemfire to support passwordless access, therefore the needs for GemFire to handle tokens have come up. GemFire currently does not handle tokens refresh flow. However, we have an alternative solution which enables customers to implement cert based authentication with a custom SSLContext and associated elements.
Environment
Product Version: 9.10
Resolution
In this approach, customers will have to provide an implementation that takes over some functions normally provided by the GemFire product during establishment of SSL connection and provide this implementation when starting GemFire. This can be implemented today in customer environments and does not need GemFire changes.
Customers would need to set `ssl-use-default-context` to true and invoke SSLContext.setDefault[1]. The provided SSLContext would need to provide a KeyManager and a TrustManager that takes over functions normally provided by the GemFire product (e.g. reading in the keystore / truststore, configuring the protocol version, etc). In addition, customers would need to implement their validation logic using an extension of X509ExtendedTrustManager[2].
An example of this approach can be seen in the attached Github link[3]. This is a solution to provide cert based authentication and it should enable GemFire users to reject client connections coming from applications which does not have the right cert or DNS names in CN field of certs. This approach is to provide the cert details to the SecurityManager framework which will let GemFire users provide an implementation of SecurityManager which can choose to reject client connections based on cert presented by client applications.
The advantage of this approach is that no product changes are required and customers can work on this today. However, the complexity is higher for customers and implementation errors may introduce new security risks (due to programming errors, using incorrect keystore and truststore).
References:
[1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#setDefault-javax.net.ssl.SSLContext-
[2] https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509ExtendedTrustManager.html
[3] https://github.com/apache/geode/compare/develop...pivotal-jbarrett:wip/server-custom-ssl
Customers would need to set `ssl-use-default-context` to true and invoke SSLContext.setDefault[1]. The provided SSLContext would need to provide a KeyManager and a TrustManager that takes over functions normally provided by the GemFire product (e.g. reading in the keystore / truststore, configuring the protocol version, etc). In addition, customers would need to implement their validation logic using an extension of X509ExtendedTrustManager[2].
An example of this approach can be seen in the attached Github link[3]. This is a solution to provide cert based authentication and it should enable GemFire users to reject client connections coming from applications which does not have the right cert or DNS names in CN field of certs. This approach is to provide the cert details to the SecurityManager framework which will let GemFire users provide an implementation of SecurityManager which can choose to reject client connections based on cert presented by client applications.
The advantage of this approach is that no product changes are required and customers can work on this today. However, the complexity is higher for customers and implementation errors may introduce new security risks (due to programming errors, using incorrect keystore and truststore).
References:
[1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#setDefault-javax.net.ssl.SSLContext-
[2] https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509ExtendedTrustManager.html
[3] https://github.com/apache/geode/compare/develop...pivotal-jbarrett:wip/server-custom-ssl
Feedback
Yes
No
Powered by
