Using LDAP with SSL
In versions 4.0 and below, The communication between Cascade Server and the LDAP server used clear-text network data. That is, that data sent between the two servers, should a third party intercept the communications, would be able to be gleaned for user information in an insecure network environment. For that reason, this communication would need to occur in a secure network environment to ensure that enterprise login credentials were not compromised by an attacker.
For versions 4.1 and higher, however, a plug-in module may be specified in the ldap-configuration file, using a common "binding" algorithm to establish an authenticated connection to the LDAP server.
ldap-config.xml
Both scenarios now use a plug-in module that is specified in the ldap-configuration file. This is configured using a “binding” element that should live in:
ldap-synchronization-configuration/options/server/binding:
The classname element specifies which binding implementation should be used when connecting to the LDAP under both scenarios. Cascade ships with two implementations of LDAPBind:- com.hannonhill.cascade.model.security.ldap.bind.LDAPCleartextBind
- com.hannonhill.cascade.model.security.ldap.bind.LDAPSSLBind
The cleartext bind does not require any parameters to be specified in the ldap-config.xml “binding” element.
The LDAPSSLBind implementation, however should make use of three configurable parameters:
- javax.net.ssl.keyStore – the location of the SSL keystore on the Cascade server
- javax.net.ssl.keyStorePassword – the password of the SSL keystore on the Cascade server
- trust-server-certificate – whether or not you wish to trust the server certificate automatically. If you do not install the client certificate into the SSL keystore on the Cascade Server, then this parameter should be set to “yes” or “true” to ensure that the SSL handshake succeeds. If not specified, this setting defaults to false.
Additional Notes
Version 4.01 and 4.1 of Cascade server supported an ldap-synchronization/configuration/options/server/custom-bind-classname element which served a similar purpose. It should be considered deprecated and the new binding configuration should be used instead.
The binding module that is specified in the ldap-config.xml file will be used both for authentication as well as user migration.
The ldap-config.xml may be modified on-the-fly. That is, that any changes you make to the file should be picked up at the next user migration or LDAP-user login attempt.
A fresh instance of your LDAPBind implementation will be constructed for each binding attempt.
The LDAPSSLBind implementation currently supports SSLv3.