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:
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.
![]() |