[OPENAM-8396] Extend depth of the heartbeat used between OpenAM<>LDAP to check a baseDN beyond the root DSE Created: 19/Feb/16  Updated: 10/Oct/17

Status: Open
Project: OpenAM
Component/s: authentication, CTS, idrepo
Affects Version/s: 14.0.0
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Ian Packer [X] (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: AME
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Support Ticket IDs:

 Description   

There are a number of areas in OpenAM where a connection pool is maintained to one or more LDAP servers with a heartbeat mechanism (if enabled).

Currently the OpenDJ SDK is used for this mechanism and the heartbeat typically requires the following chain to succeed for the server to be considered 'up'.

CONNECT -> BIND -> SEARCH for RootDSE entry ("")

This is a fairly good indication of server health, but does not cover scenarios where a particular backend might be offline.

From an OpenAM perspective each connection pool is usually with a 'main' base DN. e.g the base container for a userstore, the config base DN or the CTS base DN.

If the heartbeat search was modified to optionally allowing checking the baseDN of interest, depending on the context, this would give a stronger server 'up' indication.

Looking at the existing implementation, the OpenDJ SDK already allows a 'HEARTBEAT_SEARCH_REQUEST' to be specified on a heartbeat connection. Currently this is not set, and the default is used:

DEFAULT_HEARTBEAT = Requests.unmodifiableSearchRequest(Requests.newSearchRequest("", SearchScope.BASE_OBJECT, "(objectClass=*)", new String[]{"1.1"}));

OpenAM could override this when creating the connection pool. However, since the current LDAPUtils.newConnectionFactory() methods (for example) do not have any knowledge of baseDNs the challenge may be getting this information down to this layer of abstraction, for all the different scenarios, in a clean way and without breaking any APIs.


Generated at Mon Sep 21 15:09:56 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.