LDAP groupSearchBase = root?

[Chris Messina]

I have two groups one is "ou=GW,ou=SVCS,o=dec" the other is "ou=OPP,ou=APPS,ou=CO,o=dec".

Since the only common point between them is the root (o=dec), I need to perform my group search from the root but am having trouble configuring this.

I would like to use the namespace configuration, but when I leave off the groupSearchBase attribute or specify groupSearchBase="", or groupSearchBase=" " it ends up setting the groupSearchBase property to "ou=groups". I have even also tried setting groupSearchBase="none", because I have seen some instances where the attribute must be set to none to distinguish between setting an empty value and not setting a value, but this does not work either as the groupSearchBase is literally set to the String "none".

It is also not possible to simply call a setter for groupSearchBase from a post processor as you can do with searchSubtree because it is set in the constructor and there is no setter.

It seems that the only options are to configure the security through normal bean configuration instead of the much nicer namespace configuration, or maybe attempting to use reflection in the post processor to set the field directly.

Am I missing something, because neither of these seem like the correct answer?

[TimSin]

Has anyone got any further input into this thread? I'm experiencing the same LDAP group base problem at the moment and could use a few pointers on this.

[TimSin]

Looks like this is a mystery then. I managed to get this working by following the advice in the post above and replacing the namespace based configuration with a more traditional bean/xml based one. I've included the before and after below for future reference:

Namespace version:

    
<s:http>
        <s:intercept-url pattern="/**" access="IS_AUTHENTICATED_REMEMBERED" />

        <s:form-login />
        <s:anonymous />
        <s:logout />
    </s:http>


    <!-- Simple namespace-based configuration -->

    <s:ldap-server url="ldap://saldap.mycompany.org:389/" manager-dn="user" manager-password="password" />

    <s:ldap-authentication-provider 
        group-search-filter="(member={0})"
        group-role-attribute="" 
        group-search-base=""
        user-search-base="o=MyOrg"
        user-search-filter="(cn={0})"
        role-prefix="none"
    />

Bean version:

    <bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
         <constructor-arg value="ldap://saldap.mycompany.org:389/"/>
          <property name="userDn" value="User"/>
	  <property name="password" value="Password"/>
    </bean>

    <bean id="secondLdapProvider" class="org.springframework.security.providers.ldap.LdapAuthenticationProvider">
        <s:custom-authentication-provider />
		<constructor-arg>
			<bean class="org.springframework.security.providers.ldap.authenticator.BindAuthenticator">
				<constructor-arg ref="contextSource" />
				<property name="userSearch">
					<bean id="userSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
					  <constructor-arg index="0" value=""/>
					  <constructor-arg index="1" value="(cn={0})"/>
					  <constructor-arg index="2" ref="contextSource" />
					</bean>				
				</property>
			</bean>
		</constructor-arg>
		<constructor-arg>
			<bean class="org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopulator">
				<constructor-arg ref="contextSource" />
				<constructor-arg value="" />
				<property name="groupSearchFilter" value="(member={0})"/>
				<property name="rolePrefix" value="ROLE_"/>
				<property name="searchSubtree" value="true"/>
				<property name="convertToUpperCase" value="true"/>
			</bean>
		</constructor-arg>
    </bean>

This is authenticating against a domino based LDAP directory.

[Luke Taylor]

Looks like an issue with the namespace. Feel free to open an issue - we can either change the default search base to be the root or offer a string like "root" in the namespace options.

[TimSin]

Thanks, I've created an issue at:

jira.springframework.org/browse/SEC-963

Either of your suggestions would be suitable but it makes sense to me to set the default to root.