Аутентификация с использованием LDAP против ADAM с использованием весенней безопасности

Question

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

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

• Instance работает на локальном хосте: 389
• Корень O=Company
  • Ребенок называется OU=Company Users (orgnizationalUnit)
    • Граница под названием CN=Mike Q (пользователь)
    • uid = mike и password = welcome

Тогда у меня есть установки пружинной безопасности (версия 3.0.3, пружинный каркас 3.0.4 и пружинный 1.3.0) LDAP. 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?

Answer 1

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

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

После некоторых проб и ошибок здесь приведена конфигурация, которая работает и выполняет поиск пользователя должным образом. (Вероятно, вы можете переписать это с использованием пространства имен безопасности, но пока я работал над этим, было яснее использовать определения raw 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 в исходном контексте оно должно быть полным DN (это не просто добавить его сделать базу, поставляемый в URL (конструктор агд).

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

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

Это значение суффикса на вершине окнеРазличающееся_имя_базыполе источника контекста.

При настройке UserSearch

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

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

А вот пример кода с использованием определений боба ...

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

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

Answer 2

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