LDAP サーバーをメンバー・リポジトリーとして使用する場合の 1 つのシナリオとして、 WebSphere Commerce のインスタンスを新しく作成し、そこでデータベースをメンバー・リポジトリーとして使用するように指定する方法があります。 そのようにしておいてから、そのインスタンスを稼働させ、メンバー・リポジトリーを LDAP サーバーとして使用するように切り替えるのです。 つまり、このシナリオでは、データベースをメンバー・リポジトリーにした状態で一度 WebSphere Commerce インスタンスを稼働させてから、 構成マネージャーを使用して、メンバー・リポジトリーを LDAP サーバーとして使用するように切り替えます。
このシナリオでは、以下のことを行う必要があります。
LDAP サーバーを使用するように切り替えると、 WebSphere Commerce データベース内に存在するユーザーや組織エンティティーが自動的に LDAP サーバーに「移行」されることを覚えておいてください。 何らかのエントリーを WebSphere Commerce データベースから LDAP サーバーに手動で移行する必要は一切ありません。 ただし、上で挙げた準備作業のほかにも、ユーザーをどのようにログオンさせたいかによっては、 別の制限が適用されたり、若干のセットアップがさらに必要になることがあります。 ユーザーにログオンさせる方法を決める際には、考慮できるアプローチが 3 つあります。 現行バージョンの WebSphere Commerce では、LDAP サーバーが使用されているとき、 ユーザーの DN 値を使ったログオンと RDN 値を使ったログオンが可能です。 RDN が使用された場合は、検索基準を使用してユーザーが検出された後、認証が実行されます。 検索で複数のユーザーが検出された場合は、エラーを生成します。 検索基準は ldapentry.xml ファイルで指定されます。
続く部分の説明では、「DB ユーザー」は WebSphere Commerce データベースに存在するユーザーを表しており、 ディレクトリー・サーバーを使用するように切り替えるとこれが WebSphere Commerce によって自動的にディレクトリー・サーバーに「移行」されます。 WebSphere Commerce インスタンスを稼働させた後すぐにディレクトリー・サーバーへの切り替えを行う場合、 「DB ユーザー」がたくさん存在しているということはないはずです。「DS ユーザー」は、WebSphere Commerce 以外のアプリケーションによってディレクトリー・サーバー内に作成されるユーザーを表しており、 これらのユーザーは結局 WebSphere Commerce にログオンすることになります。 言うまでもなく、ユーザー・エントリーはディレクトリー・サーバー内にある可能性があり、 そうしたユーザーは決して WebSphere Commerce にログオンできません。 このような場合、WebSphere Commerce はそれらのユーザーを認識しません。
アプローチ A
DB ユーザーに RDN 値 (つまり、ディレクトリー・サーバーを使用するように切り替える前の LogonId 値と同じ) でログオンさせ、
DS ユーザーに DN でログオンさせたい場合。
このアプローチは、DB ユーザーと DS ユーザーで RDN 値と LogonId 値を同じにできることを意味します。 たとえば、DB ユーザーの LogonId を 'Abe' とし、 DS ユーザーの DN を 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA' とすることが可能です。
ldapentry.xml ファイルで検索基準をセットアップして、 DS ユーザーが検索基準の有効範囲から外れるようにする必要があります。 この検索基準は、ユーザーが RDN を使用してログオンする際にユーザーの検索に使用されます。
アプローチ A の利点は、固有の RDN 値が必要でないという点です。 逆に欠点は、一部のユーザー (DS ユーザー) が DN を使用してログオンしなければならないという点です。 とはいえ、DB ユーザーは引き続き RDN を使用してログオンできます。
アプローチ B
すべてのユーザーを RDN でログオンさせたい場合。 DB ユーザーの場合、このアプローチの使用は、そのまま LogonId 値を使用してログオンできることを意味します。 DS ユーザーの場合は、RDN 値を使用してログオンすることを意味します。
このアプローチを使用する場合は、WebSphere Commerce に認識させたいディレクトリー・サーバー内のすべてのユーザーに、 固有の RDN 値を付けなければならないことになります。
ディレクトリー・サーバーをメンバー・リポジトリーとして使用するように切り替えるにあたっては、まず、 WebSphere Commerce サーバーに認識させたいディレクトリー・サーバー内のすべてのユーザーに、 固有の、それもただディレクトリー・サーバー内で固有であるというだけでなく、 DB ユーザーの LogonId とも区別された固有の RDN 値を与えなければなりません。 たとえば、ディレクトリー・サーバー内に 'Abe' という RDN 値を持つユーザーがいる場合は、 同じ RDN 値を持つユーザーがいてはならないだけでなく、'Abe' という LogonId を持つ DB ユーザーがいてもなりません。 同じ RDN 値か LogonId 値を持つユーザーが 2 人存在しているなら、そのどちらかを変更してください。
ldapentry.xml ファイルで検索基準をセットアップして、 WebSphere Commerce を通してログオンするすべてのユーザーを検索できるようにする必要があります。
アプローチ B の利点は、非常に簡単な構文のストリング (RDN 値) でユーザーがログオンできるという点です。 逆にその欠点は、DS ユーザーの数が多かったり、DB ユーザーの数が多かったりすると、 固有の RDN 値を保守するのが容易でないという点です。 概して、固有の RDN 値を要求する方法は、拡張性のある解決策とは言えないかもしれません。 WebSphere Commerce インスタンスをしばらく稼働させた後でディレクトリー・サーバーを使用するように切り替えるのであれば、 DB ユーザーの数が多くなってしまう可能性があります。 ディレクトリー・サーバー上でさらにユーザーが作成されていくにつれて、 それが WebSphere Commerce を通して作成されたかどうかに関係なく、DS ユーザーの数は多くなってしまうでしょう。
アプローチ C
すべてのユーザーを DN でログオンさせたい場合。 DB ユーザーにとってこれは、ディレクトリー・サーバーへの切り替えの後、
LogonId 値を使ったログオンから DN を使用したログオンに切り替えることを意味します。
このアプローチは、DB ユーザーと DS ユーザーで RDN 値と LogonId 値を同じにできることを意味します。 たとえば、DB ユーザーの LogonId を 'Abe' とし、 DS ユーザーの DN を 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA' とすることが可能です。
このアプローチでは、DB ユーザーの DN 値を決める必要があります。 おそらく、DN の RDN 値が、USERREG テーブルでの DB ユーザーの LogonId 値になるでしょう。
ディレクトリー・サーバーへの切り替え後のログオンには DN を使用するよう、DB ユーザーに通知する必要があります。
アプローチ C の利点は、固有の RDN 値が必要でないという点です。 逆にその欠点は、ユーザーが DN を使用してログオンしなければならないという点です。
![]() |