Spring Security
  1. Spring Security
  2. SEC-871

Direct JNDI integration in LDAP Server security tag

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.0.3
    • Component/s: Core
    • Labels:
      None

      Description

      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.

      Eg. <sec:ldap-server realm="ldapServerRealm"/> or <sec:ldap-server jndiName="ldap

        Activity

        Hide
        Luke Taylor added a comment -

        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.

        Show
        Luke Taylor added a comment - 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.
        Hide
        Lou Sacco added a comment -

        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.

        Show
        Lou Sacco added a comment - 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.
        Hide
        Luke Taylor added a comment -

        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.

        Show
        Luke Taylor added a comment - 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.
        Hide
        Luke Taylor added a comment -

        A basic JMX configuration might look like:

        <ldap-server id="ldapServer"/>

        <b:bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
        <b:property name="beans">
        <b:map>
        <b:entry key="bean:name=ldapContextSource" value-ref="ldapServer"/>
        </b:map>
        </b:property>
        <b:property name="assembler">
        <b:bean class="org.springframework.jmx.export.assembler.MethodNameBasedMBeanInfoAssembler">
        <b:property name="managedMethods" value="setPassword,setUserDn,getUrls,setUrl,setUrls,setPooled,isPooled,setBase,getBaseLdapPathAsString"/>
        </b:bean>
        </b:property>
        </b:bean>

        Then start with java -Dcom.sun.management.jmxremote

        and run

        jconsole <pid of your server process>

        to test the setting of password, Url etc. through the MBean.

        Show
        Luke Taylor added a comment - A basic JMX configuration might look like: <ldap-server id="ldapServer"/> <b:bean id="exporter" class="org.springframework.jmx.export.MBeanExporter"> <b:property name="beans"> <b:map> <b:entry key="bean:name=ldapContextSource" value-ref="ldapServer"/> </b:map> </b:property> <b:property name="assembler"> <b:bean class="org.springframework.jmx.export.assembler.MethodNameBasedMBeanInfoAssembler"> <b:property name="managedMethods" value="setPassword,setUserDn,getUrls,setUrl,setUrls,setPooled,isPooled,setBase,getBaseLdapPathAsString"/> </b:bean> </b:property> </b:bean> Then start with java -Dcom.sun.management.jmxremote and run jconsole <pid of your server process> to test the setting of password, Url etc. through the MBean.
        Hide
        Lou Sacco added a comment -

        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.

        Show
        Lou Sacco added a comment - 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.
        Hide
        Luke Taylor added a comment -

        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).

        Show
        Luke Taylor added a comment - 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).

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Lou Sacco
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: