LDAP Integration
If you use, or would like to use, an LDAP server to consolidate directory services, it is possible to integrate LDAP with Clarity LIMS.
The Clarity LIMS LDAP solution allows for the following features:
User name 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.
Providing Information about your LDAP Implementation
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 you would like to use to synchronize 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 e‐mail address.
NOTE: When integrating Clarity LIMS with LDAP, the LIMS database and the LDAP directory remain as separate and distinct entities.
Supported LDAP Servers
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
Access and Changes
While user provisioning and authentication are handled with LDAP, a Clarity LIMS system administrator completes the following steps:
Determine the level of access that a user requires.
Modify the userʹs account within the LIMS to provide that access.
Once an LDAP integration with Clarity LIMS is established, all changes to user profiles must be made from the LDAP server.
Provisioning Users
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 will be synchronized between the LDAP service and Clarity LIMS systems.
Configure LDAP to connect to your Clarity LIMS systems.
Caching User Authentication Results from your LDAP Server
User authentication is handled in the 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 & Authorization request headers and session cookie in the HTTP request.
Setting the api.session.Timeout Property
Stored in the Clarity LIMS database table, the api.session.timeout property allows you to specify the period of time for which a user's session should persist, after they have been authenticated.
This property is set during installation or upgrade of the LIMS. The default value is 5 minutes. If necessary, update the value using the omxprops-ConfigTool.jar tool at the following location:
For example:
For this configuration to take effect, stop and restart Tomcat:
Including the HTTP Authorization Request Header and Session Cookie
To persist user authentication, the HTTP request must contain the following HTTP request headers:
Request Header
Connection: 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:
Cookie
JSESSIONID=<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.
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.
Last updated
Was this helpful?