LDAP シナリオ: メンバー・リポジトリーとしてのデータベース

LDAP サーバーをメンバー・リポジトリーとして使用する場合の 1 つのシナリオとして、 WebSphere Commerce のインスタンスを新しく作成し、そこでデータベースをメンバー・リポジトリーとして使用するように指定する方法があります。 そのようにしておいてから、そのインスタンスを稼働させ、メンバー・リポジトリーを LDAP サーバーとして使用するように切り替えるのです。 つまり、このシナリオでは、データベースをメンバー・リポジトリーにした状態で一度 WebSphere Commerce インスタンスを稼働させてから、 構成マネージャーを使用して、メンバー・リポジトリーを LDAP サーバーとして使用するように切り替えます。

このシナリオでは、以下のことを行う必要があります。

  1. instancename.xml ファイルを編集して、MigrateUsersFromWCSdb オプションを ON にします。
  2. ORGENTITY テーブルを調べ、 DN 列の値が組織エンティティーに対して適切な値であることを確認します。 これらの組織エンティティーのエントリーは、WebSphere Commerce によって LDAP 内に作成されますが、 この DN 値はその作成の際に使用されるものです。 ですから、前もってこれらの組織エンティティーの DN 値を確認し、それが確実に ORGENTITY テーブルに移植されるようにしなければなりません。
  3. LDAP サーバーで必要なサフィックスを作成します。 WebSphere Commerce で使用または作成されるユーザーや組織エンティティーのエントリーは、 これらのサフィックスの下に存在することになります。
  4. ldapentry.xml ファイルをセットアップして、WebSphere Commerce 属性を LDAP 属性にマップします。 また、LDAP サーバーの wcsadmin エントリーの DN によって、 USERS テーブルの DN 列と USERREG テーブルの LOGONID 列を更新します。  DN 値の区切り文字の間にある不要なスペースを除去します。 LOGONID 列に DN 値全体が入るだけの長さがない場合、その列に入るように値を切り捨ててください。 たとえば、 LDAP サーバーで DN 値 'uid=wcsadmin,o=IBM,o=Root Organization,c=US' を指定して wcsadmin エントリーを作成した場合、 この DN 値を DN 列と LOGONID 列の両方に指定します。
  5. LDAP サーバーを使用するように切り替えると、ユーザーがログオンしたとき、 WebSphere Commerce は LDAP サーバーを使用するためのユーザーの認証を行うようになります。 データベースから LDAP サーバーに切り替えた (つまり、MigrateUsersFromWCSdb オプションを ON にした) ので、LDAP サーバーに対する認証が失敗したときは、 次に USERREG テーブルを使用するためのユーザーの認証が行われることになります。

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 を使用してログオンしなければならないという点です。

関連概念

関連タスク

関連参照

IBM 著作権