Аутентификация с использованием LDAP против ADAM с использованием Spring Security - PullRequest
6 голосов
/ 24 сентября 2010

Я пытаюсь получить приложение Java, использующее Spring-Security, для связи с локальным экземпляром ADAM, который я настроил.

Я успешно установил ADAM и настроил его следующим образом ....

  • Экземпляр, запущенный на локальном хосте: 389
  • Root O=Company
    • Дочерний элемент с именем OU=Company Users (orgnizationalUnit)
      • Внук, называемый CN=Mike Q (пользователь)
      • uid = mike и password = welcome

Затем я настроил spring-security (версия 3.0.3, spring-рамки 3.0.4 и spring-ldap 1.3.0).Файл Spring

  <security:ldap-server id="contextSource" url="ldap://localhost:389/o=Company"/>

  <security:authentication-manager>
    <security:ldap-authentication-provider user-dn-pattern="uid={0},ou=Company Users"/>
  </security:authentication-manager>

  <bean class="com.xxx.test.TestAuthentication" lazy-init="false"/>

И TestAuthentication

public class TestAuthentication
{
    @Autowired
    private AuthenticationManager authenticationManager;

    public void initialise()
    {
        Authentication authentication = new UsernamePasswordAuthenticationToken( "mike", "welcome" );
        Authentication reponseAuthentication = authenticationManager.authenticate( authentication );
    }
}

При выполнении этого я получаю следующую ошибку

Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C090336, comment: AcceptSecurityContext error, data 2030, vece]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3041)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134)
at org.springframework.ldap.core.support.LdapContextSource.getDirContextInstance(LdapContextSource.java:43)
at org.springframework.ldap.core.support.AbstractContextSource.createContext(AbstractContextSource.java:254)

Если кто-то может указать, где я иду не так, яБуду благодарен.На данный момент я просто хочу подтвердить подлинность введенного пользователя / пароля с использованием LDAP, ничего более сложного, чем это.

Меня также интересуют некоторые общие моменты, поскольку это мой первый набег в мир LDAP.

  • Чувствителен ли регистр LDAP к регистру?
  • Лучше ли избегать пробелов?
  • Каковы общие примеры использования / передовые практики, позволяющие избежать отправки пароля в виде открытого текста в LDAPзапрос?

Ответы [ 2 ]

4 голосов
/ 28 сентября 2010

ОК, так как я потратил много времени на решение этого, вот ответ.

Код ошибки 2030 означает, что DN пользователя является недействительным.

После некоторой проб и ошибок здесьКонфиг, который работает и выполняет поиск пользователя правильно.(Возможно, вы можете переписать это, используя пространство имен безопасности, но пока я работал над этим, было более понятно использовать необработанные определения bean-компонентов).

  <bean id="contextSource"
        class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
    <constructor-arg value="ldap://localhost:389/cn=Sandbox,dc=ITOrg"/>
    <property name="userDn" value="cn=superuser,cn=People,cn=Sandbox,dc=ITOrg"/>
    <property name="password" value="xxxxxx"/>
  </bean>

  <bean id="ldapAuthProvider"
        class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
    <constructor-arg>
      <bean class="org.springframework.security.ldap.authentication.BindAuthenticator">
        <constructor-arg ref="contextSource"/>
        <property name="userDnPatterns">
          <list>
            <value>cn={0},cn=People</value>
          </list>
        </property>
      </bean>
    </constructor-arg>
  </bean>

  <bean id="userSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
    <constructor-arg index="0" value="cn=People"/>
    <constructor-arg index="1" value="(cn={0})"/>
    <constructor-arg index="2" ref="contextSource"/>
  </bean>

Ключевые вещи

<property name="userDn" value="cn=superuser,cn=People,cn=Sandbox,dc=ITOrg"/>

При указании userDn в источнике контекста это должен быть FULL DN (он не просто добавляет, а делает базу, указанную в url (конструктор arg).

При использовании BindAuthentication

<value>cn={0},cn=People</value>

Это значение является суффиксом над baseDn источника контекста.

При настройке пользовательского поиска

    <constructor-arg index="0" value="cn=People"/>
    <constructor-arg index="1" value="(cn={0})"/>

Я не смог заставить его работать с cn=People ввторой аргумент, но это, кажется, работает нормально. Обратите внимание, что вы можете использовать атрибуты пользователя, например (uid={0})

А вот пример кода, использующего определения bean-компонентов ...

    @Autowired
    private LdapUserSearch ldapUserSearch;

    @Autowired
    private AuthenticationProvider authenticationProvider;

    public void initialise()
    {
        DirContextOperations dirContextOperations = ldapUserSearch.searchForUser( "username" );

        Authentication authentication = authenticationProvider.authenticate( new UsernamePasswordAuthenticationToken( "username", "password" ) );    
    }

Некоторыедругие случайные сиськи ...

Error 52b - Invalid password


[LDAP: error code 32 - 0000208D: NameErr: DSID-031521D2, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Sandbox,DC=ITOrg'
     - This means the user is not in the administrator role (probably)

Надеюсь, все это поможет кому-то еще.

0 голосов
/ 01 октября 2013

Я исправил эту проблему, добавив пользователя, которого вы пытаетесь использовать в качестве члена роли администраторов, в том же базовом DN. Надеюсь, это поможет

...