スキーマの制限

Access Manager は、管理するエントリを抽象的に表現します。したがって、たとえば、Access Manager 内の組織は、Directory Server 内の組織とは必ずしも同じにはなりません。特定の DIT (Directory Infromation Tree) を管理できるかどうかは、ディレクトリエントリを表すまたは管理する方法と、DIT が各 Access Manager タイプの制限に適しているかどうかによります。

以下の項で、Access Manager スキーマに課される制限について説明します。この節の最後には、「サポートされない DIT の例」も複数記載しています。

組織としてマークできるエントリのタイプは 1 つに限られる

Access Manager sunISManagedOrganization 予備クラスを、任意のエントリに追加することにより、 Access Manager では、このエントリを組織であるように管理できます。ただし、組織としてマークできるエントリのタイプは 1 つに限られます。たとえば、DIT にエントリ o=sun と別のエントリ dc=ibm がある場合、両方のエントリを組織としてマークすることはできません。

次の例では、dc と o の両方のエントリを組織にしようとしていますが、この DIT 構造は Access Manager で管理できません。

ただし、Access Manager ルートサフィックスでのエントリは、1 つのエントリには数えられません。したがって、次の例のDIT 構造は、Access Manager で管理できます。

o=continent1 の下に dc=company1 を追加した場合、dc がコンテナとしてマークされている場合にのみ、このDIT の管理が可能になります。コンテナは、Access Manager の別の抽象タイプであり、通常、OrganizationalUnit にマッピングされます。ほとんどの DIT では、 iplanet-am-managed-container エントリをすべての OrganizationlUnits に追加します。

ただし、このマーカーオブジェクトクラスはどのエントリタイプにも追加できます。次の例の DIT 構造が可能です。

この例では、o= と ou= の両方のエントリを組織としてマークすることはできないため、o= エントリを organization としてマークし、ou= エントリを containers としてマークしています。コンソールに表示されるときに、組織とコンテナで利用できるオプションは同じです。従属または下位区分、ピープルコンテナ、グループ、ロール、およびユーザーは、両方の内部で作成できます。

ピープルコンテナをユーザーの親エントリにする必要がある

もう 1 つの抽象エントリタイプはピープルコンテナです。Access Manager タイプは、このエントリがユーザーの親エントリであると想定します。ピープルコンテナとしてエントリに iplanet-am-managed-people-container のマークが付けられていると、UI は、このコンテナには下位ピープルコンテナまたはユーザーだけが存在すると見なします。属性 OrganizationUnit が通常、ピープルコンテナとして使用されますが、iplanet-am-managed-people-container オブジェクトクラスを保有し、Access Manager の管理可能な親タイプの organization または container を保持する限り、Access Manager のどのエントリでもピープルコンテナとして使用できます。

Access Manager XML で可能な組織の説明は 1 つに限られる

Access Manager の組織は、amEntrySpecific.xml で定義されます。このファイルでは、1 つの組織の説明だけを記述できます。この結果、ディレクトリエントリのプロパティーをカスタマイズしたり、管理ページや検索ページを UI 内に作成すると、カスタム属性は Access Manager 設定全体に適用されます。この Access Manager 要件は、特にホスティングサービスを行う企業など、配備における組織ごとに異なる表示属性を必要とする諸企業のニーズに合わない場合があります。

次の例で、Edison-Watson 社はホスティング企業として、インターネットサービスを多数の企業に提供しています。企業 A では、ユーザーの姓、名、バッジ番号を入力するフィールドを表示する必要があります。企業 B では、ユーザーの姓、名、社員番号を入力するフィールドを表示する必要があります。

組織の説明は、組織レベルではなくルートレベル (o=EdisonWatson) で定義されます。デフォルトでは、企業 A と 企業 B の両方の UI を同一にする必要があります。また、すべてのサービスは、下位スキーマタイプユーザーの属性になるように、属性をグローバルに定義します。したがって、企業 A が、予備クラス CompanyA-user にそのユーザー用の属性を保持し、企業 B が、CompanyB-user に属性を保持している場合、企業 B の属性は上書きされ、表示されません。

回避策としては、ユーザー表示に対処するように ACI を修正する方法があります。ただしこの回避策は、「検索」および「作成」ウィンドウでの属性には対処しません。

サポートされない DIT の例

次の例では、次の 3 タイプの組織マーカーが必要になります。o、ou、および l。 l=california および l=alabama がピープルコンテナではないと見なされるため、この DIT は Access Manager では動作しません。

次の例では、3 タイプの Access Manager マーカー (dc、o、ou)、およびピープルコンテナ (ou=people) が必要になります。この条件下では、DIT は Access Manager で動作しません。