Current File(s): conf/authn/password-authn-config.xml, conf/ldap.properties, conf/authn/authn.properties
Format: Native Spring, Properties
...
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).
...
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) |
disabled | Does not allow SSL or startTLS connections. |
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.
...
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.
|
...
Expand | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||
LDAP attributes are returned as part of the authentication process and exposed in the LDAPResponseContext. (As noted in the Properties reference above, this feature is not supported by the adAuthenticator. If you set it, it will result in a WARN message in the logs for each authentication attempt.)
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 easiest way to that is to use the 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. |
Expand | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||
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. |
...