Using Clarity LIMS with your LDAP Server

If you use, or would like to use, an LDAP server to consolidate directory services, it is possible to integrate LDAP with BaseSpace Clarity LIMS.

The Clarity LIMS LDAP solution allows for the following features:

• Username and password authentication against LDAP to govern access to Clarity LIMS.
• Ongoing unidirectional synchronization of user information (such as first name, last name, title, phone, fax, and email) from LDAP to Clarity LIMS. For example, if your telephone number is changed in the LDAP directory, the information is pushed down to Clarity LIMS, keeping contact information current.
• Automated unidirectional provisioning of user accounts from LDAP to Clarity LIMS. For example, adding a user to a particular group within the LDAP directory automatically results in a local account with LDAP authentication being added to Clarity LIMS.

Our Field Application Specialist (FAS) team meets with you to discuss the current LDAP implementation. In preparation for this meeting, collect the following information:

• The type of provisioning to use for synchronizing Clarity LIMS with LDAP (automatic or manual).
• A list of the LDAP attributes the current system uses to record the following user properties: first name, last name, title, phone number, fax number, and email address.

When integrating Clarity LIMS with LDAP, the LIMS database and the LDAP directory remain as separate and distinct entities.

Clarity LIMS is tested with the following LDAP servers:

• ApacheDS 1.5 and later
• Microsoft Active Directory (Windows Server 2003 or later)
• OpenLDAP 2.3.35 and later

While user provisioning and authentication are handled with LDAP, a Clarity LIMS system administrator completes the following steps:

1. Determine the level of access required.
2. Modify the user account within Clarity LIMS to provide that access.

After an LDAP integration with Clarity LIMS is established, all changes to user profiles must be made from the LDAP server.

Only automatic user provisioning is available.

With automatic user provisioning, Clarity LIMS users are created automatically by a provisioning tool that periodically synchronizes the LDAP server with the LIMS.

To make use of the LDAP directory services, Clarity LIMS maps to specific LDAP attributes within a defined schema.

However, the directory structure used can vary among installations. Our Field Applications Specialist (FAS) team work with you to complete the following items:

• Analyze a specific LDAP solution and directory organization or assist with the selection and initial configuration of an LDAP service.
• Discuss the user elements that to synchronize between the LDAP service and Clarity LIMS systems.
• Configure LDAP to connect to your Clarity LIMS systems.

User authentication is handled in Clarity LIMS.

In previous versions of Clarity LIMS, a few customers reported slow response time for the REST API when using LDAP users for authentication. As of Clarity LIMS v5.2.x / v4.3.x, the REST API response time has improved by introducing a new feature that caches user authentication results through a new property (api.session.timeout).

To make use of the new feature, do the following actions:

• Make sure that api.session.timeout property is set.
• Include the HTTP Connection and Authorization request headers and session cookie in the HTTP request.

Stored in the Clarity LIMS database table, the api.session.timeout property allows you to specify how long a user session should persist, after they have been authenticated.

This property is set during installation or upgrade of Clarity LIMS. The default value is 5 minutes.

If necessary, update the value using the omxprops-ConfigTool.jar tool at the following location:

/opt/gls/clarity/tools/propertytool

For example:

$ java -jar /opt/gls/clarity/tools/propertytool/omxprops-ConfigTool.jar

set -y api.session.timeout '15'

For this configuration to take effect, stop and restart Tomcat:

service clarity_tomcat stop

service clarity_tomcat start

To persist user authentication, the HTTP request must contain the following HTTP request headers:

• Request HeaderConnection: Keep-Alive
– Authorization: Basic <credentials>

The HTTP request headers are required for the initial request and for any subsequent request to get a valid JSESSIONID. Additional scenarios are described in the following table.

To make sure that a valid authenticated session is provided if the cookie in the request has expired, also provide the following JSESSIONID cookie:

• CookieJSESSIONID=<a valid JSESSIONID from the initial request>

The following table lists the various combinations of HTTP Authorization request header and JSESSIONID cookie and their expected result. It assumes that the HTTP Connection request header is provided for all scenarios.

Clarity LIMS version

Authorization

JSESSIONID

Expected Result

v5.0.x and v5.1.x

Present

Absent

Open API performs the user authentication depending on whether the account is in the database or LDAP server, and responds with requested resources.

v5.2.x and later, and v4.3.x

 

Present

Present (Valid)

Open API does not perform the user authentication and responds with requested resources.

Present

Present (Invalid)

Open API performs the user authentication depending on whether the account is in the database or LDAP server, and responds with requested resources.

Absent

Present (Valid)

Open API does not perform the user authentication and responds with requested resources.

Absent

Present (Invalid)

Open API responds with HTTP Status 401 - Unauthorized.

Absent

Absent

Open API responds with HTTP Status 401 - Unauthorized.