LDAP Service Registry

Service registry implementation which stores the services in a LDAP Directory and attempts to map service records to LDAP entries in order to configure settings for retrieval, search and persistence of service definitions. By default, entries are assigned the objectclass that is casRegisteredService attribute and are looked up by the uid attribute.

Support is enabled by adding the following module into the overlay:

implementation "org.apereo.cas:cas-server-support-ldap-service-registry:${project.'cas.version'}"
<dependency>
  <groupId>org.apereo.cas</groupId>
  <artifactId>cas-server-support-ldap-service-registry</artifactId>
  <version>${cas.version}</version>
</dependency>
dependencyManagement {
  imports {
    mavenBom "org.apereo.cas:cas-server-support-bom:${project.'cas.version'}"
  }
}

dependencies {  
  implementation "org.apereo.cas:cas-server-support-ldap-service-registry"
}

Configuration

The default mapper has support for the following optional items:

Field Default Value
objectClass casRegisteredService
serviceDefinitionAttribute description
idAttribute uid

Service definitions are by default stored inside the serviceDefinitionAttribute attribute as JSON objects. The format and syntax of the JSON is identical to that of JSON Service Registry. That’s all, as far as the schema goes.

The following settings and properties are available from the CAS configuration catalog:

The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.

  • cas.service-registry.ldap.base-dn=
  • Base DN to use. There may be scenarios where different parts of a single LDAP tree could be considered as base-dns. Rather than duplicating the LDAP configuration block for each individual base-dn, each entry can be specified and joined together using a special delimiter character. The user DN is retrieved using the combination of all base-dn and DN resolvers in the order defined. DN resolution should fail if multiple DNs are found. Otherwise the first DN found is returned. Usual syntax is: subtreeA,dc=example,dc=net|subtreeC,dc=example,dc=net.

  • cas.service-registry.ldap.bind-credential=
  • The bind credential to use when connecting to LDAP.

  • cas.service-registry.ldap.bind-dn=
  • The bind DN to use when connecting to LDAP. LDAP connection configuration injected into the LDAP connection pool can be initialized with the following parameters:

    • bindDn/bindCredential provided - Use the provided credentials to bind when initializing connections.
    • bindDn/bindCredential set to * - Use a fast-bind strategy to initialize the pool.
    • bindDn/bindCredential set to blank - Skip connection initializing; perform operations anonymously.
    • SASL mechanism provided - Use the given SASL mechanism to bind when initializing connections.

  • cas.service-registry.ldap.ldap-url=
  • The LDAP url to the server. More than one may be specified, separated by space and/or comma.

  • cas.service-registry.ldap.search-filter=
  • User filter to use for searching. Syntax is cn=user or cn=0. You may also provide an external groovy script in the syntax of file:/path/to/GroovyScript.groovy to fully build the final filter template dynamically.

    The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.

  • cas.service-registry.ldap.allow-multiple-dns=false
  • Whether search/query results are allowed to match on multiple DNs, or whether a single unique DN is expected for the result.

  • cas.service-registry.ldap.allow-multiple-entries=false
  • Set if multiple Entries are allowed.

  • cas.service-registry.ldap.binary-attributes=
  • Indicate the collection of attributes that are to be tagged and processed as binary attributes by the underlying search resolver.

  • cas.service-registry.ldap.block-wait-time=PT3S
  • The length of time the pool will block. By default the pool will block indefinitely and there is no guarantee that waiting threads will be serviced in the order in which they made their request. This option should be used with a blocking connection pool when you need to control the exact number of connections that can be created

  • cas.service-registry.ldap.connect-timeout=PT5S
  • Sets the maximum amount of time that connects will block.

  • cas.service-registry.ldap.connection-strategy=
  • If multiple URLs are provided as the ldapURL this describes how each URL will be processed.

    • ACTIVE_PASSIVE First LDAP will be used for every request unless it fails and then the next shall be used.
    • ROUND_ROBIN For each new connection the next url in the list will be used.
    • RANDOM For each new connection a random LDAP url will be selected.
    • DNS_SRV LDAP urls based on DNS SRV records of the configured/given LDAP url will be used.

  • cas.service-registry.ldap.disable-pooling=false
  • Whether to use a pooled connection factory in components.

  • cas.service-registry.ldap.fail-fast=true
  • Attempt to populate the connection pool early on startup and fail quickly if something goes wrong.

  • cas.service-registry.ldap.follow-referrals=true
  • Set if search referrals should be followed.

  • cas.service-registry.ldap.hostname-verifier=
  • Hostname verification options. Available values are as follows:

    • DEFAULT: Default option, forcing verification.
    • ANY: Skip hostname verification and allow all.

  • cas.service-registry.ldap.id-attribute=uid
  • ID attribute used for the registered service entry in LDAP to keep track of the service numeric identifier.

  • cas.service-registry.ldap.idle-time=PT10M
  • Removes connections from the pool based on how long they have been idle in the available queue. Prunes connections that have been idle for more than the indicated amount.

  • cas.service-registry.ldap.keystore=
  • Path to the keystore used for SSL connections. Typically contains SSL certificates for the LDAP server.

  • cas.service-registry.ldap.keystore-password=
  • Keystore password.

  • cas.service-registry.ldap.keystore-type=
  • The type of keystore. PKCS12 or JKS. If left blank, defaults to the default keystore type indicated by the underlying Java platform.

  • cas.service-registry.ldap.load-filter=(objectClass=%s)
  • The load filter used to load entries by the #objectClass. This is typically used to load all definitions that might be mapped to a service definition. The search filter used to load entries by the #idAttribute. This is typically used to load a specific service definition by its id during search operations.

  • cas.service-registry.ldap.max-pool-size=10
  • Maximum LDAP connection pool size which the pool can use to grow.

  • cas.service-registry.ldap.min-pool-size=3
  • Minimum LDAP connection pool size. Size the pool should be initialized to and pruned to

  • cas.service-registry.ldap.name=
  • Name of the LDAP handler.

  • cas.service-registry.ldap.object-class=casRegisteredService
  • Object class used for the registered service entry in LDAP.

  • cas.service-registry.ldap.page-size=0
  • Request that the server return results in batches of a specific size. See RFC 2696. This control is often used to work around server result size limits. A negative/zero value disables paged requests.

  • cas.service-registry.ldap.pool-passivator=BIND
  • You may receive unexpected LDAP failures, when CAS is configured to authenticate using DIRECT or AUTHENTICATED types and LDAP is locked down to not allow anonymous binds/searches. Every second attempt with a given LDAP connection from the pool would fail if it was on the same connection as a failed login attempt, and the regular connection validator would similarly fail. When a connection is returned back to a pool, it still may contain the principal and credentials from the previous attempt. Before the next bind attempt using that connection, the validator tries to validate the connection again but fails because it’s no longer trying with the configured bind credentials but with whatever user DN was used in the previous step. Given the validation failure, the connection is closed and CAS would deny access by default. Passivators attempt to reconnect to LDAP with the configured bind credentials, effectively resetting the connection to what it should be after each bind request. Furthermore if you are seeing errors in the logs that resemble a 'Operation exception encountered, reopening connection' type of message, this usually is an indication that the connection pool’s validation timeout established and created by CAS is greater than the timeout configured in the LDAP server, or more likely, in the load balancer in front of the LDAP servers. You can adjust the LDAP server session’s timeout for connections, or you can teach CAS to use a validity period that is equal or less than the LDAP server session’s timeout. Accepted values are:

    • NONE: No passivation takes place.
    • BIND: The default behavior which passivates a connection by performing a bind operation on it. This option requires the availability of bind credentials when establishing connections to LDAP.

  • cas.service-registry.ldap.prune-period=PT2H
  • Removes connections from the pool based on how long they have been idle in the available queue. Run the pruning process at the indicated interval.

  • cas.service-registry.ldap.response-timeout=PT5S
  • Duration of time to wait for responses.

  • cas.service-registry.ldap.sasl-authorization-id=
  • SASL authorization id.

  • cas.service-registry.ldap.sasl-mechanism=
  • The SASL mechanism.

  • cas.service-registry.ldap.sasl-mutual-auth=
  • SASL mutual auth is enabled?

  • cas.service-registry.ldap.sasl-quality-of-protection=
  • SASL quality of protected.

  • cas.service-registry.ldap.sasl-realm=
  • The SASL realm.

  • cas.service-registry.ldap.sasl-security-strength=
  • SASL security strength.

  • cas.service-registry.ldap.search-entry-handlers=
  • Search handlers.

  • cas.service-registry.ldap.service-definition-attribute=description
  • Service definition attribute used for the registered service entry in LDAP to keep a representation of the service body.

  • cas.service-registry.ldap.subtree-search=true
  • Whether subtree searching is allowed.

  • cas.service-registry.ldap.trust-certificates=
  • Path of the trust certificates to use for the SSL connection. Ignores keystore-related settings when activated and used.

  • cas.service-registry.ldap.trust-manager=
  • Trust Manager options. Trust managers are responsible for managing the trust material that is used when making LDAP trust decisions, and for deciding whether credentials presented by a peer should be accepted. Accepted values are: *

    • DEFAULT: Enable and force the default JVM trust managers.
    • ANY: Trust any client or server.

  • cas.service-registry.ldap.trust-store=
  • Path to the keystore used to determine which certificates or certificate authorities should be trusted. Used when connecting to an LDAP server via LDAPS or startTLS connection. If left blank, the default truststore for the Java runtime is used.

  • cas.service-registry.ldap.trust-store-password=
  • Password needed to open the truststore.

  • cas.service-registry.ldap.trust-store-type=
  • The type of trust keystore that determines which certificates or certificate authorities are trusted. Types depend on underlying java platform, typically PKCS12 or JKS. If left blank, defaults to the default keystore type indicated by the underlying Java platform.

  • cas.service-registry.ldap.use-start-tls=false
  • Whether TLS should be used and enabled when establishing the connection.

  • cas.service-registry.ldap.validate-on-checkout=true
  • Whether connections should be validated when loaned out from the pool.

  • cas.service-registry.ldap.validate-period=PT5M
  • Period at which pool should be validated.

  • cas.service-registry.ldap.validate-periodically=true
  • Whether connections should be validated periodically when the pool is idle.

  • cas.service-registry.ldap.validate-timeout=PT5S
  • Period at which validation operations may time out.

  • cas.service-registry.ldap.search-entry-handlers[0].case-change.attribute-name-case-change=
  • The Attribute name case change.

  • cas.service-registry.ldap.search-entry-handlers[0].case-change.attribute-names=
  • The Attribute names.

  • cas.service-registry.ldap.search-entry-handlers[0].case-change.attribute-value-case-change=
  • The Attribute value case change.

  • cas.service-registry.ldap.search-entry-handlers[0].case-change.dn-case-change=
  • The Dn case change.

  • cas.service-registry.ldap.search-entry-handlers[0].dn-attribute.add-if-exists=
  • The Add if exists.

  • cas.service-registry.ldap.search-entry-handlers[0].dn-attribute.dn-attribute-name=entryDN
  • The Dn attribute name.

  • cas.service-registry.ldap.search-entry-handlers[0].merge-attribute.attribute-names=
  • The Attribute names.

  • cas.service-registry.ldap.search-entry-handlers[0].merge-attribute.merge-attribute-name=
  • The Merge attribute name.

  • cas.service-registry.ldap.search-entry-handlers[0].primary-group-id.base-dn=
  • The Base dn.

  • cas.service-registry.ldap.search-entry-handlers[0].primary-group-id.group-filter=(&(objectClass=group)(objectSid={0}))
  • The Group filter.

  • cas.service-registry.ldap.search-entry-handlers[0].recursive.merge-attributes=
  • The Merge attributes.

  • cas.service-registry.ldap.search-entry-handlers[0].recursive.search-attribute=
  • The Search attribute.

  • cas.service-registry.ldap.search-entry-handlers[0].type=
  • The type of search entry handler to choose. Available values are as follows:

    • OBJECT_GUID: Object guid search entry handler. Handles the objectGUID attribute fetching and conversion.
    • OBJECT_SID: Object sid search entry handler. Handles the objectSid attribute fetching and conversion.
    • CASE_CHANGE: Case change search entry handler. Provides the ability to modify the case of search entry DNs, attribute names, and attribute values.
    • DN_ATTRIBUTE_ENTRY: DN attribute entry handler. Adds the entry DN as an attribute to the result set. Provides a client side implementation of RFC 5020.
    • MERGE: Merge search entry handler. Merges the values of one or more attributes into a single attribute.
    • PRIMARY_GROUP: Primary group search handler. Constructs the primary group SID and then searches for that group and puts it's DN in the 'memberOf' attribute of the original search entry.
    • RANGE_ENTRY: Range entry search handler. Rewrites attributes returned from Active Directory to include all values by performing additional searches.
    • RECURSIVE_ENTRY: Recursive entry search handler. This recursively searches based on a supplied attribute and merges those results into the original entry.

  • cas.service-registry.ldap.validator.attribute-name=objectClass
  • Attribute name to use for the compare validator.

  • cas.service-registry.ldap.validator.attribute-value=top
  • Attribute values to use for the compare validator.

  • cas.service-registry.ldap.validator.base-dn=
  • Base DN to use for the search request of the search validator.

  • cas.service-registry.ldap.validator.dn=
  • DN to compare to use for the compare validator.

  • cas.service-registry.ldap.validator.scope=OBJECT
  • Search scope to use for the search request of the search validator.

  • cas.service-registry.ldap.validator.search-filter=(objectClass=*)
  • Search filter to use for the search request of the search validator.

  • cas.service-registry.ldap.validator.type=search
  • Determine the LDAP validator type. The following LDAP validators can be used to test connection health status:

    • search: Validates a connection is healthy by performing a search operation. Validation is considered successful if the search result size is greater than zero.
    • none: No validation takes place.
    • compare: Validates a connection is healthy by performing a compare operation.