LDAP (Lightweight Directory Access Protocol) is a directory service for managing hierarchical information. LDAP is often used within organizations to centralize the management and maintenance of security information about employees and other resources. LDAP integration in Volt Active Data allows you to use LDAP to authenticate Volt users and authorize their access to specific features in place of the builtin security described earlier in this chapter. In other words, manage users and permissions in LDAP rather than internally within Volt.
LDAP integration does require at least one builtin user account with administrative permissions to ensure the database is accessible in case the LDAP server is not available.
The following diagram shows the overall workflow of LDAP integration at runtime. The user, or client application, connects to the database passing in their LDAP credentials: a username and password. VoltDB passes those credentials to LDAP for authentication. Once the user is authenticated, the VoltDB server then looks for groups in LDAP of which the user is a member. Finally, the LDAP group is mapped to one or more VoltDB roles to decide what permissions the user has.
LDAP integration allows VoltDB to use existing resources within LDAP for authentication and authorization. That means that administrators can use the existing user and group definitions within LDAP for security management of VoltDB. Of course, you can always create specific users and/or groups for managing VoltDB access, but it is not necessary. As a result, very little change is needed to an existing LDAP infrastructure; most of the set up for LDAP integration belongs to the VoltDB servers, as shown below.
The following sections explain how to configure VoltDB for LDAP integration and specific requirements for the LDAP server.
You configure LDAP integration in the deployment.security
property of the VoltDB configuration
file. The following is an example configuration file that illustrates all of the available LDAP configuration
options.
deployment: security: enabled: true provider: ldap ldap: server: ldaps://ldap.myorg.com rootdn: "dc=ldaptest,dc=voltactivedata,dc=com" timeout: 12 user: "cn=admin,dc=ldaptest,dc=volt,dc=com" password: secret.password # LDAP group to Volt Role mapping group: - name: "cn=heroes,dc=ldaptest,dc=volt,dc=com" role: admin - name: "cn=zeroes,dc=ldaptest,dc=volt,dc=com" role: user ssl: truststore: path: /my/ssl/ldap/truststore.jks password: trustpasswd users: user: - name: houdini password: shazam roles: administrator
Finally, by default, Volt searches for the username in the uid attribute of the
inetOrgPerson class, then uses the full distinguished name to search the
uniqueMember attribute of the groupOfUniqueNames class to determine
what groups they belong to. If your LDAP directory uses different classes or attribute settings for users and groups, you
must specify the class and attribute names as properties of deployment.ldap
. For example, the following
configuration identifies posixAccount and posixGroup as the classes
to use for users and groups, respectively:
deployment:
security:
enabled: true
provider: ldap
ldap:
server: ldaps://ldap.myorg.com
rootdn: "dc=ldaptest,dc=voltactivedata,dc=com"
userclass: posixAccount
useruid: uid
groupclass: posixGroup
groupmemberuid: memberuid"
user: "cn=admin,dc=ldaptest,dc=volt,dc=com"
password: secret.password
The goal of LDAP integration in VoltDB is to adapt to the customer's existing LDAP implementation, avoiding any changes to the schema wherever possible. So, for example, there are configuration options that allow VoltDB to access users and groups records defined in non-standard LDAP classes and objects. However, there is one requirement on the LDAP user objects:
The LDAP user records must include the SHA-256 hash of the user's password as an alternate password.
VoltDB never actually receives the password sent by the user at runtime in clear text. The client APIs hashes the password and sends the base-64 encoding of the SHA-256 hash instead. So Volt cannot pass on the actual password to LDAP. Instead it sends the SHA-256 hash. So, to be able to authenticate the user, LDAP must have the matching hash as one of the allowable passwords for the user. You can get the SHA-256 hash of a password using the shasum Linux utility. For example:
$ echo -n 'MyFavoritePasswrd' | shasum -a 256 238d59ddd7b0b8d54d3b8ff864855bcd332e66b1a06dad010f676a23d1928a68 -