Sun Java System Access Manager 7.1 配備計画ガイド

第 3 章技術要件

ソリューションのライフサイクルにおける技術要件段階では、使用状況を分析し、ユースケースを特定して、提案された配備ソリューションの QoS 要件を決定します。この章では、Sun Java^TM System Access Manager 7.1 での、この処理に関する要件の大まかな技術概要を示します。次の節で構成されています。

配備オプション

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

配備環境でどれくらいのユーザーをサポートすることが見込まれているか。予測される成長率はどれくらいか

ユーザーの成長およびシステムの使用状況を監視し、この実データを予測されるデータと比較して、現在の能力で予測される成長を処理可能であることを確認することは重要です。
環境にサービスを追加する計画はあるか。それは現在の設計に影響を及ぼす可能性があるか

これで、開発中のアーキテクチャーは、現在のサービスに対して最適化されます。将来の計画も検討する必要があります。

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

セキュリティー

セキュリティーの確保された内部および外部ネットワーク環境を計画している場合には、以下の選択肢について考慮してください。

サーバーベースのファイアウォールは、サーバーへのポートレベルのアクセスを制限することにより、追加セキュリティーレイヤーを提供します。標準のファイアウォールと同様、サーバーベースのファイアウォールは、着信および送信 TCP/IP トラフィックを制限します。
最小化とは、システムの脆弱性が悪用される可能性を最小限に抑えるために、不要なソフトウェアおよびサービスをすべてサーバーから削除することをいいます。
分割 DNS インフラストラクチャーには、1 つのドメイン内に 2 つのゾーンが作成されます。1 つのゾーンは組織の内部ネットワーククライアントにより使用され、もう1 つのゾーンは外部ネットワーククライアントにより使用されます。この手法は、より高度なセキュリティーレベルを実現するために推奨されています。DNS サーバーでロードバランサを使用することによって、パフォーマンスを向上させることもできます。

高可用性

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

Access Manager Web コンテナ
Directory Server
Java 仮想マシン (JVM)
Directory Server ハードディスク
Access Manager ハードディスク
ポリシーエージェント

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

クラスタリング

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

スケーラビリティー

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

ハードウェア要件

Access Manager を配備する場合の最小構成は、Access Manager と Sun Java System Web Server などの Web コンテナを実行する 1 台のホストサーバーです。Directory Server が稼働するサーバーは、Access Manager と同じでも、違ってもかまいません。複数のサーバーが配備されている環境では、Access Manager インスタンスとそれに対応する Web コンテナは異なるホストサーバーにインストールされ、クライアントの要求は、ロードバランサによって各 Access Manager インスタンスに分配されます。通常、Directory Server と Access Manager は別々のサーバーにインストールされます。

パフォーマンスを最適化するために、Access Manager は 100M バイト以上の Ethernet ネットワーク上で実行してください。Access Manager と 1 つのWeb コンテナを実行する Access Manager 配備の最小構成には、1 個以上の CPU を搭載している必要がありますが、5 個以上の CPU を搭載してもプロセッサのパフォーマンスはそれほど向上しません。ホストサーバーごとに 2 〜 4 個の CPU を強くお勧めします。ソフトウェアの基本的なテストを実行するために、512M バイト以上の RAM が必要です。

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

ソフトウェア要件

Access Manager には、次のような固有のソフトウェア要件があります。

サポートされるリリース、必要なパッチ、および既知の制限を含むソフトウェア要件の最新情報については、『Sun Java System Access Manager 7.1 リリースノート』を参照してください。

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

Access Manager 7.1 は、次のプラットフォームでサポートされています。

Solaris^TM 10 OS (SPARC®、x86、および x64 ベースのシステム)
Solaris 9 OS (SPARC および x86 システム)
Red Hat^TM Linux OS
Microsoft Windows OS
HP-UX OS

サポートされる各オペレーティングシステムの特定のバージョンについては、『Sun Java System Access Manager 7.1 リリースノート』を参照してください。

OS パッチおよびパッチクラスタのダウンロード方法については、http://sunsolve.sun.com/ にある SunSolve Online にアクセスしてください。

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

Web コンテナ要件

Access Manager 7.1 は、完全インストール、または SDK のみのインストールのいずれかでの使用に関して、次の Web コンテナをサポートしています。

Sun Java System Web Server
Sun Java System Application Server
BEA WebLogic
IBM WebSphere Application Server

注 –

BEA WebLogic および IBM WebSphere Application Server は、HP-UX システムではサポートされていません。

これらの Web コンテナのサポートされているバージョンについては、『Sun Java System Access Manager 7.1 リリースノート』を参照してください。

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

Directory Server 要件

Access Manager 7.1 には、LDAP ディレクトリサーバーに対する次の要件があります。

Access Manager 情報ツリーが Sun Java System Directory Server に格納されていること。情報ツリーには次の情報が含まれます。
- ユーザー認証の方法
- ユーザーがアクセス可能なリソース
- ユーザーがリソースへのアクセス権を取得したあとに、アプリケーションで使用可能になる情報
Access Manager には、ユーザーやグループなどのユーザーデータを格納するためのアイデンティティーリポジトリが必要です。Access Manager 7.1 は、Sun Java System Directory Server または LDAP バージョン 3 (LDAP v3) 互換のディレクトリサーバーをアイデンティティーリポジトリとして使用できます。

Access Manager 情報ツリーおよびアイデンティティーリポジトリについては、『Sun Java System Access Manager 7.1 Technical Overview』を参照してください。

Java Development Kit (JDK) ソフトウェア要件

Access Manager 7.1 に必要な JDK ソフトウェアの特定のバージョンについては、『Sun Java System Access Manager 7.1 リリースノート』を参照してください。

Access Manager セッションフェイルオーバー要件

Access Manager セッションフェイルオーバーを実装することを計画している場合、以下のコンポーネントが必要です。

Access Manager を実行する Web コンテナ: Sun Java System Web Server、Sun Java System Application Server、IBM WebSphere Application Server、または BEA WebLogic。
Sun Java System Directory Server: すべての Access Manager インスタンスが、同じ Directory Server にアクセスする必要があります。
Sun Java System Message Queue。Message Queue ブローカクラスタは、Access Manager インスタンスとセッションストアデータベースの間のセッションメッセージを管理します。
Berkeley DB (http://www.oracle.com/database/berkeley-db.html) はデフォルトのセッションストアデータベースです。Sun Java Enterprise System 5 リリースによって配布されるバーションを使用します。

Access Manager のセッションフェイルオーバーは以下のプラットフォームでサポートされています。

Solaris 10 OS (SPARC、x86、および x64 ベースのシステム)
Solaris 9 OS (SPARC および x86 システム)
Red Hat Linux OS
Microsoft Windows OS
HP-UX OS

これらのプラットフォームおよびコンポーネントがサポートされるバージョンに関する最新の情報については、『Sun Java System Access Manager 7.1 リリースノート』を参照してください。

詳細は、『Sun Java System Access Manager 7.1 Postinstallation Guide』の第 6 章「Implementing Session Failover」を参照してください。

Web ブラウザ要件

Access Manager 管理者およびエンドユーザーは、Web ブラウザを使用して、管理タスクおよびユーザー管理タスクを実行します。このリリースでサポートされる Web ブラウザについては、『Sun Java System Access Manager 7.1 リリースノート』を参照してください。

Access Manager コンソールにアクセスするには、ブラウザで JavaScript を有効にする必要があります。

JSSE 暗号化要件

セキュリティー保護されたインターネット通信を実装するために、次の配備シナリオまたはアクティビティーでは、Access Manager 7.1 で JSS 暗号化の代わりに Java Secure Socket Extension (JSSE) 暗号化を使用する必要があります。

SSL 対応 Web コンテナインスタンスへのクライアント SDK 配備
SSL 対応 Web コンテナインスタンスへの分散認証配備
SSL 対応 Web コンテナインスタンスへの単一の Access Manager 7.1 WAR ファイル配備
SSL 対応 Access Manager サーバーでの com.sun.identity.idm API の使用
SSL 対応サードパーティー Web コンテナインスタンス (BEA WebLogic または IBM WebSphere Application Server) への Access Manager 配備

JSSE に関する情報およびダウンロードについては、次の Sun Developer Network (SDN) Web サイトを参照してください。http://java.sun.com/products/jsse/

管理ユーザー

Access Manager 配備の技術要件を評価するときは、次の管理ユーザーおよび管理アカウントについて考慮します。

Access Manager の管理ロール

レルムモードの管理ロール

Access Manager のレルムモードでは、委任プラグインがアイデンティティーリポジトリプラグインと連携して、ネットワーク管理者の権限の有効範囲を決定します。デフォルトの管理者ロールはアイデンティティーリポジトリプラグインで定義されます。委任プラグインは、個々のネットワーク管理者の権限の有効範囲を記述するルールを形成するとともに、そのルールが適用されるロールを指定します。次の表に、アイデンティティーリポジトリで定義されるロールと、委任プラグインが各ロールに適用するデフォルトルールの一覧を示します。

表 3–1 レルムモードでの Access Manager のロールと権限の有効範囲


アイデンティティーリポジトリのロール	委任ルール
レルム管理者	Access Manager 情報ツリーのすべてのレルム内にあるすべてのデータにアクセスできます。
サブレルム管理者	Access Manager 情報ツリーの特定のレルム内にあるすべてのデータにアクセスできます。
ポリシー管理者	Access Manager 情報ツリーのすべてのレルム内にあるすべてのポリシーにアクセスできます。
ポリシーレルム管理者	Access Manager 情報ツリーの特定レルム内部にあるポリシーのみにアクセスできます。

認証サービスとポリシーサービスは、集積されたデータを使用して認証および承認のプロセスを実行します。委任プラグインおよびアイデンティティーリポジトリプラグインのコードは、Access Manager で公開されていません。

旧バージョンモードの管理ロール

Access Manager の旧バージョンモードでは、LDAP エントリの委任管理 (Access Manager 内の各アイデンティティー関連オブジェクトにマップされる) は、定義済みのロールおよびアクセス制御命令 (ACI) を使用して実装されます。デフォルトの管理ロールおよびその定義済み ACI は、Access Manager のインストール時に作成され、Access Manager コンソールを使用して表示および管理できます。Access Manager 7.1 のレルムモードでは、ロールは ACI ではなくポリシーに依存します。

Access Manager のアイデンティティー関連オブジェクトが作成されると、適切な管理ロール (および対応する ACI) も作成され、そのオブジェクトの LDAP エントリに割り当てられます。そのあと、ロールは、そのオブジェクトのノード制御を管理する個々のユーザーに割り当てることができます。たとえば、Access Manager が組織を新規作成すると、いくつかのロールが自動的に作成され、Directory Server に格納されます。

組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。
組織のヘルプデスク管理者は、設定済み組織のすべてのエントリに対する読み取りアクセス権、およびこれらのエントリ内の userPassword 属性に対する書き込みアクセス権を持っています。
組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。

これらのロールのいずれかをユーザーに割り当てると、そのロールに与えられたすべてのアクセス権がユーザーに与えられます。

次の表に、Access Manager 管理ロール、および各ロールに適用される権限の要約を示します。

表 3–2 旧バージョンモードでのデフォルトロールおよび動的ロールと各ロールのアクセス権


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

グループベースの ACI の代わりにロールを使用すると、効率を高め、保守の手間を少なくすることができます。フィルタ処理されたロールは、ユーザーの nsRole 属性の確認のみを行うため、LDAP クライアントの処理が簡略化されます。ロールは、そのメンバーの親のピアでなければならない、という範囲制限の影響を受けます。

デフォルトACI については、Access Manager コンソールのオンラインヘルプを参照してください。

Access Manager の管理アカウント

Access Manager のインストール時には、次の管理アカウントが作成されます。

管理者ユーザー ID (amadmin) は、Access Manager の最上位管理者で、Access Manager によって管理されるすべてのエントリに無制限にアクセスできます。デフォルト名の amadmin を変更することはできません。

インストール中に、amadmin のパスワードを入力する必要があります。インストール後に amadmin のパスワードを変更するには、Access Manager 管理コンソールを使用します。
LDAP、メンバーシップ、およびポリシーサービスのバインド DN ユーザー ( amldapuser) は、すべての Directory Server エントリに対する読み取りおよび検索アクセス権を持つ管理ユーザーです。デフォルト名の amldapuser を変更することはできません。

インストール中に、amldapuser のパスワードを入力する必要があります。amadmin と同じパスワードは使用しないでください。インストール後に amldapuser のパスワードを変更するには、Directory Server コンソールか ldapmodify ユーティリティーを使用します。

amldapuser のパスワードを変更した場合は、LDAP 認証サービスとポリシー設定サービスにも、この変更を反映させる必要があります。amldapuser は、これらのサービスで使用されているデフォルトユーザーだからです。この変更は、これらのサービスを登録している組織ごとに行う必要があります。
プロキシユーザー (puser) は、任意のユーザー (組織管理者またはエンドユーザーなど) の権限を引き受けることができます。
管理ユーザー (dsameuser) は、Access Manager SDK が、特定のユーザーにリンクされていない Directory Server 上で、サービス設定情報の取得などの操作を実行するときバインドするために使用されます。

puser および dsameuser は関連付けられたパスワードを所有し、それぞれのパスワードは serverconfig.xml に暗号化された形式で格納されています。このファイルは次のディレクトリ内にあります。

Solaris システム: /etc/opt/SUNWam/config
Linux および HP-UX システム: /etc/opt/sun/identity/config
Windows システム: javaes-install-dir\identity\config

javaes-install-dir 変数は Java ES 5 のインストールディレクトリを表します。デフォルト値は C:\Program Files\Sun\JavaES5 です。

インストール後に、puser および dsameuser のパスワードを変更することをお勧めします。ただし、amadmin や amldapuser に使用したものと同じパスワードを使用しないでください。puser または dsameuser のパスワードを変更するには、ampassword ユーティリティーを使用します。

ampassword --admin (または -a) オプションでは、dsameuser のパスワードが変更されます。(このオプションでは、amadmin のパスワードは変更されません。)
ampassword --proxy (または -p) オプションでは、puser のパスワードが変更されます。

puser と dsameuser のどちらのパスワードを変更するかは、ユーザーの配備によって決まります。

Access Manager が単一のホストサーバー上に配備されている場合は、次の手順を実行します。

ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。
Access Manager Web コンテナを再起動します。

Access Manager が複数のホストサーバー上に配備されている場合は、次の手順を実行します。

最初のサーバー上で、ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。
ampassword --encrypt (または -e) オプションを使用して、新しいパスワードを暗号化します。
Access Manager の配備されているその他の各サーバー上で、手順 2 で暗号化した新しいパスワードを使用して、serverconfig.xml ファイル内のパスワードを手動で変更します。
パスワードを変更した各サーバー上 (最初のサーバーを含む) で、Access Manager Web コンテナを再起動します。

ampassword ユーティリティーについては、『Sun Java System Access Manager 7.1 Administration Reference 』を参照してください。

ポリシーエージェントの管理ユーザー

Access Manager Policy Agent 2.2 ソフトウェアセットのポリシーエージェントは、その AMAgent.properties ファイルに保存されたユーザー名とパスワードを使用して Access Manager への認証を行います。このプロセスは「Web エージェント」と「J2EE エージェント」では似ている部分もありますが、多少の違いがあります。

Web エージェント

Web エージェントは、AMAgent.properties ファイルの次のプロパティーを使用して、Access Manager への認証に使用する自身のユーザー名とパスワードを保存します。

com.sun.am.policy.am.username には、Web エージェントが Access Manager にログインするために使用するユーザー名が格納されます。デフォルト名は UrlAccessAgent です。
com.sun.am.policy.am.password には、Web エージェントが Access Manager にログインするために使用するユーザーの暗号化されたパスワードが格納されます。パスワードは crypt_util ユーティリティーを使用して暗号化する必要があります。

Access Manager インスタンスを最初に設定するとき、Java ES インストーラまたは amconfig スクリプトによって、amldapuser ユーザーと同じパスワードを持つ amService-UrlAccessAgent ユーザーが最上位レベルレルムに作成されます。

デフォルトでは、すべての Web エージェントが同じユーザー名とパスワードを使用して Access Manager インスタンスへの認証を行います。セキュリティーを強化し、各 Web エージェントが一意の名前とパスワードを使用できるようにするために、Web エージェントが認証時に使用するエージェントプロファイルを Access Manager 管理コンソールで作成できます。詳細は、「エージェントプロファイルを使用した認証」を参照してください。

J2EE エージェント

J2EE エージェントは、Access Manager 管理コンソールで作成されたエージェントプロファイルによるユーザー名 (エージェント ID) とパスワードを使用して Access Manager と通信します。エージェントプロファイルが作成されると、J2EE エージェントは AMAgent.properties ファイルの次のプロパティーを使用してユーザー名 (エージェント ID) とパスワードを保存します。

com.sun.identity.agents.app.username には、J2EE エージェントが Access Manager へのログインに使用するユーザー名 (エージェント ID) が格納されます。
com.iplanet.am.service.secret には、J2EE エージェントが Access Manager へのログインに使用するユーザー名 (エージェント ID) の暗号化されたパスワードが格納されます。パスワードは agentadmin ユーティリティーと --encrypt オプションを使用して暗号化する必要があります。

エージェントプロファイルについては、次の節を参照してください。

エージェントプロファイルを使用した認証

Access Manager への認証を行うには、J2EE エージェントが使用するエージェントプロファイルを Access Manager 管理コンソールで作成する必要があります。Web エージェントもエージェントプロファイルを使用できます。これにより、各 Web エージェントに一意のユーザー名 (エージェント ID) とパスワードを設定できるようになります。エージェントプロファイルの作成手順については、Access Manager コンソールのオンラインヘルプを参照してください。

エージェントプロファイルを使用すると、ポリシーエージェントのパスワードとユーザー名 (エージェント ID) を、配備ごとの必要に応じて変更できるようにもなります。必要な場合にパスワードとユーザー名を変更するには、次の一般的な手順に従います。

Access Manager 管理者 (amadmin) として Access Manager コンソールにログインします。
ポリシーエージェントのエージェントプロファイルで、必要に応じてパスワードとユーザー名 (エージェント ID) を変更します。プロファイルを保存します。
手順 2 で変更した新しいエージェントパスワードを、Web エージェントの場合は crypt_util ユーティリティーを使用して、J2EE エージェントの場合は agentadmin ユーティリティーと --encrypt オプションを使用して暗号化します。
ポリシーエージェントの AMAgent.properties ファイルで、次のプロパティーを設定します。
- Web エージェントの場合: com.sun.am.policy.am.password プロパティーに、手順 3 で新しく暗号化したパスワードを設定します。ユーザー名 (エージェント ID) も変更した場合は、com.sun.am.policy.am.username プロパティーに、手順 2 で変更した新しいユーザー名 (エージェント ID) を設定します。
- J2EE エージェントの場合: com.iplanet.am.service.secret プロパティーに、手順 3 で新しく暗号化したパスワードを設定します。ユーザー名 (エージェント ID) も変更した場合は、com.sun.identity.agents.app.username プロパティーに、手順 2 で変更した新しいユーザー名 (エージェント ID) を設定します。
新しいパスワード (および、変更した場合は新しいユーザー名) を有効にするために、Web エージェントの Web コンテナを再起動します。

エージェントプロファイルの作成および設定とパスワードの暗号化については、Access Manager Policy Agent 2.2 のマニュアルコレクションを参照してください。

http://docs.sun.com/coll/1322.1

匿名ユーザー

匿名モジュールが有効な場合、匿名ユーザーはパスワードを提供しなくても Access Manager にログインできます。デフォルトの匿名ユーザーは anonymous ですが、Access Manager 管理コンソールで次のレルム属性を設定することにより、名前の変更や、匿名ユーザーのリストの定義を行うことができます。

「有効な匿名ユーザー」では、匿名アクセスを許可するユーザー ID のリストを指定します。
「デフォルトの匿名ユーザー名」では、デフォルト値 (anonymous) 以外のユーザー名を指定できます。この名前は「有効な匿名ユーザー」リストが空の場合に使用されます。
「ユーザー ID の大文字と小文字を区別する」では、匿名ユーザー ID の大文字と小文字を区別する必要があることを指定します。デフォルトでは、ユーザー ID の大文字と小文字は区別されません。
「認証レベル」では、匿名ユーザーのアクセスの種類を、読み取りと検索のみなど、特定のものに制限します。デフォルト値は 0 です。

これらの属性はレルムに適用されるため、レルムごとに異なる匿名アクセス属性を設定できます。

匿名モジュールの有効化と匿名ユーザーの作成については、Access Manager コンソールのオンラインヘルプを参照してください。

Access Manager スキーマ

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

Access Manager は、Sun Java System Directory Server をデータリポジトリとして使用します。このリポジトリには Directory Server スキーマを拡張する Access Manager スキーマが組み込まれています。Access Manager のインストール時に、ds_remote_schema.ldif と sunone_schema2.ldif のファイルで構成される Access Manager スキーマは、Directory Server スキーマと統合されます。ds_remote_schema.ldif ファイルは、Access Manager が固有に使用する LDAP オブジェクトクラスと属性を定義します。sunone_schema2.ldif ファイルは、Access Manager LDAP スキーマのオブジェクトクラスと属性をロードします。

ds_remote_schema.ldif、sunone_schema2.ldif 、およびその他の Access Manager LDIF ファイルは、以下のディレクトリにあります。

Solaris システム: /etc/opt/SUNWam/config/ldif
Linux および HP-UX システム: /etc/opt/sun/identity/config/ldif
Windows システム: javaes-install-dir\identity\config\ldif

javaes-install-dir 変数は Java ES 5 のインストールディレクトリを表します。デフォルト値は C:\Program Files\Sun\JavaES5 です。

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

Access Manager コンソールを使用して作成し、Directory Server 内に格納したアイデンティティーエントリには、マーカーオブジェクトクラスが追加されます。マーカーオブジェクトクラスは、指定されたエントリを Access Manager が管理するエントリとして定義します。オブジェクトクラスは、サーバーやハードウェアなど、ディレクトリツリーのほかの面には影響を与えません。また、既存のアイデンティティーエントリは、これらのオブジェクトクラスを含めるようにエントリを変更しない限り、Access Manager を使用して管理することはできません。マーカーオブジェクトクラスについては、『Access Manager 開発者ガイド』を参照してください。既存の Directory Server データを Access Manager で使用するために移行する方法については、『 Sun Java Access Manager 6 2005Q1 Migration Guide』を参照してください。

スキーマの制限

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 がある場合、両方のエントリを組織としてマークすることはできません。

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

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

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

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

この例の場合は、o= と ou= の両方のエントリを組織としてマークすることはできませんが、o= エントリを組織としてマークし、ou= エントリをコンテナとしてマークすることができます。コンソールに表示されるときに、組織とコンテナで利用できるオプションは同じです。ピープルコンテナ、グループ、ロール、およびユーザーなどの従属エントリや下位エントリは両方で作成できます。

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

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

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 で動作しません。

第 3 章 技術要件