Spring-boot: Add LdapAutoConfiguration

[eddumelendez]

LDAP Support is missing... I think that it's time to add support for it.

[snicoll]

can you be a bit more specific?

[eddumelendez]

Adding property namespaces like spring.ldap.urls, spring.ldap.base, spring.ldap.username and spring.ldap.password we can get an instance of LdapTemplate

[philwebb]

I've marked this a waiting-for-votes. I'd be interested to hear from anyone else actively looking for LDAP support.

[eddumelendez]

PR already exist... I am waiting feedback :)

[philwebb]

@rwinch Any thoughts on adding LDAP support since you're the project lead?

[rwinch]

I think it makes sense to provide LDAP auto configuration in a similar way that we provide JDBC auto configuration. A basic outline of how I would see this working can be found below:

• If no ContextSource Bean is defined and Spring LDAP is on the classpath expose a ContextSource as a Bean
• Support for embedded ContextSource with ApacheDS on the classpath
• Configuration of the ContextSource through properties
• If no LdapOperations Bean is defined and Spring LDAP is on the classpath expose an LdapOperations as a Bean

NOTE: We would want to test to ensure this works well with Spring Security's LDAP module.

[wilkinsona]

I am _very_ wary about doing anything with ApacheDS. There are breaking API changes between 1.5.5 and 1.5.7 (the Platform is currently stuck on 1.5.5 because of this). I think we should think twice before lumbering Spring Boot with the same problem.

[rwinch]

@wilkinsona

Thanks for the feedback.

Do you have any insight as to why you feel avoiding ApacheDS / Boot support will help? In my experience, users are going to use ApacheDS for embedded LDAP regardless of if Spring Boot is automatically configuring it for them since Spring LDAP and Spring Security already support this. Additionally, as you mentioned, we must already support ApacheDS due to the platform, so we already need a known working version.

Finally, do you have a suggested alternative embedded LDAP instance we should support?

[wilkinsona]

The big difference between Boot and Spring LDAP and Spring Security is that Boot provides dependency management, i.e. we take (some) responsibility for which version of a dependency people will use.

Generally speaking, I'm vary wary of adding dependency management for anything that has fairly severe backwards compatibility problems between maintenance versions. For example, Spring LDAP does not compile against 1.5.6 (2 errors) or 1.5.7 (4 errors). The problem is that we run the risk of updating the dependency management in Boot to pick up a new maintenance release and unknowingly breaking people's applications. The alternative is to never change the version and to deal with requests for the version to be updated. Neither is ideal.

I don't have a suggestion for an alternative embedded LDAP instance. Perhaps we can update Spring LDAP and go with 1.5.7? Perhaps we should wait for Apache DS 2.0?

I'm not saying that we definitely shouldn't do something with ApacheDS, but that we need to be aware of what we're getting into.

[rwinch]

The big difference between Boot and Spring LDAP and Spring Security is that Boot provides dependency management, i.e. we take (some) responsibility for which version of a dependency people will use.

Don't we (the Spring Team) already have this problem with the platform? Isn't the platform maintaining the version? If so, I guess I don't see this as a new problem. Boot can track the version of the platform.

If users want an update, we can tell them it is broken in the future version and we are waiting on a fix.
If the updated version works for them, they can easily override the property and assume the risk of the breaking change.

I don't have a suggestion for an alternative embedded LDAP instance. Perhaps we can update Spring LDAP and go with 1.5.7?

I'm hesitant to make and update to Spring LDAP that might break previous versions of ApacheDS.

Do we have a bug logged with ApacheDS? Perhaps they would fix the problem. It seems like they would since AFAIK Apache projects follow pretty strict versioning guidelines.

[philwebb]

A third option (which would be somewhat unusual) is to add auto-configuration support but not add ApacheDS to spring-boot-dependencies. I'd still like to see a few more +1s before we add LDAP support.

[philwebb]

Another choice might be to add auto-configuration to Spring LDAP itself rather than making it a core part of Boot.

[wilkinsona]

Do we have a bug logged with ApacheDS? Perhaps they would fix the problem. It seems like they would since AFAIK Apache projects follow pretty strict versioning guidelines.

Not that I'm aware of. The 1.5.x line of Apache DS is no longer maintained (despite the fact that 2.0 isn't GA yet) so I doubt it's worth the effort. It's also another reason, IMO, not to include it in Boot's dependency management. Ideally, I'd remove it from the Platform too.

[eddumelendez]

IMO, since spring-boot provide dependency management is also offering an standard and ensuring that all the platform is working well. If any user make a change, it is under his own responsibility.
I am agree with @rwinch to support apacheds if the jar is in the classpath but the final decision is the spring team.

So, in order to do this contribution I would like to know the final thogughts to support LDAP? apacheds will be supported?

Thanks in advance for all your feedback.

[dsyer]

I think we should have LDAP and ApacheDS is the only viable inplementation AFAIK, so really it's more a question of how we can choose the right version. Spring LDAP might be able to shield is (and users) from stupid compatibility problems in ApacheDS? Can we reach out to them @rwinch?

[rwinch]

I think the first step is for me to better understand the compatibility problems. I will try to take a look at this shortly.

So I don't forget to address this, I'm going to assign this issue to me. Hopefully that is ok. If not, feel free to reassign to @dsyer

[wgorder]

I will +1 LDAP support.

[wilkinsona]

A further complication here is that Spring Security Kerberos uses ApacheDS 2.0 and doesn't work with Apache DS 1.5.x.

[anandchida]

+1 for LDAP auto-configuration

Can't this be independent of LDAP server implementation for server name, tls, binddn are common for all implementations to get a basic connection going. IS there anything specific to ApacheDS required for initial connection?

[rwinch]

@anandchida The reason it might make sense with ApacheDS is that we would know the connection information.

There is nothing specific to ApacheDS required for the initial connection. However, I'm not sure how we would provide LDAP connection configuration without knowing what the connection is.

Does this make sense?

[bonhamcm]

+1 for LDAP auto configuration.

[mmoayyed]

+1

I have always stayed away from apache DS. I much prefer unboundid. Much easier and more lightweight. CAS uses an embedded unboundid instance to run all ldap integration tests.

[eddumelendez]

Hi Everyone,

Since spring-ldap:2.1.0.RELEASE was released (spring-data hopper compatibility) and after a research to implement another embedded ldap server different than apacheds in the same project https://github.com/spring-projects/spring-ldap/pull/399. PR #2656 has been updated adding support to unboundid:ldap-sdk as a embedded server.

Let me know your thoughts about this. Thanks.

[jgoldhammer]

+1 for integrating it...

[philwebb]

@jgoldhammer (and anyone else that's watching) Would you mind using GitHub's new "add reaction" button for voting. It's much better for us because it keeps a running total and it doesn't generate so many emails. Thanks!

[snicoll]

@cmsandiga how about reading Phil's comment just above yours? Thanks.

[eddumelendez]

Closing this issue in favor of ldap-spring-boot

[jgoldhammer]

Ups, maybe this this the right reaction to the unknown and intransparent way how to get PRs into Spring boot. Who is responsible for all the PRs? How is the team internal process to accept PRs?

I think, this was an excellecent PR and @eddumelendez was willing to change according your needs. Would love to see a better and transparent process in the future...

[eddumelendez]

@jgoldhammer my fault because I've not explained why I've created another project but I talked with the spring boot team about this at SpringOne. Just to avoid a misunderstanding I think that @snicoll @philwebb or @rwinch can explain the reasons why the PR hasn't been merged.

Just to be clear, the project creation wasn't a way to complain about spring boot or the process, it's a way to contribute to open source.

[snicoll]

Thanks you @eddumelendez! I've added a reference to your starter in https://github.com/spring-projects/spring-boot/commit/7e9aa92f5c588235661f1bbe9b7cad15aeb88002

[philwebb]

@jgoldhammer

... the unknown and intransparent way how to get PRs into Spring boot.

I'm sorry that you feel the process isn't transparent, we try to be as open as possible with our feedback. We need to balance many items when we consider merging a pull-request. In this particular case the comment above by Andy sums up why we are so reluctant to merge this one.

Who is responsible for all the PRs? How is the team internal process to accept PRs?

Generally speaking we consider pull-requests on a case-by-case basis. Bug fixes and minor improvements are usually just merged by someone that has commit rights.

For larger bits of work we'll usually discuss it during our weekly team call to see if it we can foresee any problems, and then provide feedback. Don't forget that we're trying to balance the needs of individual developers with the long term health of the project. Everything that we merge (including our own work) has the potential to add complexity and could become a maintenance burden.

It's quite hard to always get the balance right when accepting new code, and I'm glad that @eddumelendez doesn't seem too upset with our decision. It would never be our intention to upset prolific and talented contributors such as Eddú!