Pour mettre en oeuvre le scénario consistant à utiliser le serveur LDAP comme référentiel de membre, vous devez créer une nouvelle instance WebSphere Commerce et la définir de sorte qu'elle utilise une base de données comme référentiel de membre. Ultérieurement, une fois l'instance en cours de fonctionnement, vous pouvez revenir à l'utilisation du serveur LDAP en tant que référentiel de membre. Dans le cadre de ce scénario, une fois l'instance WebSphere Commerce en cours de fonctionnement alors que la base de données a été définie en tant que référentiel de membre, vous pouvez revenir à l'utilisation du serveur LDAP en tant que référentiel de membre à l'aide du gestionnaire de configuration.
Pour mettre en oeuvre ce scénario, vous devez exécuter les opérations suivantes :
Une fois que vous êtes revenu à l'utilisation du serveur LDAP, les utilisateurs et les entreprises existant dans la base de données WebSphere Commerce feront l'objet d'une "migration" automatique sur le serveur LDAP. Vous n'avez pas besoin de procéder à la migration manuelle de la base de données WebSphere Commerce sur le serveur LDAP. Toutefois, outre le travail de préparation décrit précédemment, selon le mode de connexion que vous souhaitez définir pour vos utilisateurs, diverses restrictions s'appliquent et des étapes de configuration supplémentaires sont nécessaires. Vous pouvez envisager la question de la définition du mode de connexion de vos utilisateurs de trois façons différentes. Dans la version en cours de WebSphere Commerce, lorsque le serveur LDAP est utilisé, les utilisateurs peuvent se connecter à l'aide de leur valeur DN ou de leur valeur RN. Si la valeur RDN est utilisée, l'utilisateur est recherché à l'aide de bases de recherche et l'authentification est effectuée. Si plusieurs utilisateurs sont détectés lors de cette recherche, une erreur est générée. Les bases de recherche sont indiquées dans le fichier ldapentry.xml.
Dans la description ci-après, les utilisateurs BD désignent les utilisateurs qui existent dans la base de données WebSphere Commerce et qui feront l'objet d'une migration automatique sur le serveur d'annuaires par WebSphere Commerce après le retour à l'utilisation du serveur LDAP. Il se peut qu'il y ait peu d'utilisateurs BD si vous revenez à l'utilisation du serveur d'annuaires rapidement après la mise en fonctionnement de l'instance WebSphere Commerce.Les utilisateurs SA désignent les utilisateurs ayant été créés dans le serveur d'annuaires par des applications autres que WebSphere Commerce et qui se connecteront tôt ou tard à WebSphere Commerce. Il peut bien sûr exister des entrées d'utilisateur dans votre serveur d'annuaires qui ne se connecteront jamais à WebSphere Commerce. Dans ce cas, WebSphere Commerce ne les reconnaîtra pas.
Approche A
Vous souhaitez que vos utilisateurs BD se connectent à l'aide de leur valeur RDN (autrement dit, la même valeur que leur ID de connexion (valeur LogonId) avant que vous ne passiez à l'utilisation du serveur d'annuaires) et que vos utilisateurs SA se connectent à l'aide de leur valeur DN.
Cette approche implique que les utilisateurs BD et les utilisateurs SA peuvent avoir les mêmes valeurs RDN et LogonId. Par exemple, un utilisateur BD peut avoir 'Abe' comme valeur LogonId et un utilisateur SA peut avoir 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA' comme valeur de nom distinctif.
Vous devez définir vos bases de recherche dans le fichier ldapentry.xml de sorte que vos utilisateurs SA restent en dehors de la portée des bases de recherche. Les bases de recherche permettront de rechercher des utilisateurs lors de leur connexion à l'aide de leur valeur RDN.
Dans le cadre de l'approche A, les valeurs RDN uniques ne sont pas requises. L'inconvénient est que certains utilisateurs (les utilisateurs SA) doivent se connecter à l'aide de leur nom distinctif. Toutefois, les utilisateurs BD peuvent continuer à se connecter à l'aide de leur valeur RDN.
Approche B
Vous souhaitez que tous les utilisateurs se connectent à l'aide de leur valeur RDN. Cela signifie que les utilisateurs BD continueront à se connecter à l'aide de leur valeur LogonId et que les utilisateurs SA se connecteront à l'aide de leur valeur RDN.
Dans le cadre de cette approche, tous les utilisateurs de votre serveur d'annuaires devant être reconnus par WebSphere Commerce doivent être associés à une valeur RDN unique.
Avant de passer à l'utilisation du serveur d'annuaires en tant que référentiel de membre, vous devez vous assurer que les utilisateurs présents dans votre serveur d'annuaires et devant être reconnus par WebSphere Commerce sont associés à des valeurs RDN uniques, non seulement les unes par rapport aux autres, mais également par rapport aux valeurs LogonId de vos utilisateurs BD. Par exemple, si l'un de vos utilisateurs a pour valeur RDN 'Abe' dans votre serveur d'annuaires, aucun autre utilisateur ne peut disposer de la même valeur RDN et aucun utilisateur BD ne peut avoir 'Abe' comme valeur LogonId. Si deux utilisateurs disposent de la même valeur RDN ou LogonId, vous devez modifier l'une ou l'autre.
Vous devez définir vos bases de recherche dans le fichier ldapentry.xml de sorte que tous les utilisateurs qui se connecteront via WebSphere Commerce puissent être retrouvés.
L'approche B permet aux utilisateurs de se connecter à l'aide d'une chaîne dont la syntaxe est très simple (une valeur RDN). Par contre, s'il existe un grand nombre d'utilisateurs BD ou d'utilisateurs SA, il peut s'avérer difficile de gérer des valeurs RDN uniques. Le fait que des valeurs RDN uniques soient obligatoires peut ne pas être une solution évolutive. Le nombre d'utilisateurs BD peut s'avérer volumineux si vous passez à l'utilisation du serveur d'annuaires alors que l'instance WebSphere Commerce est en cours de fonctionnement depuis un certain temps. Le nombre d'utilisateurs SA peut s'avérer volumineux lorsque de plus en plus d'utilisateurs sont créés sur le serveur d'annuaires, que cette création soit effectuée ou non via WebSphere Commerce.
Approche C
Vous souhaitez que tous les utilisateurs se connectent à l'aide de leur nom distinctif. Cela signifie que les utilisateurs BD passeront du mode de connexion via leur valeur LogonId au mode de connexion via leur nom distinctif une fois que vous aurez redéfini l'utilisation du serveur d'annuaires.
Cette approche implique que les utilisateurs BD et les utilisateurs SA peuvent avoir les mêmes valeurs RDN et LogonId. Par exemple, un utilisateur BD peut avoir 'Abe' comme valeur LogonId et un utilisateur SA peut avoir 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA' comme valeur de nom distinctif.
Vous devez déterminer les valeurs DN pour les utilisateurs BD. Le système considère que les valeurs RDN des noms distinctifs correspondent aux valeurs LogonId des utilisateurs DB dans la table USERREG.
Vous devez informer vos utilisateurs BD qu'ils doivent se connecter à l'aide de leur nom distinctif après que vous ayez redéfini l'utilisation du serveur d'annuaires.
Dans le cadre de l'approche C, les valeurs RDN uniques ne sont pas requises. L'inconvénient est que les utilisateurs doivent se connecter à l'aide de leur nom distinctif.
![]() |