第 4 章配備前の考慮事項

Sun Java^TM Identity Server 2004Q2 を使用すると、異機種のハードウェア、ソフトウェア、およびアプリケーションインフラストラクチャを抱える大規模な組織で、従業員、受託業者、顧客、およびサプライヤのアイデンティティ管理ソリューションをうまく配備できます。この章では、このプロセスに関連する高度な技術的概要を説明します。次の節で構成されています。

配備オプション

Identity Server の配備を計画する際、組織が考慮する必要のある重要な要素がいくつかあります。これらは、通常、リスク評価および成長戦略と関連があります。例を示します。

さらに、アーキテクチャは、以降の節で説明する目標を達成するための基礎を提供する必要があります。

セキュリティ

セキュリティの確保された内部および外部ネットワーク環境を提供する際、考慮する必要のあるオプションが多数存在します。以下にその内容を示します。

高可用性

IT の配備では、ユーザーに対して可用性を継続するとともに、SPOF (Single Point Of Failure) を発生させないことが重要です。可用性を高めるための手法は、クラスタリングやマルチマスターレプリケーションなど、製品ごとに異なります。望ましい高可用性とは、システムやコンポーネントが期待どおりに長期間、連続的に使用可能であることです。このシステムは一般的に、複数のサーバーマシンで構成されますが、ユーザーには、1 つの高可用性システムのように見えます。すべてのアプリケーションが 1 台のサーバーで動作する、最小構成の配備の場合、次の SPOF が含まれます。

これらの問題のうち、その大半は事前に予測できるので、高可用性の実現手法は、データストレージのバックアップやアクセスに対するフェイルオーバーの処理を中心に計画することが可能です。ストレージに関する 1 つの手法は、RAID (redundant array of independent disks) です。より高い可用性が求められるシステムでは、システムの各部分が適切に設計され、本稼働に先立ち、十分にテストされていることが必要です。たとえば、テストが十分ではない新規のアプリケーションプログラムほど、本番での稼働中に、システム全体に影響するエラーを引き起こす可能性が高くなります。

クラスタリング

クラスタリングとは、単一の高可用性システムを構築するために複数のコンピュータを使用することを指します。クラスタリングは、Sun Java System Identity Server では使用できないものの、システムの基盤である Sun Java System Directory Server のデータストアでは、極めて重要な手法です。たとえば、クラスタ化された 1 組の MMR サーバーでは、クラスタでの可用性を保証することにより、各マスターインスタンスの可用性を向上させることができます。

スケーラビリティ

「水平スケーリング」は、複数のサーバーマシンを接続して 1 つの装置として動作させることで実現します。ロードバランスに対応したサーバーは、サービスの速度と可用性が向上するため、水平スケーリングが行われていると見なされます。一方、「垂直スケーリング」は、1 台のサーバーマシン内部にリソースを追加することにより、既存のハードウェアの容量を拡張します。スケーリング可能なリソースには、CPU、メモリ、および記憶装置が含まれます。水平スケーリングおよび垂直スケーリングは相互排他的なものではないため、協調動作が可能です。通常、環境内のサーバーのインストールにより能力の限界まで使用されることはないため、垂直スケーリングはパフォーマンスを改善するために使用されます。また、特定のマシンが処理能力の限界に近づいた場合も、水平スケーリングは、多数のサーバーによって負荷を分散します。


注	高可用性シナリオでは、Identity Server のインストールすべてで同一の暗号化キーを指定する必要があります。

ハードウェア要件

Identity Server をインストールするハードウェアは、一定の要件を満たす必要があります。Identity Server は、最低限、データストアとして使用する Sun Java System Directory Server 2004Q2 (5.2) および配備先の Web コンテナとともにインストールする必要があります。さらに、Directory Server と Identity Server は、異なるマシンにインストールすることが推奨されています。

詳細な要件は、コンポーネントのデフォルト設定 (Web Server によって配備される 1 つの Identity Server インスタンスと、1 つの Directory Server インスタンス) に基づく高度な内容です。Identity Server をインストールする前に、『Directory Server 5 2004Q2 Installation and Migration Guide』、『Directory Server 5 2004Q2 配備計画ガイド』、および選択した Web コンテナのマニュアルを参照してください。

パフォーマンスを最適化するために、Identity Server は、100M バイト以上の Ethernet ネットワーク上で実行してください。Identity Server 配備の最小構成は、Identity Server と Sun Java System Web Server の両方がインストールされたマシンです。1 個以上の CPU を搭載している必要がありますが、5 個以上の CPU を搭載しても効果はあまり期待できません。サーバーごとに 2 ～ 4 個の CPU を強くお勧めします。ソフトウェアの基本的なテストを実行するために、256M バイト以上の RAM が必要です。

現実の配備シナリオでは、スレッド、SDK、HTTP サーバー、および他の内部処理用に 1G バイトの RAM、基本操作およびオブジェクト割り当て領域に 2G バイトの RAM、さらに 10,000 並行セッションごとに 100M バイトの RAM が推奨されています。各 Identity Server は、並行セッションが 100,000 でキャップアウトすることが推奨されています。その後、水平ロードバランスを適用する必要があります (32 ビットアプリケーションの 4G バイトメモリ制限を前提とする)。


注	推奨される手順は、Sun Java System Identity Server を設計および配備する前に Sun Java System プロフェッショナルサービスまたは Sun Java System 認定システムインテグレータに相談することです。


注	ディレクトリリソース要件は、顧客固有のデータおよび使用方法に応じて変化しますが、通常は高度な要件が求められます。

ソフトウェア要件

Identity Server のインストール先システムは、最小のソフトウェアおよびオペレーティングシステム要件を満たす必要があります。

オペレーティングシステム要件

Identity Server 2004Q2 は、次のプラットフォームでサポートされています。

プラットフォームの詳細については、『Sun Java Enterprise System 2004Q2 リリースノート』を参照してください。

Solaris 用パッチクラスタ

パッチクラスタは、108827-15 のように 2 つの番号で識別されます。最初の番号はパッチ自体を識別するためのもので、2 番目の番号はパッチのバージョンを識別するためのものです。全般的なパッチ情報および推奨されるパッチは、次の SunSolve Patch Portal からダウンロードできます。

現在 Solaris マシンにインストールされているパッチを表示するには、showrev -p コマンドを使用します。

必要なパッチのリストについては、『Identity Server 2004Q2 リリースノート』および『Java Enterprise System 2004Q2 リリースノート』を参照してください。

JDK ソフトウェア要件

Identity Server 2004Q2 では、次の JDK ソフトウェアが必要になります。

Web コンテナ要件

Identity Server 2004Q2 では、完全インストールを行うか、SDK だけをインストールするかに応じて、さまざまな Web コンテナをサポートしています。完全インストールの場合は、次の Web コンテナのいずれかを使用します。

SDK だけをインストールする場合は、次の Web コンテナのいずれかを使用します。

ポリシーエージェントを Web コンテナにインストールする場合は、約 10M バイトのディスク容量が使用されます。Web コンテナを設定するときには、この容量を考慮に入れる必要があります。詳細は、『Sun Java System Identity Server Web Policy Agents Guide』または『Sun Java System Identity Server J2EE Policy Agents Guide』を参照してください。

Directory Server 要件

Identity Server 2004Q2 には、次のバージョンのいずれかが必要になります。

Web ブラウザ要件

管理者およびエンドユーザーは、Web ブラウザを使用してユーザー管理タスクを実行します。Identity Server2004Q2 では、次の Web ブラウザをサポートしています。

Identity Server スキーマの理解

スキーマとは、データに課されるルールセットのことで、通常はデータの格納方法の定義に利用されます。Directory Server には、データの格納方法を定義する LDAP (Lightweight Directory Access Protocol) スキーマが含まれます。オブジェクトクラスは、LDAP スキーマ内の属性を定義します。Directory Server では、各データエントリは、内部の属性セットを記述および定義するオブジェクトのタイプを指定するため、1 つ以上のオブジェクトクラスを保持する必要があります。基本的に、各エントリは、属性セットとその対応する値、およびこれらの属性に対応するオブジェクトクラスのリストになります。

Identity Server は、Directory Server を、アイデンティティプロファイル、資格定義、および配備設定情報すべてのデータリポジトリとして使用します。このために、Identity Server は、Directory Server スキーマを拡張する独自のスキーマを保持します。Identity Server のインストール時に、ds_remote_schema.ldif および sunone_schema2.ldif に記述された Identity Server スキーマは、Directory Server スキーマと統合されます。ds_remote_schema.ldif には、特に Identity Server により使用される LDAP オブジェクトクラスおよび属性が記述されます。一般に、これらのオブジェクトクラスおよび属性は、以前のバージョンの Identity Server から受け継いだものです。sunone_schema2.ldif は、Sun Microsystems の新しい内部スキーマドキュメントで定義された Identity Server 固有の LDAP スキーマオブジェクトクラスおよび属性をロードします。参照用に、ds_remote_schema.ldif および sunone_schema2.ldif の内容を、それぞれコード例 4-1 およびコード例 4-2 に示します。

コード例 4-1 ds_remote_schema.ldif


add: objectClasses

objectClasses: ( 2.16.840.1.113730.3.2.175 NAME 'iplanet-am-session-service' DESC 'Session Service OC' SUP top AUXILIARY MAY ( iplanet-am-session-max-session-time $ iplanet-am-session-max-idle-time $ iplanet-am-session-max-caching-time $ iplanet-am-session-get-valid-sessions $ iplanet-am-session-destroy-sessions $ iplanet-am-session-add-session-listener-on-all-sessions $ iplanet-am-session-service-status ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.176 NAME 'iplanet-am-user-service' DESC 'User Service OC' SUP top AUXILIARY MAY ( iplanet-am-user-auth-modules $ iplanet-am-user-login-status $ iplanet-am-user-admin-start-dn $ iplanet-am-user-auth-config $ iplanet-am-user-alias-list $ iplanet-am-user-success-url $ iplanet-am-user-failure-url $ iplanet-am-user-federation-info-key $ iplanet-am-user-federation-info $ iplanet-am-user-password-reset-options $ iplanet-am-user-password-reset-question-answer $ iplanet-am-user-password-reset-force-reset $ sunIdentityServerDiscoEntries ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.177 NAME 'iplanet-am-web-agent-service' DESC 'Web Agent Service OC' SUP top AUXILIARY MAY ( iplanet-am-web-agent-access-allow-list $ iplanet-am-web-agent-access-deny-list $ iplanet-am-web-agent-access-not-enforced-list $ iplanet-am-web-agent-service-status ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.179 NAME 'iplanet-am-managed-role' DESC 'Managed Role OC' SUP top AUXILIARY MAY ( iplanet-am-role-type $ iplanet-am-role-description $ iplanet-am-role-aci-description $ iplanet-am-role-aci-list $ iplanet-am-role-service-options $ iplanet-am-role-any-options $ iplanet-am-role-managed-container-dn $ iplanet-am-role-display-options) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.180 NAME 'iplanet-am-managed-group' DESC 'Managed Group OC' SUP top AUXILIARY MAY ( iplanet-am-group-subscribable $ inetgroupstatus ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.181 NAME 'iplanet-am-managed-filtered-group' DESC 'Managed Filter Group OC' SUP iplanet-am-managed-group AUXILIARY X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.182 NAME 'iplanet-am-managed-assignable-group' DESC 'Managed Assignable Group OC' SUP iplanet-am-managed-group AUXILIARY X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.183 NAME 'iplanet-am-managed-static-group' DESC 'Managed Static Group OC' SUP iplanet-am-managed-group AUXILIARY X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.184 NAME 'iplanet-am-managed-person' DESC 'Managed Person OC' SUP top AUXILIARY MAY ( iplanet-am-modifiable-by $ iplanet-am-static-group-dn $ iplanet-am-user-account-life ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.186 NAME 'iplanet-am-managed-org-unit' DESC 'Managed OrganizationalUnit OC' SUP top AUXILIARY MAY ( sunPreferredDomain $ associatedDomain $ sunPreferredOrganization $ sunAdditionalTemplates $ sunOverrideTemplates $ iplanet-am-service-status ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.187 NAME 'iplanet-am-managed-people-container' DESC 'Managed People Container OC' SUP top AUXILIARY X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.189 NAME 'iplanet-am-managed-group-container' DESC 'Managed Group Container OC' SUP top AUXILIARY X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.166 NAME 'iplanet-am-managed-policy' DESC 'Managed Name Policy OC' SUP top AUXILIARY MAY iplanet-am-named-policy-dn X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 2.16.840.1.113730.3.2.167 NAME 'iplanet-am-domain-url-access-service' DESC 'Domain URL Access Service OC' SUP top AUXILIARY MAY iplanet-am-domain-url-access-allow X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.22 NAME 'iplanet-am-saml-service' DESC 'SAML Service OC' SUP top AUXILIARY MAY ( iplanet-am-saml-user $ iplanet-am-saml-password ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.23 NAME 'iplanet-am-auth-configuration-service' DESC 'Authentication Configuration Service OC' SUP top AUXILIARY MAY ( iplanet-am-auth-configuration $ iplanet-am-auth-login-success-url $ iplanet-am-auth-login-failure-url $ iplanet-am-auth-post-login-process-class ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.25 NAME 'sunservice' DESC 'object containing service information' SUP top MUST ou MAY ( labeleduri $ sunserviceschema $ sunkeyvalue $ sunxmlkeyvalue $ sunpluginschema $ description ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.26 NAME 'sunorgservice' DESC 'Service information specific to organizations' SUP top MUST ou MAY ( sunkeyvalue $ sunxmlkeyvalue $ description ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.27 NAME 'sunservicecomponent' DESC 'Sub-components of the service' SUP top MUST ou MAY ( sunserviceid $ sunsmspriority $ sunkeyvalue $ sunxmlkeyvalue $ description ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.28 NAME 'sunserviceplugin' DESC 'Object that stores information specific to plugins' SUP top MUST ou MAY ( sunpluginid $ sunkeyvalue $ sunxmlkeyvalue $ sunsmspriority ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.74 NAME 'iplanet-am-managed-filtered-role' DESC 'Managed Filtered Role OC' SUP iplanet-am-managed-role AUXILIARY X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( sunISManagedOrganization-oid NAME 'sunISManagedOrganization' DESC 'Sun Java System objectclass to identify organizations' SUP top AUXILIARY MAY ( sunOrganizationAlias ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( sunIdentityServerDiscoveryService-OID NAME 'sunIdentityServerDiscoveryService' DESC 'Discovery Service OC' SUP top AUXILIARY MAY ( sunIdentityServerDynamicDiscoEntries ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( sunIdentityServerLibertyPPService-oid NAME 'sunIdentityServerLibertyPPService' DESC 'sunIdentityServerLibertyPPService OC' SUP top AUXILIARY MAY ( sunIdentityServerPPCommonNameCN $ sunIdentityServerPPCommonNameALTCN $ sunIdentityServerPPCommonNameFN $ sunIdentityServerPPCommonNameSN $ sunIdentityServerPPCommonNamePT $ sunIdentityServerPPCommonNameMN $ sunIdentityServerPPInformalName $ sunIdentityServerPPLegalIdentityLegalName $ sunIdentityServerPPLegalIdentityDOB $ sunIdentityServerPPLegalIdentityMaritalStatus $ sunIdentityServerPPLegalIdentityGender $ sunIdentityServerPPLegalIdentityAltIDType $ sunIdentityServerPPLegalIdentityAltIDValue $ sunIdentityServerPPLegalIdentityVATIDType $ sunIdentityServerPPLegalIdentityVATIDValue $sunIdentityServerPPEmploymentIdentityJobTitle $sunIdentityServerPPEmploymentIdentityOrg $ sunIdentityServerPPEmploymentIdentityAltO ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( sunIdentityServerDevice-OID NAME 'sunIdentityServerDevice' DESC 'Device OC' SUP top AUXILIARY MAY ( cn $ uid $ sunIdentityServerDeviceVersion $ sunIdentityServerDeviceType $ userpassword $ sunIdentityServerDeviceKeyValue $ sunxmlkeyvalue $ description $ sunIdentityServerDeviceStatus ) X-ORIGIN 'Sun Java System Identity Management' )

マーカーオブジェクトクラス

Identity Server コンソールを使用して作成し、Directory Server 内に格納したアイデンティティエントリには、マーカーオブジェクトクラスが追加されます。マーカーオブジェクトクラスは、指定されたエントリを Identity Server が管理するエントリとして定義します。オブジェクトクラスは、サーバーやハードウェアなど、ディレクトリツリーの他の面には影響を与えません。また、既存のアイデンティティエントリは、これらのオブジェクトクラスを含めるようにエントリを変更しない限り、Identity Server を使用して管理することはできません。マーカーオブジェクトクラスの詳細は、『Identity Server 2004Q2 Developer's Guide』の第 5 章「Identity Management」を参照してください。既存の Directory Server データを Identity Server で使用するために移行する方法については、『Identity Server 2004Q2 Migration Guide』を参照してください。

管理ロール

LDAP エントリの委任された管理 (Identity Server 内の各アイデンティティ関連オブジェクトにマップされる) は、定義済みのロールおよびアクセス制御命令 (ACI) を使用して実装されます。デフォルトの管理ロールおよびその定義済み ACI は、Identity Server のインストール時に作成され、Identity Server コンソールを使用して表示および管理できます。Identity Server のアイデンティティ関連オブジェクトが作成されると、適切な管理ロール (および対応する ACI) も作成され、そのオブジェクトの LDAP エントリに割り当てられます。その後、ロールは、そのオブジェクトのノード制御を管理する個々のユーザーに割り当てることができます。たとえば、Identity Server が組織を新規作成すると、いくつかのロールが自動的に作成され、Directory Server に格納されます。

これらのロールのいずれかをユーザーに割り当てると、そのロールに適したすべてのアクセス権がユーザーに与えられます。表 4-1 に、Identity Server 管理ロールおよび、各ロールに対応する書き込み権限の範囲を示します。

表 4-1 デフォルトおよび動的なロールとそのアクセス権
ロール	管理サフィックス	アクセス権
最上位組織の管理者 (amadmin)	ルートレベル	最上位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権
最上位組織のヘルプデスク管理者	ルートレベル	最上位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権
最上位組織のポリシー管理者	ルートレベル	最上位組織内で作成されたポリシーに対する読み取りおよび書き込みアクセス権のみ。参照ポリシー作成を委任するため、下位組織により使用される
組織管理者	組織のみ	作成された下位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ
組織のヘルプデスク管理者	組織のみ	作成された下位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ
組織ポリシー管理者 (Organization Policy Admin)	組織のみ	作成された下位組織内のすべてのポリシーに対する読み取りおよび書き込みアクセス権のみ
コンテナ管理者 (Container Admin)	コンテナのみ	作成されたコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ
コンテナヘルプデスク管理者 (Container Help Desk Admin)	コンテナのみ	作成されたコンテナ内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ
グループ管理者	グループのみ	作成されたグループ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ
ピープルコンテナ管理者	ピープルコンテナのみ	作成されたピープルコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ
ユーザー (自己管理者)	ユーザーのみ	ユーザーエントリ内のすべての属性に対する読み取りおよび書き込みアクセス権のみ

グループベースの ACI の代わりにロールを使用すると、効率を高め、保守の手間を少なくすることができます。フィルタ処理されたロールは、ユーザーの nsRole 属性の確認のみを行うため、LDAP クライアントの処理が簡略化されます。ロールは、そのメンバーの親のピアでなければならない、という範囲制限の影響を受けます。デフォルト ACI の詳細は、『Sun Java System Identity Server 管理ガイド』の第 14 章「管理属性」を参照してください。

管理者パスワード

Identity Server のインストール中には、管理者ユーザー ID (amadmin) と LDAP ユーザー ID (amldapuser) のパスワードを入力する必要があります。

serverconfig.xml ファイルには、Identity SDK が Directory Server への LDAP 接続プールを確立するために使用するパラメータが含まれます。たとえば、次のユーザーです。

これらのユーザーにはそれぞれのパスワードが伴い、serverconfig.xml ファイルに暗号化された形式で格納されています。もちろん、これらのパスワード (特に puser パスワード) を常に保護する必要がありますが、次の点にも注意してください。

puser および dsameuser のパスワードの変更については、『Identity Server 2004Q2 管理ガイド』のamPassword コマンド行ツールを参照してください。

スキーマの制限

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

以下の項で、Identity Server スキーマに課される制限について説明します。

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

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

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

この規則には 1 つの例外があります。Identity Server ルートサフィックスでのエントリは、1 つのエントリには数えられません。したがって、次の例の DIT 構造は、Identity Server で管理できます。

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

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

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

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

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

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

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

次の例で、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 は Identity Server では動作しません。

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

前へ目次索引次へ
Sun Java System Identity Server 2004Q2 配備計画ガイド