Como configurar a autenticação LDAP em vários diretórios LDAP

Pergunta/problema

É possível configurar vários diretórios e servidores LDAP para autenticação. Para isso, várias seções LDAPLoginModule deverão ser configuradas.

Começando com o CRX2.0, várias dessas configurações LDAPLoginModule não são mais eficazes, apenas uma configuração é executada. Isso significa que a autenticação LDAP em vários diretórios não é possível.

Resposta/resolução

Há uma solução alternativa disponível para dar suporte à autenticação em vários servidores LDAP. O principal problema é que com o CRX2.0, o atributo principal_provider.name que, basicamente, fornneceu o ID único de um diretório LDAP, foi preterido. Em vez dele, o atributo principal_provider.class é usado como identificador exclusivo.

Como solução alternativa, os nomes de classe exclusivos devem ser configurados para atributo principal_provider.class para cada LDAPLoginModule configurado. Anexado a este artigo encontra-se um arquivo jar contendo 6 classes exclusivas que apenas estendem o padrão com.day.crx.security.principals.LDAPPrincipalProvider classe:

  • com.day.daycare.ldap.LDAP1
  • com.day.daycare.ldap.LDAP2
  • com.day.daycare.ldap.LDAP3
  • com.day.daycare.ldap.LDAP4
  • com.day.daycare.ldap.LDAP5
  • com.day.daycare.ldap.LDAP6

Implante o arquivo multi-ldap-patch.jar na pasta do webapps CRX WEB-INF/lib, por exemplo crx-quickstart/server/runtime/0/_crx/WEB-INF/lib e configure o LoginModules corretamente.

Exemplo:

com.day.crx {
   com.day.crx.security.authentication.CRXLoginModule sufficient;
   com.day.crx.security.ldap.LDAPLoginModule sufficient
       principal_provider.class="com.day.crx.security.principals.LDAPPrincipalProvider"
       host="MyHost1"
       ...;

   com.day.crx.security.ldap.LDAPLoginModule sufficient
       principal_provider.class="com.day.daycare.ldap.LDAP1"
       host="MyHost2"
       ...;

   com.day.crx.security.ldap.LDAPLoginModule sufficient
       principal_provider.class="com.day.daycare.ldap.LDAP2"
       host="MyHost3"
       ...;
}

CRX 2.2 / 2.3

Observação: Para a versão atual do CRX 2.2, esse problema foi corrigido. O atrtibuto principal_provedor.name foi adicionado novamente, portanto, não é mais necessário ter nomes de classe exclusivos configurados para o principal_provider.class atributo.

A seguir, um exemplo que funciona com o CRX 2.2 e vários servidores LDAP:

com.day.crx {
   com.day.crx.security.authentication.CRXLoginModule sufficient;
   com.day.crx.security.ldap.LDAPLoginModule sufficient
       principal_provider.class="com.day.crx.security.principals.LDAPPrincipalProvider"
       principal_provider.name="ldap1"
       host="MyHost1"
       ...;

   com.day.crx.security.ldap.LDAPLoginModule sufficient
       principal_provider.class="com.day.crx.security.principals.LDAPPrincipalProvider"
       principal_provider.name="ldap2"
       host="MyHost2"
       ...;

   com.day.crx.security.ldap.LDAPLoginModule sufficient
       principal_provider.class="com.day.crx.security.principals.LDAPPrincipalProvider"
       principal_provider.name="ldap3"
       host="MyHost3"
       ...;
}

Aplica-se a

CRX 2.0 / 2.1 / 2.2 / 2.3

Download

 Adobe

Receba ajuda com mais rapidez e facilidade

Novo usuário?