Authenticating user credentials

For the first step, authentication against the LDAP directory, a custom authentication provider is wired into AuthenticationManager. The o.s.s.ldap.authentication.LdapAuthenticationProvider interface takes the user's provided credentials and verifies them against the LDAP directory, as illustrated in the following diagram:

We can see that the o.s.s.ldap.authentication.LdapAuthenticator interface defines a delegate to allow the provider to make the authentication request in a customizable way. The implementation that we've implicitly configured to this point, o.s.s.ldap.authentication.BindAuthenticator, attempts to use the user's credentials to bind (log in) to the LDAP server as if it were the user themselves making a connection. For an embedded server, this is sufficient for our authentication needs; however, external LDAP servers may be stricter, and in these, users may not be allowed to bind to the LDAP directory. Fortunately, an alternative method of authentication exists, which we will explore later in this chapter.

As noted in the preceding diagram, keep in mind that the search is performed under an LDAP context created by the credentials specified in the DefaultSpringSecurityContextSource reference's baseDn attribute. With an embedded server, we don't use this information, but with an external server reference, unless baseDn is supplied, anonymous binding is used. Retaining some control over the public availability of information in the directory is very common for organizations which require valid credentials to search an LDAP directory, and as such, baseDn will be almost always required in real-world scenarios. The baseDn attribute represents the full DN of a user with valid access to bind the directory and perform searches.