Domanda / Problema

E' possibile configurare più directory e server LDAP per l'autenticazione. Per questo, devono essere configurate più sezioni del modulo LDAPLoginModule.

A partire da CRX2.0, configurazioni multiple come LDAPLoginModule non sono più efficaci, viene presa una sola configurazione. Questo significa che l'autenticazione LDAP di più directory non è possibile.

Risposta/Risoluzione

È disponibile una soluzione alternativa per supportare l'autenticazione di più server LDAP. Il problema principale è che con CRX2.0, l'attributo principal_provider.name che ha fornito l'ID univoco di una directory LDAP è stato deprecato. Invece, l'attributo principal_provider.class è usato come identificatore unico.

Come soluzione alternativa, i nomi univoci delle classi possono essere configurati per l'attributo principal_provider.class per ogni Modulo di login LDAP configurato. In allegato a questo articolo è un file jar contenente 6 classi uniche che si limitano ad estendere la classe predefinita com.day.crx.security.principals.LDAPPrincipalProvider:

  • 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

Disribuisci il file multi-ldap-patch.jar nella cartella WEB-INF/lib delle WebApp di CRX, come crx-quickstart/server/runtime/0/_crx/WEB-INF/lib e configura i moduli di accesso di conseguenza.

Esempio:

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: Per l'attuale versione di CRX 2.2, questo problema è stato risolto. L'attributo principal_provider.name è stato aggiunto nuovamente, quindi non è più necessario avere nomi di classe univoci configurati per l'attributo principal_provider.class.

Di seguito è riportato un esempio che funziona con CRX 2.2 e più server 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"
       ...;
}

Prodotti interessati:

CRX 2.0 / 2.1 / 2.2 / 2.3

Scarica

Questo prodotto è concesso in licenza in base alla licenza di Attribuzione-Non commerciale-Condividi allo stesso modo 3.0 Unported di Creative Commons.  I post su Twitter™ e Facebook non sono coperti dai termini di Creative Commons.

Note legali   |   Informativa sulla privacy online