Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-8396

Extend depth of the heartbeat used between OpenAM<>LDAP to check a baseDN beyond the root DSE

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 14.0.0
    • Fix Version/s: None
    • Component/s: authentication, CTS, idrepo
    • Labels:
    • 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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              ian.packer Ian Packer [X] (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: