LDAP

The Lightweight Directory Access Protocol (LDAP) is an application protocol for accessing and maintaining distributed directory information services over an IP network. Directory services may provide any organized set of records, often with a hierarchical structure. The usage referred to here is the authentication of user records.

Defining the LDAP Profile
To authenticate users in LDAP, an external system profile must be defined. Only one LDAP profile can be defined for an institution. Following is a list of the decisions that must be taken when defining a profile:

1.  LDAP server – It is currently possible to define up to five LDAP servers which will be searched in sequential order until a user is authenticated. Each of these servers must be active and open for the Alma client. For information on the ports that should be opened, refer to Alma OLH.

The following command may be used to ensure that the LDAP server is up:

ldapsearch -LLL -h <LDAP server host> -p <LDAP server port> -D <initial bind user> -w <initial bind password> -b <search base> uid=<specific user name>

This command should retrieve all entries on the given host machine, using the given port, searching in the given base for the given user, using the initial bind password.

For each of the five LDAP servers, the following should be specified:

• the host name and port of the LDAP server

• that the communication between Alma and LDAP should be performed using SSL

NOTE: SSL connections must be secured with a certificate issued by a recognized certificate authority. See the list here.

• whether the communication between Alma and LDAP should be done using Transport Layer Security (TLS). Note that this requires LDAP version 3 or later.

• the connection timeout (If not specified, the default is 60000 or one minute.)

• the initial bind DN

• the initial bind password

• the DN for binding before each search. Use this parameter to specify the DN when you want to use dynamic password binding instead of a hard-coded password for the initial bind.

• whether response encoding is required. This setting is used to encode the LDAP response before sending it back to the calling application. The only possible value is UTF8.

2. Search bases and filters – The user record is searched in the LDAP tree, based on the search base and search filter. For each of the five defined LDAP servers, it is possible to define up to five bases and filters. If the results of the search base/search filter are not unique (or a zero-size result), the search step is repeated for the next provided search base/search filter.

Following is an example of a search base and search filter for querying the LDAP server. The search base defines the LDAP base to be searched and the search filter defines the LDAP user.

Search base: o= City University, st=New York ,c=US Search filter: uid=johndoe

In the above example, if a user named johndoe is trying to log in to Alma, the LDAP server is searched on the base City University, filtering the results by uid= johndoe.
NOTE: The filter syntax can be any of the following: uid=, uid, or uid=USERNAME. In all three of these cases, Alma searches for uid=<the entered login user name>.

3. Match ID – For each of the five defined LDAP servers, the LDAP user needs to be mapped to a user that Alma recognizes. One of the user attributes that is returned by LDAP should be used as a matching point in Alma.
   In order to authenticate users with LDAP, they must have an identifier, unique cross-institution, that matches this attribute. This identifier can be the primary identifier, or any other identifier that is unique cross-institution.

For example, the LDAP code can return:

sn: Orange

cn: Becky Orange

mailLocalAddress: becky.orange@exlibris.co.il

PortalName: EBSCO

If the cn attribute is defined as a matching point, a user in Alma with the Becky Orange identifier should exist. If a user is authenticated in LDAP, but no matching user is found in Alma, the user is logged in, but has permissions to access the default areas only.
For further details on configuring the LDAP profile, see  Alma OLH.

The LDAP authentication workflow is illustrated in the following diagram: