LDAPConnector
Namespace: urn:mace:shibboleth:2.0:resolver
Schema: http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd
Overview
The LDAPDirectory
data connector generates one or more attributes based on a query to an LDAP directory.
The underlying library used for this is called ldaptive, and many of the more advanced options are usable only by referring to its documentation, but most deployers should be able to make to do with the information we supply.
General Configuration
The IdP ships with an example configuration file (conf/examples/attribute-resolver-ldap.xml), that demonstrates property-driven attribute resolution, using the properties defined in ldap.properties, much of which can be shared with the LDAP Authentication Configuration for the common case of a single LDAP directory used for both authentication and attributes. You can freely mix use of properties with explicit settings.
If execution of the query returns multiple results, these are merged by default.
The following properties are demonstrated. They take their defaults from the values of the similarly-named authentication properties, but can be explicitly set to split them off as needed.
Property | Type | Default Authn Property | Function |
---|---|---|---|
idp.attribute.resolver.LDAP.ldapURL | URL | idp.authn.LDAP.ldapURL | Connection URL for the LDAP directory |
idp.attribute.resolver.LDAP.baseDN | String | idp.authn.LDAP.baseDN | Base DN to search against, |
idp.attribute.resolver.LDAP.bindDN | String | idp.authn.LDAP.bindDN | DN to bind as before performing the search |
idp.attribute.resolver.LDAP.bindDNCredential | String | idp.authn.LDAP.bindDNCredential | Password to bind with before performing the search |
idp.attribute.resolver.LDAP.useStartTLS | Boolean | idp.authn.LDAP.useStartTLS (defaults true) | Whether StartTLS should be used immediately after connecting to the LDAP |
idp.attribute.resolver.LDAP.trustCertificates | Resource | idp.authn.LDAP.trustCertificates | A resource to load trust anchors from, usually a local file in %{idp.home}/credentials |
idp.attribute.resolver.LDAP.connectTimeout | Duration | idp.authn.LDAP.connectTimeout (defaults PT3S) | Connection timeout in milliseconds |
idp.attribute.resolver.LDAP.responseTimeout | Duration | idp.authn.LDAP.responseTimeout (defaults PT3S) | Time to wait for an LDAP response (Applies to every request except startTLS) |
idp.attribute.resolver.LDAP.connectionStrategy | Enumeration | ACTIVE_PASSIVE | Connection strategy to use when multiple URLs are supplied, one of ACTIVE_PASSIVE, ROUND_ROBIN, RANDOM |
TLS Validation Configuration
Assuming either LDAP-over-TLS (ldaps) or StartTLS are used, you MUST configure the rules for validating the LDAP server's TLS key within the connector.
There are generally two ways to do this:
Reference a CA (Certificate Authority) that has signed the certificate chain presented by the LDAP server.
Reference the LDAP server's certificate explicitly.
The latter provides better security but likely will require constant updating and coordination with the LDAP server's operational staff unless it relies on a longer-lived certificate.
You may configure multiple certificates by concatenating PEM formatted certificates together.
You reference the certificate(s) you choose to trust by setting the trustFile
XML attribute inside the <DataConnector>
element, and the example below passes that through to a property you can configure separately, but that's purely a matter of style.
Note that this is distinct from configuring the IdP to authenticate itself to the LDAP server with a certificate. That relies on a different set of options (authKey
, authCert
).