Pregunta/Problema

Es posible configurar la autenticación en varios directorios y servidores LDAP. Para ello, deben configurarse varias secciones de LDAPLoginModule.

Desde CRX2.0, varias configuraciones de LDAPLoginModule ya no son efectivas, ya que solo se acepta una configuración. Esto significa que la autenticación LDAP en varios directorios no es posible.

Respuesta/Resolución

Existe una solución alternativa disponible para admitir la autenticación en varios servidores de LDAP. El problema principal es que con CRX2.0, el atributo principal_provider.name, que básicamente proporcionaba el ID único de un directorio LDAP, está obsoleto. En su lugar, se utiliza el atributo principal_provider.class como identificador único.

Como solución alternativa, se deben configurar nombres de clase únicos para el atributo principal_provider.class para cada módulo LDAPLoginModule configurado. Adjunto a este artículo hay disponible un archivo jar que contiene 6 clases únicas, que simplemente extienden la clase com.day.crx.security.principals.LDAPPrincipalProvider predeterminada:

  • 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

Implemente el archivo multi-ldap-patch.jar en la carpeta WEB-INF/lib de la aplicación web CRX. Por ejemplo, crx-quickstart/server/runtime/0/_crx/WEB-INF/lib y configure los LoginModules según corresponde.

Ejemplo:

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

Nota: Este problema se ha corregido para la versión actual de CRX 2.2. El atributo principal_provider.name se ha añadido de nuevo, por lo que ya no es necesario tener nombres de clase únicos configurados para el atributo principal_provider.class.

A continuación, se muestra un ejemplo que funciona con CRX 2.2 y varios servidores de 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

CRX 2.0, 2.1, 2.2, 2.3

Descargar