AD-bind-principal: New abstraction for ActiveDirectory LDAP auth

[Turbots]

Most use cases don't require another implementation than the standard
way of binding and searching for a user in Active Directory.

However, sometimes there is a different implementation needed
for creating the principal string for binding a user and the principal
string for searching a user.

The new abstract class basically contains the same methods
as the old final class and contains two abstract methods
for creating a bindPrincipal and searchPrincipal string, respectively.

The new abstract class allows for users to create a different
implementation according to their needs, based on the given
authentication token (or a subclass of the authentication token).

[Turbots]

I have signed and agree to the terms of the SpringSource Individual Contributor License Agreement.

[pivotal-issuemaster]

@Turbots Please sign the Contributor License Agreement!

[Turbots]

I have signed the (new?) contributor license agreement

[pivotal-issuemaster]

@Turbots Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@Turbots Thank you for signing the Contributor License Agreement!

[jgrandja]

Hi @Turbots. Thank you for submitting this PR !

This is definitely a feature users are asking for so we appreciate you submitting your proposal.

The AbstractActiveDirectoryLdapAuthenticationProvider implementation you provided will definitely allow the user to adapt the user/CN used for the bind operation as well will allow the same/different user/CN for the search operation.

I'm not sure if you had a chance to look at the other implementation of AbstractLdapAuthenticationProvider being LdapAuthenticationProvider?

This specific implementation uses the strategy LdapAuthenticator, for example, BindAuthenticator. I'm wondering if this strategy is the way to go for ActiveDirectoryLdapAuthenticationProvider?

An option would be to have a default implementation of LdapAuthenticator similar to the BindAuthenticator. It would either use the credentials from the incoming Authentication when authenticate() is called OR the credentials passed into the constructor at creation time. The latter option would suit the use case where the same 'system account' is used each time for the bind operation.

Furthermore, the LdapAuthenticator implementation could leverage a LdapUserSearch strategy for the search operation. The existing FilterBasedLdapUserSearch can be reused and it allows the user to provide a custom searchFilter.

What are your thoughts on this implementation strategy?

[jgrandja]

Thanks again for submitting this PR @Turbots.

We are currently re-thinking our approach to an Active Directory AuthenticationProvider implementation. Our direction is to deprecate ActiveDirectoryLdapAuthenticationProvider and leverage the existing LdapAuthenticationProvider and provide a custom strategy of LdapAuthenticator for Active Directory.

The work has already started in #4064 if you would like to track the progress and provide any input/feedback.

I'm going to close this PR as we will address your input/feedback in #4064.
Thank you.

[Turbots]

Thanks for the feedback! I'm glad to see people are continuing (or at least improving) upon my work 👍

I'll keep an eye on the new issue!