Current File(s): conf/authn/password-authn-config.xml, conf/ldap.properties, conf/authn/ldap-authn-config.xml (V4.0), conf/authn/authn.properties (V4.1+)
Format: Native Spring
The LDAPCredentialValidator for the password authentication login flow uses native LDAP libraries for password-based authentication instead of using a JAAS module. The primary advantages are slightly better performance and more control over the process, such as the ability to extract detailed account status information from the directory during a login. One disadvantage is that JAAS configurations may be reloaded each time they're used, while the native configuration is static.
Configuring LDAP as a back-end relies on beans defined via an import in authn/password-authn-config.xml: Import in authn/password-authn-config.xml
The properties in ldap.properties do most of the work out of the box. Adding additional beans may be needed in very advanced cases where a higher degree of control is required. These beans also act as global defaults that can be overridden on specific instances of beans inheriting from shibboleth.LDAPValidator defined in authn/password-authn-config.xml in the shibboleth.authn.Password.Validators bean. In the simple case of LDAP used alone: Defining use of LDAP in password-authn-config.xml
If desired, it's possible to directly configure the various settings within the validator bean instead of or in addition to relying on the defaults. As an example, you could chain together multiple LDAP servers (rather than hoping the client library will do it for you) like this: Chaining LDAP validators
Note Regarding UpgradesThe ldap-authn-config.xml file has changed dramatically since V3 and is now very short, relying primarily on a special bean with a hidden parent definition taking a large set of properties that will generally auto-configure the proper objects.
One issue that does come up with the older file: the defaults around pooling validation in V3 were expressed numerically in seconds, and these numbers are interpreted in V4 as milliseconds. The proper syntax is really XML Duration syntax (PT5M == 5 minutes) and not numerically, but out of the box using the old file with V4 and not setting some of the pooling properties will result in dramatically frequent pool validation on the order of every half second. The logs will be very noisy so it's quite obvious. To correct this, either update to the V4 file (and define the new bean noted above), or change the property defaults in the old file, or actually set the properties themselves rather than leaving them commented. |
Configuring LDAP as a back-end relies on beans internally that are configured using ldap.properties (defined separately from other properties because they are sometimes shared for LDAPConnector configuration). Older releases included an authn/ldap-authn-config.xml file; this remains supported but is no longer required or provided. The properties in ldap.properties do most of the work out of the box. Adding additional beans may be needed in very advanced cases where a higher degree of control is required, and you are welcome to place them within authn/password-authn-config.xml. The properties act as global defaults that can be overridden on specific instances of beans inheriting from shibboleth.LDAPValidator defined in authn/password-authn-config.xml in the shibboleth.authn.Password.Validators bean. In the simple case of LDAP used alone: Defining use of LDAP in password-authn-config.xml
It's possible to directly configure the various settings within the validator bean instead of or in addition to relying on the defaults. Typically this involves injecting a bean based on shibboleth.LDAPAuthenticationFactory into the validator bean’s As an example, you could chain together multiple LDAP servers (rather than hoping the client library will do it for you) like this: Chaining LDAP validators
Note Regarding UpgradesThe ldap-authn-config.xml file from V3 has been removed, with the associated objects declared internally and using a large set of properties that will generally auto-configure the proper objects.
One issue that does come up with the older file: the defaults around pooling validation in V3 were expressed numerically in seconds, and these numbers are interpreted in V4 as milliseconds. The proper syntax is really XML Duration syntax (PT5M == 5 minutes) and not numerically, but out of the box using the old file with V4 and not setting some of the pooling properties will result in dramatically frequent pool validation on the order of every half second. The logs will be very noisy so it's quite obvious. To correct this, either remove the old file (and define the new bean noted above), or change the property defaults in the old file, or actually set the properties themselves rather than leaving them commented. |
The following sections describe how to configure a single instance of an LDAP CredentialValidator using the beans and properties that were available in V3 and are used by default in V4.
The idp.authn.LDAP.authenticator property controls the workflow for how authentication occurs against the LDAP directory for most “simple” cases by automatically configuring a number of underlying objects based on a set of built-in “authenticator types” supported by the ldaptive library.
anonSearchAuthenticator | Performs an anonymous search for the user's DN |
bindSearchAuthenticator | Binds with a configured DN as a service account, then searches for the user's DN |
directAuthenticator | User DNs are of a known format. i.e. CN=user_name,ou=accounts,dc=domain,dc=edu. No DN search is performed. |
adAuthenticator | Configuration that leverages the AD specific @domain.com format. No DN search is performed since AD supports binding directly with that user name. |
Depending on the choice above, various other properties must be set (see the reference section below).
Use the following properties to configure basic connection information for the LDAP directory:
idp.authn.LDAP.ldapURL
idp.authn.LDAP.useStartTLS
idp.authn.LDAP.connectTimeout
A connection pool is used, and there are several properties used to configure pool behavior (see the reference below).
If StartTLS or SSL are used, a source of trust anchors must be configured to control certificate validation, using the idp.authn.LDAP.sslConfig property:
certificateTrust | Uses the idp.authn.LDAP.trustCertificates property to load a resource containing the trust anchors (such as a file of PEM-format certificates) |
keyStoreTrust | Uses the idp.authn.LDAP.trustStore property to load a keystore containing the trust anchors |
jvmTrust | Uses the default JVM trust anchors (the JVM-wide "cacerts" file) |
We have tentative plans to deprecate the “jvmTrust” option, which has already been removed from the attribute resolution side of the software, as it is bad practice and has been a source of serious security flaws.
A number of properties are found in ldap.properties to configure LDAP authentication global defaults. Most of the time, this is sufficient to deal with most configurations without having to delve into modifying any beans, unless you're trying to chain together separately configured back-ends. Note that the big "override everything" hook tends to be the idp.authn.LDAP.authenticator property, as most of the other properties auto-configure specific aspects of one of the built-in Authenticator beans.
|
Properties can be used to configure all of the built-in beans used for this feature, so the only bean of relevance is below.
|
Note that for some advanced use cases, it may be necessary to dig deeply into the Ldaptive documentation and wire up custom objects using, or based on beans in the older V3 version of authn/ldap-authn-config.xml, ultimately installing an instance of org.ldaptive.auth.Authenticator into the "authenticator" property of a particular LDAPCredentialValidator bean. Most of the flexibility comes from all the various types of objects that can be injected into instances of the Authenticator class.
LDAP attributes are returned as part of the authentication process and exposed in the LDAPResponseContext.
By default, attributes will be searched for using the same connection the user authenticated on. Therefore the user must have read on any attributes for those to be returned. If you need access to attributes that user does not have read access to, then you must configure a connection pool that is authorized to read that data. The following configuration demonstrates how to add a new connection pool for that purpose. Spring Configuration
Add the idp.authn.LDAP.entryResolver.bindDN and idp.authn.LDAP.entryResolver.bindDNCredential properties to conf/ldap.properties and credentials/secrets.properties respectively. Then set idp.authn.LDAP.authenticator to anonSearchAuthenticator. to complete the configuration. Note: if you're using the bindSearchAuthenticator and those credentials can be reused for entry resolution, then this configuration can be shortened by wiring the bindPooledConnectionFactory to the entry resolver. |
Single Directory with Multiple BranchesExtensible MatchingIf your directory supports extensible matching, this is the easiest way to find users that are distributed over multiple branches.
Aggregate DN ResolverThis authenticator combines the results of multiple DN resolvers. Spring Configuration
Add the idp.authn.LDAP.baseDN[12] and idp.authn.LDAP.userFilter[12] properties to conf/ldap.properties. The key values used in dnResolvers and authHandlers can be anything, but must tie a single DN resolver to a single auth handler. By default an error will occur if more than (1) DN is resolved. In addition to these beans, the aggregateAuthenticator bean (in the example above) must be injected into the LDAP credential validator in password-authn-config.xml:
Multiple DirectoriesAggregate DN ResolverThis authenticator combines the results of multiple DN resolvers that connect to multiple directories. Spring Configuration
Complete example with DN resolvers and authentication handlers for bindSearch
DN resolvers are invoked asynchronously, so all resolvers will be used for each authentication request. |
The ldaptive LDAP library has the ability to extract detailed account status information from the directory during authentication. According to the Ldaptive documentation, no standard for exposing account state data has been universally adopted by LDAP vendors, but the library uses a handler which encapsulates account state information. This state contains Warning and Error types that are common to the most popular policy implementations. Password Policy ControlThe Password Policy for LDAP Directories (draft) standard is implemented by several LDAP directories, including OpenLDAP and Oracle DSEE. The Password Policy Control is used during an LDAP bind operation to request information about the user's account state. To enable the Password Policy Control handlers in ldaptive, add the following to conf/ldap.properties: conf/ldap.properties
The user will be informed on the login page if there are any Password Policy warnings or errors (messages can be customized in messages/messages.properties). Password expiration warnings have been confirmed to work with Oracle DSEE. Please notify us or edit this page if you test successfully with other directory products. Locked AccountsTo inform the user of a locked account, some configuration is needed to detect the error code returned by the LDAP bind request. In authn/password-authn-config.xml, add an entry to the message clasification rules defined by shibboleth.authn.Password.ClassifiedMessageMap password-authn-config.xml
This maps the error code to a AccountLocked event. It will run the empty user flow authn/conditions/account-locked and then pass control back to the form. With this configuration, the user gets the message "Your account is locked". Debug informationDetails of the AuthenticationResponse received, including the password policy controls, can be viewed using the TRACE log level in the logger of name "net.shibboleth.idp" (edit logback.xml). Active Directory ConfigurationThe system comes with definitions to configure Active Directory authentication response handlers against a single directory. Active Directory does not fully support extensible match rules (https://msdn.microsoft.com/en-us/library/cc223241.aspx). Active Directory (by default) does not support anonymous queries (https://technet.microsoft.com/en-us/library/Cc755809%28v=WS.10%29.aspx). Using an entry resolver to generate password expiration warningsSpring Configuration
Example for two Active Directories with two DN Resolvers for eachThis example uses directed BaseDN's with LDAP filters, and binds the queries. Spring Configuration
Add missing Active Directory account state errorsIf adAuthenticator is the authenticator set in the idp.authn.LDAP.authenticator property, Short Description values are contained in the response. If bindSearchAuthenticator is the authenticator set in the idp.authn.LDAP.authenticator property, HEX values are contained in the response. It is possible to use either or both as outlined in the following example. (http://ldapwiki.willeke.com/wiki/Common%20Active%20Directory%20Bind%20Errors ) password-authn-config.xml
messages/messages.properties
|