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 <security> element of the VoltDB
configuration file. The following is an example configuration file that illustrates all of the available LDAP
configuration options.
<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"/>
<group name="cn=zeroes,dc=ldaptest,dc=volt,dc=com" role="user"/> <ssl> <truststore path="/my/ssl/ldap/truststore.jks"
password="trustpasswd"/> </ssl> </ldap> </security> <users> <user name="houdini" password="shazam" roles="administrator" />
</users>
| Enabling LDAP security — To enable LDAP integration, you must set the
|
| LDAP server address — The location of the LDAP server, using either plain
("ldap://") or secure ("ldaps://") LDAP protocol. Secure LDAP is recommended. But if you use secure LDAP, you must
also provide the TLS/SSL credentials ( |
| Root domain name — The LDAP domain containing both the user and group objects needed for Volt access. |
| Timeout (OPTIONAL) — The timeout period, in seconds, to wait for a response from the LDAP server. After the timeout expires with no response from the LDAP server, the authentication of the user will fail. The default timeout is 10 seconds. |
| LDAP privileged account (username and password) — The username and password of an LDAP account that has read-only access to the specified root domain. This account is used to search the domain for the specified username and the groups of which that user is a member. You can mask the password for the LDAP account so it does not appear in plain text in the configuration file using the voltdb mask command. |
| LDAP group ➞ Volt role mapping — The mapping of LDAP group names to Volt
roles. The roles themselves are defined in the database schema. Each |
| TLS/SSL credentials — The |
| Local administrator's account — There must be at least one local user account with administrative privileges defined in the configuration. This account provides access to the database in case the LDAP server is not reachable. You can define other local accounts if you wish. When a user attempts to access the server, Volt looks for the username in the local accounts first; if no local account with that username exists, it then passes the credentials on to LDAP for authentication and authorization. |
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 attributes of the <ldap> element.
For example, the following configuration identifies posixAccount and
posixGroup as the classes to use for users and groups, respectively:
Documentation<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 -