Lou Sacco(Migrated from SEC-871) said:
It would be nice to have the ability to define an LDAP server through JNDI or a Realm rather than explicitly defining the attributes much like you can do with a data source using Spring’s data source wrapper. This would provide for better portability of the WAR and security of the passwords.
Luke Taylor said:
Could you expand a bit on what you’re asking for here?
DataSource lookups in JNDI will resolve to a javax.sql.DataSource but the ldap-server element creates a Spring LDAP ContextSource based on its configuration, so there isn’t a direct relationship between the two. Likewise, I’m not aware of a container-agnostic concept of a “realm”. Many containers use the term to refer to a security configuration – whether for LDAP or something else.
Lou Sacco said:
In other words, if you could externalize the settings you currently have in ldap-server (such as url, admin-dn, password), that would be ideal. Perhaps leveraging what you guys already have done in the adapters package to accommodate the various server. In that case you could inject a reference of a bean that could pull the realm (in the case of Tomcat) to pull the stuff that ldap-server needs.
I can’t really see much benefit in this considering the amount of work (and container-specific maintenance) that would be required. It would only be of value where the container was already being used for authentication – otherwise you would be setting up a tomcat realm purely to be able to use your Spring Security LDAP configuration.
The use of container-specific beans would make your WAR non-portable and there is no standard way of working out what the container configuration actually contains. Instead you could just use a PropertyPlaceholderConfigurer to externalise the LDAP properties and the rest of the configuration would remain the same. Another option might be to use Spring’s JMX integration to expose the ContextSource as an MBean.
A basic JMX configuration might look like:
Then start with java -Dcom.sun.management.jmxremote
to test the setting of password, Url etc. through the MBean.
I shouldn’t need to do a JMX configuration to externalize the LDAP server configuration. Having to code the server, admin DN, and password in a Spring configuration is non-portable and should be externalized through the container, just like you would any other container based resource. The reason for this is because of promotion through various environments where your LDAP server will most certainly change from DEV to TEST to PROD. This aspect of portability is much more important to me.
Of course I can work around this through commons-configuration, which is much cleaner than JMX in my opinion, but it would be a nice-to-have through the configuration. Your consideration for a feature like this maybe in some future release would be appreciated but I can appreciate the difficulty in implementing this without a generic way to abstract the LDAP configuration.
I don’t really see how to go about implementing what you appear to be asking for – i.e. the ability to read container configuration data for LDAP realms etc in a portable way. In fact, I doubt if it’s possible. Most containers are architected so that things like security realms are not accessible to applications. If you think it can be done then feel free to submit a patch.
If you are just interested in externalizing configuration properties which may vary across different deployments, then that’s not something that is specific to Spring Security. I don’t really see what the problem with using JMX is since many containers support it out of the box. It’s also a lot more portable than attempting to read a Tomcat LDAP realm in development and then going on to test and production on some other server (also a very common scenario).