Un escenario para utilizar el servidor LDAP como depósito de miembros es que cree una nueva instancia de WebSphere Commerce y especifique que ésta ha de utilizar una base de datos como depósito de miembros. Posteriormente, después de que la instancia esté activa y en ejecución, pasará a utilizar el servidor LDAP como depósito de miembros. En este escenario, después de que la instancia de WebSphere Commerce esté activa y en ejecución con la base de datos como depósito de miembros, se utiliza el Gestor de configuración para pasar a utilizar el servidor LDAP como depósito de miembros.
En este escenario, debe realizar las siguientes acciones:
Tenga en cuenta que una vez haya pasado a utilizar el servidor LDAP, los usuarios y las entidades de organización que existan en la base de datos de WebSphere Commerce se "migrarán" automáticamente al servidor LDAP. No hace falta que migre manualmente ninguna entrada de la base de datos de WebSphere Commerce al servidor LDAP. No obstante, además del trabajo de preparación listado anteriormente, según cómo desee que se conecten los usuarios, se aplican diversas restricciones y es necesaria una configuración adicional. Existen tres métodos que puede sopesar cuando decida cómo desea que se conecten los usuarios. En la versión actual de WebSphere Commerce, cuando se utiliza el servidor LDAP, los usuarios pueden conectarse utilizando sus valores DN o su valores RDN. Si se utiliza RDN, se utilizan bases de búsqueda para encontrar el usuario y luego se lleva a cabo la autenticación. Si se encuentran múltiples entradas de usuario durante la búsqueda, se generará un error. Las bases de búsqueda se especifican en el archivo ldapentry.xml.
En la descripción siguiente, 'usuarios de BD' hace referencia a los usuarios que existen en la base de datos de WebSphere Commerce y que WebSphere Commerce 'migrará' automáticamente al servidor de directorios cuando pase a utilizar el servidor de directorios. Puede que no no haya muchos 'usuarios de BD' si pasa a utilizar el servidor de directorios poco tiempo después de que la instancia de WebSphere Commerce esté activa y en ejecución. Los 'usuarios DS' hacen referencia a los usuarios que otras aplicaciones distintas de WebSphere Commerce han creado en el servidor de directorios y que eventualmente se conectarán a WebSphere Commerce. Obviamente, pueden haber entradas de usuario en su servidor de directorios y puede que esos usuarios no se conecten nunca a WebSphere Commerce, en cuyo caso WebSphere Commerce no los reconocerá.
Método A
Desea que sus usuarios BD se conecten utilizando el valor RDN (esto es, lo mismo
que su valor LogonId antes de que pase a utilizar el servidor de directorios) y que sus
usuarios DS se conecten utilizando DN.
Este método significa que los usuarios BD y los usuarios DS pueden tener el mismo valor RDN y LogonId. Por ejemplo, puede haber un usuario BD con LogonId 'Abe' y un usuario DS con DN 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA'.
Tiene que configurar sus bases de búsqueda en el archivo ldapentry.xml de manera que sus usuarios DS estén fuera del ámbito de las bases de búsqueda. Las bases de búsqueda se utilizarán para buscar usuarios cuando se conecten utilizando RDN.
La ventaja del método A es que no se requieren valores RDN exclusivos. El inconveniente es que algunos usuarios (los usuarios DS) tienen que conectarse utilizando DN. No obstante, sus usuarios BD pueden seguir utilizando RDN para conectarse.
Método B
Desea que todos los usuarios se conecten utilizando RDN. Para los usuarios BD, esto
significa que siguen conectándose utilizando su valor LogonId. Para los usuarios DS, esto
significa que se conectan utilizando su valor RDN.
Este método significa que todos los usuarios de su servidor de directorios que desea que WebSphere Commerce reconozca deben tener valores RDN exclusivos.
Antes de que pase a utilizar el servidor de directorios como depósito de miembros, tendrá que asegurarse de los usuarios de su servidor de directorios que desea que WebSphere Commerce reconozca tengan valores RDN que sean exclusivos, no sólo entre ellos sino también respecto a los valores LogonId de los usuarios BD. Por ejemplo, si tiene un usuario con el valor RDN 'Abe' en su servidor de directorios, no debe tener otro usuario con el mismo valor RDN y no debe tener un usuario BD con LogonId 'Abe'. Si dos usuarios cualesquiera tienen el mismo valor RDN o LogonId, uno de ellos debe cambiarlo.
Tiene que configurar sus bases de búsqueda en el archivo ldapentry.xml de tal manera que todos los usuarios que vayan a conectarse mediante WebSphere Commerce puedan localizarse.
La ventaja del método B es que los usuarios pueden conectarse con una serie de caracteres que tiene una sintaxis muy simple (esto es, un valor RDN). El inconveniente es que si el número de usuarios BD o el número de usuarios DS es grande, mantener los valores RDN exclusivos puede que no sea fácil. En general, requerir valores RDN exclusivos puede que no sea una solución escalable. El número de usuarios BD puede ser grande si pasa a utilizar el servidor de directorios después de que la instancia de WebSphere Commerce haya estado activa y en ejecución durante un tiempo. El número de usuarios DS puede ser muy grande cuando se creen más y más usuarios en el servidor de directorios, tanto si se crean mediante WebSphere Commerce como si no.
Método C
Desea que todos los usuarios se conecten utilizando DN. Para los usuarios BD, esto significa
que, cuando pase a utilizar el servidor de directorios, pasarán a conectarse
utilizando DN en vez de conectarse utilizando su valor LogonId.
Este método significa que los usuarios BD y los usuarios DS pueden tener el mismo valor RDN y LogonId. Por ejemplo, puede haber un usuario BD con LogonId 'Abe' y un usuario DS con DN 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA'.
Tiene que determinar los valores DN para sus usuarios BD. Se supone que los valores RDN de los DN son los valores LogonId de los usuarios BD en la tabla USERREG.
Tiene que avisar a sus usuarios BD que se conecten utilizando DN después de que pase a utilizar el servidor de directorios.
La ventaja del método C es que no se requieren valores RDN exclusivos. El inconveniente es que los usuarios tienen que conectarse utilizando DN.
![]() |