Scenario LDAP: un database come magazzino di membri

Uno scenario per l'utilizzo del server LDAP come magazzino di membri si realizza quando si crea una nuova istanza di WebSphere Commerce in modo che utilizzi un database come magazzino di membri. Dopo avere creato un'istanza, è possibile utilizzare il server LDAP come magazzino di membri. In questo scenario, dopo avere attivato l'istanza di WebSphere Commerce con il database come magazzino di membri, è possibile utilizzare il server LDAP come magazzino di membri mediante Gestore configurazione.

Per questo scenario, è necessario eseguire quanto segue:

  1. Modificare il file instancename.xml per impostare l'opzione MigrateUsersFromWCSdb su ON.
  2. Esaminare la tabella ORGENTITY per verificare che la colonna DN contenga i valori corretti per le entità aziendali. Le voci per queste entità aziendali verranno create nel server LDAP da WebSphere Commerce e i valori DN verranno utilizzati durante la creazione. Ne consegue che è necessario determinare prima i valori DN di queste entità aziendali e verificare che esse siano inserite nella tabella ORGENTITY.
  3. Creare i suffissi richiesti nel server LDAP. Le voci utente e le entità aziendali che verranno utilizzate da o create da WebSphere Commerce sono presenti in questi suffissi.
  4. Impostare il file ldapentry.xml per associare gli attributi di WebSphere Commerce con quelli di LDAP. Inoltre,  aggiornare la colonna DN nella tabella USERS e la colonna LOGONID nella tabella USERREG con il valore DN della voce wcsadmin sul server LDAP. Eliminare gli spazi non richiesti tra i separatori nel valore DN. Se la colonna LOGONID non è sufficientemente lunga per l'intero valore DN, accorciare il valore in modo che rientri nella colonna. Ad esempio, se è stata creata la voce wcsadmin sul server LDAP con valore DN 'uid=wcsadmin,o=IBM,o=Root Organization,c=US', inserire questo valore DN nella colonna DN e nella colonna LOGONID.
  5. Dopo essere passati all'utilizzo del server LDAP, quando gli utenti effettuano il collegamento, WebSphere Commerce li autentica mediante il server LDAP. Poiché si sta passando dal database al server LDAP (l'opzione MigrateUsersFromWCSdb è impostata su ON), se l'autenticazione mediante il server LDAP non viene eseguita correttamente, verrà effettuato un secondo tentativo di autenticazione mediante la tabella USERREG.

Dopo essere passati all'utilizzo del server LDAP, gli utenti e le entità aziendali presenti nel database di WebSphere Commerce verranno "migrati" automaticamente sul server LDAP. Non è necessario eseguire manualmente la migrazione delle entità dal database di WebSphere Commerce sul server LDAP. Tuttavia, oltre alle attività precedentemente elencate, a seconda della modalità di collegamento scelta per gli utenti, si applicano alcune limitazioni e sono richieste ulteriori operazioni di configurazione. Sono disponibili tre approcci quando si decide il tipo di collegamento da impostare per i propri utenti. Nella versione corrente di WebSphere Commerce, quando viene utilizzato il server LDAP, gli utenti possono collegarsi utilizzando i propri valori DN oppure i valori RDN. Se si utilizzano i valori RDN, per trovare l'utente vengono utilizzate le basi di ricerca e viene eseguita l'autenticazione. Se durante la ricerca vengono individuate diverse voci utente, si verificherà un errore. Le basi di ricerca vengono specificate nel file ldapentry.xml.

Nella seguente descrizione, gli 'utenti DB' sono gli utenti presenti nel database di WebSphere Commerce che verranno automaticamente 'migrati' nel server di directory da WebSphere Commerce dopo essere passati all'utilizzo del server di directory. E' possibile che non vi siano molti 'utenti DB' se si passa all'utilizzo del server di directory subito dopo avere attivato l'istanza di WebSphere Commerce.Gli utenti DS sono gli utenti creati nel server di directory da applicazioni diverse da WebSphere Commerce e che si collegheranno a WebSphere Commerce. E' tuttavia possibile che vi siano delle voci utente nel server di directory e che tali utenti non si colleghino mai a WebSphere Commerce. In tal caso, WebSphere Commerce non li riconoscerà.

Approccio A
Si desidera che gli utenti DB si colleghino utilizzando il valore RDN (uguale al valore LogonId prima di passare al server di directory) e che gli utenti DS si colleghino mediante DN.

In tal modo, gli utenti DB e gli utenti DS possono presentare lo stesso valore RDN e LogonId. Ad esempio, è possibile che esista un utente DB con LogonId 'Abe' ed un utente DS con DN 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA'.

E' necessario impostare le basi di ricerca nel file ldapentry.xml in modo che gli utenti DS siano al di fuori dell'ambito delle basi di ricerca. Le basi di ricerca verranno utilizzate per ricercare gli utenti quando essi si collegano mediante RDN.

Il vantaggio dell'approccio A consiste nel fatto che i valori univoci RDN non sono richiesti. Lo svantaggio è costituito dal fatto che alcuni utenti (gli utenti DS) devono collegarsi utilizzando DN. Tuttavia, gli utenti DB possono continuare ad utilizzare RDN per il collegamento.

Approccio B
Si desidera che tutti gli utenti si colleghino utilizzando RDN. Per gli utenti DB, ciò significa che essi continuano a collegarsi utilizzando il loro valore LogonId. Per gli utenti DS, ciò significa che essi si collegano utilizzando il loro valore RDN.

Con questo approccio tutti gli utenti presenti nel server di directory che si desidera vengano riconosciuti da WebSphere Commerce devono presentare valori RDN univoci.

Prima di passare all'utilizzo del server di directory come magazzino di membri, è necessario verificare che gli utenti presenti nel server di directory che si desidera vengano riconosciuti da WebSphere Commerce presentino valori RDN univoci non soltanto al loro interno, ma anche rispetto ai valori LogonId degli utenti DB. Ad esempio, se un utente presenta il valore RDN 'Abe' nel server di directory, non dovrà esistere un altro utente con lo stesso valore RDN, né un utente DB con LogonId 'Abe'. Se due utenti presentano lo stesso valore RDN o LogonId, uno di essi deve essere modificato.

E' necessario impostare le basi di ricerca nel file ldapentry.xml in modo che tutti gli utenti che si collegheranno mediante WebSphere Commerce possano essere individuati.

Il vantaggio dell'approccio B è rappresentato dal fatto che gli utenti possono collegarsi con una stringa che presenta una sintassi molto semplice (un valore RDN). Lo svantaggio è rappresentato dal fatto che se vi è un gran numero di utenti DB o DS, potrebbe non essere facile gestire i valori RDN univoci. In generale, la richiesta di valori RDN univoci può non essere una soluzione scalabile. Il numero di utenti DB può essere ampio se si passa all'utilizzo del server di directory dopo avere attivato l'istanza di WebSphere Commerce. Il numero di utenti DS può essere ampio quando un numero sempre maggiore di utenti viene creato sul server di directory, indipendentemente dal fatto che vengano creati mediante WebSphere Commerce.

Approccio C
Si desidera che tutti gli utenti si colleghino utilizzando DN. Per gli utenti DB, ciò significa che essi si collegheranno mediante DN e non mediante il loro valore LogonId dopo essere passati all'utilizzo del server di directory.

In tal modo, gli utenti DB e gli utenti DS possono presentare lo stesso valore RDN e LogonId. Ad esempio, è possibile che esista un utente DB con LogonId 'Abe' ed un utente DS con DN 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA'.

E' necessario determinare i valori DN per gli utenti DB. Si assume che i valori RDN dei DN siano i valori LogonId degli utenti DB nella tabella USERREG.

E' necessario informare gli utenti DB in modo che si colleghino utilizzando DN dopo essere passati all'utilizzo del server di directory.

Il vantaggio dell'approccio C consiste nel fatto che i valori RDN univoci non sono richiesti. Lo svantaggio è rappresentato dal fatto che gli utenti devono collegarsi mediante DN.

Argomenti correlati

Attività correlate

Riferimento correlato

IBM copyright