test

Sun Java System Access Manager 7.1 管理ガイド

パート II ディレクトリ管理とデフォルトサービス

これは『Sun Java System Access Manager 7.1 管理ガイド』の第 2 部です。「ディレクトリ管理」の章では、Access Manager を旧バージョンモードで配備するときにディレクトリオブジェクトを管理する方法について説明します。その他の章では、Access Manager の一部のデフォルトサービスを設定および使用する方法について説明します。次の章で構成されています。

第 7 章 ディレクトリ管理

「ディレクトリ管理」タブは、Access Manager を旧バージョンモードでインストールした場合にのみ表示されます。このディレクトリ管理機能は、Sun Java System の Directory Server に対応した Access Manager の配備に必要なアイデンティティー管理ソリューションを提供します。

インストール時の旧バージョンモードオプションについては、『Sun Java Enterprise System 5 インストールガイド (UNIX 版)』を参照してください。

ディレクトリオブジェクトの管理

「ディレクトリ管理」タブには、Directory Server オブジェクトの表示および管理に必要なすべてのコンポーネントが含まれています。この節では、オブジェクトタイプと、それらを設定する方法の詳細について説明します。Access Manager コンソールまたはコマンド行インタフェースを使用して、ユーザー、ロール、グループ、組織、サブ組織、およびコンテナの各オブジェクトを定義、修正、または削除できます。コンソールには、ディレクトリオブジェクトを作成および管理する権限が異なる、複数のデフォルト管理者が存在しています。ロールに基づいて、管理者を追加作成できます。管理者は、Access Manager でインストールしたときに、Directory Server 内に定義されます。次の Directory Server オブジェクトを管理できます。

組織

組織は、企業が部門とリソースの管理に使用する最上位レベルの階層構造を表します。インストール時に、Access Manager は最上位レベルの組織 (インストール時に定義) を動的に作成して、Access Manager の企業構成を管理します。インストール後に組織を追加作成して、企業を個別に管理できます。作成した組織はすべて、最上位レベルの組織の下に入ります。

Procedure組織を作成する

  1. 「ディレクトリ管理」タブをクリックします。

  2. 「組織」リストで、「新規」をクリックします。

  3. フィールドの値を入力します。「名前」だけが必須です。フィールドは次のとおりです。

    名前

    組織の名前の値を入力します。

    「ドメイン名」

    ドメインネームシステム (DNS) を使用している場合は、DNS の完全な名前を入力します。

    「組織の状態」

    「アクティブ」または「非アクティブ」の状態を選択します。デフォルトは「アクティブ」です。これは、その組織の存続期間中であればいつでも、「プロパティー」アイコンを選択して変更できます。「非アクティブ」を選択すると、その組織にログインした場合、ユーザーアクセスが無効になります。

    「組織のエイリアス」

    このフィールドでは、組織のエイリアス名を指定します。URL ログインで、認証にエイリアスを使用できるようになります。たとえば exampleorg という組織があり、エイリアスとして 123 および abc を指定すると、次の URL を使用して組織にログインできます。

    http://machine.example.com/amserver/UI/Login?org=exampleorg

    http://machine.example.com/amserver/UI/Login?org=abc

    http://machine.example.com/amserver/UI/Login?org=123

    組織のエイリアス名は、組織全体で一意でなければなりません。「一意の属性リスト」を使用して一意性を実現できます。

    「DNS エイリアス名」

    組織の DNS 名にエイリアス名を追加できます。この属性では、実際のドメインエイリアスだけを使用できます。ランダムな文字列は使用できません。たとえば example.com という DNS があり、exampleorg という組織のエイリアスとして example1.com および example2.com を指定すると、次の URL を使用して組織にログインできます。

    http://machine.example.com/amserver/UI/

    Login?org=exampleorg

    http://machine.example1.com/amserver/

    UI/Login?org=exampleorg

    http://machine.example2.com/amserver/

    UI/Login?org=exampleorg

    「一意の属性リスト」

    組織内のユーザー用に一意の属性名リストを追加できます。たとえば、電子メールアドレスを示す一意の属性名を追加した場合、同一の電子メールアドレスを持つ 2 人のユーザーを作成できなくなります。このフィールドには、コンマ区切りのリストも指定できます。リスト内の属性名は、どれも一意性を定義します。たとえば、このフィールドに次の属性名リストが指定されたとします。

    PreferredDomain, AssociatedDomain

    また、特定のユーザーに対して、PreferredDomain は http://www.example.com と定義されています。この場合、コンマ区切りのリスト全体が、その URL に関して一意であると定義されます。「一意の属性リスト」にネーミング属性「ou」を追加しても、デフォルトの groups、people コンテナでは一意性は要求されません。(ou=Groups、ou=People)。

    すべてのサブ組織で一意性が要求されます。

    注 –

    一意の属性はレルムモードには設定できません。また、一意の属性は、7.0 または 7.1 ベースのコンソールで旧バージョンモードに設定することもできません。一意の属性リストを作成するには、6.3 ベースのコンソールにログインする必要があります。詳細は、「旧バージョンモード 6.3 コンソール」を参照してください。

  4. 「了解」をクリックします。

    新しい組織が「組織」リストに表示されます。組織の作成時に定義したプロパティーを編集するには、編集対象の組織の名前をクリックし、プロパティーを変更して「保存」をクリックします。

Procedure組織を削除する

  1. 削除する組織名の横にあるチェックボックスを選択します。

  2. 「削除」をクリックします。

    注 –

    削除を実行するときに警告メッセージは表示されません。組織内のエントリがすべて削除されます。この操作を元に戻すことはできません。

ポリシーに組織を追加する

Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。

コンテナ

コンテナエントリは、オブジェクトクラスおよび属性が異なるために組織エントリが使用できない場合に使用します。Access Manager コンテナエントリと Access Manager 組織エントリは、必ずしも LDAP オブジェクトクラス organizationalUnit および organization と同等とはかぎらないことに留意してください。これらは抽象アイデンティティーエントリです。可能であれば、コンテナエントリではなく組織エントリを使用します。

注 –

コンテナの表示は必要に応じて行います。コンテナを表示するには、「設定」>「コンソールプロパティー」の「管理」サービスでコンテナを表示するようにオプションを選択します。

Procedureコンテナを作成する

  1. 新しいコンテナを作成する組織またはコンテナのリンクを選択します。

  2. 「コンテナ」タブをクリックします。

  3. 「コンテナ」リストで「新規」をクリックします。

  4. 作成するコンテナの名前を入力します。

  5. 「了解」をクリックします。

Procedureコンテナを削除する

  1. 「コンテナ」タブをクリックします。

  2. 削除するコンテナ名の横にあるチェックボックスを選択します。

  3. 「削除」をクリックします。

    注 –

    コンテナを削除すると、そのコンテナに含まれるオブジェクトがすべて削除されます。すべてのオブジェクトとサブコンテナが対象になります。

グループコンテナ

グループコンテナを使用してグループを管理します。グループコンテナにはグループとほかのグループコンテナだけを含めることができます。グループコンテナの「グループ」は、すべての管理されているグループの親エントリとしてダイナミックに割り当てられます。必要に応じて、グループコンテナを追加することができます。

注 –

グループコンテナの表示は必要に応じて行います。グループコンテナを表示するには、「設定」>「コンソールプロパティー」の「管理」サービスでグループコンテナを有効にするようにオプションを選択します。

Procedureグループコンテナを作成する

  1. 新しいグループコンテナを追加する組織またはグループコンテナのリンクを選択します。

  2. 「グループコンテナ」タブを選択します。

  3. 「グループコンテナ」リストで「新規」をクリックします。

  4. 「名前」フィールドに値を入力して、「了解」をクリックします。「グループコンテナ」リストに新しいグループコンテナが表示されます。

Procedureグループコンテナを削除する

  1. 削除対象のグループコンテナを含む組織に移動します。

  2. 「グループコンテナ」タブを選択します。

  3. 削除するグループコンテナの横にあるチェックボックスを選択します。

  4. 「削除」をクリックします。

グループ

グループは、共通の機能、特徴、または関心事を持つユーザーの集まりを表します。通常、このグループには関連付けられた権限はありません。グループは、組織内および管理されているほかのグループ内という、2 つのレベルに存在できます。ほかのグループ内に存在するグループは、サブグループと呼ばれます。サブグループは、親グループ内に「物理的に」存在する子ノードです。

Access Manager は、入れ子グループもサポートします。入れ子グループは、1 つのグループに含まれる既存のグループを表します。サブグループとは対照的に、入れ子グループは DIT 内のどこにでも存在できます。入れ子グループは、多数のユーザーに対するアクセス権の設定を簡単にします。

作成できるグループには、静的グループと動的グループの 2 種類があります。ユーザーを手動で追加できるのは静的グループのみです。動的グループでは、フィルタによってユーザーの追加が制御されます。入れ子グループまたはサブグループは、両方に追加できます。

静的グループ

静的グループは、指定した管理されているグループタイプに基づいて作成されます。グループメンバーは、groupOfNames または groupOfUniqueNames オブジェクトクラスを使用してグループエントリに追加されます。

注 –

管理されているグループタイプのデフォルトは dynamic です。このデフォルトは、管理サービス設定で変更できます。

動的グループ

動的グループは、LDAP フィルタを使用して作成されます。エントリはすべてフィルタを通してまとめられ、グループに動的に割り当てられます。フィルタはエントリの属性を検索して、その属性を含むエントリを返します。たとえば、建物番号に基づいてグループを作成する場合、フィルタを使用すると建物番号属性を含むすべてのユーザーのリストを返します。

注 –

Access Manager は、Directory Server とともに参照整合性プラグインを使用するように設定されている必要があります。参照整合性プラグインが有効になっているときは、削除操作や名前の変更操作の直後に、指定された属性について整合性更新が実行されます。これにより、関連するエントリ間の関係がデータベース全体で維持されます。Directory Server では、データベースインデックスによって検索パフォーマンスが向上します。このプラグインを有効にする方法の詳細は、『Sun Java System Access Manager 6 Migration Guide』を参照してください。

Procedure静的グループを作成する

  1. 新しいグループを作成する組織、グループ、またはグループコンテナに移動します。

  2. 「グループ」リストから「新規静的」をクリックします。

  3. 「グループ名」フィールドにグループの名前を入力します。「次へ」をクリックします。

  4. 「ユーザーのグループ加入を有効」属性を選択すると、ユーザーが自分でそのグループに加入できるようになります。

  5. 「了解」をクリックします。

    グループの作成後、グループの名前を選択して「一般」をクリックすることにより、「ユーザーのグループ加入を有効」属性を編集できます。

Procedure静的グループのメンバーを追加または削除する

  1. 「グループ」リストから、メンバーを追加するグループを選択します。

  2. 「アクションの選択」メニューで実行するアクションを選択します。実行できるアクションは次のとおりです。

    「新規ユーザー」

    このアクションでは、新規ユーザーが作成され、ユーザー情報の保存時にユーザーがグループに追加されます。

    「ユーザーの追加」

    このアクションでは、既存のユーザーがグループに追加されます。このアクションを選択する場合は、追加するユーザーを指定する検索条件を作成します。条件の作成に使用するフィールドでは、「いずれか」または「すべて」演算子を使用します。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。フィールドを空白のままにすると、その属性に関してはすべてのエントリが一致したとみなされます。

    検索条件を作成したら、「次へ」をクリックします。返されたユーザーのリストから、追加するユーザーを選択し、「終了」をクリックします。

    「グループを追加」

    このアクションでは、入れ子グループが現在のグループに追加されます。このアクションを選択すると、検索範囲、グループの名前 ("*" ワイルドカードを使用可能) を含む検索条件を作成し、ユーザーが自分でグループに加入できるかどうかを指定できます。情報を入力したら、「次へ」をクリックします。返されたグループのリストから、追加するグループを選択し、「終了」をクリックします。

    「メンバーを消去」

    このアクションでは、グループからメンバー (ユーザーとグループを含む) が消去されますが、メンバー自身の削除はされません。消去するメンバーを選択し、「アクションの選択」メニューから「メンバーを消去」を選択します。

    「メンバーを削除」

    このアクションでは、選択されたメンバー自身のエントリーが Directory Server から物理的に削除されます。削除するメンバーを選択し、「メンバーを削除」を選択します。

Procedure動的グループを作成する

  1. 新しいグループを作成する組織またはグループに移動します。

  2. 「グループ」タブをクリックします。

  3. 「新規動的」をクリックします。

  4. 「グループ名」フィールドにグループの名前を入力します。

  5. LDAP 検索フィルタを作成します。

    デフォルトでは、Access Manager は基本検索フィルタインタフェースを表示します。フィルタの作成に使用する基本フィールドでは、「いずれか」または「すべて」演算子を使用します。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。フィールドを空白のままにすると、その属性に関してはすべてのエントリが一致したとみなされます。

  6. 「了解」をクリックすると、検索条件に一致するすべてのユーザーが自動的にグループに追加されます。

Procedure動的グループのメンバーを追加または削除する

  1. 「グループ」リストで、メンバーを追加するグループの名前をクリックします。

  2. 「アクションの選択」メニューで実行するアクションを選択します。実行できるアクションは次のとおりです。

    「グループを追加」

    このアクションでは、入れ子グループが現在のグループに追加されます。このアクションを選択すると、検索範囲、グループの名前 ("*" ワイルドカードを使用可能) を含む検索条件を作成し、ユーザーが自分でグループに加入できるかどうかを指定できます。情報を入力したら、「次へ」をクリックします。返されたグループのリストから、追加するグループを選択し、「終了」をクリックします。

    「メンバーを消去」

    このアクションでは、グループからメンバー (グループを含む) が消去されますが、メンバー自身の削除はされません。消去するメンバーを選択し、「メンバーを消去」を選択します。

    「メンバーを削除」

    このアクションでは、選択されたメンバー自身のエントリーが Directory Server から物理的に削除されます。削除するメンバーを選択し、「メンバーを削除」を選択します。

ポリシーにグループを追加する

Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、ポリシーの「対象」ページで、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。

ピープルコンテナ

ピープルコンテナはデフォルトの LDAP 組織単位です。ユーザーはすべて、組織内で作成されるときにその組織単位に割り当てられます。ピープルコンテナは組織レベルで、あるいはサブピープルコンテナとしてピープルコンテナレベルで表示されます。ピープルコンテナにはほかのピープルコンテナとユーザーだけを含めることができます。必要に応じて、ピープルコンテナを組織に追加することができます。

注 –

ピープルコンテナの表示は必要に応じて行います。ピープルコンテナを表示するには、管理サービスで「ピープルコンテナを有効」を選択します

Procedureピープルコンテナを作成する

  1. ピープルコンテナを作成する組織またはピープルコンテナに移動します。

  2. 「ピープルコンテナ」リストで「新規」をクリックします。

  3. 作成するピープルコンテナの名前を入力します。

  4. 「了解」をクリックします。

Procedureピープルコンテナを削除する

  1. 削除対象のピープルコンテナを含む組織またはピープルコンテナに移動します。

  2. 削除するピープルコンテナ名の横にあるチェックボックスを選択します。

  3. 「削除」をクリックします。

    注 –

    ピープルコンテナを削除すると、そのピープルコンテナに含まれるオブジェクトがすべて削除されます。すべてのユーザーとサブピープルコンテナが対象になります。

ユーザー

ユーザーは、個人のアイデンティティーを表します。Access Manager のアイデンティティー管理モジュールを使用して、組織、コンテナ、およびグループに対するユーザーの作成と削除、ロールやグループに対するユーザーの追加と削除が可能です。サービスをユーザーに割り当てることもできます。

注 –

amadmin と同じユーザー ID でサブ組織のユーザーを作成すると、amadmin のログインが失敗します。このような問題が起こったら、管理者はディレクトリサーバーコンソールを使って、そのユーザーの ID を変更する必要があります。これで、管理者がデフォルトの組織にログインできるようになります。さらに、認証サービスの「ユーザー検索の開始 DN」をピープルコンテナ DN に設定し、ログイン処理で一意のユーザーが特定できます。

Procedureユーザーを作成する

  1. ユーザーを作成する組織、コンテナ、またはピープルコンテナに移動します。

  2. 「ユーザー」タブをクリックします。

  3. 「ユーザー」リストで「新規」をクリックします。

  4. 次の値のデータを入力します。

    「ユーザー ID」

    このフィールドには、ユーザーが Access Manager へログインするために使用する名前を指定します。このプロパティーは、DN 以外の値になることがあります。

    「名」

    このフィールドには、ユーザーの名 (ファーストネーム) を指定します。名 (ファーストネーム) の値と姓 (ラストネーム) の値によって、「現在ログイン中」フィールドのユーザーが識別されます。これは必須の値ではありません。

    「姓」

    このフィールドには、ユーザーの姓 (ラストネーム) を指定します。名 ( ファーストネーム) の値と姓 ( ラストネーム) の値によってユーザーが識別されます。

    「フルネーム」

    このフィールドには、ユーザーのフルネームを指定します。

    パスワード

    このフィールドには、「ユーザー ID」フィールドで指定した名前のパスワードを指定します。

    「パスワード (確認)」

    パスワードを確認します。

    「ユーザー状態」

    このオプションは、Access Manager による認証をユーザーに許可するかどうかを指定します。アクティブなユーザーだけが認証を受けることができます。デフォルト値は「アクティブ」です。

  5. 「了解」をクリックします。

Procedureユーザープロファイルを編集する

管理者ロールを割り当てられていないユーザーが Access Manager に認証されると、そのユーザーのユーザープロファイルがデフォルトの表示になります。また、適切な権限を持つ管理者はユーザープロファイルを編集できます。この表示では、ユーザーが各自の個人プロファイルに特有の属性値を編集できます。ユーザープロファイルビューに表示された属性は、展開することができます。オブジェクトおよびアイデンティティーのためにカスタマイズされた属性の追加については、『Access Manager Developer's Guide』を参照してください。

  1. プロファイルが編集されるユーザーを選択します。デフォルトでは、「一般」表示となっています。

  2. 次のフィールドを編集します。

    「名」

    このフィールドには、ユーザーの名 (ファーストネーム) を指定します。

    「姓」

    このフィールドには、ユーザーの姓 (ラストネーム) を指定します。

    「フルネーム」

    このフィールドには、ユーザーのフルネームを指定します。

    パスワード

    「編集」リンクをクリックして、ユーザーのパスワードを追加し、確認します。

    「電子メールアドレス」

    このフィールドには、ユーザーの電子メールアドレスを指定します。

    「社員番号」

    このフィールドには、ユーザーの社員番号を指定します。

    「電話番号」

    このフィールドには、ユーザーの電話番号を指定します。

    「ホームアドレス」

    このフィールドには、ユーザーのホームアドレスを指定します。

    「ユーザー状態」

    このオプションは、Access Manager による認証をユーザーに許可するかどうかを指定します。アクティブなユーザーだけが Access Manager を使用して認証を受けることができます。デフォルト値は「アクティブ」です。プルダウンメニューから次のどちらかを選択することができます。

    • 「アクティブ」— ユーザーは Access Manager を使用して認証を受けることができます。

    • 「非アクティブ」— ユーザーは Access Manager を使用して認証を受けることはできませんが、ユーザープロファイルはそのままディレクトリに格納されます。

      注 –

      ユーザー状態を「非アクティブ」に変えても、Access Manager による認証に影響するだけです。Directory Server は、nsAccountLock 属性を使用してユーザーアカウント状態を判別しますが、Access Manager での「ユーザー状態」の設定は、nsAccountLock 属性には影響しません。Access Manager にて、ユーザー状態を「非アクティブ」にしたユーザーアカウントでも、Access Manager を必要としないタスクは実行できます。Access Manager 認証だけではなく、ディレクトリのユーザーアカウントも無効にするには、nsAccountLock の値を「false」に設定します。サイトの委託管理者がユーザーを定期的に無効にしている場合は、nsAccountLock 属性を Access Manager のユーザープロファイルページに追加することを検討してください。詳細は、『Sun Java System Access Manager 7.1 Developer’s Guide』を参照してください。

    「アカウント有効期限」

    この属性が存在し、その値が現在の日時以前であれば、認証サービスはログインを無効にします。この属性の形式は次のとおりです。mm/dd/yyyy hh:mm

    「ユーザー認証設定」

    この属性は、ユーザーの認証連鎖を設定します。

    「ユーザーエイリアスリスト」

    このフィールドは、ユーザーに適用される可能性のあるエイリアスを定義します。この属性に設定されたエイリアスを使用するために、iplanet-am-user-alias-list 属性を LDAP サービスのユーザーエントリ検索属性フィールドに追加して、LDAP サービスを修正する必要があります。

    「設定ロケール」

    このフィールドは、ユーザーのロケールを指定します。

    「成功 URL」

    この属性は、認証が成功した場合にユーザーをリダイレクトする URL を指定します。

    「失敗 URL」

    この属性は、認証が失敗した場合にユーザーをリダイレクトする URL を指定します。

    「パスワードリセットオプション」

    ここでは、パスワードを忘れた場合に使用する質問を選択します。パスワードを忘れたときは、選択した質問に答えることで、パスワードを回復できます。

    「ユーザーディスカバリのリソースオファリング」

    ユーザーの、ユーザーディスカバリサービスのリソースオファリングを設定します。

    「MSISDN 番号」

    MSISDN 認証を使用している場合に、ユーザーの MSISDN 番号を定義します。

Procedureロールおよびグループにユーザーを追加する

  1. 「ユーザー」タブをクリックします。

  2. 変更するユーザーの名前をクリックします。

  3. 「ロール」タブまたは「グループ」タブを選択します。

  4. ユーザーを追加するロールまたはグループを選択し、「追加」をクリックします。

  5. 「保存」をクリックします。

    注 –

    ロールまたはグループからユーザーを削除するには、ロールまたはグループを選択し、「削除」をクリックして「保存」をクリックします。

ポリシーにユーザーを追加する

Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、ポリシーの「対象」ページで、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。

ロール

ロールとは、グループの概念に似た、Directory Server の 1 つのエントリメカニズムです。グループにはメンバーがあるように、ロールにもメンバーがあります。ロールのメンバーは、ロールを持つ LDAP エントリです。ロール自体の基準は、属性を持つ LDAP エントリとして定義されます。このエントリは、エントリの識別名 (DN) 属性で特定されます。Directory Server にはさまざまなタイプのロールがありますが、Access Manager で管理できるのは、管理ロールだけです。

注 –

そのほかの Directory Server ロールタイプもディレクトリの配備で使用できますが、Access Manager コンソールで管理することはできません。ポリシーの対象定義にほかの Directory Server タイプを使用することもできます。ポリシー対象については、「ポリシーの作成」を参照してください。

ユーザーには 1 つ以上のロールを持たせることができます。たとえば、セッションサービスとパスワードリセットサービスの属性を持つ契約社員ロールを作成できます。新しい契約社員が入社したときに、管理者は契約社員エントリの別の属性を設定しなくても、契約社員にこのロールを割り当てることができます。契約社員がエンジニアリング部門に属し、エンジニアリング社員に適用可能なサービスとアクセス権が必要な場合は、管理者は契約社員にエンジニアリングロールおよび契約社員ロールを割り当てることができます。

Access Manager では、ロールを使用して、アクセス制御の命令を適用します。Access Manager をはじめてインストールしたときに、管理者アクセス権を定義するアクセス制御命令 (ACI) が定義されます。次にこれらの ACI をロール (組織管理者ロール、組織ヘルプデスク管理者ロールなど) に割り当てます。このロールをユーザーに割り当てると、ユーザーのアクセス権が定義されます。

ユーザーは、管理サービスで「ユーザープロファイルページにロールを表示」属性が有効である場合だけ、割り当てられたロールを確認できます。

注 –

Access Manager は、Directory Server とともに参照整合性プラグインを使用するように設定されている必要があります。参照整合性プラグインが有効になっているときは、削除操作や名前の変更操作の直後に、指定された属性について整合性更新が実行されます。これにより、関連するエントリどうしの関係がデータベース全体で維持されます。Directory Server では、データベースインデックスによって検索パフォーマンスが向上します。

ロールには、次の 2 種類があります。

Procedure静的ロールを作成する

  1. ロールを作成する組織に移動します。

  2. 「ロール」タブをクリックします。

    組織の設定時にデフォルトのロールが作成され、「ロール」リストに表示されます。デフォルトのロールは次のとおりです。

    コンテナヘルプデスク管理者: コンテナのヘルプデスク管理者ロールは、組織単位のすべてのエントリに対する読み取りアクセス権、およびそのコンテナ単位だけにあるユーザーエントリの userPassword 属性に対する書き込みアクセス権を持っています。

    組織ヘルプデスク管理者: 組織ヘルプデスク管理者は、組織のすべてのエントリに対する読み取りアクセス権、および userPassword 属性に対する書き込みアクセス権を持っています。

    注 –

    サブ組織を作成するときは、管理者ロールは親組織ではなくサブ組織に作成してください。

    コンテナ管理者: コンテナ管理者ロールは、LDAP 組織単位のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。Access Manager では、LDAP 組織単位をコンテナと呼ぶことがあります。

    組織ポリシー管理者: 組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っており、組織内のすべてのポリシーについて作成、割り当て、修正、および削除ができます。

    ピープル管理者: デフォルトで、新規に作成した組織のユーザーエントリはその組織のメンバーです。ピープル管理者は、組織のすべてのユーザーエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。なお、このロールは、ロールおよびグループ DN を含む属性に対する読み取りアクセス権と書き込みアクセス権を持っていないため、ロールまたはグループの属性を変更したり、ロールまたはグループからユーザーを消去したりすることができません。

    注 –

    ほかのコンテナは、Access Manager とともに設定して、ユーザーエントリ、グループエントリ、またはほかのコンテナを保持することができます。組織を構成したあとで、作成されたコンテナに管理者ロールを適用するには、デフォルトのコンテナ管理者ロールまたはコンテナヘルプデスク管理者を使用します。

    グループ管理者: グループ作成時に作成されたグループ管理者は、特定グループのすべてのメンバーに対する読み取りアクセス権および書き込みアクセス権を持っており、新しいユーザーの作成、管理しているグループへのユーザーの割り当て、および作成したユーザーの削除を行うことができます。

    グループを作成すると、そのグループを管理するのに必要な権限を持つグループ管理者ロールが自動的に作成されます。このロールはグループのメンバーに自動的には割り当てられません。グループの作成者、またはグループ管理者ロールへのアクセス権を持つ人が割り当てる必要があります。

    最上位レベル管理者: 最上位レベル管理者は、最上位レベル組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。言い換えれば、最上位レベル管理者ロールには、Access Manager アプリケーション内のすべての設定主体に対する権限があります。

    組織管理者: 組織管理者は、組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。組織を作成すると、その組織を管理するのに必要な権限を持つ組織管理者ロールが自動的に作成されます。

  3. 「新規静的」ボタンをクリックします。

  4. ロールの名前を入力します。

  5. ロールの詳細を入力します。

  6. 「タイプ」メニューからロールのタイプを選択します。

    ロールは、管理者ロールまたはサービスロールにすることができます。ロールのタイプは、Access Manager コンソールが、コンソール内でどのユーザーをどの位置から始動させるかを決定するために使用します。管理者ロールは、ロールの所有者が管理者権限を持っていることをコンソールに通知します。サービスロールは、その所有者がエンドユーザーであることをコンソールに通知します。

  7. 「アクセス権」メニューから、ロールに適用する権限のデフォルトセットを選択します。これは、組織内のエントリにアクセスする権限です。ここで示すデフォルトの権限は順不同です。権限は次のとおりです。

    アクセス権なし

    ロールにアクセス権が設定されません。

    組織管理者

    組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。

    組織ヘルプデスク管理者

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

    組織ポリシー管理者

    組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。組織のポリシー管理者は、ピア組織に対する参照ポリシーを作成できません。

    一般に、「アクセス権なし」ACI をサービスロールに割り当て、管理者ロールにはデフォルト ACI のいずれかを割り当てます。

Procedure静的ロールにユーザーを追加する

  1. ユーザーを追加するロールの名前をクリックします。

  2. 「メンバー」リストで、「アクションの選択」メニューから「ユーザーの追加」を選択します。

  3. 検索条件を入力します。表示される 1 つ以上のフィールドを基に、ユーザーの検索方法を選択できます。フィールドは次のとおりです。

    「一致」

    フィルタ用として含めるフィールドを選択できます。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。

    「名」

    名 (ファーストネーム) でユーザーを検索します。

    「ユーザー ID」

    ユーザー ID でユーザーを検索します。

    「姓」

    姓 (ラストネーム) でユーザーを検索します。

    「フルネーム」

    フルネームでユーザーを検索します。

    「ユーザー状態」

    ユーザーの状態 (アクティブまたは非アクティブ) でユーザーを検索します。

  4. 「次へ」をクリックすると、検索が始まります。検索結果が表示されます。

  5. ユーザー名の横にあるチェックボックスを選択して、返された名前の中からユーザーを選択します。

  6. 「終了」をクリックします。

    これで、ユーザーがロールに割り当てられます。

Procedure動的ロールを作成する

  1. ロールを作成する組織に移動します。

  2. 「ロール」タブをクリックします。

    組織の設定時にデフォルトのロールが作成され、「ロール」リストに表示されます。デフォルトのロールは次のとおりです。

    コンテナヘルプデスク管理者: コンテナのヘルプデスク管理者ロールは、組織単位のすべてのエントリに対する読み取りアクセス権、およびそのコンテナ単位だけにあるユーザーエントリの userPassword 属性に対する書き込みアクセス権を持っています。

    組織ヘルプデスク管理者: 組織ヘルプデスク管理者は、組織のすべてのエントリに対する読み取りアクセス権、および userPassword 属性に対する書き込みアクセス権を持っています。

    注 –

    サブ組織を作成するときは、管理者ロールは親組織ではなくサブ組織に作成してください。

    コンテナ管理者: コンテナ管理者ロールは、LDAP 組織単位のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。Access Manager では、LDAP 組織単位をコンテナと呼ぶことがあります。

    組織ポリシー管理者: 組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っており、組織内のすべてのポリシーについて作成、割り当て、修正、および削除ができます。

    ピープル管理者: デフォルトで、新規に作成した組織のユーザーエントリはその組織のメンバーです。ピープル管理者は、組織のすべてのユーザーエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。なお、このロールは、ロールおよびグループ DN を含む属性に対する読み取りアクセス権と書き込みアクセス権を持っていないため、ロールまたはグループの属性を変更したり、ロールまたはグループからユーザーを消去したりすることができません。

    注 –

    ほかのコンテナは、Access Manager とともに設定して、ユーザーエントリ、グループエントリ、またはほかのコンテナを保持することができます。組織を構成したあとで、作成されたコンテナに管理者ロールを適用するには、デフォルトのコンテナ管理者ロールまたはコンテナヘルプデスク管理者を使用します。

    グループ管理者: グループ作成時に作成されたグループ管理者は、特定グループのすべてのメンバーに対する読み取りアクセス権および書き込みアクセス権を持っており、新しいユーザーの作成、管理しているグループへのユーザーの割り当て、および作成したユーザーの削除を行うことができます。

    グループを作成すると、そのグループを管理するのに必要な権限を持つグループ管理者ロールが自動的に作成されます。このロールはグループのメンバーに自動的には割り当てられません。グループの作成者、またはグループ管理者ロールへのアクセス権を持つ人が割り当てる必要があります。

    最上位レベル管理者: 最上位レベル管理者は、最上位レベル組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。言い換えれば、最上位レベル管理者ロールには、Access Manager アプリケーション内のすべての設定主体に対する権限があります。

    組織管理者: 組織管理者は、組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。組織を作成すると、その組織を管理するのに必要な権限を持つ組織管理者ロールが自動的に作成されます。

  3. 「新規動的」ボタンをクリックします。

  4. ロールの名前を入力します。

  5. ロールの詳細を入力します。

  6. 「タイプ」メニューからロールのタイプを選択します。

    ロールは、管理者ロールまたはサービスロールにすることができます。ロールのタイプは、Access Manager コンソール内でどのユーザーをどの位置から始動させるかを決定するために使用します。管理者ロールは、ロールの所有者が管理者権限を持っていることをコンソールに通知します。サービスロールは、その所有者がエンドユーザーであることをコンソールに通知します。

  7. 「アクセス権」メニューから、ロールに適用する権限のデフォルトセットを選択します。これは、組織内のエントリにアクセスする権限です。ここで示すデフォルトの権限は順不同です。権限は次のとおりです。

    アクセス権なし

    ロールにアクセス権が設定されません。

    組織管理者

    組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。

    組織ヘルプデスク管理者

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

    組織ポリシー管理者

    組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。組織のポリシー管理者は、ピア組織に対する参照ポリシーを作成できません。

    一般に、「アクセス権なし」ACI をサービスロールに割り当て、管理者ロールにはデフォルト ACI のいずれかを割り当てます。

  8. 検索条件を入力します。フィールドは次のとおりです。

    「一致」

    演算子を含めるフィルタのフィールドに、演算子を含めることができます。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。

    「名」

    名 (ファーストネーム) でユーザーを検索します。

    「ユーザー ID」

    ユーザー ID でユーザーを検索します。

    「姓」

    姓 (ラストネーム) でユーザーを検索します。

    「フルネーム」

    フルネームでユーザーを検索します。

    「ユーザー状態」

    ユーザーの状態 (アクティブまたは非アクティブ) でユーザーを検索します。

  9. 「了解」をクリックして、フィルタ条件を基に、検索を開始します。そのフィルタ条件で定義されたユーザーがロールに自動的に割り当てられます。

Procedureロールからユーザーを消去する

  1. 変更するロールを含む組織に移動します。

    アイデンティティー管理モジュールで「表示」メニューから「組織」を選択し、「ロール」タブを選択します。

  2. 変更するロールを選択します。

  3. 「表示」メニューから「ユーザー」を選択します。

  4. 消去する各ユーザーの横にあるチェックボックスを選択します。

  5. 「アクションの選択」メニューから「ユーザーの消去」をクリックします。

    これで、ロールからユーザーが消去されます。

ポリシーにロールを追加する

Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、ポリシーの「対象」ページで、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。

第 8 章 現在のセッション

この章では、Access Manager のセッション管理機能について説明します。セッション管理モジュールでは、ユーザーセッションの情報を確認したり、ユーザーセッションを管理したりする手段を用意しています。さまざまなセッションの時間を追跡するほかに、管理者がセッションを終了することができます。システム管理者は、プラットフォームサーバーリストに表示されたロードバランササーバーを無視してください。

現在のセッションのインタフェース

「現在のセッション」モジュールインタフェースを使用すると、適切な権限を持った管理者は、Access Manager にログインしている任意のユーザーのセッション情報を参照できます。

セッション管理

セッション管理フレームには、現在管理されている Access Manager の名前が表示されます。

セッション情報

セッション情報ウィンドウには、Access Manager に現在ログイン中のすべてのユーザーと、各ユーザーのセッション時間が表示されます。表示フィールドは次のとおりです。

「ユーザー ID」: 現在ログイン中のユーザーのユーザー ID が表示されます。

「残り時間」: ユーザーの再認証までの、セッションの残り時間 (分単位) が表示され ます。

「最大セッション時間」: ユーザーがログインした状態でいられる最大時間 (分単位) が表示されます。この時間が経過すると、セッションが期限切れになり、ユーザーは アクセスするために再度認証を受ける必要があります。

「アイドル時間」: ユーザーがアイドル状態になっている時間 (分単位) が表示されます。

「最大アイドル時間」: ユーザーの再認証が必要になるまでの残りの最大アイドル時間 (分単位) が表示されます。

時間の制限値は、管理者がセッション管理サービスに定義します。

「ユーザー ID」フィールドに入力して「フィルタ」をクリックすれば、特定のユーザーのセッションや特定の範囲のセッションを表示できます。ワイルドカードも使用できます。

「更新」ボタンをクリックすれば、セッションの表示が更新されます。

セッションの終了

適切な権限を持った管理者は、ユーザーのセッションをいつでも終了させることができます。

Procedureセッションを終了させる

  1. 終了させるユーザーのセッションを選択します。

  2. 「セッションを終了」をクリックします。

第 9 章 パスワードリセットサービス

Access Manager では、Access Manager によって保護されている特定のサービスやアプリケーションにアクセスするためのパスワードをユーザー自身がリセットできるように、パスワードリセットサービスが用意されています。パスワードリセットサービス属性は、最上位レベル管理者が定義します。この属性を使用して、ユーザーを検証するための証明情報 (秘密の質問形式) を制御し、新規または既存のパスワード通知の機構を制御し、不正なユーザーに適用するロックアウト間隔を設定します。

この章の内容は次のとおりです。

パスワードリセットサービスの登録

パスワードリセットサービスは、ユーザーが属しているレルムに対して登録する必要はありません。ユーザーが割り当てられている組織にパスワードリセットサービスが存在しない場合は、「設定」タブの「パスワードリセット」に定義されている値が継承されます。

Procedure別のレルムに存在するユーザーのパスワードリセットを登録する

  1. そのユーザーのパスワードを登録するレルムに移動します。

  2. レルム名をクリックし、「サービス」タブをクリックします。

    選択したレルムにレルム名が追加されていない場合は、「追加」ボタンをクリックします。

  3. 「パスワードリセット」を選択し、「次へ」をクリックします。

    パスワードリセットサービス属性が表示されます。属性の定義については、オンラインヘルプを参照してください。

  4. 「終了」をクリックします。

パスワードリセットサービスの設定

パスワードリセットサービスの登録が完了したら、管理者権限を持っているユーザーがこのサービスを設定する必要があります。

Procedureサービスを設定する

  1. パスワードリセットサービスが登録されているレルムを選択します。

  2. 「サービス」タブをクリックします。

  3. サービスリストから「パスワードリセット」をクリックします。

  4. 「パスワードリセット」属性が表示され、ここでパスワードリセットサービスの要件を定義できます。パスワードリセットサービスが有効になっていることを確認します (デフォルトでは有効)。少なくとも次の属性を定義する必要があります。

    • ユーザー検証

      • 秘密の質問

      • バインド DN

      • バインドパスワード

        「バインド DN」属性には、パスワードをリセットする権限を持っているユーザー (ヘルプデスク管理者など) を指定する必要があります。Directory Server の制限により、バインド DN が cn=Directory Manager の場合はパスワードリセットは機能しません。

        残りの属性は省略可能です。これらのサービス属性の説明については、オンラインヘルプを参照してください。

      注 –

      Access Manager では、ランダムなパスワードを生成するパスワードリセット Web アプリケーションが自動的にインストールされます。ただし、パスワードの生成や通知を行う独自のプラグインクラスを記述することもできます。このようなプラグインクラスのサンプルについては、次の場所にある Readme.html ファイルを参照してください。

      PasswordGenerator:


      AccessManager-base/SUNWam/samples/console/PasswordGenerator

      NotifyPassword:


      AccessManager-base/SUNWam/samples/console/NotifyPassword

  5. 独自の質問を定義するユーザーには、「個人的な質問を有効」属性を選択します。属性を定義し終えたら、「保存」をクリックします。

Procedure秘密の質問をローカライズする

ローカライズ版の Access Manager を実行していて、秘密の質問をロケールに固有の文字セットで表示する場合は、次の手順を実行します。

  1. パスワードリセットサービスの「秘密の質問」属性の下の「現在の値」リストに秘密の質問キーを追加します。たとえば、favorite-color を追加するとします。

  2. このキーとキーの値を表示するために必要な質問を amPasswordReset.properties ファイルに追加します。次に例を示します。

    favorite-color=好きな色はなんですか。

  3. 同じキーとローカライズされた質問を /opt/SUNWam/locale にある AMPasswordReset_ locale.properties に追加します。ユーザーが自分のパスワードの変更を試みると、ローカライズされた質問が表示されます。

パスワードリセットのロックアウト

パスワードリセットサービスには、ユーザーが秘密の質問に正しく回答するまでの回数を制限するために、ロックアウト機能が用意されています。ロックアウト機能は、パスワードリセットサービス属性を使用して設定します。これらのサービス属性の説明については、オンラインヘルプを参照してください。パスワードリセットでは、メモリーロックアウトと物理的なロックアウトの 2 種類がサポートされています。

メモリーロックアウト

これは一時的なロックアウトです。「パスワードリセット失敗のロックアウト持続時間」属性の値が 0 より大きく、「パスワードリセット失敗のロックアウトを有効」属性が有効になっている場合にのみ機能します。ロックアウトされたユーザーは、パスワードリセット Web アプリケーションを使用してもパスワードをリセットできなくなります。「パスワードリセット失敗のロックアウト持続時間」に指定した時間が経過するまで、またはサーバーが再起動されるまで、ロックアウトは持続します。これらのサービス属性の説明については、オンラインヘルプを参照してください。

物理的なロックアウト

メモリーロックアウトより永続的なロックアウトです。「パスワードリセット失敗のロックアウトカウント」属性の値が 0 に設定され、「パスワードリセット失敗のロックアウトを有効」属性が有効になっている場合には、秘密の質問に正しく回答できなかったユーザーのアカウント状態が非アクティブに変更されます。これらのサービス属性の説明については、オンラインヘルプを参照してください。

エンドユーザーから見たパスワードリセット

以降の節では、ユーザーの観点からパスワードリセットサービスについて説明します。

パスワードリセットのカスタマイズ

管理者がパスワードリセットサービスを有効にし、属性を定義したら、ユーザーは Access Manager コンソールにログインして秘密の質問をカスタマイズできます。

Procedureパスワードリセットをカスタマイズする

  1. ユーザー名とパスワードを入力して認証に成功したら、Access Manager コンソールにログインします。

  2. 「ユーザープロファイル」ページで、「パスワードリセットのオプション」を選択します。「質問と回答」画面が表示されます。

  3. 管理者が定義した、このサービスで選択できる質問が表示されます。たとえば、次のような質問が表示されます。

    • ペットの名前は何でしょうか ?

      • 好きなテレビ番組は何でしょうか ?

      • 母親の旧姓は何でしょうか ?

      • よく行くレストランの名前は何でしょうか ?

  4. 秘密の質問を選択します。管理者がこのレルムに定義した最大質問数 (パスワードリセットサービスに定義) まで選択できます。選択した質問への回答を指定します。これらの質問と回答を元に、自分でパスワードをリセットすることができます (次の節を参照)。管理者が「個人的な質問を有効」属性を選択している場合は、自分だけの秘密の質問と回答を入力できるように、テキストフィールドが表示されます。

  5. 「保存」をクリックします。

パスワードを忘れた場合のリセット

パスワードを忘れた場合には、パスワードリセット Web アプリケーションによって新しいパスワードがランダムに生成され、それがユーザーに通知されます。パスワードを忘れた場合の標準的な手順を次に示します。

Procedureパスワードを忘れた場合にリセットする

  1. 管理者から渡された URL を使って、パスワードリセット Web アプリケーションにログインします。次に例を示します。

    http://hostname:port /ampassword (デフォルトのレルムの場合)

    または、

    http://hostname: port/deploy_uri /UI/PWResetUserValidation?realm=realmname。realmname はレルムの名前です。

    注 –

    パスワードリセットサービスがサブレルムで有効になっていても、親レルムで無効になっている場合は、次の構文を使ってサービスにアクセスする必要があります。


    http://hostname: port/deploy_uri/UI/PWResetUserValidation?realm=realmname

  2. ユーザー ID を入力します。

  3. パスワードリセットサービスに定義されている質問のうち、パスワードリセット設定をカスタマイズした際にユーザーが選択した質問が表示されます。事前に「ユーザープロファイル」ページにログインしておらず、パスワードリセット設定をカスタマイズしていない場合には、パスワードは生成されません。

    質問に正しく回答すると、新しいパスワードが生成され、電子メールで通知されます。また、回答が正しいかどうかにかかわらず、パスワードをリセットしようとしたことが通知されます。新しいパスワードおよびパスワードをリセットしようとしたことの通知を受け取るには、「ユーザープロファイル」ページに電子メールアドレスを入力しておく必要があります。

パスワードポリシー

パスワードポリシーは、特定のディレクトリ内でパスワードがどのように使用されるかを規定した規則の集合です。パスワードポリシーは Directory Server 内に、通常は Directory Server コンソールを使用して定義されます。安全なパスワードポリシーとして次のような条件をパスワードに適用すると、推測されやすいパスワードによるリスクを最小限に抑えることができます。

Directory Server では、いくつかの方法により、ツリー内の任意のノードにパスワードポリシーを設定できます。詳細は、

『Directory Server Enterprise Edition 6.0 管理ガイド』の「Directory Server のパスワードポリシー」を参照してください。

注 –

Directory Server では、パスワードポリシーに passwordExp 属性が含まれます。この属性は、一定の秒数が経過するとユーザーパスワードが期限切れになるかどうかを定義します。管理者が passwordExp 属性を on に設定すると、エンドユーザーパスワードの有効期限と、amldap、 dsame、puser などの Access Manager の管理アカウントの有効期限が設定されます。Access Manager 管理者アカウントのパスワードが期限切れになったときにエンドユーザーがログインしている場合は、そのユーザーにパスワード変更画面が表示されます。ただし、Access Manager では、そのパスワード変更画面に関係するユーザーを特定しません。この場合、このパスワード変更画面は管理者向けに表示されており、エンドユーザーはパスワードを変更できません。

この問題を解決するには、管理者が Directory Server にログインし、amldap、dsame、および puser の各パスワードを変更するか、または将来のために passwordExpirationTime 属性を変更します。

第 10 章 ログサービス

Sun Java™ System Access Manager には、ユーザーアクティビティー、トラフィックパターン、認証違反などの情報を記録するために、ログサービスが用意されています。また、管理者はデバッグファイルを利用して、インストールの障害追跡を行うことができます。

ログファイル

ログファイルには、ログサービスが監視するイベントが記録されます。管理者は、ログファイルを定期的に確認することをお勧めします。ログファイルのデフォルトのディレクトリは、SPARC システムの場合は /var/opt/SUNWam/logs 、Linux システムの場合は /var/opt/sun/identity、HP-UX の場合は /var/opt/sun/identity、そして Windows の場合は jes-install-dir\identity です。ログサービスのログファイルディレクトリを設定するときには、Access Manager コンソールを使用します。

ログファイルのデフォルトタイプ、記録される情報、ログファイルの形式の詳細については、『Sun Java System Access Manager 7.1 Technical Overview』の「Logging Overview」を参照してください。

ログサービスの属性定義については、Access Manager コンソールの「ヘルプ」ボタンをクリックしてオンラインヘルプを参照してください。

Access Manager サービスのログ

サービスログファイルには、アクセスログファイルとエラーログファイルの 2 種類があります。アクセスログファイルには、アクションが実行されたことと正常に実行されたアクションの結果が記録されます。エラーログファイルには、Access Manager サービスで発生したエラーが記録されます。フラットログファイルには、.error または .access という拡張子が付きます。データベース列名の最後には、Oracle データベースの場合は _ERROR または _ACCESS、MySQL データベースの場合は _error または _access が付きます。たとえば、コンソールイベントを記録するフラットファイルログには amConsole.access という名前が付き、コンソールイベントを記録するデータベース列には AMCONSOLE_ACCESS という名前が付きます。以下の節では、ログサービスによって記録されるログファイルについて説明します。

セッションログ

ログサービスでは、次のセッションサービスイベントが記録されます。

セッションログのファイル名は、amSSO で始まります。

コンソールログ

Access Manager コンソールログには、アイデンティティー関連のオブジェクト、ポリシー、およびサービスが作成、削除、および変更されたことが記録されます。たとえば、組織、組織単位、ユーザー、ロール、ポリシー、グループが記録されます。コンソールログには、パスワードなどのユーザー属性が変更されたことや、ロールとグループに対してユーザーが追加または削除されたことも記録されます。また、委託やデータストアのアクティビティーも記録されます。コンソールログのファイル名は、amConsole で始まります。

認証ログ

認証コンポーネントでは、ユーザーのログインおよびログアウトがログとして記録されます。認証ログのファイル名は、amAuthentication で始まります。

連携ログ

連携コンポーネントでは、連携関連のイベントなどがログとして記録されます。たとえば、認証ドメインが作成されたことや、ホストプロバイダが作成されたことが記録されます。連携ログのファイル名は、amFederation で始まります。

ポリシーログ

ポリシーコンポーネントでは、ポリシー関連のイベントなどがログとして記録されます。たとえば、ポリシー管理 (ポリシーの作成、削除、および変更) やポリシー評価が記録されます。ポリシーログのファイル名は、amPolicy で始まります。

エージェントログ

ポリシーエージェントログには、ユーザーがアクセスを許可または拒否されているログリソースに関する例外が記録されます。エージェントログのファイル名は、amAgent で始まります。amAgent ログは、エージェントサーバーだけに存在します。エージェントイベントのログは、Access Manager サーバー上の認証ログに記録されます。この機能の詳細については、ポリシーエージェントのマニュアルを参照してください。

SAML ログ

SAML コンポーネントでは、SAML 関連のイベントなどが記録されます。たとえば、表明およびアーティファクトが作成または削除されたこと、応答および要求の詳細、SOAP エラーなどが記録されます。SAML ログのファイル名は、amSAML で始まります。

amAdmin ログ

コマンド行ログには、コマンド行ツールを使用する操作中に発生したイベントエラーが記録されます。たとえば、サービススキーマがロードされたこと、ポリシーが作成されたこと、ユーザーが削除されたことなどが記録されます。コマンド行ログのファイル名は amAdmin. で始まります。 amadmin.access および amadmin.error の各ログファイルは、主要なログディレクトリのサブディレクトリに置かれます。デフォルトでは、amadmin コマンド行ツールのログファイルは /var/opt/SUNWam/logs に置かれます。

ログ機能

ログサービスにはいくつかの特殊な機能が用意されていて、追加機能として有効にできます。このような機能として、「セキュリティー保護されたログを有効」、「コマンド行ログ」、および「リモートログ」があります。

セキュリティー保護されたログ

このオプションの機能を追加すると、ログ機能のセキュリティーが強化されます。セキュリティー保護されたログを有効にすると、セキュリティーログに対する未承認の変更や改ざんを検出できます。この機能を使用するために、特にコーディングする必要はありません。セキュリティー保護されたログには、システム管理者が事前に登録した証明書が必要です。この MAC (Manifest Analysis and Certification) は、すべてのログレコードについて生成および格納されます。また、特別な「署名」ログレコードが定期的に挿入されます。このログレコードは、その時点までに書き込まれたログの内容に対する署名となります。これらの 2 つのレコードによって、ログが改ざんされていないことが保証されます。

Procedureセキュリティー保護されたログを有効にする

  1. Logger という名前の証明書を作成し、Access Manager を実行する配備コンテナにインストールします。配備コンテナの詳細については、マニュアルを参照してください。

  2. Access Manager コンソールを使用して「ログサービス」設定の「セキュリティー保護されたログ」を有効にし、変更を保存します。管理者は、「ログサービス」のその他の属性のデフォルト値を変更することもできます。

    ログディレクトリがデフォルトのディレクトリ (/var/opt/SUMWam/logs) から変更されている場合は、アクセス権が 0700 に設定されていることを確認してください。このディレクトリが存在しない場合には、ログサービスによって作成されますが、そのアクセス権は 0755 に設定されます。

    また、デフォルトではないログディレクトリを指定した場合は、Web コンテナの server.policy ファイルで次のパラメータをその 新しいディレクトリに変更する必要があります。

    permission java.io.FilePermission “/var/opt/SUNWam/logs/*”,”delete,write”

  3. AccessManager-base/SUNWam/config ディレクトリに証明書データベースパスワードを含むファイルを作成し、.wtpass という名前を付けます。

    注 –

    ファイル名とそのパスは、AMConfig.properties ファイルに設定できます。詳細については、『Access Manager Administration Reference』の AMConfig.properties ファイルリファレンスの「Certificate Database」を参照してください

    セキュリティー上の理由から、このファイルへの読み取りアクセス権を持つ管理者だけが配備コンテナを使用できるようにしてください。

  4. サーバーを再起動します。

    このとき、セキュリティー保護されたログディレクトリをクリアすることをお勧めします。セキュリティー保護されたログを開始したときに、誤解を招きやすい検証エラーが /var/opt/SUNWam/debug/amLog ファイルに書き込まれることがあります。

    セキュリティーログに対する未承認の変更や改ざんを検出するには、検証プロセスによって /var/opt/SUNWam/debug/amLog に書き込まれたエラーメッセージを探してください。改ざんを手動で確認する場合は、VerifyArchive ユーティリティーを実行します。詳細については、『Access Manager Administration Reference』を参照してください。

コマンド行ログ

amadmin コマンド行ツールを使用して、Directory Server のアイデンティティーオブジェクト (組織、ユーザー、ロールなど) を作成、変更、および削除することができます。このツールを使用して、サービステンプレートをロード、作成、および登録することもできます。-t オプションを指定すれば、ログサービスでこれらのアクションを記録できます。AMConfig.properties の com.iplanet.am.logstatus プロパティーが有効 (ACTIVE) になっている場合は、ログレコードが作成されます。このプロパティーはデフォルトでは有効になっています。コマンド行ログのファイル名は、amAdmin で始まります。詳細については、『Access Manager Administration Reference』の「The amadmin Command Line Tool」を参照してください。

ログプロパティー

AMConfig.properties ファイルには、ログ出力を制御するプロパティーが入っています。

com.iplanet.am.logstatus=ACTIVE

このプロパティーを使用して、ログの有効または無効を切り替えます。デフォルトでは ACTIVE になっています。

iplanet-am-logging.service.level= level

service にはログを記録するサービス名を指定します。この名前はそのままログファイルの名前になります。たとえば、amSAML.access にログレベルを指定するには、iplanet-am-logging.amSAML.access.level プロパティーを使用します。level は java.util.logging.Level の値のいずれかであり、記録されるログファイルの詳細レベルを表します。指定できるレベルは、OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、および ALL です。ほとんどのサービスでは、INFO レベルより詳細なログは記録されません。

リモートログ

Access Manager では、リモートログがサポートされます。これにより、Access Manager SDK がインストールされたホストを使用するクライアントアプリケーションが、リモートマシン上に配備された Access Manager インスタンス上にログレコードを作成できるようになります。リモートログは、次のいずれかの場合に開始されます。

  1. ある Access Manager インスタンスのネームサービスのログ URL にリモートの Access Manager インスタンスの URL が指定されていて、2 つのインスタンスの間に信頼関係が設定されている場合に、リモート Access Manager インスタンスにログが記録されます。

  2. Access Manager SDK がリモート Access Manager インスタンスにインストールされていて、SDK サーバーで実行されているクライアント (または Java クラス) がログ API を使用している場合に、リモート Access Manager マシンにログが記録されます。

  3. ログ API が Access Manager エージェントで使用されているとき。

Procedureリモートログを有効にする

  1. Sun Java System Web Server を使用する場合は、server.xml 設定ファイルに次の環境変数を設定する必要があります。

    • java.util.logging.manager=com.sun.identity.log.LogManager

    • java.util.logging.config.file=/ AccessManager-base /SUNwam/lib/LogConfig.properties

    • Java™ 2 Platform, Standard Edition の 1.4 以上を使用している場合には、コマンド行で次のコマンドを実行すると、リモートログが有効になります。

      java -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/ AccessManager-base /SUNWam/lib/xercesImpl.jar:/ AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/ AccessManager-base /SUNWam/lib/jaas.jar:/ AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/ AccessManager-base /SUNWam/lib/servlet.jar:/ AccessManager-base /SUNWam/locale:/ AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.

      -Djava.util.logging.manager=com.sun.identity.log.LogManager

      -Djava.util.logging.config.file=/ AccessManager-base /SUNwam/lib/LogConfig.properties <logTestClass>

    • 1.4 より前の Java 2 Platform, Standard Edition を使用している場合には、コマンド行で次のコマンドを実行すると、リモートログが有効になります。

      java -Xbootclasspath/a:/ AccessManager-base /SUNWam/lib/jdk_logging.jar -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/ AccessManager-base /SUNWam/lib/xercesImpl.jar:/ AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/ AccessManager-base /SUNWam/lib/jaas.jar:/ AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/ AccessManager-base /SUNWam/lib/servlet.jar:/ AccessManager-base /SUNWam/locale:/ AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.

      -Djava.util.logging.manager=com.sun.identity.log.LogManager

      -Djava.util.logging.config.file=/ AccessManager-base /SUNwam/lib/LogConfig.properties <logTestClass>

  2. AccessManager-base/SUNWam/lib の LogConfig.properties に次のパラメータが設定されていることを確認します。

    • iplanet-am-logging-remote-handler=com.sun.identity.

      log.handlers.RemoteHandler

    • iplanet-am-logging-remote-formatter=com.sun.

      identity.log.handlers.RemoteFormatter

    • iplanet-am-logging-remote-buffer-size=1

      リモートログでは、ログレコード数に基づいてバッファー機能がサポートされます。この値には、レコード数でログバッファーサイズを定義します。バッファーがいっぱいになったら、バッファーに保管されたすべてのレコードがサーバーにフラッシュされます。

    • iplanet-am-logging-buffer-time-in-seconds=3600

      この値には、ログバッファーとクリーナのスレッドを呼び出すときの、タイムアウト期間を定義します。

    • iplanet-am-logging-time-buffering-status=OFF

      この値には、ログバッファー (およびバッファークリーナのスレッド) を有効にするかどうかを定義します。デフォルトでは、この機能は無効になっています。

    注 –

    ログファイルが空の場合、セキュリティー保護されたログに「verification failure」と表示される可能性があります。これは、作成されたファイルの数がアーカイブサイズに等しい場合、セキュリティー保護されたログが、このセットからアーカイブし、再起動するからです。ほとんどの場合、このエラーは無視してもかまいません。レコード数がアーカイブサイズに等しくなると、このエラーは表示されなくなります。

  3. プログラムをクライアント SDK とともに使用している場合は、AMConfig.properties ファイル内の次のプロパティーをそれに応じて設定する必要があります。

    • com.iplanet.am.naming.url

    • com.sun.identityagents.app.username

    • com.iplanet.am.service.password

    • com.iplanet.am.server.protocol

    • com.iplanet.am.server.host

    • com.iplanet.am.server.port

    /opt/SUNWam/war ディレクトリの README.clientsdk で、クライアント SDK のサンプルを参照してください。ここには、AMConfig.properties ファイルおよび make ファイルが /opt/SUNWam/war/clientsdk-samples ディレクトリに生成される経緯が詳しく説明されています。これらのファイルは、サンプルの make ファイルのコンパイルおよび実行エントリによって順番に使用されます。

エラーログとアクセスログ

Access Manager には 2 種類のログファイルが存在します。アクセスログファイルとエラーログファイルです。

アクセスログファイルには、Access Manager 配備に関する一般的な監査情報が記録されます。ログには、認証の成功など、特定のイベントに対する単一のレコードが含まれる場合があります。またその同じイベントに対する複数のレコードが含まれる場合もあります。たとえば、管理者がコンソールを使って特定の属性の値を変更した場合、ログサービスは、その変更の試みを 1 つのレコードとしてログに記録します。ログサービスはさらに、その変更の実行結果も、2 番目のレコードとしてログに記録します。

エラーログファイルには、アプリケーション内で発生したエラーが記録されます。ある処理のエラーはエラーログに記録されますが、その処理が試みられたことはアクセスログファイルに記録されます。

フラットログファイルには、.error、.access のいずれかの拡張子が付けられます。データベーステーブル名は、_ERROR、_ACCESS のいずれかで終わります。たとえば、コンソールイベントのログを記録するフラットファイルの名前が amConsole.access である場合、その同じイベントのログを記録するデータベーステーブルの名前は、AMCONSOLE_ACCESS または amConsole_access になります。

次の表では、各 Access Manager コンポーネントが生成するログファイルについて簡単に説明します。

表 10–1 Access Manager コンポーネントのログ

コンポーネント 

ログファイル名のプレフィックス 

ログに記録される情報 

セッション 

amSSO

ログイン時刻、ログアウト時刻、タイムアウト制限などのセッション管理属性値。 

管理コンソール 

amConsole

アイデンティティー関連のオブジェクト、レルム、ポリシーの作成、削除、変更など、管理コンソール経由で実行されるユーザーアクション。 

認証 

amAuthentication

ユーザーのログインとログアウト。 

アイデンティティー連携 

amFederation

認証ドメインの作成やホストプロバイダの作成など、連携関連のイベント。認証ログのファイル名は、amFederation で始まります。

承認 (ポリシー) 

amPolicy

ポリシーの作成、削除、変更やポリシー評価など、ポリシー関連のイベント。 

ポリシーエージェント 

amAgent

特定のユーザーからのアクセスが許可または拒否されたリソースに関する例外。amAgent ログは、ポリシーエージェントがインストールされたサーバー上に存在します。エージェントイベントのログは、Access Manager マシン上の認証ログに記録されます。

SAML 

amSAML

表明、アーティファクトの作成または削除、応答や要求の詳細、SOAP エラーなど、SAML 関連のイベント。 

コマンド行 

amAdmin

amadmin コマンド行ツールによる操作中に発生したイベントエラー。フラットファイルログを指定した場合、amAdmin ログファイルは、主要なログディレクトリ (デフォルトでは /var/opt/SUNWam/logs) の下の amadmincli サブディレクトリに置かれます。例: サービススキーマの読み込み、ポリシーの作成、ユーザーの削除。

Access Manager のログファイルの一覧と説明については、『Access Manager Administration Reference』の「Access Manager Log File Reference」を参照してください。

デバッグファイル

デバッグファイルは、ログサービスの機能ではありません。デバッグファイルは、ログ API とは別の API を使用して記録されます。デバッグファイルは、/var/opt/SUNWam/debug に格納されます。この場所は、デバッグ情報のレベルと一緒に、AccessManager-base/SUNWam/lib/ ディレクトリの AMConfig.properties ファイルで設定できます。デバッグプロパティーの詳細については、『Access Manager Administration Reference』の「AMConfig.properties file reference」を参照してください。

デバッグレベル

デバッグファイルに記録できる情報には、いくつかのレベルがあります。デバッグレベルは、AMConfig.properties の com.iplanet.services.debug.level プロパティーを使用して設定します。

  1. off—デバッグ情報は記録されません。

  2. error—このレベルは本稼働環境で使用されます。運用者は、本稼働環境ではデバッグファイルにエラーが記録されることのないように努めてください。

  3. warning—現在、このレベルを使用することは推奨されていません。

  4. message—コードトレースを使用するときに発生する可能性のある問題を警告します。ほとんどの Access Manager モジュールでは、このレベルを使用してデバッグメッセージが送信されます。

    注 –

    warning および message レベルは、本稼働環境では使用してはいけません。パフォーマンスが大きく低下し、大量のデバッグメッセージが送信されます。

デバッグ出力ファイル

デバッグファイルは、モジュールがデバッグファイルに書き込むときに作成されます。したがって、デフォルトの「error」モードでは、デバッグファイルは生成されません。デバッグレベルを「message」に設定した状態で基本的なログインを実行すると、次のデバッグファイルが作成されます。

もっとも頻繁に使用されるファイルは、amSDK、amProfile、および認証に関連するすべてのファイルです。記録された情報には、日付、時刻、およびメッセージタイプ (エラー、警告、message) が含まれます。

デバッグファイルの使用

デバッグレベルは、デフォルトでは「error」に設定されています。デバッグファイルは、管理者が次の作業を行っているときに役立ちます。

デバッグファイルは、今後提供する予定の障害追跡ガイドと一緒に使用することをお勧めします。たとえば、SSL に障害が発生したときには、「message」レベルのデバッグを有効にして、amJSS デバッグファイルで証明書固有のエラーを探してみるとよいでしょう。

複数の Access Manager インスタンスとデバッグファイル

Access Manager には、多数のサーバーインスタンスを設定するときに使用できるように、ammultiserverinstall スクリプトが用意されています。複数のサーバーインスタンスがそれぞれ異なるデバッグディレクトリを使用するように設定されている場合、各インスタンスに対してそれぞれのデバッグディレクトリへの読み取りアクセス権と書き込みアクセス権を割り当てる必要があります。

第 11 章 通知サービス

Sun Java System Access Manager 7.1 Notification Service を使用すると、セッション通知をリモートの web コンテナに送信できます。このサービスを、Access Manager サーバー本体から離れた場所で実行されている SDK アプリケーションが使用できるようにする必要があります。この章では、リモート web コンテナで通知を受信できるようにする方法について説明します。次の節があります。

概要

Notification Service を使用すると、Access Manager SDK をリモートで実行している web コンテナにセッション通知を送信できます。通知は、セッションサービス、ポリシーサービス、およびネームサービスにだけ適用されますまた、リモートアプリケーションは web コンテナ内で実行されなければなりません。通知には次のような目的があります。

リモート SDK が web コンテナにインストールされている場合にのみ、通知を受信できます。

通知サービスの有効化

次に、セッション通知を受信するためのリモート SSO SDK の設定手順を示します。

Procedureセッション通知を受信する

  1. Machine 1 に Access Manager をインストールします。

  2. Machine 2 に Sun Java System Web Server をインストールします。

  3. Web Server と同じマシンに SUNWamsdk をインストールします。

    Access Manager SDK をリモートでインストールする手順については、『Sun Java Enterprise System 5 インストールガイド』を参照してください。

  4. SDK がインストールされているマシンに関して、次のことが当てはまることを確認します。

    1. SDK がインストールされているサーバーの / remote_SDK_server/ SUNWam/lib ディレクトリおよび / remote_SDK_server / SUNWam/locale ディレクトリに対して正しいアクセス権が設定されている。

      これらのディレクトリには、リモートサーバーのファイルおよび jar ファイルが含まれます。

    2. Web Server の server.policy ファイルの「Grant」セクションに次のアクセス権が設定されていることを確認します。

      server.policy が、Web Server インストールの config ディレクトリに含まれる。これらのアクセス権は必要に応じてコピーおよびペーストできます。

      permission java.security.SecurityPermission "putProviderProperty.Mozilla-JSS"

      permission java.security.SecurityPermission "insertProvider.Mozilla-JSS";

    3. server.xml に正しいクラスパスが設定されていることを確認します。

      server.xml も、Web Server インストールの config ディレクトリに含まれる。標準的なクラスパスは次のとおりです。

      <JAVA javahome="/export/home/ws61/bin/https/jdk" 
serverclasspath="/export/home/ws61/bin/https/jar/webserv-rt.jar:${java.home}/lib/tools.jar:/export/home/ws61/bin/https/jar/webserv-ext.jar:/export/home/ws61/bin/https/jar/webserv-jstl.jar:/export/home/ws61/
	bin/https/jar/nova.jar"
classpathsuffix="::/IS_CLASSPATH_BEGIN_DELIM:				//usr/share/lib/xalan.jar:				//export/SUNWam/lib/xmlsec.jar:				//usr/share/lib/xercesImpl.jar:				//usr/share/lib/sax.jar:				//usr/share/lib/dom.jar:				//export/SUNWam/lib/dom4j.jar:				//export/SUNWam/lib/jakarta-log4j1.2.6.jar:				//usr/share/lib/jaxm-api.jar:				//usr/share/lib/saaj-api.jar:				//usr/share/lib/jaxrpc-api.jar:				//usr/share/lib/jaxrpc-impl.jar:				//export/SUNWam/lib/jaxm-runtime.jar:				//usr/share/lib/saaj-impl.jar:/export/SUNWam
				//lib:/export/SUNWam/locale:				//usr/share/lib/mps/jss3.jar:				//export/SUNWam/lib/	am_sdk.jar:				//export/SUNWam/lib/am_services.jar:				//export/SUNWam/lib/am_sso_provider.jar:				//export/SUNWam/lib/swec.jar:				//export/SUNWam/lib/acmecrypt.jar:				//export/SUNWam/lib/iaik_ssl.jar:				//usr/share/lib/jaxp-api.jar:				//usr/share/lib/mail.jar:				//usr/share/lib/activation.jar:				//export/SUNWam/lib/servlet.jar:				//export/SUNWam/lib/am_logging.jar:				//usr/share/lib/commons-logging.jar:				//IS_CLASSPATH_END_DELIM:" 
envclasspathignored="true" debug="false"
debugoptions="-Xdebug -Xrunjdwp:transport=dt_socket,
server=y,suspend=n" 
javacoptions="-g" 
dynamicreloadinterval="2">

  5. リモート SDK サーバーにインストールされた SSO サンプルを確認の目的で使用します。

    1. / remote_SDK_server /SUNWam/samples/sso ディレクトリに変更します。

    2. gmake を実行します。

    3. 生成されたクラスファイルを / remote_SDK_server /SUNWam/samples/sso から / remote_SDK_server /SUNWam/lib/ へコピーします。

  6. am.encryption.pwd プロパティーの暗号化値を、Access Manager とともにインストールされた AMConfig.properties ファイルから、SDK がインストールされたリモートサーバー上の AMConfig.properties ファイルにコピーします。

    am.encryption.pwd の値は、暗号化および復号化のためのパスワードとして使用されます。

  7. Access Manager に amadmin としてログインします。

    http://AcceessManager-HostName :3000/amconsole

  8. ブラウザの場所フィールドに次のアドレスを入力してサーブレットを実行し、SSOToken を検証します。http:// remote_SDK_host:58080/servlet/SSOTokenSampleServlet

    SSOTokenSampleServlet は、セッショントークンの検証とリスナーの追加に使用されます。サーブレットを実行すると、次のメッセージが出力されます。

    SSOToken host name: 192.18.149.33 SSOToken Principal name: uid=amAdmin,ou=People,dc=red,dc=iplanet,dc=com Authentication type used: LDAP IPAddress of the host: 192.18.149.33 The token id is AQIC5wM2LY4SfcyURnObg7vEgdkb+32T43+RZN30Req/BGE= Property: Company is - Sun Microsystems Property: Country is - USA SSO Token Validation test Succeeded

  9. クライアント SDK がインストールされているマシンの AMConfig.properties に com.iplanet.am.notification.url= プロパティーを設定します。


    com.iplanet.am.notification.url=http://clientSDK_host.domain:port
/servlet
    com.iplanet.services.comm.client.PLLNotificationServlet

  10. Web Server を再起動します。

  11. Access Manager に amadmin としてログインします。

    http://AcceessManager-HostName :3000/amconsole

  12. ブラウザの場所フィールドに次のアドレスを入力してサーブレットを実行し、再度 SSOToken を検証します。http:// remote_SDK_host:58080/servlet/SSOTokenSampleServlet

    リモート SDK が動作しているマシンが通知を受信すると、セッション状態が変わったときに個々のリスナーを呼び出します。リモート SDK が web コンテナにインストールされている場合にのみ、通知を受信できます。

Procedureポータルのみのインストール環境で通知サービスを有効化する

この節では、ポータルのみのインストール環境の WebLogic 8.1 で通知サービスを有効にする手順を説明します。デフォルトでは、WebLogic 8.1 は polling モードで動作します。amserver コンポーネントも含むポータルインスタンスの場合、これらの手順は不要です。amserver コンポーネントは、通知を実行するように自動的に設定されます。

  1. PLLNotificationServlet を WebLogic に登録します。

    WebLogic 8.1 では、web アプリケーションが配備されている必要があります。また、サーブレット URL は有効でなければなりません。有効な場合、ブラウザからアクセスすると次のメッセージが返されます。


    Webtop 2.5 Platform Low Level notification servlet

  2. 登録された URL を AMConfig.properties に次のように入力します。

    com.iplanet.am.notifaction.url=http:// weblogic_instance-host.domain:port/notification/PLLNotificationServlet

  3. AMConfig.properties でポーリングを無効にします。これにより、通知が自動的に有効になります。

    com.iplanet.am.session.client.polling.enable=false

  4. WebLogic を再起動して、設定をテストします。

    デバッグモードを message に設定している場合は、トリガーされたときにポータルにセッション通知が到達します。たとえば、Access Manager コンソールからあるユーザーを終了するなどのアクションにより、通知イベントが発生します。