Sun Java System Access Manager 7 2005Q4 管理ガイド

パート II アクセス制御

これは『Sun Java System Access Manager^TM 7 2005Q4 管理ガイド』の第 2 部です。アクセス制御インタフェースを利用すると、レルムベースのリソースを保護および規制するための認証サービスと承認サービスを作成および管理できます。企業内のユーザーが情報を要求すると、Access Manager はユーザーのアイデンティティーを検証し、ユーザーが要求した特定のリソースにそのユーザーがアクセスすることを承認します。次の章で構成されています。

第 4 章 Access Manager コンソール

Access Manager コンソールは、さまざまなレベルのアクセス権を持つ管理者がさまざまな操作を行うための Web インタフェースです。たとえば、レルムや組織を作成したり、それらのレルムに対してユーザーの作成または削除を行ったり、レルムのリソースへのアクセスを保護および制限するために適用するポリシーを確立するなどの操作を行います。また、現在のユーザーセッションを表示または終了したり、セッションの連携設定の管理 (認証ドメインやプロバイダの作成、削除、変更) も行います。管理者権限を持たないユーザーの場合は、個人情報 (名前、電子メールアドレス、電話番号など) の管理、パスワードの変更、グループへの加入または加入の解除、ロールの表示などを行うことができます。Access Manager コンソールは、以下の 2 つの基本ビューで構成されます。

管理ビュー

管理者ロールを持つユーザーが Access Manager から認証されると、デフォルトのビューが管理ビューになります。このビューでは、管理者は Access Manager に関連するほとんどの管理タスクを実行できます。Access Manager は、レルムモードと旧バージョンモードの 2 つのモードでインストールできます。それぞれのモードには、固有のコンソールが使用されます。レルムモードと旧バージョンモードの詳細は、『Sun Java System Access Manager 7 2005Q4 Technical Overview』を参照してください。

レルムモードのコンソール

管理者はレルムモードのコンソールを使用して、レルムベースのアクセス制御、デフォルトのサービス設定、Web サービスおよび連携を管理できます。管理者ログイン画面にアクセスするには、ブラウザで次のアドレス構文を使用します。

protocol://servername/amserver/UI/Login

protocol には、配備方法に応じて http または https を指定します。

図 4–1 レルムモードの管理ビュー

旧バージョンモードのコンソール

旧バージョンモードのコンソールは、Access Manager 6.3 アーキテクチャーに基づいて設計されています。この旧バージョンの Access Manager アーキテクチャーでは、Sun Java System Directory Server に備えられている LDAP ディレクトリ情報ツリー (directory information tree、DIT) が使用されます。旧バージョンモードでは、ユーザー情報とアクセス制御情報が LDAP 組織に格納されます。旧バージョンモードを選択した場合、LDAP 組織はアクセス制御レルムに相当します。レルム情報は、LDAP 組織に統合されます。旧バージョンモードでは、「ディレクトリ管理」タブを使用して、Access Manager ベースのアイデンティティー管理を行うことができます。

管理者ログイン画面にアクセスするには、ブラウザで次のアドレス構文を使用します。

protocol://servername/amserver/console

protocol には、配備方法に応じて http または https を指定します。

図 4–2 旧バージョンモードの管理ビュー

旧バージョンモード 6.3 コンソール

Access Manager 6.3 の一部の機能は、Access Manager 7.0 コンソールでは使用できません。このため、管理者は 7.0 の旧バージョン配備から 6.3 コンソールにログインできるようになっています。Access Manager を構築する Sun Java System Portal Server またはその他の Sun Java System 通信製品の主アイデンティティーリポジトリとして、Sun Java System Directory Server を使用しなければならない場合には、通常はこのコンソールを使用します。委任管理やサービスクラスなどのほかの機能には、このコンソールだけからアクセスできます。

注 –

6.3 旧バージョンモードコンソールと 7.0 旧バージョンモードコンソールを交互に使用しないでください。

6.3 コンソールにアクセスするには、ブラウザで次のアドレス構文を使用します。

protocol://servername/amconsole

protocol には、配備方法に応じて http または https を指定します。

図 4–3 6.3 ベースのコンソールの管理ビュー

ユーザープロファイルビュー

管理者ロールが割り当てられていないユーザーが Access Manager から認証されると、それぞれのユーザープロファイルビューがデフォルトビューになります。ユーザープロファイルビューには、レルムモードまたは旧バージョンモードでアクセスできます。このビューにアクセスするには、「ログイン」ページでそれぞれのユーザー名とパスワードを入力する必要があります。

ユーザープロファイルビューでは、それぞれのユーザープロファイル固有の属性の値を修正できます。たとえば、名前、ホームアドレス、パスワードなどの属性を修正できます。ユーザープロファイルビューに表示された属性は、展開することができます。

図 4–4 ユーザープロファイルビュー

第 5 章レルムの管理

アクセス制御レルムは、ユーザーまたはユーザーのグループと関連付けることのできる認証プロパティーおよび承認ポリシーのグループです。レルムデータは、指定されたデータストアの内部に Access Manager が作成する独自形式の情報ツリーに格納されます。Access Manager フレームワークは、各レルムに含まれるポリシーおよびプロパティーを Access Manager 情報ツリーの内部に集約します。デフォルトでは、Access Manager 7 は自動的に、ユーザーデータとは別の、Sun Java Enterprise System Directory Server 内の特別なブランチとして Access Manager 情報ツリーを挿入します。アクセス制御レルムは、任意の LDAPv3 データベースの使用中に使用できます。

レルムの詳細については、『Sun Java System Access Manager 7 2005Q4 Technical Overview』を参照してください。

「レルム」タブで、アクセス制御に関する次のプロパティーを設定できます。

レルムの作成と管理

ここでは、レルムを作成および管理する方法について説明します。

新しいレルムを作成する

手順

「アクセス制御」タブの下の「レルム」リストから「新規」を選択します。

次の一般属性を定義します。

名前

レルムの名前を入力します。

親

レルムを作成する位置を定義します。その下に新しいレルムが作成される親のレルムを選択します。

次のレルム属性を定義します。

レルムの状態

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

レルムまたは DNS のエイリアス

レルムの DNS 名に対するエイリアス名を追加できます。この属性では、実際のドメインエイリアスだけを使用できます。ランダムな文字列は使用できません。

「了解」をクリックして保存するか、「取消し」をクリックして前のページに戻ります。

一般プロパティー

「一般プロパティー」ページには、レルムの基本属性が表示されます。これらのプロパティーを変更するには、「アクセス制御」タブの下の「レルム名」リストからレルムをクリックします。その後、次のプロパティーを編集します。

レルムの状態: 「アクティブ」または「非アクティブ」の状態を選択します。デフォルトは「アクティブ」です。この属性は、レルムの存続期間中であればいつでも「プロパティー」アイコンを選択して変更できます。「非アクティブ」を選択すると、ログイン時のユーザーアクセスが無効になります。
レルムまたは DNS のエイリアス: レルムの DNS 名に対するエイリアス名を追加できます。この属性では、実際のドメインエイリアスだけを使用できます。ランダムな文字列は使用できません。

プロパティーを編集したら、「保存」をクリックします。

認証

ユーザーがほかの認証モジュールを使ってログインできるようにするには、事前に一般認証サービスをサービスとしてレルムに登録する必要があります。コア認証サービスでは、Access Manager 7 管理者がレルムの認証パラメータのデフォルト値を定義できます。その後、指定された認証モジュールでオーバーライド値が定義されない場合にこれらの値を使用できます。コア認証サービスに対するデフォルト値は amAuth.xml ファイルで定義され、インストール後に Directory Server に格納されます。

詳細については、第 7 章「認証の管理」を参照してください。

サービス

Access Manager におけるサービスとは、Access Manager コンソールでひとまとめに管理される属性のグループのことです。社員の氏名、役職、電子メールアドレスなど、関連性のある情報を属性として扱うことができます。ただし、属性は一般に、メールアプリケーションや給与支払サービスのようなソフトウェアモジュール用の設定パラメータとして使用されます。

「サービス」タブでは、多数の Access Manager デフォルトサービスをレルムに追加し、設定できます。次のサービスを追加できます。

管理
ディスカバリサービス
国際化設定
パスワードリセット
セッション
ユーザー

注 –

Access Manager は、サービスの .xml ファイルの必須属性に一部のデフォルト値が含まれるようにします。値のない必須属性のあるサービスがある場合は、デフォルト値を追加してサービスを再読み込みします。

サービスをレルムに追加する

手順

新しいサービスを追加するレルムの名前をクリックします。

「サービス」タブを選択します。

「サービス」リスト内の「追加」をクリックします。

レルムに追加するサービスを選択します。

「次へ」をクリックします。

レルム属性を定義して、サービスを設定します。サービス属性の詳細については、オンラインヘルプの「設定」を参照してください。

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

サービスのプロパティーを編集するには、「サービス」リスト内の名前をクリックします。

権限

権限は、レルムの内部に存在するロールまたはグループへのアクセス権を定義します。ロールまたはグループは、Access Manager アイデンティティー対象タイプに対するポリシー対象定義として使用されます。権限の割り当てまたは変更を行うには、編集するロールまたはグループの名前をクリックします。割り当てることができる権限には次のものがあります。

ポリシープロパティーのみに対する読み取りおよび書き込みアクセス
すべてのレルムプロパティーおよびポリシープロパティーに対する読み取りおよび書き込みアクセス
すべてのプロパティーおよびサービスに対する読み取り専用アクセス

第 6 章データストア

データストアは、ユーザー属性およびユーザー設定データを格納できるデータベースです。

Access Manager は、アイデンティティーリポジトリフレームワークに接続するアイデンティティーリポジトリプラグインを提供します。この新しいモデルにより、既存のユーザーデータベースに変更を加える必要なしに、Access Manager ユーザー情報を表示および取得できます。Access Manager フレームワークは、アイデンティティーリポジトリプラグインからのデータをほかの Access Manager プラグインからのデータと統合し、各ユーザーの仮想アイデンティティーを形成します。Access Manager はその後、複数のアイデンティティーリポジトリ間で、認証と承認のプロセスにユニバーサルアイデンティティーを使用できます。仮想ユーザーアイデンティティーは、ユーザーのセッション終了時に破棄されます。

LDAPv3 データストア

Access Manager をレルムモードと旧バージョンモードの両方でインストールするときに、任意の一般 LDAPv3 リポジトリの新しいデータストアインスタンスを作成できます。次の場合に LDAPv3 リポジトリタイプを選択することをお勧めします。

ロール、サービスのクラス (CoS)、および以前のバージョンの Access Manager との互換性が必要でない場合。
既存のディレクトリを使用する場合。
Sun Java System Directory Server 以外のディレクトリサーバーをアイデンティティーリポジトリに使用する場合。
Access Manager からアイデンティティーリポジトリに書き込まない場合。
平坦なディレクトリ情報ツリー (DIT) を使用する場合。

新しい LDAPv3 データストアを作成する

次の節では、一般的な LDAPv3 データストアを接続する手順について説明します。

手順

新しいデータストアを追加するレルムを選択します。

「データストア」タブをクリックします。

「データストア」リストから「新規」をクリックします。

データストアの名前を入力します。

LDAPv3 リポジトリプラグインの属性を定義します。

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

LDAPv3 リポジトリプラグインの属性

LDAPv3 リポジトリプラグインを設定するために、次の属性を使用できます。

プライマリ LDAP サーバー

接続先 LDAP サーバーの名前を入力します。「ホスト名.ドメイン名:ポート番号」の形式を使用することをお勧めします。

複数の「ホスト:ポート番号」エントリが入力された場合、リスト内の最初のホストへの接続が試みられます。リスト内の次のエントリは、現在のホストへの接続試行が失敗した場合にのみ試行されます。

LDAP バインド DN

現在接続している LDAP サーバーに対して認証を行うために Access Manager が使用する DN 名を指定します。バインドに使用される DN 名を持つユーザーには、「LDAPv3 でサポートされるタイプおよび操作」属性で設定した、正しい追加/変更/削除権限を付与することをお勧めします。

LDAP バインドパスワード

現在接続している LDAP サーバーに対して認証を行うために Access Manager が使用する DN パスワードを指定します。

LDAP バインドパスワード (確認)

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

LDAP 組織 DN

このデータストアリポジトリのマッピング先となる DN。これは、このデータストア内で実行されるすべての操作のベース DN となります。

LDAP SSL を有効

有効にすると、Access Manager は HTTPS プロトコルを使用してプライマリサーバーに接続します。

LDAP 接続プールの最小サイズ

接続プール内の接続の初期数を指定します。接続プールを利用すると、新しい接続を毎回作成する必要がなくなります。

LDAP 接続プールの最大サイズ

許容される接続数の上限を指定します。

検索で返される結果の最大数

検索操作で返されるエントリ数の上限を指定します。この制限に達すると、Directory Server は検索要求に一致するあらゆるエントリを返します。

検索タイムアウト

検索要求に割り当てられる最大の秒数を指定します。この制限に達すると、Directory Server は検索要求に一致するあらゆる検索エントリを返します。

LDAP の従う参照

このオプションを有効にすると、ある LDAP サーバーからの別の LDAP サーバーに対する参照が自動的に実行されます。

LDAPv3 リポジトリプラグインクラス名

LDAPv3 リポジトリを実装するクラスファイルの場所を指定します。

属性名マッピング

フレームワークが認識する共通属性をネイティブデータストアにマップできるようにします。たとえば、フレームワークがユーザー状態の判定に inetUserStatus を使用する場合に、ネイティブデータストアが実際には userStatus を使用することが可能です。属性定義では大文字と小文字が区別されます。

LDAPv3 プラグインでサポートされるタイプおよび操作

この LDAP サーバー上で許可されている、または実行可能な操作を指定します。この LDAPv3 リポジトリプラグインでサポートされている操作はデフォルト操作だけです。LDAPv3 リポジトリプラグインでサポートされている操作は次のとおりです。

グループ — 読み取り、作成、編集、削除
レルム — 読み取り、作成、編集、削除、サービス
ユーザー — 読み取り、作成、編集、削除、サービス
エージェント — 読み取り、作成、編集、削除

LDAP サーバー設定とタスクに基づいて、これらの操作からアクセス権を削除できますが、アクセス権の追加はできません。

LDAP ユーザー検索属性

このフィールドは、ユーザーの検索を実行するための属性タイプを定義します。たとえば、ユーザーの DN が「uid=k user5,ou=people,dc=iplanet,dc=com」の場合、ネーミング属性は uid です。(uid=*) がユーザーの検索フィルタに付加されます。

LDAP ユーザー検索フィルタ

ユーザーエントリの検索に使用する検索フィルタを指定します。たとえば、「LDAP ユーザー検索属性」が uid で、「LDAP ユーザー検索フィルタ」が (objectClass=inetorgperson) の場合、実際のユーザー検索フィルタは次のようになります。(&(uid=*)(objectClass=inetorgperson))

LDAP ユーザーオブジェクトクラス

ユーザーのオブジェクトクラスを指定します。ユーザーが作成されると、このユーザーオブジェクトクラスのリストがユーザーの属性リストに追加されます。

LDAP ユーザー属性

ユーザーと関連付けられる属性のリストを定義します。このリストにないユーザー属性の読み取りまたは書き込みは一切行うことができません。属性は大文字と小文字が区別されます。ここでオブジェクトクラスと属性スキーマを定義する前に、Directory Server でオブジェクトクラスと属性スキーマが定義されている必要があります。

LDAP グループ検索属性

このフィールドは、グループの検索を実行するための属性タイプを定義します。たとえば、グループ DN が「cn=group1,ou=groups,dc=iplanet,dc=com」で、グループのネーミング属性が cn の場合、(cn=*) がグループ検索フィルタに付加されます。

LDAP グループ検索フィルタ

グループエントリの検索に使用する検索フィルタを指定します。たとえば、「LDAP グループ検索属性」が cn で、「LDAP グループ検索フィルタ」が (objectclass=groupOfUniqueNames) の場合、実際のグループ検索フィルタは ((&(cn=*)(objectclass=groupOfUniqueNames)) になります。

LDAP グループコンテナネーミング属性

グループがコンテナ内に位置する場合に、グループコンテナのネーミング属性を指定します。コンテナ内に位置しない場合、この属性は空のままとされます。たとえば、「cn=group1,ou=groups,dc=iplanet,dc=com」のグループDN が ou=groups 内に位置する場合、グループコンテナネーミング属性は ou です。

LDAP グループコンテナ値

グループコンテナの値を指定します。たとえば、「cn=group1,ou=groups,dc=iplanet,dc=com」のグループ DN がコンテナ名 ou=groups 内に位置する場合、グループコンテナ値は groups になります。

LDAP グループオブジェクトクラス

グループのオブジェクトクラスを指定します。グループが作成されると、グループオブジェクトクラスのこのリストがグループの属性リストに追加されます。

LDAP グループ属性

グループと関連付けられる属性のリストを定義します。このリストにないグループ属性の読み取りまたは書き込みは一切行うことができません。属性は大文字と小文字が区別されます。ここでオブジェクトクラスと属性スキーマを定義する前に、Directory Server でオブジェクトクラスと属性スキーマが定義されている必要があります。

グループメンバーシップの属性名

DN が属する全グループの名前がその値である属性の名前を指定します。デフォルトは memberOf です。

グループメンバーの属性名

このグループに属している DN がその値である属性名を指定します。デフォルトは uniqueMember です。

グループメンバー URL の属性名

このグループに属しているメンバーを決定する LDAP URL がその値である、属性の名前を指定します。デフォルトは memberUrl です。

LDAP ピープルコンテナネーミング属性

ユーザーがピープルコンテナ内に位置する場合に、ピープルコンテナのネーミング属性を指定します。ユーザーがピープルコンテナ内に位置しない場合、このフィールドは空のままとされます。たとえば、ユーザー DN を「uid=kuser5,ou=people,dc=iplanet,dc=com,」とすると、ou=people がピープルコンテナの名前の場合、ネーミング属性は ou です。

LDAP ピープルコンテナ値

ピープルコンテナの値を指定します。デフォルトは people です。たとえば、ユーザー DN を「uid=kuser5,ou=people,dc=iplanet,dc=com」とすると、ou=people がピープルコンテナの名前の場合、ネーミング属性は ou で、people は「LDAP ピープルコンテナ値」です。

LDAP エージェント検索属性

このフィールドは、エージェントの検索を実行するための属性タイプを定義します。デフォルトは uid です。たとえば、エージェントの DN が「uid=kagent1,ou=agents,dc=iplanet,dc=com」の場合、エージェントのネーミング属性は uid です。(uid=*) がエージェントの検索フィルタに付加されます。

LDAP エージェントコンテナネーミング属性

エージェントがエージェントコンテナ内に位置する場合の、エージェントコンテナのネーミング属性。エージェントがエージェントコンテナ内に位置しない場合、このフィールドは空のままとされます。たとえば、ユーザー DN を「uid=kagent1,ou=agents,dc=iplanet,dc=com」とすると、エージェントネーミング属性は ou です。

LDAP エージェントコンテナ値

エージェントコンテナの値を指定します。エージェントがエージェントコンテナ内に位置しない場合は空のままとされます。前の例では、エージェントコンテナ値は agents になります。

LDAP エージェント検索フィルタ

エージェントの検索に使用するフィルタを定義します。実際のエージェント検索フィルタは、このフィールドの値の前に「LDAP エージェント検索属性」の値を付加することによって構築されます。

たとえば、「LDAP エージェント検索属性」が uid で、「LDAP ユーザー検索フィルタ」が (objectClass=sunIdentityServerDevice) の場合、実際のユーザー検索フィルタは次のようになります。(&(uid=*)(objectClass=sunIdentityServ erDevice))

LDAP エージェントオブジェクトクラス

エージェントのオブジェクトクラスを定義します。エージェントが作成されると、エージェントオブジェクトクラスのリストがエージェントの属性リストに追加されます。

LDAP エージェント属性

エージェントと関連付けられる属性のリストを定義します。このリストにないエージェント属性の読み取りまたは書き込みは一切行うことができません。属性は大文字と小文字が区別されます。ここでオブジェクトクラスと属性スキーマを定義する前に、Directory Server でオブジェクトクラスと属性スキーマが定義されている必要があります。

持続検索ベース DN

持続検索に使用するベース DN を定義します。一部の LDAPv3 サーバーは、ルートサフィックスレベルでの持続検索のみをサポートします。

再起動前の持続検索の最大アイドル時間

持続検索を再開するまでの最大アイドル時間を定義します。1 よりも大きい値を設定する必要があります。1 以下の値を設定すると、接続のアイドル時間とは無関係に検索を再開します。

Access Manager がロードバランサとともに配備される場合、一部のロードバランサは、指定された時間アイドル状態が続くとタイムアウトします。この場合、ロードバランサに対して指定された時間よりも小さい値を「再起動前の持続検索の最大アイドル時間」に設定することをお勧めします。

エラーコードのあとの再試行の最大数

「再試行する LDAPException エラーコード」で指定されたエラーコードが返された場合に、持続検索操作を再試行する回数の上限を定義します。

再試行の間の遅延時間

各再試行の前に待機する時間を指定します。これは、持続検索接続にのみ適用されます。

再試行する LDAPException エラーコード

持続検索操作を再試行させるエラーコードを指定します。この属性は持続検索のみに適用され、すべての LDAP 操作に適用されるわけではありません。

AMSDK リポジトリプラグイン

AMSDK アイデンティティーリポジトリは、Access Manager を旧バージョンモードでインストールするときに、自動的に Access Manager 情報ツリーと混合されます。レルムモードでは、AMSDK リポジトリのインストールは選択できますが、アイデンティティーリポジトリは Access Manager 情報ツリーと混合されません。次の場合に AMSDK リポジトリタイプを選択することをお勧めします。

ロールや CoS など、Sun Java System Directory Server 固有の機能を利用する場合。
前のバージョンの Access Manager との互換性を確保する場合。

新しい AMSDK リポジトリプラグインを作成する

手順

Access Manager リポジトリプラグインを設定するレルムを選択します。

「データストア」タブをクリックします。

「データストア」リストから「新規」をクリックします。

リポジトリプラグインの名前を入力します。

「Access Manager リポジトリプラグイン」を選択します。

「次へ」をクリックします。

次のフィールドを定義します。

Access Manager プラグインクラス名

Access Manager リポジトリプラグインを実装するクラスファイルの場所を指定します。

Access Manager 組織

Access Manager によって管理される、Directory Server 内の組織を指す DN。これは、このデータストア内で実行されるすべての操作のベース DN となります。

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

第 7 章認証の管理

認証サービスは、Access Manager の配備先にインストールされたすべてのデフォルト認証タイプに対して Web ベースのユーザーインタフェースを提供します。このインタフェースは、アクセスを要求するユーザーに対して、呼び出される認証モジュールに基づいたログイン条件画面を表示して認証資格を収集する動的かつカスタマイズ可能な手段を提供します。このインタフェースは、開発者が実用的な Web アプリケーションを作成するのに役立つ Java 2 Enterprise Edition (J2EE) プレゼンテーションフレームワークである Sun Java System™ Application Framework (JATO と呼ばれることもある) を使用して作成されています。

認証の設定

ここでは、配備の認証を設定する方法について説明します。最初の節では、デフォルトの認証モジュールタイプの概要について説明し、必要な事前の設定手順を示します。レルム、ユーザー、ロールなどに対して、同じ認証モジュールタイプの複数の設定インスタンスを設定できます。また、認証に成功するためには複数のインスタンスの条件に合格する必要があるようにするため、認証連鎖を追加することもできます。次の内容で構成されています。

認証モジュールタイプ

認証モジュールは、ユーザー ID やパスワードなどのユーザー情報を収集し、その情報をデータベース内のエントリで確認するプラグインです。ユーザーが認証条件を満たす情報を入力した場合、そのユーザーは要求するリソースへのアクセスを許可されます。ユーザーが認証条件を満たしていない情報を入力した場合、そのユーザーは要求したリソースへのアクセスを拒否されます。Access Manager は、次の 15 タイプの認証モジュールとともにインストールされます。

注 –

一部の認証モジュールタイプでは、認証インスタンスとして使用できるようにするには、事前の設定が必要です。必要に応じて、設定手順がモジュールタイプの説明にリスト表示されています。

コア

Access Manager では、コア認証モジュールばかりではなく、デフォルトで 15 種類の認証モジュールを提供しています。コア認証モジュールでは、認証モジュールの全体的な設定を行います。Active Directory 認証、匿名認証、証明書に基づく認証、HTTP 基本認証、JDBC 認証、LDAP 認証、任意の認証のモジュールを追加して有効にする前に、コア認証モジュールの追加と有効化を行う必要があります。コア認証モジュールおよび LDAP 認証モジュールは両方とも、デフォルトのレルムに対して自動的に有効になります。

「拡張プロパティー」ボタンをクリックすると、レルムに対して定義できる「コア」認証属性が表示されます。グローバル属性はレルムに適用できないので表示されません。

Active Directory

Active Directory 認証モジュールでは、LDAP モジュールと同様の認証が実行されますが、LDAP 認証モジュールの場合の Directory Server ではなく、Microsoft の Active Directory™ サーバーが使用されます。LDAP 認証モジュールを Active Directory サーバー用に設定できますが、このモジュールでは、LDAP と Active Directory 認証の両方を同一レルム下に存在させることができます。

注 –

このリリースの Active Directory 認証モジュールでは、ユーザー認証のみがサポートされます。パスワードポリシーは LDAP 認証モジュールのみでサポートされます。

匿名 (anonymous)

デフォルトでは、このモジュールを有効にすると、ユーザーは匿名ユーザーとして Access Manager にログインできるようになります。「有効な匿名ユーザー」のリスト属性を設定して、このモジュールに匿名ユーザーのリストを定義することもできます。匿名アクセスを許可するということは、パスワードなしでアクセスさせるということです。匿名アクセスは、特定の種類のアクセス (読み取りのためのアクセスや検索のためのアクセスなど)、特定のサブツリー、またはディレクトリ内の個別のエントリに制限されます。

証明書

証明書に基づく認証では、個人用デジタル証明書 (PDC) を使用してユーザーを特定し、認証します。Directory Server に格納された PDC に一致すること、また証明書失効リスト (CRL) で確認されていることを求めるように、PDC を設定できます。

証明書に基づく認証モジュールをレルムに追加する前に、行う必要のある作業があります。まず、Access Manager とともにインストールした Web コンテナを保護し、証明書に基づく認証で使用できるように設定する必要があります。証明書に基づくモジュールを有効にする前に、Web Server に対するこれらの初期設定手順について、『Sun ONE Web Server 6.1 管理者ガイド』の第 6 章「証明書と鍵の使用」を参照してください。このマニュアルは、次の場所にあります。

http://docs.sun.com/db/prod/s1websrv#hic

または、次の場所にある『Sun ONE Application Sever Administrator's Guide to Security』を参照してください。

http://docs.sun.com/db/prod/s1appsrv#hic

注 –

証明書に基づくモジュールを使用して認証されるユーザーは、ブラウザ用に PDC を要求する必要があります。使用しているブラウザによって、手順が異なります。詳細は、お使いのブラウザのマニュアルを参照してください。

このモジュールを追加するためには、Access Manager にレルム管理者としてログインし、Access Manager と Web コンテナに対して SSL を設定し、クライアント認証を有効化しておく必要があります。詳細は、第 3 章「Access Manager の SSL モードへの設定」を参照してください。

HTTP 基本

このモジュールは、HTTP プロトコルのビルトイン認証サポートである基本認証を使用します。Web サーバーはユーザー名とパスワードを求めるクライアント要求を発行し、その情報を認証済み要求の一部としてサーバーに返します。Access Manager ではユーザー名とパスワードを取得し、LDAP 認証モジュールに対してユーザーを内部的に認証します。HTTP 基本認証が正常に機能するために、LDAP 認証モジュールを追加する必要があります (HTTP 基本モジュールを単独で追加しても機能しない)。いったん認証に成功したユーザーには、再認証の際にユーザー名とパスワードの入力は要求されません。

JDBC

JDBC (Java Database Connectivity) 認証モジュールでは、JDBC 技術に対応したドライバを提供する SQL データベースを通して Access Manager でユーザーを認証できるようにするメカニズムが提供されます。SQL データベースへの接続は、JDBC ドライバを通して直接行うか、JNDI 接続プールで行います。

注 –

このモジュールは、MySQL4.0 と Oracle 8i でテストされています。

LDAP

LDAP 認証モジュールを使用すると、ユーザーがログインするときに、特定のユーザー DN およびパスワードを使用して、LDAP Directory Server にバインドする必要があります。すべてのレルムに基づく認証では、デフォルトの認証モジュールです。ユーザーが Directory Server に存在するユーザー ID およびパスワードを指定すると、ユーザーは有効な Access Manager セッションへのアクセスが許可され、セットアップされます。コア認証モジュールおよび LDAP 認証モジュールは両方とも、デフォルトのレルムに対して自動的に有効になります。

メンバーシップ

メンバーシップ認証は、my.site.com または mysun.sun.com のように、パーソナライズされたサイトのように実装されます。モジュールが有効なときに、ユーザーは管理者の支援なしでアカウントを作成し、パーソナライズします。ユーザーは作成したアカウントを使用し、追加済みユーザーとしてアクセスできます。また、ユーザーはビューアのインタフェースにアクセスできます。ビューアのインタフェースは、認証データおよびユーザー設定として、ユーザープロファイルデータベースに保存されています。

MSISDN

MSISDN (Mobile Station Integrated Services Digital Network) 認証モジュールでは、携帯電話などのデバイスに関連するモバイル加入者 ISDN を使用して認証できます。これは対話型モジュールではありません。このモジュールでは加入者 ISDN が取得されて Directory Server で妥当性が検査され、番号が一致するユーザーが検索されます。

RADIUS

Access Manager は、すでにインストールされている RADIUS サーバーと連携するように設定できます。エンタープライズで認証のために旧バージョンの RADIUS サーバーを使用している場合に便利です。RADIUS 認証モジュールを有効にするには、次の 2 つの手順を行います。

RADIUS サーバーを設定します。

詳しい手順については、RADIUS サーバーのマニュアルを参照してください。
RADIUS 認証モジュールを登録し、有効にします。

Sun Java System Application Server で RADIUS を設定する

RADUIS クライアントがそのサーバーに対してソケット接続を作成するとき、デフォルトでは、Application Server の server.policy ファイルで SocketPermission の connect アクセス権だけが与えられています。RADUIS 認証を正常に機能させるには、次のアクションを許可する必要があります。

accept (受け入れ)
connect (接続)
listen (待機)
resolve (解決)

ソケット接続のアクセス権を与えるには、Application Server の server.policy ファイルにエントリを追加します。SocketPermission は、ホストの指定と、そのホストへの接続方法を指定する一連のアクションとで構成されます。ホストは次のように指定されます。

host = hostname | IPaddress:portrange:portrange = portnumber 
| -portnumberportnumber-portnumber

ホストは、DNS 名または IP アドレスの数値で表されるか、ローカルマシンの場合は localhost と表されます。DNS 名でホストを指定する場合は、ワイルドカード "*" を 1 つだけ使用できます。ワイルドカードを使用する場合は、*.example.com のように、左端に置く必要があります。

ポート (またはポート範囲) は省略可能です。N- という形式のポート指定は、N またはそれ以上の番号を持つすべてのポートを表します。ここで、N はポート番号です。-N という形式のポート指定は、N またはそれ以下の番号を持つすべてのポートを表します。

listen アクションは、ローカルホストで使用される場合のみ有効です。resolve (ホスト/IP 解決のネームサービスルックアップ) アクションは、ほかの任意のアクションが存在する場合に暗黙的に使用されます。

たとえば、SocketPermission を作成するときに次のアクセス権をコードに与えると、そのコードは machine1.example.com のポート 1645 に接続でき、またそのポート上で接続を受け入れることができます。

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

同様に、次のアクセス権を与えられたコードは、ローカルホストのポート 1024 〜 65535 に接続することと、これらのポートで接続受け入れおよび待機を行うことができます。

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

注 –

リモートホストに対する接続受け入れや接続作成のアクセス権をコードに与えると、悪意のあるコードによって、本来アクセス権を持たない第三者に機密データが転送されたり共有されたりしやすくなるので、問題が発生することがあります。適切なアクセス権だけを与えるために、ポート番号を範囲で指定するのではなく、正確なポート番号を指定してください。

SafeWord

Secure Computing の SafeWord™ または SafeWord PremierAccessd™ 認証サーバーに対して送られる SafeWord 認証要求を処理するように、Access Manager を設定できます。Access Manager は、SafeWord 認証のクライアント部分を担当します。SafeWord サーバーは、Access Manager のインストールされているシステムにも、別のシステムにも置くことができます。

Sun Java System Application Server で SafeWord を設定する

SafeWord クライアントがそのサーバーに対してソケット接続を作成するとき、デフォルトでは、Application Server の server.policy ファイルで SocketPermission の connect アクセス権だけが与えられています。SafeWord 認証を正常に機能させるには、次のアクションを許可する必要があります。

accept (受け入れ)
connect (接続)
listen (待機)
resolve (解決)

host = (hostname | IPaddress)[:portrange] portrange = 
portnumber | -portnumberportnumber-[portnumber]

ポート (portrange) は省略可能です。N- という形式のポート指定は、N またはそれ以上の番号を持つすべてのポートを表します。ここで、N はポート番号です。-N という形式のポート指定は、N またはそれ以下の番号を持つすべてのポートを表します。

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

注 –

SAML

SAML (Security Assertion Markup Language) 認証モジュールでは、ターゲットサーバーで SAML アサーションの受信と確認が行われます。このモジュールが、Access Manager 2005Q1 から Access Manager 2005Q4 などのアップグレード後も含めて、ターゲットマシンで設定されている場合にかぎって、SAML SSO は動作します。

SecurID

RSA の ACE/Server 認証サーバーに対して送られる SecurID 認証要求を処理するように、Access Manager を設定できます。Access Manager は、SecurID 認証のクライアント部分を担当します。ACE/Server は、Access Manager のインストールされているシステムにも、別のシステムにも置くことができます。ローカルで管理されたユーザー ID を認証する (admintool (1M) 参照) には、ルートでアクセスする必要があります。

SecurID 認証では、認証ヘルパー amsecuridd を使用します。認証ヘルパーは Access Manager のメインのプロセスとは独立したプロセスです。起動すると、このヘルパーは設定情報を得るためにポートで待機します。Access Manager が nobody として、または root 以外のユーザー ID で実行するようにインストールされている場合でも、AccessManager-base/SUNWam/share/bin/amsecuridd プロセスは root ユーザーとして実行する必要があります。amsecuridd ヘルパーについては、第 20 章「amsecuridd ヘルパー」を参照してください。

注 –

このリリースの Access Manager の場合、Linux プラットフォームと Solaris x86 プラットフォームでは SecurID 認証モジュールを使用できません。この 2 つのプラットフォームでは、SecurID 認証モジュールの登録、設定、有効化を行わないでください。SecurID 認証モジュールは、SPARC のみで使用できます。

UNIX

Access Manager がインストールされている Solaris または Linux システムで既知の UNIX ユーザー ID およびパスワードに対する認証要求を処理するように、Access Manager を設定できます。UNIX 認証ではレルム属性は 1 つだけしかなく、またグローバル属性は少ししかありませんが、システムの観点から検討すべき点があります。ローカルで管理されたユーザー ID を認証する (admintool (1M) 参照) には、ルートでアクセスする必要があります。

UNIX 認証では、認証ヘルパー amunixd を使用します。認証ヘルパーは Access Manager のメインのプロセスとは独立したプロセスです。起動すると、このヘルパーは設定情報を得るためにポートで待機します。UNIX ヘルパーは Access Manager ごとに 1 つだけあり、そのすべてのレルムで共用されます。

Access Manager が nobody として、または root 以外のユーザー ID で実行するようにインストールされている場合でも、AccessManager-base/SUNWam/share/bin/amunixd プロセスは root ユーザーとして実行する必要があります。UNIX 認証モジュールは、UNIX 認証要求を待機するために localhost:58946 へのソケットを開くことで、amunixd デーモンを呼び出します。デフォルトのポートで amunixd ヘルパーを実行するには、次のコマンドを入力します。

./amunixd

デフォルト以外のポートで amunixd ヘルパーを実行するには、次のコマンドを入力します。

./amunixd [-c portnm] [ipaddress]

ipaddress と portnumber は、AMConfig.properties 内の UnixHelper.ipadrs 属性 (IPV4 形式) と UnixHelper.port 属性で指定されています。amunixd を amserver コマンド行ユーティリティーから実行することもできます。amserver は AMConfig.properties からポート番号と IP アドレスを取り出し、このプロセスを自動的に実行します。

/etc/nsswitch.conf ファイル内の passwd エントリでは、/etc/passwd および /etc/shadow ファイル、または NIS を認証で探すかどうかを指定します。

Windows デスクトップ SSO

Windows デスクトップ SSO 認証モジュールは、Windows 2000™ に使用する、Kerberos ベースのプラグインモジュールです。このサービスを使用すると、Kerberos Distribution Center (KDC) で認証されたユーザーは、ログインの条件を再度提示しなくても Access Manager に認証されます (シングルサインオン)。

ユーザーは、SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) プロトコルで Access Manager に Kerberos トークンを送信します。この認証モジュールで Access Manager への Kerberos ベースのシングルサインオンを実行するには、ユーザーが、クライアントサイドにおいて、SPNEGO プロトコルをサポートして自分自身を認証する必要があります。一般的に、このプロトコルをサポートするすべてのユーザーは、このモジュールを使用して Access Manager に認証できます。クライアントサイドでトークンを使用できるかどうかにより、SPENGO トークンか Kerberos トークンがこのモジュールによって提供されます。どちらの場合でもプロトコルは同一です。Microsoft Windows 2000 以上で動作している Microsoft Internet Explorer 5.01 以上では、現在このプロトコルがサポートされています。Solaris 9 および 10 の Mozilla 1.4 では SPNEGO がサポートされますが、Solaris では SPNEGO がサポートされていないので、返されるトークンは KERBEROS トークンのみです。

注 –

Kerberos V5 認証モジュールの新機能を使用するには、JDK 1.4 以上を使用する必要があります。この SPNEGO モジュールで Kerberos ベースの SSO を実行するには、Java GSS API を使用する必要があります。

Internet Explorer の既知の制限事項

WindowsDesktopSSO 認証に Microsoft Internet Explorer 6.x を使用しており、WindowsDesktopSSO モジュールで設定されている KDC レルムと一致する、ユーザーの Kerberos/SPNEGO トークンにこのブラウザでアクセスできない場合、WindowsDesktopSSO モジュールへの認証がエラーになったあとで、このブラウザはその他のモジュールに対して不正に動作します。この問題の直接的な原因は、Internet Explorer が WindowsDesktopSSO モジュールでエラーになると、ブラウザを再起動するまで、コールバックを要求されても、別のモジュールのコールバックを Access Manager に渡すことができなくなることです。このため、WindowsDesktopSSO のあとのすべてのモジュールは、ユーザー資格が NULL であるためにエラーとなります。

関連情報については、次の資料を参照してください。

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

Windows デスクトップ SSO の設定

Windows デスクトップ SSO 認証を有効にするプロセスには、次の 2 つの段階があります。

Windows 2000 のドメインコントローラにユーザーを作成します。
Internet Explorer をセットアップします。

Windows 2000 のドメインコントローラにユーザーを作成する

手順

ドメインコントローラで、Access Manager 認証モジュール用のユーザーアカウントを作成します。
1. 「スタート」メニューから、「プログラム」>「管理ツール」に進みます。
2. 「Active Directory ユーザーとコンピュータ」を選択します。
3. Access Manager ホスト名をユーザー ID (ログイン名) として新しいユーザーを作成します。Access Manager ホスト名には、ドメイン名を含めないでください。

ユーザーアカウントをサービスプロバイダの名前と関連付け、Keytab ファイルを Access Manager がインストールされたシステムにエクスポートします。そのためには、次のコマンドを実行します。

ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out 
hostname.host.keytab
ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass 
password -mapuser userName-out hostname
.HTTP.keytab

ktpass コマンドには、次のパラメータを使用できます。

hostname: Access Manager が稼働する、ドメイン名なしのホスト名です。

domainname: Access Manager のドメイン名です。

DCDOMAIN: ドメインコントローラのドメイン名です。この名前は、Access Manager のドメイン名とは異なる場合があります。

password: ユーザーアカウントのパスワードです。ktpass はパスワードを検証しないので、パスワードが正しいことを確認してください。

userName: ユーザーアカウント ID です。これはホスト名と同じにする必要があります。

注 –

両方の Keytab ファイルがセキュリティー保護されているようにします。

サービステンプレートの値は、次の例のようになっている必要があります。

「サービス主体」: HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

「Keytab ファイル名」: /tmp/machine1.HTTP.keytab

「Kerberos レルム」: ISQA.EXAMPLE.COM

「Kerberos サーバー名」: machine2.EXAMPLE.com

「ドメイン名を含む主体を返す」: false

「認証レベル」: 22

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

Internet Explorer をセットアップする

この手順は、Microsoft Internet Explorer™ 6 以上に当てはまります。これよりも前のバージョンを使用している場合は、Access Manager がブラウザのインターネットゾーンにあり、ネイティブ Windows 認証が有効であることを確認します。

手順

「ツール」メニューで、「インターネットオプション」>「詳細設定」>「セキュリティー」に進みます。

「統合 Windows 認証を使用する」オプションを選択します。

「セキュリティー」>「イントラネット」に進みます。
1. 「レベルのカスタマイズ」を選択します。「ユーザー認証」の「ログオン」で「イントラネットゾーンでのみ自動的にログオンする」オプションを選択します。
2. 「サイト」に進み、すべてのオプションを選択します。
3. 「詳細設定」をクリックして、Access Manager をローカルゾーンに追加します (まだ追加されていない場合)。

Windows NT

Access Manager は、すでにインストールされている Windows NT サーバーまたは Windows 2000 サーバーで使用できるように設定できます。Access Manager は、NT 認証のクライアント部分を担当します。

NT サーバーを設定します。詳しい手順については、Windows NT サーバーのマニュアルを参照してください。
Windows NT 認証モジュールを追加し、有効にする前に、Samba クライアントを入手してインストールし、Solaris システム上の Access Manager と通信できるようにする必要があります。

Samba クライアントのインストール

Windows NT 認証モジュールをアクティブにするには、Samba Client 2.2.2 をダウンロードして次のディレクトリにインストールする必要があります。

AccessManager-base/SUNWam/bin

Samba Client は、Windows マシンと UNIX マシンを共存させるためのファイルサーバー兼プリントサーバーで、専用の Windows NT/2000 Server を必要としません。詳細とダウンロードについては、http://wwws.sun.com/software/download/products/3e3af224.html を参照してください。

Red Hat Linux とともに出荷される Samba クライアントは、次のディレクトリに置かれています。

/usr/bin

Linux 用 Windows NT 認証モジュールを使って認証を行うためには、クライアントのバイナリを Access Manager の次のディレクトリにコピーします。

AccessManager-base/sun/identity/bin

注 –

複数のインタフェースがある場合には、追加の設定が必要です。複数のインタフェースは smb.conf ファイルで設定し、それを mbclient へ伝えることにより、設定できます。

認証モジュールインスタンス

デフォルトの認証モジュールに基づいて、複数の認証モジュールインスタンスをレルム用に作成できます。同じ認証モジュールを元に、個別に設定した複数のインスタンスを追加できます。

新しい認証モジュールインスタンスを作成する

手順

新しい認証モジュールインスタンスを追加するレルムの名前をクリックします。

「認証」タブを選択します。

注 –
「管理者認証設定」ボタンにより、管理者専用に認証サービスを定義できます。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。この属性で設定したモジュールは、Access Manager コンソールにアクセスするときに選択されます。

「モジュールインスタンス」リストの「新規」をクリックします。

認証モジュールインスタンスの名前を入力します。名前は一意にする必要があります。

レルムの認証モジュールタイプの「タイプ」を選択します。

「作成」をクリックします。

新しく作成したモジュールインスタンスの名前をクリックし、そのモジュールのプロパティーを編集します。各モジュールタイプのプロパティーの定義については、オンラインヘルプの「認証」の節を参照してください。

複数のモジュールインスタンスを追加するときは、これらの手順を繰り返します。

認証連鎖

1 つ以上の認証モジュールが設定できるので、ユーザーは認証資格をすべての認証モジュールに渡す必要があります。これは、認証連鎖と呼ばれます。Access Manager での認証連鎖は、認証サービスに統合された JAAS フレームワークを使用して実現されます。モジュール連鎖は、認証設定サービスの下に設定されます。

新しい認証連鎖を作成する

手順

新しい認証連鎖を追加するレルムの名前をクリックします。

「認証」タブを選択します。

「認証連鎖」リストの「新規」をクリックします。

認証連鎖の名前を入力します。

「作成」をクリックします。

「追加」をクリックし、連鎖に含める認証モジュールインスタンスを定義します。そのためには、「インスタンス」リストからモジュールインスタンス名を選択します。このリストに表示されるモジュールインスタンス名は、「モジュールインスタンス」属性で作成されます。

連鎖の条件を選択します。以上のフラグによって、認証モジュールの適用条件が確立されます。適用には階層があります。「必須」がもっとも高く、「オプション」がもっとも低くなります。

必要

認証にはモジュールインスタンスが必要です。認証に成功すると、「認証連鎖」リストの次のインスタンスへと認証が進行します。認証に失敗すると、制御がただちにアプリケーションに返されます。この場合、「認証連鎖」リストの次のインスタンスには認証が進行しません。

必須

認証には、このモジュールへの認証が必要です。この連鎖の必須モジュールのいずれかが失敗すると、最終的に認証連鎖全体が失敗します。ただし、必須モジュールが成功しても失敗しても、連鎖の次のモジュールへと制御が進行します。

十分

認証にモジュールインスタンスは必要ありません。認証に成功するとすぐに、制御がアプリケーションに返されます。この場合、モジュールインスタンスリストの次のインスタンスには認証が進行しません。認証に失敗すると、「認証連鎖」リストの次のインスタンスへと認証が進行します。

オプション

認証にモジュールインスタンスは必要ありません。認証に成功しても失敗しても、「認証連鎖」リストの次のインスタンスへと認証が進行します。

連鎖のオプションを入力します。これにより、モジュールの追加オプションがキーと値のペアとして有効になります。複数のオプションを指定するときは、スペースで区切ります。

次の属性を定義します。

「成功したログイン URL」

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

「失敗したログイン URL」

認証が成功しなかった場合にユーザーをリダイレクトする URL を指定します。

「認証ポストプロセスクラス」

ログインが成功または失敗したあとに認証ポストプロセスのカスタマイズに使用する Java クラスの名前を定義します。

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

認証タイプ

認証サービスは、さまざまな認証適用方法を提供します。それらの異なる認証方法にアクセスするには、ログイン URL パラメータを指定するか、認証 API を使用します。詳細については、『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』の第 5 章「Using Authentication APIs and SPIs」を参照してください。認証モジュールを設定する前に、特定の認証モジュール名を含むように、コア認証サービス属性のレルム認証モジュールを修正する必要があります。

認証設定サービスは、次の認証タイプ用の認証モジュールを定義するために使用します。

認証モジュールは、これらの認証タイプのいずれかで定義すると、認証プロセスの成功または失敗に基づいて、ポストプロセス Java クラス仕様だけでなく、リダイレクト URL も提供するように設定できます。

認証タイプによってアクセスが決定される方法

各認証方法では、ユーザーは認証に成功するか失敗します。成功または失敗の決定後、各方法では次の手順を実行します。手順 1 〜 3 は認証が成功した場合に実行され、手順 4 は成功した認証と失敗した認証の両方で実行されます。

Access Manager によって、認証されたユーザーが Directory Server データストアに定義されているかどうか、またプロファイルが有効であるかどうかが確認されます。

コア認証モジュールの「ユーザープロファイル」属性は、「必須」、「動的」、「ユーザーエイリアスを使用して動的に」、または「無視」として定義できます。認証に成功すると、Access Manager によって、認証されたユーザーが Directory Server データストアに定義されているかどうかが確認され、「ユーザープロファイル」の値が「必須」である場合は、プロファイルが有効かどうかが確認されます。これはデフォルトの場合です。「ユーザープロファイル」が動的な設定である場合、認証サービスはユーザープロファイルを Directory Server のデータストアに作成します。「ユーザープロファイル」が「無視」に設定されている場合は、ユーザーの検証は行われません。
認証ポストプロセス SPI が実行されます。

コア認証モジュールには、値として認証ポストプロセスクラス名を含む「認証ポストプロセスクラス」属性が含まれています。AMPostAuthProcessInterface は、ポストプロセスインタフェースです。このインタフェースは、認証の成功または失敗時、またはログアウト時に実行できます。
セッショントークンで次のプロパティーが追加または更新され、ユーザーのセッションがアクティブになります。

realm: これは、ユーザーが所属するレルムの DN です。

Principal: ユーザーの DN です。

Principals: ユーザーが認証を受けた名前のリストです。このプロパティーは、パイプで区切られたリストとして定義された複数の値を持つことができます。

UserId: モジュールが返すユーザーの DN であるか、LDAP またはメンバーシップ以外のモジュールの場合はユーザー名です。すべての Principal は、同じユーザーにマッピングされる必要があります。UserId は、すべての Principal がマッピングされるユーザー DN です。

注 –
このプロパティーは、DN 以外の値になることがあります。

UserToken: ユーザー名です。すべての Principal は、同じユーザーにマッピングされる必要があります。UserToken は、すべての Principal がマッピングされるユーザー名です。

Host: クライアント用のホスト名または IP アドレスです。

authLevel: ユーザーが認証を受けた最高のレベルです。

AuthType: ユーザーが認証を受けた認証モジュールの、パイプで区切られたリストです (例、module1|module2|module3)。

clientType: クライアントブラウザのデバイスタイプです。

Locale: クライアントのロケールです。

CharSet: クライアント用に定めらた文字セットです。

Role: ロールに基づく認証にのみ適用可能であり、ユーザーが属すロールです。

Service: サービスに基づく認証にのみ適用可能であり、ユーザーが属すサービスです。
Access Manager は、成功または失敗した認証のあとにユーザーをリダイレクトする場所についての情報を検索します。

URL のリダイレクトは、Access Manager のページまたは URL のどちらかにすることができます。リダイレクトは、Access Manager が認証方法に基づいて、また認証が成功したか失敗したかによってリダイレクトを検索する優先順位のもとに行われます。この順序については、次の認証方法についての節の、URL のリダイレクトの部分で詳しく説明します。

URL のリダイレクト

認証設定サービスでは、成功または失敗した認証に対する URL のリダイレクトを割り当てることができます。その URL 自体は、認証設定サービスの「ログイン成功 URL」および「ログイン失敗 URL」属性で定義します。URL のリダイレクトを有効にするために、ロール、レルム、またはユーザー用に設定するように、認証設定サービスをレルムに追加し、利用可能にする必要があります。認証設定サービスの追加時は、LDAP で必須、というように認証モジュールを追加するようにしてください。

レルムに基づく認証

この認証方式により、ユーザーはレルムまたはサブレルムの認証を受けることができます。これは、Access Manager のデフォルトの認証方法です。レルムの認証方法は、コア認証モジュールをレルムに登録し、「レルム認証設定」属性を定義することによって設定します。

レルムに基づく認証ログイン URL

認証のレルムは、ユーザーインタフェースのログイン URL に realm パラメータまたは domain パラメータを定義して指定できます。認証の要求のレルムは、次の優先順位で判断されます。

domain パラメータ。
realm パラメータ。

管理サービスの「DNS エイリアス名」属性の値。

正しいレルムを呼び出したあと、ユーザーが認証を受ける認証モジュールは、コア認証サービスの「レルム認証設定」属性から取得されます。レルムに基づく認証を指定し、開始するログイン URL を次に示します。

http://server_name.domain_name:port/amserver/UI/Login
http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name
http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name

定義されたパラメータがない場合、レルムはログイン URL に指定されたサーバーホストとドメインから判断されます。

レルムに基づく認証リダイレクト URL

組織に基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

レルムに基づく認証が成功した場合のリダイレクト URL

レルムに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

レルムに基づく認証に失敗した場合のリダイレクト URL

レルムに基づく認証に失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
gotoOnFail ログイン URL パラメータで設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

レルムに基づく認証を設定する

認証モジュールは、最初にコア認証サービスをレルムに追加することで、レルム用に設定できます。

レルムの認証属性を設定する

手順

認証連鎖を追加するレルムに移動します。

「認証」タブをクリックします。

プルダウンメニューから「デフォルト認証連鎖」を選択します。

プルダウンメニューから「管理者認証連鎖」を選択します。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。デフォルトの認証モジュールは LDAP です。

認証連鎖を定義したら、「保存」をクリックします。

組織に基づく認証

この認証タイプは、旧バージョンモードでインストールされた Access Manager の配備先にのみ適用されます。

この認証方法では、ユーザーが組織またはサブ組織に対する認証を受けることができます。これは、Access Manager のデフォルトの認証方法です。組織の認証方法は、コア認証モジュールを組織に登録し、「組織認証設定」属性を定義することによって設定します。

組織に基づく認証のログイン URL

認証のための組織は、ユーザーインタフェースのログイン URL に org パラメータまたは domain パラメータを定義して指定できます。認証の要求の組織は、次の優先順位で判断されます。

domain パラメータ。
org パラメータ。
管理サービスの「DNS エイリアス名」 (組織のエイリアス名) 属性の値。

正しい組織を呼び出したあと、ユーザーが認証を受ける認証モジュールは、コア認証サービスの「組織認証設定」属性から取得されます。組織に基づく認証を指定し、開始するログイン URL を次に示します。
http://server_name.domain_name:port/amserver/UI/Login http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name http://server_name.domain_name:port/amserver/UI/Login?org=org_name
定義されたパラメータがない場合、組織はログイン URL に指定されたサーバーホストとドメインから判断されます。

組織に基づく認証のリダイレクト URL

組織に基づく認証が成功した場合のリダイレクト URL

組織に基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

組織に基づく認証に失敗した場合のリダイレクト URL

組織に基づく認証に失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
gotoOnFail ログイン URL パラメータで設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

組織に基づく認証を設定する

認証モジュールは、最初にコア認証サービスを組織に追加することで、組織用に設定できます。

組織の認証属性を設定する

手順

認証連鎖を追加する組織に移動します。

「認証」タブをクリックします。

プルダウンメニューから「デフォルト認証連鎖」を選択します。

プルダウンメニューから「管理者認証連鎖」を選択します。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。デフォルトの認証モジュールは LDAP です。

認証連鎖を定義したら、「保存」をクリックします。

ロールに基づく認証

この認証方法では、ユーザーはレルムまたはサブレルム内の (静的またはフィルタリングされた) ロールに対する認証を受けることができます。

注 –

認証設定サービスは、レルムに登録してからでなければロールにインスタンスとして登録できません。

認証を成功させるには、ユーザーはロールに属し、そのロールに設定された認証設定サービスインスタンスに定義された各モジュールに対する認証を受ける必要があります。ロールに基づく認証の各インスタンスに対して、次の属性を指定できます。

「競合の解決レベル」: 同一のユーザーが含まれることがある 2 つの異なるロールに定義された認証設定サービスインスタンスに対する優先レベルを設定します。たとえば、User 1 が Role 1 および Role 2 に割り当てられている場合を想定します。ユーザーが認証を試みたときに、認証の成功または失敗時のリダイレクトや認証後プロセスに対して Role 1 の優先順位がより高くなるように、Role1 により高い競合解決レベルを設定することができます。

「認証設定」: ロールの認証プロセスに設定された認証モジュールを定義します。

「ログイン成功 URL」: 認証が成功した場合にユーザーがリダイレクトされる URL を定義します。

「ログイン失敗 URL」: 認証が失敗した場合にユーザーがリダイレクトされる URL を定義します。

「認証ポストプロセスクラス」: 認証後インタフェースを定義します。

ロールに基づく認証のログイン URL

ロールに基づく認証は、ユーザーインタフェースのログイン URL にロールパラメータを定義して指定できます。正しいロールを呼び出したあと、ユーザーが認証を受ける認証モジュールは、そのロールに定義された認証設定サービスインスタンスから取得されます。

このロールに基づく認証を指定し開始するログイン URL を次に示します。

http://server_name.domain_name:port/amserver/UI/Login?role=role_name
http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&role=role_name

realm パラメータが設定されていない場合、ロールが属すレルムはログイン URL そのものに指定されたサーバーホストおよびドメインから判断されます。

ロールに基づく認証のリダイレクト URL

ロールに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

ロールに基づく認証が成功した場合のリダイレクト URL

ロールに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーが認証を受けたロールの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
認証されたユーザーの別のロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。このオプションは、前のリダイレクト URL が失敗した場合の代替リダイレクト URL です。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーが認証を受けたロールの iplanet-am-auth-login-success-url 属性に設定された URL。
認証されたユーザーの別のロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。このオプションは、前のリダイレクト URL が失敗した場合の代替リダイレクト URL です。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

ロールに基づく認証が失敗した場合のリダイレクト URL

ロールに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーが認証を受けたロールの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
認証されたユーザーの別のロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。このオプションは、前のリダイレクト URL が失敗した場合の代替リダイレクト URL です。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
ユーザーが認証を受けたロールの iplanet-am-auth-login-failure-url 属性に設定された URL。
認証されたユーザーの別のロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。このオプションは、前のリダイレクト URL が失敗した場合の代替リダイレクト URL です。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

ロールに基づく認証を設定する

手順

認証設定サービスを追加するレルム (または組織) に移動します。

「対象」タブをクリックします。

「フィルタロール」または「ロール」です。

認証設定を設定するロールを選択します。

認証設定サービスがロールに追加されていない場合は、「追加」をクリックし、「認証サービス」を選択して「次へ」をクリックします。

プルダウンメニューから、有効にする「デフォルト認証連鎖」を選択します。

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

注 –
新しいロールを作成している場合、そのロールに認証設定サービスは自動的に割り当てられません。ロールを作成する前に、ロールプロファイルページの上部で認証設定サービスを選択していることを確認してください。

ロールに基づく認証が有効になっているときは、LDAP 認証モジュールはデフォルトのままにでき、メンバーシップを設定する必要はありません。

サービスに基づく認証

この認証方法では、ユーザーはレルムまたはサブレルムに登録された特定のサービスまたはアプリケーションに対する認証を受けることができます。このサービスは、認証設定サービス内でサービスインスタンスとして設定され、インスタンス名が関連付けられます。認証を成功させるには、ユーザーはサービスに設定された認証設定サービスインスタンスに定義された各モジュールに対して認証を受ける必要があります。サービスに基づく認証の各インスタンスに対して、次の属性を指定できます。

「認証設定」: サービスの認証プロセスに設定された認証モジュールを定義します。

「ログイン成功 URL」: 認証が成功した場合にユーザーがリダイレクトされる URL を定義します。

「ログイン失敗 URL」: 認証が失敗した場合にユーザーがリダイレクトされる URL を定義します。

「認証ポストプロセスクラス」: 認証後インタフェースを定義します。

サービスに基づく認証のログイン URL

サービスに基づく認証は、ユーザーインタフェースのログイン URL にサービスパラメータを定義して指定できます。サービスを呼び出したあと、ユーザーが認証を受ける認証モジュールは、そのサービスに定義された認証設定サービスインスタンスから取得されます。

このサービスに基づく認証を指定し開始するログイン URL を次に示します。

http://server_name.domain_name:port/amserver/UI/
Login?service=auth-chain-name

および

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name
e

org パラメータが設定されていない場合、レルムはログイン URL そのものに指定されたサーバーホストとドメインから判断されます。

サービスに基づく認証のリダイレクト URL

サービスに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

サービスに基づく認証が成功した場合のリダイレクト URL

サービスに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーが認証を受けたサービスの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーが認証を受けたサービスの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

サービスに基づく認証が失敗した場合のリダイレクト URL

サービスに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーが認証を受けたサービスの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
ユーザーが認証を受けたサービスの iplanet-am-auth-login-failure-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

サービスに基づく認証を設定する

認証モジュールは、認証設定サービスを追加すると、サービス用に設定されます。そのためには、次の手順を実行します。

手順

サービスに基づく認証を設定するレルムを選択します。

「認証」タブをクリックします。

認証モジュールインスタンスを作成します。

認証連鎖を作成します。

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

レルムのサービスに基づく認証にアクセスするには、次のアドレスを入力します。

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name

ユーザーに基づく認証

この認証方法では、ユーザーはユーザー専用に設定された認証プロセスに対する認証を受けることができます。このプロセスは、ユーザーのプロファイルの「ユーザー認証設定」属性の値として設定されます。認証を成功させるには、ユーザーは定義された各モジュールに対して認証する必要があります。

ユーザーに基づく認証のログイン URL

ユーザーに基づく認証は、ユーザーインタフェースのログイン URL にユーザーパラメータを定義して指定できます。正しいユーザーを呼び出したあと、ユーザーが認証を受ける認証モジュールは、そのユーザーに定義されたユーザー認証インスタンスから取得されます。

このロールに基づく認証を指定し開始するログイン URL を次に示します。

http://server_name.domain_name:port/amserver/UI/Login?user=user_name
http://server_name.domain_name:port/amserver/UI/Login?org=org_name&user=user_name

ユーザーエイリアスリスト属性

ユーザーに基づく認証の要求を受け取ると、認証サービスはまずユーザーが有効なユーザーであることを確認してから、ユーザーの認証設定データを取得します。ユーザーログイン URL パラメータの値に複数の有効なユーザープロファイルが関連付けられている場合は、すべてのプロファイルを指定されたユーザーにマップする必要があります。ユーザープロファイルのユーザーエイリアス属性 (iplanet-am-user-alias-list) には、ユーザーに属すその他のプロファイルを定義できます。マッピングが失敗すると、ユーザーは有効なセッションを拒否されます。ユーザーの 1 人がユーザーのマッピングの検証が行われない最上位の管理者であり、そのユーザーに最上位の管理者権限が与えられている場合は、例外です。

ユーザーに基づく認証のリダイレクト URL

ユーザーに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

ユーザーに基づく認証が成功した場合のリダイレクト URL

ユーザーに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

ユーザーに基づく認証に失敗した場合のリダイレクト URL

ユーザーに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
gotoOnFail ログイン URL パラメータで設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

ユーザーに基づく認証を設定する

手順

ユーザーの認証を設定するレルムに移動します。

「対象」タブをクリックし、「ユーザー」をクリックします。

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

ユーザープロファイルが表示されます。

注 –
新しいユーザーを作成している場合、そのユーザーに認証設定サービスは自動的に割り当てられません。ユーザーを作成する前に、サービスプロファイルで認証設定サービスを選択していることを確認してください。このオプションを選択しないと、ユーザーはロールに定義された認証設定を継承しません。

「ユーザー認証設定」属性で、適用する認証連鎖を選択します。

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

認証レベルに基づく認証

それぞれの認証モジュールは、その認証レベルに整数値が関連付けられています。認証レベルを割り当てるには、「サービス設定」で認証モジュールの「プロパティー」矢印をクリックし、モジュールの「認証レベル」属性で対応する値を変更します。認証レベルが高いということは、1 つ以上の認証モジュールで認証を受けたそのユーザーの信頼性のレベルが高いということです。

ユーザーがそのモジュールに対する認証に成功すると、認証レベルがユーザーの SSO トークンに設定されます。複数の認証モジュールに対して認証を受ける必要があり、認証に成功した場合は、最高の認証レベルの値がユーザーの SSO トークンに設定されます。

ユーザーがサービスへのアクセスを試みる場合、サービスでは、そのユーザーの SSO トークンの認証レベルを確認することで、そのユーザーがアクセスを許可されているかどうかを判別できます。次に、設定された認証レベルで認証モジュールにパスするように、ユーザーをリダイレクトします。

ユーザーは特定の認証レベルで認証モジュールにアクセスすることもできます。たとえばユーザーが次の構文でログインします。

http://hostname:port/deploy_URI/UI/Login?authlevel=
auth_level_value

認証レベルが auth_level_value 以上であるすべてのモジュールが、ユーザーが選択するための認証メニューとして表示されます。一致するモジュールが 1 つしかなかった場合は、その認証モジュールのログインページが直接表示されます。

この認証の方法では、ID が認証を受けられるモジュールのセキュリティーレベルを、管理者が指定できます。各認証モジュールには、それぞれの「認証レベル」属性があり、この属性の値は任意の有効な整数として定義できます。認証レベルに基づく認証では、認証サービスは、ログイン URL パラメータに指定された値以上の認証レベルを持つ認証モジュールを含むメニューを持つモジュールログインページを表示します。ユーザーは、提示されたリストからモジュールを選択します。ユーザーがモジュールを選択すると、以降のプロセスはモジュールに基づく認証に基づきます。

認証レベルに基づく認証のログイン URL

認証レベルに基づく認証は、ユーザーインタフェースのログイン URL に authlevel パラメータを定義して指定できます。関連するモジュールのリストを示すログイン画面を呼び出したあと、ユーザーは認証を受けるモジュールを選択する必要があります。認証レベルに基づく認証を指定し開始するログイン URL を次に示します。

http://server_name.domain_name:port/amserver/UI/Login?authlevel=authentication_level

および

http://server_name.domain_name:port/amserver/UI/
Login?realm=realm_name&authlevel=authentication_level

realm パラメータが設定されていない場合、ユーザーが属すレルムはログイン URL そのものに指定されたサーバーホストおよびドメインから判断されます。

認証レベルに基づく認証のリダイレクト URL

認証レベルに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

認証レベルに基づく認証が成功した場合のリダイレクト URL

認証レベルに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

認証レベルに基づく認証が失敗した場合のリダイレクト URL

認証レベルに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
gotoOnFail ログイン URL パラメータで設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

モジュールに基づく認証

ユーザーは次の構文を使用して、特定の認証モジュールにアクセスできます。

http://hostname:port/deploy_URI/UI/Login?module=
module_name

認証モジュールにアクセスする前に、その認証モジュール名を含むように、コア認証サービス属性のレルム認証モジュールを修正する必要があります。認証モジュール名がこの属性に含まれていない場合、ユーザーが認証を試みると「認証モジュールが拒否されました」ページが表示されます。

この認証の方法では、ユーザーは認証を受けるモジュールを指定できます。指定するモジュールは、ユーザーがアクセスするレルムまたはサブレルムに登録する必要があります。これは、レルムのコア認証サービスの「レルム認証モジュール」属性に設定されます。モジュールに基づく認証の要求を受け取ると、認証サービスは、モジュールが指定されたように正しく設定されていることを確認し、モジュールが定義されていない場合は、ユーザーはアクセスを拒否されます。

モジュールに基づく認証のログイン URL

モジュールパラメータを定義して、ユーザーインタフェースのログイン URL にモジュールに基づく認証を指定できます。モジュールに基づく認証を指定し開始するログイン URL を次に示します。

http://server_name.domain_name:port/amserver/UI/Login?module=authentication_module_name
http://server_name.domain_name:port/amserver/UI/
Login?org=org_name&module=authentication_module_name

org パラメータが設定されていない場合、ユーザーが属すレルムはログイン URL そのものに指定されたサーバーホストおよびドメインから判断されます。

モジュールに基づく認証のリダイレクト URL

モジュールに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

モジュールに基づく認証が成功した場合のリダイレクト URL

モジュールに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

モジュールに基づく認証に失敗した場合のリダイレクト URL

モジュールに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

認証モジュールで設定された URL。
gotoOnFail ログイン URL パラメータで設定された URL。
ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

ユーザーインタフェースのログイン URL

認証サービスユーザーインタフェースには、Web ブラウザの場所ツールバーにログイン URL を入力してアクセスします。この URL は次のとおりです。

http://AccessManager-root/.domain_name:port /service_deploy_uri /UI/Login

注 –

インストールの間に、service_deploy_uri は amserver として設定されます。このマニュアル全体にわたり、このデフォルトのサービス配備 URI が使用されています。

特定の認証方法や、成功、失敗した認証のリダイレクト URL を定義するために、ユーザーインタフェースのログイン URL にログイン URL パラメータを付加することもできます。

ログイン URL パラメータ

URL パラメータは、URL の終わりに付加される名前と値のペアです。このパラメータは疑問符 (?) で始まり、名前=値の形式をとります。たとえば、次のようにいくつかのパラメータを 1 つのログイン URL に結合できます。

http://server_name.domain_name:port/amserver/UI/
Login?module=LDAP&locale=ja&goto=http://www.sun.com

複数のパラメータを指定する場合は、アンパサンド (&) で区切ります。複数のパラメータを指定する場合は、次のガイドラインに従う必要があります。

各パラメータは、1 つの URL に 1 回のみ指定できます。たとえば、module=LDAP&module=NT は受け入れられません。
org パラメータと domain パラメータは両方ともログインレルムを決定します。この場合、ログイン URL にはこの 2 つのパラメータどちらかを使用する必要があります。両方を使用する場合に優先順位を指定しないと、1 つのみが有効になります。
user、role、service、module、および authlevel は、それぞれの基準に基づいて認証モジュールを定義するためのパラメータです。このため、ログイン URL にはこれらのパラメータのいずれか 1 つのみを使用する必要があります。複数のパラメータを使用する場合に優先順位を指定しないと、1 つのみが有効になります。

次の節では、ユーザーインタフェースのログイン URL に付加され、Web ブラウザの場所ツールバーに入力されたときに、さまざまな認証機能を実現するパラメータについて説明します。

注 –

レルム全体に配布する認証 URL およびパラメータを単純なものにするには、管理者は単純な URL を持つ HTML ページを作成し、そのページにすべての設定された認証方法に対するより複雑なログイン URL へのリンクを含めることができます。

goto パラメータ

goto=successful_authentication_URL パラメータは、認証設定サービスの「ログイン成功 URL」に定義された値を置き換えます。このパラメータは、認証が成功すると指定された URL にリンクします。goto= logout_URL パラメータも、ユーザーのログアウト時に指定された URL にリンクするのに使用できます。次に認証成功 URL の例を示します。

http://server_name.domain_name:port/amserver/
UI/Login?goto=http://www.sun.com/homepage.html

次に goto ログアウト URL の例を示します。

http://server_name.domain_name:port/amserver/
UI/Logout?goto=http://www.sun.com/logout.html.

注 –

Access Manager が認証成功リダイレクト URL を確認する優先順位が定められています。リダイレクト URL とそれらの順番は認証方法に基づいているので、この順番および関連情報については、「認証タイプ」の節で詳しく説明します。

gotoOnFail パラメータ

gotoOnFail=failed_authentication_URL パラメータは、認証設定サービスの「ログイン失敗 URL」に定義された値を置き換えます。ユーザーが認証に失敗すると、指定された URL にリンクします。次に gotoOnFail URL の例を示します。http:// server_name.domain_name:port /amserver/UI/Login?gotoOnFail=http://www.sun.com/auth_fail.html

注 –

Access Manager が認証失敗リダイレクト URL を確認する優先順位が定められています。リダイレクト URL とそれらの順番は認証方法に基づいているので、この順番および関連情報については、「認証タイプ」の節で詳しく説明します。

realm パラメータ

org=realmName パラメータを使用すると、指定されたレルムのユーザーとしてユーザーを認証することができます。

注 –

指定されたレルムのメンバーになっていないユーザーが、realm パラメータで認証を試みると、エラーメッセージを受け取ります。ただし、次の条件をすべて満たせば、Directory Server に動的にユーザープロファイルを作成できます。

コア認証サービスの「ユーザープロファイル」属性に、「動的」または「ユーザーエイリアスを使用して動的に」が設定されている。
ユーザーが、必要なモジュールに対する認証に成功している。
ユーザーのプロファイルは、まだ Directory Server にない。

このパラメータから、レルムおよびそのロケールの設定に基づいて、正しいログインページが表示されます。このパラメータが設定されない場合は、デフォルトは最上位のレルムになります。たとえば、org URL は次のようになります。

http://server_name.domain_name:port/amserver/UI/Login?realm=sun

org パラメータ

org=orgName パラメータを使用すると、指定された組織のユーザーとしてユーザーを認証することができます。

注 –

指定された組織のメンバーになっていないユーザーが、org パラメータで認証を試みると、エラーメッセージを受け取ります。ただし、次の条件をすべて満たせば、Directory Server に動的にユーザープロファイルを作成できます。

コア認証サービスの「ユーザープロファイル」属性に、「動的」または「ユーザーエイリアスを使用して動的に」が設定されている。
ユーザーが、必要なモジュールに対する認証に成功している。
ユーザーのプロファイルは、まだ Directory Server にない。

このパラメータから、組織およびそのロケールの設定に基づいて、正しいログインページが表示されます。このパラメータが設定されない場合は、デフォルトは最上位の組織になります。たとえば、org URL は次のようになります。

http://server_name.domain_name:port/amserver/UI/Login?org=sun

user パラメータ

user=userName パラメータは、ユーザーのプロファイルの「ユーザー認証設定」属性に設定されたモジュールに基づいて、認証を強制します。たとえば、あるユーザーのプロファイルを証明書モジュールを使用して認証するよう設定できる一方で、別のユーザーを LDAP モジュールを使用して認証するように設定できます。このパラメータを追加すると、ユーザーはユーザーの組織に設定された認証方法ではなく、ユーザー用に設定された認証プロセスに送られます。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?user=jsmith

role パラメータ

role=roleName パラメータは、ユーザーを指定されたロール用に設定された認証プロセスに送ります。指定されたロールのメンバーになっていないユーザーが、このパラメータで認証を試みると、エラーメッセージを受け取ります。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?role=manager

locale パラメータ

Access Manager は、認証プロセスとコンソール自身について、ローカライズされた (英語以外の言語に翻訳された) 画面を表示することができます。locale=localeName パラメータは、指定されたロケールをその他の定義されたロケールよりも優先させることができます。ログインのロケールは、次の順序で次の場所から設定を検索したあとに、クライアントに表示されます。

ログイン URL のロケールパラメータの値

locale=localeName パラメータの値は、定義されたその他のすべてのロケールよりも優先されます。
ユーザーのプロファイルに定義されたロケール

URL パラメータがない場合は、ロケールはユーザープロファイルの「ユーザー設定言語」属性に設定された値に基づいて表示されます。
HTTP ヘッダーに定義されたロケール

このロケールは、Web ブラウザによって設定されます。
コア認証サービスに定義されたロケール

これは、コア認証モジュールの「デフォルト認証ロケール」属性の値です。
プラットフォームサービスに定義されたロケール

これは、プラットフォームサービスの「プラットフォームロケール」属性の値です。

オペレーティングシステムのロケール

この優先順位から導き出されるロケールは、ユーザーのセッショントークンに格納され、Access Manager が、ローカライズされた認証モジュールのロードだけに使用します。認証に成功すると、ユーザーのプロファイルの「ユーザー設定言語」属性に定義されたロケールが使用されます。ロケールが設定されていない場合は、認証に使用されたロケールが引き続き使用されます。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?locale=ja

注 –

画面のテキストおよびエラーメッセージのローカライズの方法については、Access Manager を参照してください。

module パラメータ

module=moduleName パラメータを使用すると、指定した認証モジュールによって認証を行うことができます。どのモジュールでも指定できますが、まずユーザーが所属するレルムに登録し、コア認証モジュールでそのレルムの認証モジュールの 1 つとして選択する必要があります。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?module=Unix

注 –

認証モジュール名は、URL パラメータで使用する場合には大文字と小文字が区別されます。

service パラメータ

service=serviceName パラメータを使用すると、サービスの設定された認証スキームによってユーザーを認証できます。認証設定サービスを使用して、異なるサービスに異なる認証スキームを設定できます。たとえば、オンラインの給料支払いアプリケーションにはより安全な証明書認証モジュールを使用した認証が必要になり、レルムの社員のディレクトリアプリケーションには LDAP 認証モジュールのみが必要になるなどです。認証スキームを、それらの各サービスに設定および指定できます。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?service=sv1

注 –

認証設定サービスを使用して、サービスに基づく認証のスキームを定義します。

arg パラメータ

arg=newsession パラメータを使用して、ユーザーの現在のセッションを終了し、新しいセッションを開始します。認証サービスは、1 回の要求でユーザーの既存のセッショントークンを破棄し、新しいログインを実行します。このオプションは通常、匿名の認証モジュールで使用されます。ユーザーは、まず匿名セッションで認証を受けてから、登録リンクまたはログインリンクをヒットします。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?arg=newsession

authlevel パラメータ

authlevel=value パラメータは、指定された認証レベル値以上の認証レベルのモジュールを呼び出すように認証サービスに指示します。各認証モジュールは、固定整数の認証レベルで定義されます。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?authlevel=1

注 –

認証レベルは、各モジュールの特定のプロファイルに設定されます。

domain パラメータ

このパラメータを使用すると、指定されたドメインとして識別されるレルムにユーザーがログインできます。指定するドメインは、レルムのプロファイルの「ドメイン名」属性に定義された値に一致する必要があります。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?domain=sun.com

注 –

指定されたドメイン、つまりレルムのメンバーになっていないユーザーが、org パラメータで認証を試みると、エラーメッセージを受け取ります。ただし、次の条件をすべて満たせば、Directory Server に動的にユーザープロファイルを作成できます。

コア認証サービスの「ユーザープロファイル」属性に、「動的」または「ユーザーエイリアスを使用して動的に」が設定されている。
ユーザーが、必要なモジュールに対する認証に成功している。
ユーザーのプロファイルは、まだ Directory Server にない。

iPSPCookie パラメータ

iPSPCookie=yes パラメータを使用すると、ユーザーは持続 Cookie でログインできます。持続 Cookie とは、ブラウザウィンドウが閉じられたあとも存在し続ける Cookie のことです。このパラメータを使用するには、ユーザーがログインするレルムのコア認証モジュールで「持続 Cookie」が有効になっている必要があります。ユーザーが認証されブラウザを閉じると、ユーザーは新しいブラウザセッションでログインすることが可能であり、再認証する必要なくコンソールにダイレクトされます。これは、コアサービスに指定された「Cookie の最大持続時間」属性の値まで有効です。次に例を示します。

http://server_name.domain_name:port/amserver/UI/Login?org=example&iPSPCookie=yes

IDTokenN パラメータ

このパラメータオプションを使用すると、ユーザーは URL または HTML 形式で認証資格を渡すことができます。IDTokenN=value パラメータを使用すると、ユーザーは認証サービスユーザーインタフェースにアクセスせずに認証を受けることができます。この処理は、ゼロページログインと呼ばれます。ゼロページログインは、1 つのログインページを使用する認証モジュールの場合にのみ機能します。IDToken0、IDToken1、...、IDTokenN の値は、認証モジュールのログインページのフィールドにマッピングされます。たとえば、LDAP 認証モジュールが、userID 情報に IDToken1 を、パスワード情報に IDToken2 を使用するとします。この場合、LDAP モジュールの IDTokenN URL は次のようになります。

http://server_name.domain_name:port/amserver/UI/
Login?module=LDAP&IDToken1=userID&IDToken2=password

LDAP がデフォルトの認証モジュールである場合は、module=LDAP を省略できます。

匿名認証の場合は、ログイン URL パラメータは次のようになります。

http://server_name.domain_name:port/amserver/UI/Login?module=Anonymous&IDToken1=anonymousUserID

注 –

以前のリリースのトークン名 Login.Token0、Login.Token1、...、Login.TokenN は、現在はサポートされていますが今後のリリースではサポートされません。新しい IDTokenN パラメータを使用することをお勧めします。

アカウントのロック

認証サービスには、n 回失敗すると、ユーザーが認証からロックアウトされる機能があります。この機能はデフォルトではオフになっていますが、Access Manager コンソールを使用して有効にできます。

注 –

無効なパスワード例外をスローするモジュールのみが、アカウントロック機能を利用できます。

コア認証サービスには、この機能を有効化およびカスタマイズするための次の属性 (ただし、これらに限定されない) が含まれています。

「ログイン失敗時のロックアウトモード」は、アカウントロックを有効にします。
「ログイン失敗時のロックアウト回数」は、ユーザーがロックアウトされるまでに認証を試みることができる回数を定義します。この回数は、ユーザー ID ごとにのみ有効であり、同一ユーザー ID が指定された回数だけ認証に失敗するとロックアウトされます。
「ログイン失敗時のロックアウト間隔」は、分単位で定義された時間内にユーザーのログイン失敗の回数が「ログイン失敗時のロックアウト回数」で定義された値に達した場合に、そのユーザーをロックアウトすることを意味します。
「ロックアウト通知の送信先電子メールアドレス」は、ユーザーロックアウト通知が送信される電子メールアドレスを指定します。
「ユーザーに警告を出すまでの失敗回数」は、認証の失敗回数がここで定義した値に達したら、警告メッセージをユーザーに表示することを意味します。これにより、ロックアウトの発生が迫っていることを知らせる警告をユーザーが受けたあとに、さらに実行できるログインの試行回数を、管理者が設定できます。
「ログイン失敗時のロックアウト持続時間」は、ロックアウト後、次に認証を再試行できるようになるまで、ユーザーが待たなければならない時間を分単位で定義します。
「ロックアウト属性名」は、物理ロックのためにユーザーのプロファイルのどの LDAP 属性を「非アクティブ」に設定するかを定義します。
「ロックアウト属性値」は、「ロックアウト属性名」に指定された LDAP 属性を「非アクティブ」または「アクティブ」のどちらに設定するかを定義します。

アカウントのロックアウトに関する電子メールの通知が、管理者に送信されます。アカウントロックのアクティビティーはログにも記録されます。

注 –

Microsoft® Windows 2000 オペレーティングシステムでこの機能を使用する場合の特別な指示については、付録 A、「AMConfig.properties ファイル」の「Simple Mail Transfer Protocol (SMTP)」を参照してください。

Access Manager では、物理ロックとメモリーロックの 2 つのタイプのアカウントロックがサポートされます。次の節では、この 2 つについて説明します。

物理ロック

物理ロックは、Access Manager のデフォルトのロック動作です。このロックは、ユーザーのプロファイルの LDAP 属性の状態を非アクティブに変更することによって開始されます。「ロックアウト属性名」属性は、ロックの目的で使用する LDAP 属性を定義します。

注 –

エイリアス化されたユーザーとは、LDAP プロファイルで「ユーザーエイリアスリスト」属性 (amUser.xml の iplanet-am-user-alias-list) を設定して既存の LDAP ユーザープロファイルにマッピングされるユーザーのことです。エイリアス化されたユーザーは、コア認証サービスの「エイリアス検索属性名」フィールドに iplanet-am-user-alias-list を追加することによって確認できます。つまり、エイリアス化されたユーザーがロックアウトされると、ユーザーがエイリアス化された実際の LDAP プロファイルがロックされます。これは、LDAP およびメンバーシップ以外の認証モジュールの物理ロックアウトにのみ関係します。

メモリーロック

メモリーロックは、「ログイン失敗時のロックアウト持続時間」属性の値を 0 よりも大きな値に変更すると有効になります。有効にすると、ユーザーのアカウントは指定された時間メモリー上でロックされます。指定された期間が過ぎると、このアカウントはロック解除されます。メモリーロック機能を使用する場合の考慮事項を次に示します。

Access Manager が再起動されると、メモリー上でロックされたすべてのアカウントはロック解除されます。
ユーザーのアカウントがメモリー上でロックされ、管理者がロックアウト持続時間を 0 に設定してアカウントロックメカニズムを物理ロックに変更すると、ユーザーのアカウントはメモリーでロック解除され、ロックカウントがリセットされます。
メモリーのロックアウト後、LDAP およびメンバーシップ以外の認証モジュールを使用するときに、ユーザーが正しいパスワードでログインを試みると、「このレルムにユーザーのプロファイルがありません。」というエラーが返され、「ユーザーがアクティブではありません。」というエラーは返されません。

注 –

ユーザーのプロファイルに「失敗 URL」属性を設定すると、ロックアウト警告メッセージもアカウントがロックされたことを示すメッセージも表示されず、ユーザーは定義された URL にリダイレクトされます。

認証サービスのフェイルオーバー

プライマリサーバーにハードウェアまたはソフトウェア上の問題で障害が発生した場合、または一時的にシャットダウンした場合には、認証サービスのフェイルオーバーにより、認証要求はセカンダリサーバーへ自動的にリダイレクトされます。

認証コンテキストは認証サービスが使用可能な Access Manager のインスタンス上でまず作成されなければなりません。Access Manager のこのインスタンスが使用できない場合は、認証フェイルオーバーメカニズムにより Access Manager の別のインスタンス上に認証コンテキストが作成されます。認証コンテキストは次のような順序でサーバーが使用可能かどうか確認します。

認証サービス URL を AutoContext API に送ります。次に例を示します。
AuthContext(orgName, url)
この API を使う場合は、URL で参照されたサーバーのみを使用します。この場合、そのサーバー上で認証サービスが使用可能であっても、フェイルオーバーは起きません。
認証コンテキストが AMConfig.properties ファイルの com.iplanet.am.server* 属性に定義されたサーバーをチェックします。
手順 2 で失敗すると、認証コンテキストはネーミングサービスが利用可能なサーバーからのプラットフォームリストを照会します。ディレクトリサーバーの 1 つのインスタンスを共有する複数のインスタンスが、(主にフェイルオーバーを目的として) Access Manager 上にインストールされたときに、このプラットフォームリストが自動的に作成されます。

たとえば、プラットフォームリストに Server1、Server2、および Server3 の URL が含まれていると、認証コンテキストは Server1、Server2、および Server3 のいずれかで認証が成功するまでループします。

プラットフォームリストは、ネーミングサービスの有無に依存しているので、常に同一のサーバーから得られるわけではありません。さらに、ネーミングサービスのフェイルオーバーが最初に起こります。複数ネーミングサービス URL は AMConfing.properties の com.iplanet.am.naming.url プロパティーに定義されます。利用可能な最初のネーミングサービス URL は、認証フェイルオーバーが発生する (プラットフォームサーバーリスト中の) サーバーのリストを持つサーバーを特定するのに使われます。

完全修飾ドメイン名のマッピング

完全修飾ドメイン名 (FQDN) のマッピングは、ユーザーが誤った URL を入力した (保護されたリソースにアクセスするために部分的なホスト名または IP アドレスを指定したなど) 場合に認証サービスが訂正を行うことができるようにします。FQDN のマッピングは、AMConfig.properties ファイルで com.sun.identity.server.fqdnMap 属性を変更することによって可能になります。このプロパティーは次の形式で指定します。

com.sun.identity.server.fqdnMap[invalid-name ]=valid-name

invalid-name の値はユーザーが入力する可能性がある無効な FQDN ホスト名であり、valid-name はフィルタがユーザーをリダイレクトする実際のホスト名です。定められた要件に準拠するかぎり、コード例 1-1 に示すようにいくつでもマッピングを指定できます。このプロパティーを設定しない場合は、ユーザーは com.iplanet.am.server.host=server_name プロパティーに設定されたデフォルトのサーバー名に送信されます。このプロパティーも AMConfig.properties ファイルにあります。

例 7–1 `AMConfig.properties` の FQDN マッピング属性

com.sun.identity.server.fqdnMap[isserver]=isserver.mydomain.com
com.sun.identity.server.fqdnMap[isserver.mydomain]=isserver.mydomain.com
com.sun.identity.server.fqdnMap[
            IP address]=isserver.mydomain.com

FQDN のマッピングの使用例

このプロパティーは、サーバーにホストされたアプリケーションが複数のホスト名でアクセス可能な場合に、複数のホスト名のマッピングを作成するために使用できます。このプロパティーを使用して、特定の URL について訂正を行わないように Access Manager を設定することもできます。たとえば、IP アドレスを使用してアプリケーションにアクセスするユーザーにリダイレクトが必要ない場合は、この機能は次のようなマップエントリを指定して実現できます。

com.sun.identity.server.fqdnMap[IP address ]=IP address

注 –

複数のマッピングを定義する場合は、無効な FQDN 名で値が重複しないようにします。そのようにしないと、アプリケーションにアクセスできなくなる場合があります。

持続 Cookie

持続 Cookie とは、Web ブラウザを閉じたあとも存在する Cookie のことであり、ユーザーが再認証なしに新しいブラウザセッションにログインすることを可能にします。Cookie の名前は、AMConfig.properties の com.iplanet.am.pcookie.name プロパティーに定義されます。デフォルト値は、DProPCookie です。Cookie の値は、3DES で暗号化された文字列であり、この文字列には、ユーザー DN、レルム名、認証モジュール名、最大セッション時間、アイドル時間、およびキャッシュ時間が含まれます。

持続 Cookie を有効にする

手順

コア認証モジュールで「持続 Cookie モード」をオンにします。

コア認証モジュールで「Cookie の最大持続時間」属性の時間値を設定します。

ユーザーインタフェースのログイン URL に yes の値で iPSPCookie パラメータを付加します。

ユーザーがこの URL を使用して認証を受けると、ブラウザを閉じた場合、新しいブラウザウィンドウを開くことができ、再認証なしにコンソールにリダイレクトされます。手順 2 で定義された時間が経過するまでこのようになります。

持続 Cookie モードは、次の認証 SPI メソッドを使用してオンにできます。

AMLoginModule.setPersistentCookieOn()

レガシーモードにおけるマルチ LDAP 認証モジュール設定

フェイルオーバーの形式として、あるいは、Access Manager コンソールで値フィールドが 1 つだけ提供されている場合に、属性に複数の値を設定するために、管理者は 1 つのレルムに複数の LDAP 認証モジュール設定を定義できます。これら追加の設定はコンソールに表示されませんが、要求を行っているユーザーの承認が初期検索で見つからない場合に、主設定とともに機能します。たとえば、1 つのレルムで 2 つの異なるドメインでの認証に LDAP サーバーを介した検索を定義したり、あるいは 1 つのドメインに複数のユーザーネーミング属性を設定できます。後者の場合、コンソールにはテキストフィールドが 1 つのみあり、第 1 の検索基準でユーザーが見つからない場合は、LDAP モジュールは第 2 の検索範囲で検索します。追加の LDAP 構成を設定する手順を次に示します。

追加の LDAP 構成を設定する

手順

2 番目 (または 3 番目の) LDAP 認証設定に必要な属性および新しい値の完全なセットを含めた XML ファイルを作成します。

利用可能な属性は、/etc/opt/SUNWam/config/xml にある amAuthLDAP.xml で参照できます。この手順で作成された XML ファイルは、amAuthLDAP.xml とは異なり、amadmin.dtd の構造に基づいています。このファイルには、任意のまたはすべての属性を定義できます。コード例 1-2 は、LDAP 認証設定に利用できるすべての属性の値が含まれる副設定ファイルの例です。

<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
  Copyright (c) 2002 Sun Microsystems, Inc. All rights reserved.
  Use is subject to license terms.
-->
<!DOCTYPE Requests
    PUBLIC "-//iPlanet//Sun ONE Access Manager 6.0 Admin CLI DTD//EN"
    "jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<!--
  Before adding subConfiguration load the schema with
GlobalConfiguration defined and replace corresponding
 serviceName and subConfigID in this sample file OR load
 serviceConfigurationRequests.xml before loading this sample
-->
<Requests>
<realmRequests DN="dc=iplanet,dc=com">
    <AddSubConfiguration subConfigName = "ssc"
        subConfigId = "serverconfig"
        priority = "0" serviceName="iPlanetAMAuthLDAPService">

              <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-server"/>
            <Value>vbrao.red.iplanet.com:389</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-base-dn"/>
            <Value>dc=iplanet,dc=com</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="planet-am-auth-ldap-bind-dn"/>
            <Value>cn=amldapuser,ou=DSAME Users,dc=iplanet,dc=com</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-bind-passwd"/>
            <Value>
                  プレーンテキストのパスワード</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-user-naming-attribute"/>
            <Value>uid</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-user-search-attributes"/>
            <Value>uid</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-search-scope"/>
            <Value>SUBTREE</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-ssl-enabled"/>
            <Value>false</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-return-user-dn"/>
            <Value>true</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-auth-level"/>
            <Value>0</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-server-check"/>
            <Value>15</Value>
        </AttributeValuePair>

    </AddSubConfiguration>

</realmRequests>
</Requests>

手順 1 で作成した XML ファイルで iplanet-am-auth-ldap-bind-passwd の値としてプレーンテキストのパスワードをコピーします。

この属性の値は、コード例に太字で示されています。

amadmin コマンド行ツールを使用して、XML ファイルをロードします。
./amadmin -u amadmin -w administrator_password -v -t name_of_XML_file.
この 2 番目の LDAP 設定は、コンソールを使用して表示も変更もできません。

ヒント –
複数 LDAP 設定に利用できるサンプルが用意されています。/AccessManager-base /SUNWam/samples/admin/cli/bulk-ops/ にある serviceAddMultipleLDAPConfigurationRequests.xml コマンド行テンプレートを参照してください。手順については、/AccesManager-base/SUNWam/samples/admin/cli/ にある Readme.html を参照してください。

セッションのアップグレード

認証サービスでは、1 つのレルムに対して同一ユーザーが実行した 2 回目の成功した認証に基づいて有効なセッショントークンのアップグレードを行うことができます。有効なセッショントークンを持つユーザーが、現在のレルムによってセキュリティー保護されているリソースに対して認証を試み、この 2 回目の認証が成功すると、セッションは新しい認証に基づく新しいプロパティーで更新されます。認証が失敗すると、ユーザーの現在のセッションがアップグレードなしに戻されます。有効なセッショントークンを持つユーザーが別のレルムによってセキュリティー保護されているリソースに対して認証を試みると、新しいレルムの認証を受けるどうかを尋ねるメッセージを受け取ります。この時点では、ユーザーは、現在のセッションを維持するか、または新しいレルムの認証を受けることができます。認証が成功すると、古いセッションは破棄され、新しいセッションが作成されます。

セッションのアップグレード時に、ログインページの時間切れになると、元の成功 URL へのリダイレクトが発生します。タイムアウト値は、次の条件に基づいて判断されます。

各モジュールに設定されたページタイムアウト値 (デフォルトは 1 分)
AMConfig.properties の com.iplanet.am.invalidMaxSessionTime プロパティー (デフォルトは 10 分)
iplanet-am-max-session-time (デフォルトは 120 分)

com.iplanet.am.invalidMaxSessionTimeout と iplanet-am-max-session-time の値は、ページタイムアウト値よりも大きい必要があり、そうでない場合はセッションアップグレード時に有効なセッション情報が失われ、前回の成功 URL へのリダイレクトは失敗します。

検証プラグインインタフェース

管理者は、レルムに適したユーザー名またはパスワード検証ロジックを作成し、そのロジックを認証サービスにプラグインできます。この機能は、LDAP およびメンバーシップの認証モジュールのみでサポートされます。ユーザーを認証したりパスワードを変更する前に、Access Manager はこのプラグインを呼び出します。検証が成功すると、認証が継続され、失敗すると、認証失敗ページがスローされます。プラグインは、サービス管理 SDK の一部である com.iplanet.am.sdk.AMUserPasswordValidation クラスを拡張します。SDK についての情報は、Access Manager Javadocs の com.iplanet.am.sdk パッケージを参照してください。

検証プラグインを作成して設定する

手順

新しいプラグインクラスは、com.iplanet.am.sdk.AMUserPasswordValidation クラスを拡張し、validateUserID() および validatePassword() メソッドを実装します。検証が失敗した場合は、AMException がスローされます。

プラグインクラスをコンパイルし、.class ファイルを必要な場所に配置します。実行時に Access Manager がプラグインにアクセスできるように、クラスパスを更新します。

最上位の管理者として Access Manager コンソールにログインします。「サービス管理」タブをクリックし、管理サービスの属性にアクセスします。「ユーザー ID とパスワードの検証プラグインクラス」フィールドにパッケージ名を含むプラグインクラスの名前を入力します。

ログアウトし、ログインし直します。

JAAS 共有状態

JAAS 共有状態を有効にすることで、ユーザー ID とパスワードの両方を認証モジュール間で共有できます。各認証モジュールに対して次のオプションを定義します。

レルム (または、組織)
ユーザー
サービス
ロール

失敗した場合、モジュールは必要な資格を要求します。認証の失敗後、モジュールが停止するか、ログアウト共有状態がクリアされます。

JAAS 共有状態の有効化

JAAS 共有状態を設定するには、次のようにします。

iplanet-am-auth-shared-state-enabled オプションを使用します。
共有状態オプションの使用法を次に示します。iplanet-am-auth-shared-state-enabled=true
このオプションのデフォルトは、true です。
この変数は、認証連鎖設定の「オプション」列で指定されます。

失敗すると、認証モジュールは、JAAS の仕様で提案される tryFirstPass オプションの動作ごとに必要な資格を要求します。

JAAS 共有状態ストアオプション

「JAAS 共有状態ストア」オプションを設定するには、次のようにします。

iplanet-amauth-store-shared-state-enabled オプションを使用します。
「共有状態」オプションの使用法を次に示します。iplanet-am-auth-store-shared-state-enabled=true
このオプションのデフォルトは、false です。
この変数は、認証連鎖設定の「オプション」列で指定されます。

コミット、中断、またはログアウト後に、共有状態はクリアされます。

第 8 章ポリシーの管理

この章では、Sun Java™ System Access Manager のポリシー管理機能について説明します。Access Manager のポリシー管理機能では、最上位レベル管理者または最上位レベルポリシー管理者が、すべてのレルムで使用できる特定サービスのポリシーの表示、作成、削除、修正を行うことができるようになります。レルムまたはサブレルムの管理者あるいはポリシー管理者が、レルムレベルでポリシーを表示、作成、削除、修正することもできます。

この章は、次の節で構成されています。

概要

ポリシーは、組織の保護されたリソースに対するアクセス権限を指定するルールを定義します。ビジネスには、保護、管理、監視しなければならない、リソース、アプリケーション、およびサービスがあります。ポリシーはこれらのリソースに対するアクセス権と使用を管理し、ユーザーがあるリソースに対して、いつ、どのようにアクションを実行できるかを定義します。ポリシーによって、特定の主体のリソースが定義されます。

注 –

主体には、個人、企業、ロール、グループなど、アイデンティティーを持つことができるすべてのものが該当します。詳細については、『Java™ 2 Platform Standard Edition Javadoc』を参照してください。

1 個のポリシーでは、二者択一または任意設定の決定を定義できます。二者択一の決定は、「はい」/「いいえ」、「真」/ 「偽」 または 「許可する」/「許可しない」の形式です。任意設定の決定では、属性の値を表します。たとえば、メールサービスは、ユーザーごとの最大保存容量の値セットを持つ mailboxQuota 属性を含んでいます。一般的に、ポリシーは主体が、どのような条件でどのリソースに何をできるかを定義するように設定されています。

ポリシー管理機能

ポリシー管理機能には、ポリシーの作成および管理を行うポリシーサービスが備わっています。ポリシーサービスにより、管理者は Access Manager の配備の中でリソースを保護するために、アクセス権を定義、変更、付与、無効化、および削除することができます。通常、ポリシーサービスには、データストアと、ポリシーの作成、管理、評価ができるインタフェースライブラリ、およびポリシーエンフォーサ (ポリシーエージェント) が含まれています。デフォルトでは、Access Manager は Sun Java Enterprise System Directory Server をデータ保存に使い、ポリシーの評価とポリシーサービスのカスタマイズのために Java と C の API を提供します。詳細は、『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』を参照してください。また、管理者は Access Manager コンソールを使用してポリシー管理を行うこともできます。Access Manager は、ダウンロード可能なポリシーエージェントを使用してポリシーを適用する、URL ポリシーエージェントサービスを提供します。

URL ポリシーエージェントサービス

Access Manager をインストールするときに、HTTP URL を保護するポリシーを定義するための URL ポリシーエージェントサービスが実装されます。このサービスにより、管理者はポリシーエンフォーサ、つまりポリシーエージェントにより、ポリシーの作成および管理を行えます。

ポリシーエージェント

ポリシーエージェントは企業のリソースが保存されているサーバーへのポリシー適用ポイント (Policy Enforcement Point、PEP) です。ポリシーエージェントは Access Manager とは別に Web サーバー上にインストールされており、ユーザーが保護された Web サーバー上のリソースを要求すると、追加の認証ステップとして働きます。この認証は、リソースが実行するあらゆるユーザー認証要求に追加されます。ポリシーエージェントは Web サーバーを保護し、一方、認証プラグインはリソースを保護します。

たとえば、リモートインストールされた Access Manager で保護されている人事部の Web サーバーにエージェントがインストールされているとします。このエージェントにより、適切なポリシーを持っていない担当者には機密の給与情報またはその他の秘密情報は表示されません。このポリシーは Access Manager の管理者が定義し、Access Manager の配備に保存され、リモート Web サーバーのコンテンツにユーザーがアクセスするのをポリシーエージェントが許可または拒否するのに使われます。

最新の Access Manager ポリシーエージェントは Sun Microsystems Download Center からダウンロードできます。

ポリシーエージェントのインストールおよび管理の詳細については、『Sun Java System Access Manager Policy Agent 2.2 User’s Guide』を参照してください。

注 –

ポリシーの評価に特定の順序はありませんが、評価の途中であるアクションの値が「許可しない」となったときには、ポリシー設定サービスにより「拒否決定で評価を続行」属性が有効になっていないかぎり、以降のポリシーの評価は中止されます。

Access Manager ポリシーエージェントが決定を適用するのは Web URL (http://... 、または https//...) だけですが、Java と C の Policy Evaluation API を使ってエージェントをプログラミングすれば、ほかのリソースにもポリシーを適用可能です。

この場合、追加作業として、ポリシー設定サービスの「リソースコンパレータ」属性をデフォルトから次のように変更する必要があります。

serviceType=Name_of_LDAPService |class=com.sun.identity.policy.plugins.SuffixResourceName|wildcard=*

|delimiter=,|caseSensitive=false

もしくは、LDAPResourceName などの実装により、com.sun.identity.policy.interfaces.ResourceName を実装して、その上で「リソースコンパレータ」を適切に設定するという方法もあります。

ポリシーエージェントプロセス

Web ブラウザがポリシーエージェントによって保護されたサーバー上の URL を要求すると、保護された Web リソースに対するプロセスが始まります。このサーバーにインストールされたポリシーエージェントはこの要求を傍受し、既存の認証資格をチェックします (セッショントークン)。

エージェントが要求を傍受し、既存のセッショントークンを検証したら、プロセスは以下のように続きます。

セッショントークンが有効であれば、ユーザーのアクセスは許可または拒否されます。ユーザーのトークンが無効であれば、以下の手順にあるようにユーザーを認証サービスにリダイレクトします。

既存のセッショントークンが存在しない要求をエージェントが傍受した場合は、そのリソースが異なる認証方法で保護されているときでも、エージェントはユーザーをログインページにリダイレクトします。
ユーザーの資格が適切に認証されると、エージェントは Access Manager の内部サービスの接続に使う URL を定義するネーミングサービスに要求を出します。
ポリシーを適用しないリソースリストがエージェントに設定されている場合、リソースがそのリストに一致する場合には、アクセスが許可されます。
ネーミングサービスはポリシーサービス、セッションサービス、およびログサービスのロケータを返します。
エージェントはユーザーに適用されるポリシー決定を取得するためにポリシーサービスに要求を送信します。
アクセスされるリソースに関してのポリシー決定に基づいて、ユーザーのアクセスが許可または拒否されます。ポリシー決定へのアドバイスが異なる認証レベルまたは認証メカニズムを示している場合、エージェントはすべての基準が検証されるまで要求を認証サービスにリダイレクトします。

ポリシータイプ

Access Manager を使用して設定できるポリシーは、次の 2 種類です。

標準ポリシー

Access Manager では、アクセス権を定義するポリシーを標準ポリシーと呼びます。標準ポリシーは、ルール、対象、条件、および応答プロバイダから構成されます。

ルール

ルールは 1 つのリソース、1 つ以上のアクション、および 1 つの値からなります。各アクションには、1 つ以上の値を設定できます。

リソースは保護される特定のオブジェクトを指します。たとえば、人事サービスを使ってアクセスする HTML ページまたはユーザーの給与情報です。
アクションはリソースに対して実行される操作の名前です。Web サーバーアクションの例としては POST または GET があります。たとえば、人事サービスに対して自宅電話番号を変更するアクションを許可できます。
値は各アクションの可否を示します。たとえば、allow (許可する) または deny (許可しない) です。

注 –

一部のサービスに対しては、リソースなしでアクションを定義することも可能です。

対象

対象はポリシーが影響を与えるユーザーまたはユーザーの集合 (たとえば、グループ、または特定のロールを持つ複数のユーザー) を定義します。対象はポリシーに割り当てられます。対象の一般則は、ユーザーがポリシー中の少なくとも 1 つの対象のメンバーである場合にのみポリシーが適用される、というものです。デフォルトの対象は次のとおりです。

AM アイデンティティー対象

レルムの「対象」タブで作成して管理しているアイデンティティーを対象の値として追加できます。

Access Manager ロール

この対象には、任意の LDAP ロールを値として追加できます。LDAP ロールは、Directory Server ロール機能を使用するロール定義です。LDAP ロールは、Directory Server ロール定義が規定するオブジェクトクラスを持ちます。ポリシー設定サービスで LDAP ロール検索フィルタを変更して、検索範囲を絞り込みパフォーマンスを向上させることができます。

認証済みユーザー

有効な SSOToken を持つ任意のユーザーがこの対象のメンバーです。すべての認証済みユーザーは、ポリシーが定義されている組織とは別の組織に認証しても、この対象のメンバーになります。リソース所有者が、別の組織のユーザー用に管理されているリソースにアクセスできるようにする場合は、これが便利です。

LDAP グループ

ある LDAP グループの任意のメンバーをこの対象の値として追加できます。

LDAP ロール

LDAP ユーザー

この対象には、任意の LDAP ユーザーを値として追加できます。

組織

ある組織の任意のメンバーがこの対象のメンバーです。

Web サービスクライアント

有効な値は、信頼できる WSC の証明書に対応する、ローカル JKS キーストア内の信頼できる証明書の DN です。この対象は、Liberty Web サービスフレームワークに依存し、Liberty サービスプロバイダが WSC を承認するためにのみ使用する必要があります。SSOToken に含まれる主体の DN がこの対象の選択された値のいずれかに一致する場合、SSOToken が特定する Web サービスクライアント (WSC) がこの対象のメンバーです。

この対象をポリシーに追加する前に、キーストアが作成されていることを確認します。キーストアの設定に関する説明は、次の場所にあります。

AccessManager-base /SUNWam/samples/saml/xmlsig/keytool.html

Access Manager ロールと LDAP ロールの比較

Access Manager ロールは Access Manager を使用して作成します。これらのロールは Access Manager が規定するオブジェクトクラスを持ちます。LDAP ロールは、Directory Server ロール機能を使用するロール定義です。LDAP ロールは、Directory Server ロール定義が規定するオブジェクトクラスを持ちます。すべての Access Manager ロールは Directory Server のロールとして使用できます。しかし、すべての Directory Server ロールが必ずしも Access Manager ロールというわけではありません。LDAP ロールは、「ポリシー設定サービス」を設定することにより、既存のディレクトリから利用できます。Access Manager のロールには、ホスティングする Access Manager のポリシーサービス経由でのみアクセスできます。ポリシー設定サービスで LDAP ロール検索フィルタを変更して、検索範囲を絞り込みパフォーマンスを向上させることができます。

入れ子ロール

入れ子ロールはポリシー定義の対象の LDAP ロールとして正しく評価できます。

条件

条件によって、ポリシーに制約を定義できます。たとえば、給与アプリケーション用のポリシーを定義する場合、アプリケーションへのアクセスを特定の時間帯だけに制限するようにアクションに対して条件を定義することができます。また、所定の IP アドレスまたは企業のイントラネットからの要求に対してのみアクションを許可するように条件を定義することもできます。

条件は、同じドメインの別の URI で別のポリシーを設定するために、補助的に使用されることもあります。たとえば、http://org.example.com/hr/*jsp は org.example.net ドメインより午前9 時〜午後5 時の間だけアクセスでき、一方、http://org.example.com/finance/*.jsp は org.example2.net ドメインより午前5 時〜午後11 時の間だけアクセスできる、といった具合にです。これは IP 条件と時間条件を使用して実現します。またルールのリソースを http://org.example.com/hr/*.jsp に指定することで、ポリシーは http://org.example.com/hr 以下、サブディレクトリ内を含むすべての JSP に適用されるようになります。

注 –

参照、ルール、リソース、対象、条件、属性、値の各用語は、policy.dtd 内の Referral、Rule、 ResourceName、Subject、Condition、Attribute、Value の各要素に対応しています。

追加できるデフォルトの条件は、次のとおりです。

認証レベル

ユーザーの認証レベルが条件に設定された認証レベル以上である場合にポリシーが適用されます。

この属性は、認証の信頼レベルを示しています。

認証レベルの条件を使用して、そのレルムに登録された認証モジュールレベル以外のレベルを指定できます。これは、別のレルムから認証を受けたユーザーにポリシーを適用する場合に役立ちます。

「LE 認証レベル」の場合、ユーザーの認証レベルが条件に設定された認証レベル以下である場合にポリシーが適用されます。認証レベルの条件を使用して、そのレルムに登録された認証モジュールレベル以外のレベルを指定できます。これは、別のレルムから認証を受けたユーザーにポリシーを適用する場合に役立ちます。

認証方式

プルダウンメニューから条件の認証方式を選択します。これらの認証方式は、レルムのコア認証サービスで定義されている認証モジュールです。

IP アドレス

IP アドレスの範囲に基づいて条件を設定します。定義できるフィールドは、次のとおりです。

「IP アドレス開始 / 終了」: IP アドレスの範囲を指定します。
「DNS 名」: DNS 名を指定します。このフィールドには、完全修飾ホスト名または次の形式の文字列を指定できます。

domainname

*.domainname

セッション

ユーザーセッションのデータに基づいて条件を設定します。変更できるフィールドは、次のとおりです。

「最大セッション時間」: セッションを開始してからポリシーを適用する間の最大ユーザーセッション時間を指定します。
「セッションを終了」: 選択すると、「最大セッション時間」フィールドで定義した許可される最大値をセッション時間が超えた場合に、ユーザーセッションを終了します。

この条件を使用すれば、認証後の限られた期間だけリソースを使用可能にする方法で、機密リソースを保護できます。

セッションプロパティー

ユーザーの Access Manager セッションに設定されたプロパティーの値に基づいて要求にポリシーを適用できるかどうかを決定します。ポリシーの評価中に条件が「真」を返すのは、ユーザーのセッションに条件で定義されたすべてのプロパティー値が存在する場合だけです。条件の中で複数の値を使用して定義されたプロパティーについては、トークンのプロパティーの値が少なくとも 1 つあれば十分です。たとえば、この条件を使用すれば、外部リポジトリの属性に基づいてポリシーを適用することができます。認証後のプラグインは、外部属性に基づいてセッションプロパティーを設定できます。

時間

時間の制約に基づいて条件を設定します。フィールドは次のとおりです。

「開始日付 / 終了日付」: 日付の範囲を指定します。
「時刻」: 1 日での時間の範囲を指定します。
「曜日」: 曜日を指定します。
「タイムゾーン」: タイムゾーンを標準またはカスタムで指定します。カスタムのタイムゾーンとして指定できるのは、Java で認識されるタイムゾーン ID だけです (PST など)。値を指定しない場合は、デフォルト値は Access Manager JVM に設定されたタイムゾーンになります。

応答プロバイダ

応答プロバイダは、ポリシーベースの応答属性を提供するプラグインです。応答プロバイダ属性は、ポリシー決定とともに PEP に送信されます。Access Manager に実装されているのは IDResponseProvider の 1 つだけです。このバージョンの Access Manager では、カスタム応答プロバイダはサポートされていません。エージェントの PEP は通常、これらの応答属性をヘッダーとしてアプリケーションに渡します。アプリケーションは通常、これらの属性を使用して、ポータルページなどのアプリケーションページをポリシーに基づいて設定します。

ポリシーアドバイス

条件で決定したようにポリシーを適用できない場合は、ポリシーを要求に適用できなかった理由を示すアドバイスメッセージを条件によって作成できます。このアドバイスメッセージは、ポリシー決定でポリシー適用ポイントに伝わります。ポリシー適用ポイントでは、このアドバイスを取得し、認証メカニズムにユーザーを戻してより高いレベルに認証するなど、適切なアクションを実行しようとします。アドバイスの適切なアクションを実行したあとでポリシーが適用可能になると、ユーザーはより高いレベルの認証を要求され、リソースにアクセスできるようになることがあります。

詳細は、次のクラスを参照してください。

com.sun.identity.policy.ConditionDecision.getAdvices()

条件が満たされない場合、アドバイスを提供するのは、AuthLevelCondiiton と AuthSchemeCondition のみです。

AuthLevelCondition アドバイスは、次のキーに関連します。

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_LEVEL_CONDITION_ADVICE

AuthSchemeCondition アドバイスは、次のキーに関連します。

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_SCHEME_CONDITION_ADVICE

カスタム条件でもアドバイスを作成できます。ただし、Access Manager ポリシーエージェントは、認証レベルアドバイスと認証方式アドバイスのみに応答します。カスタムエージェントを作成してより多くのアドバイスを理解させて応答させたり、既存の Access Manager エージェントを拡張してより多くのアドバイスを理解させて応答させたりすることができます。詳細は、『Sun Java System Access Manager Policy Agent 2.2 User’s Guide』を参照してください。

参照ポリシー

管理者は、あるレルムのポリシーの定義と決定を別のレルムに委任することが必要になる場合があります。または、あるリソースに対するポリシー決定を別のポリシー製品に委任することもできます。参照ポリシーは、ポリシーの作成と評価の両方に対するポリシーの委任を管理します。1 つ以上のルールと、1 つ以上の参照で構成されます。

ルール

ルールは、ポリシーの定義と評価が参照されるリソースを定義します。

参照

参照は、ポリシーの評価をどの組織に対して参照するかを定義します。デフォルトでは、2 種類の参照があります。ピアレルムとサブレルムです。それぞれ、同じレベルのレルム、下位レベルのレルムを表します。詳細は、「ピアレルムおよびサブレルムのポリシーの作成」を参照してください。

注 –

参照先のレルムでは、そのレルムをすでに参照済みのリソース (またはサブリソース) のポリシーのみを定義または評価できます。ただし、この制約は最上位のレルムには適用されません。

ポリシー DTD

作成して設定したポリシーは、Directory Server に XML 形式で保存されます。Directory Server では、XML でエンコードされたデータは 1 か所に保管されます。ポリシーは、amAdmin.dtd (またはコンソール) を使って定義され設定されますが、実際には policy.dtd に基づく XML として、Directory Server に保存されます。policy.dtd は、amAdmin.dtd から抽出されたポリシー要素タグ (ポリシー作成タグを除く) を含んでいます。したがって、ポリシーサービスは Directory Server からポリシーをロードすると、policy.dtd に基づいて XML をパースします。ポリシーをコマンド行から作成するときには、amAdmin.dtd のみが使われます。この節では、policy.dtd の構造について説明します。policy.dtd は次の場所にあります。

AccessManager-base/SUNWam/dtd (Solairs)
AccessManager-base/identity/dtd (Linux)

注 –

本章ではこれ以降、ディレクトリ情報は Solaris についてのみ記します。Linux のディレクトリ構造は異なっていることに注意してください。

Policy 要素

Policy はアクセス権、つまりポリシーのルールと、ルールの適用先、つまり対象を定義するルート要素です。また、ポリシーが参照 (委任) ポリシーかどうか、およびポリシーになんらかの制限 (または条件) があるかどうかも定義します。この要素には、Rule、Conditions、Subjects、Referrals、response providersというサブ要素のうち 1 つ以上が含まれることがあります。必須の XML 属性は name で、これはポリシーの名前を指定します。referralPolicy 属性は、ポリシーが参照ポリシーであるかどうかを識別します。指定がなければ標準ポリシーとして扱われます。オプションの XML 属性には name と description があります。

注 –

ポリシーに referral タグを付けると、対象と条件はポリシー評価の際、無視されます。逆に、ポリシーに normal タグを付けると、Referrals は無視されます。

Rule 要素

Rule 要素では、ポリシーの詳細を定義します。ServiceName、ResourceName 、AttributeValuePair という 3 つのサブ要素を持つことができます。この要素は、リソース名やそこで実行されるアクションだけではなく、ポリシーが作成されたサービスやアプリケーションのタイプを定義します。アクションを持たないルールも定義できます。たとえば、参照ポリシールールにはアクションはありません。

注 –

ResourceName 要素を含まないポリシーの定義も可能です。

ServiceName 要素

ServiceName 要素は、ポリシーを適用するサービスの名前を定義します。この要素は、サービスのタイプを表しています。ほかの要素は含みません。値は、そのサービスの XML ファイルで (sms.dtd に基づいて) 定義されているとおりです。ServiceName 要素の XML サービス属性はサービスの名前 (値は文字列) です。

ResourceName 要素

ResourceName 要素は対象となるオブジェクトを定義します。ポリシーは、このオブジェクトを保護するように設定されています。ほかの要素は含みません。ResourceName 要素の XML サービス属性は、オブジェクトの名前です。ResourceName の例としては、Web サーバー上の http://www.sunone.com:8080/images、ディレクトリサーバー上の ldap://sunone.com:389/dc=example,dc=com などが挙げられます。より具体的なリソースとしては、 salary://uid=jsmith,ou=people,dc=example,dc=com などが考えられます。この場合、処理対象のオブジェクトは John Smith の給与情報になります。

AttributeValuePair 要素

AttributeValuePair 要素はアクションとその値を定義します。この要素は「Subject 要素」、「Referral 要素」、および「Condition 要素」のサブ要素として扱われます。これは Attribute 要素と Value 要素を含み、XML サービス属性は含んでいません。

Attribute 要素

Attribute 要素はアクションの名前を定義します。アクションとは処理、つまりリソースに対して行われるイベントのことです。POST や GET は Web サーバーリソースに対して行われるアクションであり、READ や SEARCH はディレクトリサーバーリソースに対して行われるアクションです。Attribute 要素は Value 要素とペアにする必要があります。Attribute 要素自体は、ほかの要素を含みません。Attribute 要素に対する XML サービス属性は、アクションの名前です。

Value 要素

Value 要素はアクションの値を定義します。Allow (許可する)/Deny (許可しない)、Yes (はい) /No (いいえ) はアクションの値の例です。ほかのアクションの値は、ブール型、数値型、または文字列型が可能です。値は、そのサービスの XML ファイルの中で (sms.dtd に基づいて) 定義されています。Value 要素はほかの要素を含まず、また XML サービス属性も含みません。

注 –

許可しないルールは許可するルールより優先度が高くなります。たとえば、あるポリシーはアクセスを拒否し、別のポリシーが許可すると、(両方のポリシーのほかの条件がすべて一致する場合) 結果は拒否となります。許可しないポリシーを使用すると、ポリシー間で潜在的に衝突が生じるおそれがあるため、十分に注意して拒否ポリシーを使用することをお勧めします。明示的な許可しないルールを使用すると、さまざまな対象 (ロールやグループメンバーシップなど) を通じてユーザーに割り当てられたポリシーが、アクセスを拒否する可能性があります。通常は、ポリシー定義プロセスでは、許可するルールのみを使うべきです。デフォルトで「許可しない」というのは、ほかに適用するポリシーがない場合に使用します。

Subjects 要素

Subjects サブ要素はポリシーが適用される主体の集合を特定します。この集合はグループのメンバーシップ、ロールの所有権、または個別ユーザーに基づいて選択されます。この要素は、Subject というサブ要素を持ちます。定義できる XML 属性は以下のとおりです。

name: 集合の名前を定義します。

description: 対象の説明を定義します。

includeType: 現在は使われていません。

Subject 要素

Subject サブ要素はポリシーを適用する主体の集合を特定します。この集合は、Subjects 要素が定義する集合をさらに絞り込んだものです。メンバーシップは、ロール、グループメンバーシップ、または単なる個別ユーザーのリストに基づきます。この要素は、「AttributeValuePair 要素」というサブ要素を含みます。必須の XML 属性は type で、特定の定義済み対象を持つ、オブジェクトの一般的な集合を特定します。ほかの XLM 属性には、集合の名前を定義する name、対象のメンバーでないユーザーに対してポリシーを適用するかどうかに関して、集合が定義されたとおりになっているかどうかを定義する includeType があります。

注 –

複数の対象を定義した場合、ポリシーを適用するためには少なくとも 1 つの対象をユーザーに適用しなければなりません。includeType を false にして対象を定義するときは、ユーザーがその対象のメンバーではないことが必要です。

Referrals 要素

Referrals サブ要素はポリシー参照の集合を特定します。この要素は、Referral というサブ要素を持ちます。ともに定義できる XML 属性には、集合の名前を定義する name、説明を含む description があります。

Referral 要素

Referral サブ要素は個別のポリシー参照を特定します。この要素は、サブ要素として「AttributeValuePair 要素」を取ります。必須の XML 属性は type で、特定の定義済み参照を持つ、割り当ての一般的な集合を特定します。また、集合の名前を定義する name 属性を持つこともできます。

Conditions 要素

Conditions サブ要素はポリシーの制限 (時間範囲、認証レベル、その他) の集合を特定します。この要素は複数の Condition サブ要素を含んでいなければなりません。ともに定義できる XML 属性には、集合の名前を定義する name、説明を含む description があります。

注 –

conditions 要素は、ポリシーの中ではオプションの要素です。

Condition 要素

Condition サブ要素は特定のポリシーの制限 (時間範囲、認証レベル、その他) を特定します。この要素は、サブ要素として「AttributeValuePair 要素」を取ります。必須の XML 属性は type で、特定の定義済み対象を持つ、オブジェクトの一般的な集合を特定します。また、集合の名前を定義する name 属性を持つこともできます。

ポリシーを有効にしたサービスの追加

サービススキーマの <Policy> 要素が sms.dtd に設定されている場合にのみ、そのサービスのリソースにポリシーを定義することができます。

デフォルトで、Access Manager は URL ポリシーエージェントサービス (iPlanetAMWebAgentService) を提供します。このサービスは、XML ファイル形式で定義され、次のディレクトリにあります。

/etc/opt/SUNWam/config/xml/

Access Manager にさらにポリシーサービスを追加することもできます。ポリシーサービスを作成したら、amadmin コマンド行ユーティリティーを使って、これを Access Manager に追加します。

新しいポリシーを有効にしたサービスを追加する

手順

新しいポリシーサービスを sms.dtd に基づいて XML ファイルで作成します。新しいポリシーサービスファイルの雛型にできるポリシーサービス XML ファイルが 2 つ、Access Manager から提供されます。

amWebAgent.xml はデフォルトの URL ポリシーエージェントサービスのための XML ファイルです。これは /etc/opt/SUNWam/config/xml/ にあります。

SampleWebService.xml は、ポリシーサービスファイルのサンプルであり、SampleWebService.xml にあります。

新しいポリシーサービスをロードするディレクトリに XML ファイルを保存します。次に例を示します。
/config/xml/newPolicyService.xml

新しいポリシーサービスを amadmin コマンド行ユーティリティーを使ってロードします。次に例を示します。

AccessManager-base/SUNWam/bin/amadmin
    --runasdn “uid=amAdmin,ou=People,default_org,
root_suffix
    --password password
    --schema /config/xml/newPolicyService.xml

新しいポリシーサービスをロードしたあと、Access Manager コンソールから作業を行うか、または、amadmin で新しいポリシーをロードすることにより、ポリシー定義のルールを定義できます。

ポリシーの作成

Policy API と Access Manager コンソールを使用してポリシーを作成、変更、および削除でき、amadmin コマンド行ツールを使用してポリシーを作成および削除できます。また、amadmin ユーティリティーを使用して、ポリシーの一覧を XML 形式で取得して表示することもできます。この節では、amadmin コマンド行ユーティリティーと Access Manager コンソールを使用してポリシーを作成することを中心に説明します。Policy API の詳細は、『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』を参照してください。

通常ポリシーは XML ファイルで作成し、amadmin コマンド行ユーティリティーを使って Access Manager に追加し、Access Manager のコンソールを使って管理します (ただし、ポリシーをコンソールで作成することもできる)。これは、ポリシーが amadmin を使って直接変更できないからです。ポリシーを修正するには、そのポリシーを Access Manager から削除してから、修正したポリシーを amadmin を使用して追加します。

一般に、ポリシーはレルムツリー全体で使用するために、レルムまたはサブレルムレベルで作成します。

amadmin でポリシーを作成する

手順

ポリシーの XML ファイルを amadmin.dtd に基づいて作成します。このファイルは次のディレクトリにあります。

AccessManager-base /SUNWam/dtd

ポリシーの XML ファイルを作成したら、次のコマンドを使用してロードできます。
AccessManager-base/SUNWam/bin/amadmin --runasdn "uid=amAdmin,ou=People,default_org, root_suffix" --password password --data policy.xml
複数のポリシーを同時に追加するには、各 XML ファイルにポリシーを 1 つずつ置くのではなく、1 つの XML ファイルにすべてのポリシーを置きます。複数の XML ファイルでポリシーを次々とロードすると、内部ポリシーインデックスが破損したり、ポリシーの評価に参加できないポリシーが生じたりするおそれがあります。

ポリシーを amadmin で作成するときは、認証スキーム条件を作成中にレルムに認証モジュールを登録することの確認、レルム、LDAP グループ、LDAP ロール、および LDAP ユーザーの対象を作成中に、対応する LDAP オブジェクト (レルム、グループ、ロール、およびユーザー) が存在することの確認、IdentityServerRoles 対象を作成中に、Access Manager ロールが存在することの確認、そしてサブレルムまたはピアレルムの参照を作成中に、関連があるレルムが存在することの確認を行ってください。

SubrealmReferral、PeerRealmReferral、Realm 対象、IdentityServerRoles 対象、LDAPGroups 対象、LDAPRoles 対象、および LDAPUsers 対象の Value 要素のテキストには、完全な DN を指定する必要があります。

Access Manager コンソールを使って標準ポリシーを作成する

手順

ポリシーを作成するレルムを選択します。

「ポリシー」タブをクリックします。

「ポリシー」リストから「新規ポリシー」をクリックします。

ポリシーの名前と説明を入力します。

ポリシーをアクティブにする場合は、「アクティブ」属性で「はい」を選択します。

この時点では、標準ポリシーのフィールドすべてを定義する必要はありません。ポリシーの作成後、ルール、対象、条件、および応答プロバイダを追加できます。詳細は、「ポリシーの管理」を参照してください。

「作成」をクリックします。

Access Manager コンソールを使って参照ポリシーを作成する

手順

ポリシーを作成するレルムを選択します。

「ポリシー」タブから「新規参照」をクリックします。

ポリシーの名前と説明を入力します。

ポリシーをアクティブにする場合は、「アクティブ」属性で「はい」を選択します。

この時点では、参照ポリシーのフィールドすべてを定義する必要はありません。ポリシーの作成後、ルールおよび参照を追加できます。詳細は、「ポリシーの管理」を参照してください。

「作成」をクリックします。

ピアレルムおよびサブレルムのポリシーの作成

ピアレルムまたはサブレルムのポリシーを作成するには、まず親レルムまたは別のピアレルムで参照ポリシーを作成する必要があります。参照ポリシーのルールの定義には、サブレルムが管理するリソースプレフィックスを含める必要があります。親レルムまたは別のピアレルムで参照ポリシーを作成すれば、サブレルムまたはピアレルムで標準ポリシーを作成できます。

次の例では、o=isp は親レルム、o=example.com は、http://www.example.com のリソースとサブリソースを管理するサブレルムです。

サブレルムのポリシーを作成する

手順

o=isp で参照ポリシーを作成します。参照ポリシーについては、「参照ポリシーの修正」の手順を参照してください。

参照ポリシーは、http://www.example.com をリソースとしてルールに定義し、参照内に example.com を値として持つ SubRealmReferral を含んでいる必要があります。

example.com というサブレルムに移動します。

これで isp によってリソースが example.com の管理に委ねられたので、http://www.example.com というリソース、または http://www.example.com から始まる任意のリソースに対して標準ポリシーを作成できます。

example.com で管理する別のリソースのポリシーを定義するには、追加の参照ポリシーを o=isp に作成する必要があります。

ポリシーの管理

標準または参照ポリシーを作成し、Access Manager に追加したあとは、ポリシーの管理は、Access Manager のコンソールを使用して、ルール、対象、条件と参照を変更することにより行えます。

標準ポリシーの修正

「ポリシー」タブを使用して、アクセス権を定義する標準ポリシーを変更することができます。複数のルール、対象、条件、およびリソースコンパレータを定義および設定できます。ここでは、標準ポリシーを変更する手順のいくつかについて説明します。

標準ポリシーのルールを追加または変更する

手順

すでにポリシーを作成済みである場合は、ルールを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

「ルール」メニューから「新規」をクリックします。

次のデフォルトのサービスタイプから、ルール用に 1 つ選択します。ポリシーに複数のサービスが使用できる場合は、さらに多くのサービスが一覧表示されます。

ディスカバリサービス

ディスカバリサービスクエリー用の認証アクションを定義し、指定されたリソースについて、Web サービスクライアントによるプロトコル呼び出しを変更します。

Liberty 個人プロファイルサービス

Liberty 個人プロファイルサービスクエリー用の認証アクションを定義し、指定されたリソースについて、Web サービスクライアントによるプロトコル呼び出しを変更します。

URL ポリシーエージェント

ポリシーを適用するための URL ポリシーエージェントサービスを提供します。このサービスにより、管理者はポリシーエンフォーサ、つまりポリシーエージェントにより、ポリシーの作成および管理を行えます。

「次へ」をクリックします。

ルールの名前とリソース名を入力します。

現在、ポリシーエージェントでサポートされているリソースは http:// と https:// だけです。また、ホスト名の代わりに IP アドレスを使用することはできません。

ホスト名、ポート名、およびリソース名にはワイルドカードを使用できます。次に例を示します。
http*://*:*/*.html
URL ポリシーエージェントサービスでは、ポート番号が入力されていない場合のデフォルトのポート番号は、http:// では 80、https:// では 443 となります。

ルールのアクションを選択します。URL ポリシーエージェントサービスを使用する場合は、次のアクションを選択できます。
- GET
- POST

アクションの値を選択します。
- 許可 — ルールに定義されたリソースに一致するリソースへのアクセスを許可
- 拒否 — ルールに定義されたリソースに一致するリソースへのアクセスを拒否
- 拒否するルールは許可するルールより優先度が高くなります。たとえばあるリソースに 2 つのポリシーがあり、1 つはアクセス拒否でもう 1 つはアクセス許可の場合、その結果はアクセスの拒否になります (両方のポリシーの条件が一致する場合)。拒否ポリシーを使用すると、ポリシー間で潜在的に衝突が生じるおそれがあるため、十分に注意して拒否ポリシーを使用することをお勧めします。ポリシー定義プロセスでは、許可するルールのみを使うべきです。リソースに適用するポリシーがない場合、アクセスは自動的に拒否されます。
  
  拒否ルールを明示的に使用すると、1 つ以上のポリシーでアクセスが許可される場合でも、異なる対象 (ロールやグループのメンバーシップ) を通じてユーザーに割り当てられたポリシーによって、リソースへのアクセスを拒否されるおそれがあります。たとえば、1 つのリソースについて、Employee ロールに適用される拒否ポリシーと、Manager ロールに適用される許可ポリシーがあるとします。この場合、Employee ロールと Manager ロールの両方を割り当てられているユーザーへのポリシーの決定は拒否されます。
  
  このような問題を解決する 1 つの方法は、条件プラグインを使ってポリシーを設計することです。上記の例では、Employee ロールに認証されたユーザーには拒否ポリシーを適用し、Manager ロールに認証されたユーザーには許可ポリシーを適用するという " ロール条件" を利用することで、2 つのポリシーを区別できます。Manager ロールにはより高い認証レベルが与えられることから、認証レベル条件を使用する方法もあります。

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

標準ポリシーの対象を追加および変更する

手順

すでにポリシーを作成済みである場合は、対象を追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

「対象」リストから、「新規」をクリックします。

デフォルトの対象タイプを次の中から選択します。対象タイプの説明は、「対象」を参照してください。

「次へ」をクリックします。

対象の名前を入力します。

「排他的」フィールドを選択または選択解除します。

このフィールドが選択されていないと (デフォルト)、ポリシーは、対象のメンバーであるアイデンティティーに適用されます。このフィールドが選択されていると、ポリシーは、対象のメンバーではないアイデンティティーに適用されます。

ポリシーに複数の対象が存在する場合には、1 つ以上の対象のメンバーであるアイデンティティーにポリシーが適用されます。

検索を実行して、対象に追加するアイデンティティーを表示します。この手順は、「認証済みユーザー」対象や「Web サービスクライアント」対象には適用できません。

デフォルト (*) の検索パターンでは、すべてのエントリが表示されます。

対象に追加する個々のアイデンティティーを選択するか、または「すべて追加」を選択して一度にすべてのアイデンティティーを追加します。「追加」をクリックしてアイデンティティーを選択リストに移動します。この手順は、「認証済みユーザー」対象には適用されません。

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

ポリシーから対象を削除するには、対象を選択して「削除」をクリックします。対象の名前をクリックすると、対象の定義を編集できます。

標準ポリシーに条件を追加する

手順

すでにポリシーを作成済みである場合は、条件を追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

「条件」リストから、「新規」をクリックします。

条件タイプを選択して、「次へ」をクリックします。

条件タイプのフィールドを定義します。条件タイプの説明は、「条件」を参照してください。

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

標準ポリシーに応答プロバイダを追加する

手順

すでにポリシーを作成済みである場合は、応答プロバイダを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

「応答プロバイダ」リストから、「新規」をクリックします。

応答プロバイダの名前を入力します。

次の値を定義します。

StaticAttribute

その名前と値が IDResponseProvider インスタンスに定義され、ポリシーに保存されている応答属性。

DynamicAttribute

ここで選択する応答属性は、対応するレルムのポリシー設定サービス内で事前に定義されている必要があります。定義される属性名は、設定済みデータストア内に存在する属性名と同じになるようにしてください。属性の定義方法の詳細については、Access Manager のオンラインヘルプで、ポリシー設定属性定義の項目を参照してください。

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

ポリシーから応答プロバイダを削除する場合は、そのプロバイダを選択し、「削除」をクリックします。名前をクリックすると、応答プロバイダの定義を編集できます。

参照ポリシーの修正

参照ポリシーを使用すると、あるレルムのポリシーの定義や判断を別のレルムに委任できます。カスタム参照を使用すると、任意のポリシー適用先からポリシー決定を取得できます。参照ポリシーを作成したら、関連付けられているルール、参照、および応答プロバイダを追加または変更できます。

参照ポリシーのルールを追加および変更する

手順

すでにポリシーを作成済みである場合は、ルールを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って参照ポリシーを作成する」を参照してください。

「ルール」リストから「新規」をクリックします。

次のデフォルトのサービスタイプから、ルール用に 1 つ選択します。ポリシーに複数のサービスが使用できる場合は、さらに多くのサービスが一覧表示されます。

ディスカバリサービス

ディスカバリサービスクエリー用の認証アクションを定義し、指定されたリソースについて、Web サービスクライアントによるプロトコル呼び出しを変更します。

Liberty 個人プロファイルサービス

Liberty 個人プロファイルサービスクエリー用の認証アクションを定義し、指定されたリソースについて、Web サービスクライアントによるプロトコル呼び出しを変更します。

URL ポリシーエージェント

ポリシーを適用するための URL ポリシーエージェントサービスを提供します。このサービスにより、管理者はポリシーエンフォーサ、つまりポリシーエージェントにより、ポリシーの作成および管理を行えます。

「次へ」をクリックします。

ルールの名前とリソース名を入力します。

現在、ポリシーエージェントでサポートされているリソースは http:// と https:// だけです。また、ホスト名の代わりに IP アドレスを使用することはできません。

リソース名、ポート番号、およびプロトコルにはワイルドカードを使用できます。次に例を示します。
http://*:*/*.html
URL ポリシーエージェントサービスでは、ポート番号が入力されていない場合のデフォルトのポート番号は、http:// では 80、https:// では 443 となります。

リソースを http://host*:* として定義して、特定のマシンにインストールされたすべてのサーバーに対してリソースの管理を許可できます。また、次のリソースを定義して、組織のすべてのサービスに対する特定の組織権限を管理者に与えることができます。
http://*.subdomain.domain.topleveldomain

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

ポリシーの参照を追加または変更する

手順

すでにポリシーを作成済みである場合は、応答プロバイダを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って参照ポリシーを作成する」を参照してください。

「ルール」リストから「新規」をクリックします。

「サービスタイプ」を選択します。

「ルール」フィールドにリソースを定義します。フィールドは次のとおりです。

参照— 現在の参照タイプが表示されます。

名前— 参照の名前を入力します。

リソース名— リソースの名前を入力します。

フィルタ— 「値」フィールドに表示する組織名を絞り込むためのフィルタを指定します。デフォルトでは、すべての組織名が表示されます。

値 — 参照の組織名を選択します。

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

ポリシーから参照を削除するには、参照を選択して「削除」をクリックします。

参照名の横にある「編集」リンクをクリックすれば、参照の定義を編集できます。

参照ポリシーに応答プロバイダを追加する

手順

すでにポリシーを作成済みである場合は、応答プロバイダを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

「応答プロバイダ」リストから、「新規」をクリックします。

応答プロバイダの名前を入力します。

次の値を定義します。

StaticAttribute

その名前と値が IDResponseProvider インスタンスに定義され、ポリシーに保存されている応答属性。

DynamicAttribute

その名前がポリシーの IDResponseProvider インスタンスで選択されただけの応答属性。値は、ポリシーが評価されるときに要求されたユーザーアイデンティティーに基づいて、 IDRepostitories から読み込まれます。

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

ポリシーから応答プロバイダを削除する場合は、そのプロバイダを選択し、「削除」をクリックします。名前をクリックすると、応答プロバイダの定義を編集できます。

ポリシー設定サービス

各組織のポリシーに関連する属性の設定を Access Manager コンソールから行うにはポリシー設定サービスを使用します。Access Manager ポリシーフレームワークで使用するリソース名の実装および Directory Server データストアを定義することもできます。ポリシー設定サービスに指定した Directory Server は、LDAP ユーザー、LDAP グループ、LDAP ロール、および組織ポリシー対象のメンバーシップの評価に使用されます。

対象結果の有効時間

ポリシー評価のパフォーマンスを上げるため、ポリシー設定サービスの「対象結果の有効時間」属性で定義されるとおり、メンバーシップ評価を一定の時間キャッシュします。これらのキャッシュされたメンバーシップ決定は「対象結果の有効時間」属性で定義された時間が経つまで使用されます。この時間が経過したあとは、ディレクトリ内のユーザーの現在の状態を反映するために、メンバーシップ評価が使用されます。

動的属性

これらは使用可能な動的属性の名前であり、ポリシーの応答プロバイダの動的属性を定義する際に一覧表示され、選択されます。定義される名前は、データリポジトリ内に定義された属性名と同じである必要があります。

amldapuser の定義

amldapuser はインストール時に作成されたユーザーで、ポリシー設定サービスに指定した Directory Server でデフォルトで使用されます。amldapuser は、レルムの管理者またはポリシー管理者が必要に応じて変更できます。

ポリシー設定サービスの追加

レルムを作成すると、そのレルムのためにポリシー設定サービスの属性が自動的に設定されます。ただし、これらの属性は必要に応じて変更できます。

リソースベースの認証

組織によっては高度な認証シナリオが必要です。この場合、ユーザー認証は、アクセスしようとするリソースごとに特定のモジュールで行われます。リソースベースの認証は、Access Manager の機能で、ユーザーはデフォルトの認証モジュールではなく、そのリソースを保護している認証モジュールから認証される必要があります。この機能は、ユーザーが初めて認証される時にのみ適用可能です。

注 –

これは、「セッションのアップグレード」で説明しているリソースベースの認証とは別の機能です。その機能には何の制限もありません。

制限

リソースベースの認証には、次のような制限があります。

リソースに適用可能なポリシーに認証モジュールが複数個含まれていた場合、そのどちらかの認証モジュールがシステムによって自動的に選択されます。
このポリシーについて定義できる条件はレベルと方式だけです。
この機能は、異なる DNS ドメイン間では働きません。

リソースベースの認証を設定する

Access Manager とポリシーエージェントをインストールしたら、リソースベースの認証を設定できます。そのためには、Access Manager が Gateway サーブレットを指す必要があります。

手順

AMAgent.properties を開きます。

AMAgent.properties は Solaris 環境では /etc/opt/SUNWam/agents/config/ にあります。

次の行をコメントアウトします。

#com.sun.am.policy.am.loginURL = http://Access Manager_server_host.domain_name:port/amserver/UI/Login.

ファイルに次の行を追加します。

com.sun.am.policy.am.loginURL = http://AccessManager_host.domain_name:port/amserver/gateway

注 –
ゲートウェイサーブレットは Policy Evaluation API を使って開発します。このサーブレットを使えば、リソースベースの認証を実現するためのカスタムメカニズムを記述できます。『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』の第 6 章「Using the Policy APIs」を参照してください。

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

第 9 章対象の管理

「対象」インタフェースにより、レルム内部で基本的なアイデンティティー管理を行うことができます。「対象」インタフェースで作成するすべてのアイデンティティーは、Access Manager アイデンティティー対象タイプを使って作成されるポリシーに対する対象定義で使用できます。

作成および変更できるアイデンティティーには、次のものがあります。

ユーザー

ユーザーは、個人のアイデンティティーを表現します。グループ内でユーザーを作成および削除できます。また、ロールやグループにユーザーを追加したり、ロールやグループからユーザーを削除することができます。サービスをユーザーに割り当てることもできます。

ユーザーを作成または変更する

手順

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

「新規」をクリックします。

次のフィールドのデータを入力します。

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

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

「姓」: このフィールドはユーザーの姓 (ラストネーム) を取得します。

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

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

「パスワード (確認)」: 確認のためにパスワードを再入力します。

「ユーザー状態」: このオプションは、Access Manager による認証をユーザーに許可するかどうかを指定します。

「作成」をクリックします。

ユーザーの作成後は、ユーザーの名前をクリックすることによってユーザー情報を編集できます。ユーザー属性の詳細については、「ユーザー属性」を参照してください。実行できるその他の変更には、次のものがあります。

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

手順

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

「ロール」または「グループ」を選択します。ユーザーにすでに割り当てられているロールおよびグループだけが表示されます。

「利用可能」リストからロールまたはグループを選択して「追加」をクリックします。

ロールまたはグループが「選択」リストに表示されたら、「保存」をクリックします。

サービスをアイデンティティーに追加する

手順

サービスを追加するアイデンティティーを選択します。

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

「追加」をクリックします。

選択したアイデンティティータイプに応じて、次のサービスのリストが表示されます。
- 認証設定
- ディスカバリサービス
- Liberty 個人プロファイルサービス
- セッション
- ユーザー

追加するサービスを選択して「次へ」をクリックします。

サービスの属性を編集します。サービスの説明を見るには、ステップ 4 でサービス名をクリックします。

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

エージェント

Access Manager ポリシーエージェントは、Web サーバーおよび Web プロキシサーバー上のコンテンツを未承認の不正侵入から保護します。エージェントは、管理者によって設定されたポリシーに基づいて、サービスおよび Web リソースへのアクセスを制御します。

エージェントオブジェクトは、ポリシーエージェントプロファイルを定義します。また、Access Manager リソースを保護している特定のエージェントの認証情報やその他のプロファイル情報を Access Manager で保存できるようにします。管理者は Access Manager コンソールから、エージェントプロファイルを参照、作成、変更、および削除できます。

エージェントオブジェクト作成ページは、エージェントが Access Manager の認証を受ける UID およびパスワードを定義できる場所です。同一の Access Manager を使用して複数の AM/WS を設定した場合は、これにより、異なるエージェントに対して複数の ID を有効にすることができ、Access Manager から独立してそれらの ID を有効にしたり無効にしたりできます。また、マシンごとに AMAgent.properties を編集するのではなく、エージェントの設定値によっては集中的に管理することもできます。

エージェントを作成または変更する

手順

「エージェント」タブをクリックします。

「新規」をクリックします。

次のフィールドの値を入力します。

「名前」: エージェントの名前またはアイデンティティーを入力します。これは、エージェントが Access Manager にログインするために使用する名前です。1 バイト文字による名前のみ受け付けます。

「パスワード」: エージェントのパスワードを入力します。このパスワードは、LDAP 認証時にエージェントが使用するパスワードとは異なっている必要があります。

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

「デバイスの状態」: エージェントのデバイスの状態を入力します。「アクティブ」に設定すると、エージェントで Access Manager に対する認証の実行および Access Manager との通信が可能になります。「非アクティブ」に設定すると、エージェントは Access Manager に対して認証を実行できなくなります。

「作成」をクリックします。

エージェントを作成したあとで、さらに次のフィールドを編集できます。

「説明」: エージェントの簡単な説明を入力します。たとえば、エージェントのインスタンス名や、エージェントが保護しているアプリケーションの名前を入力できます。

「エージェントキー値」: キーと値のペアでエージェントのプロパティーを設定します。このプロパティーは、ユーザーに関する資格表明の要求をエージェントから受け付けるために Access Manager によって使用されます。現時点では 1 つのプロパティーだけが有効であり、その他のプロパティーはすべて無視されます。次の形式を使用します。

agentRootURL=http:// server_name:port/

一意のポリシーエージェントアイデンティティーの作成

デフォルトでは、信頼できる環境で複数のポリシーエージェントを作成するときは、ポリシーエージェントに同一の UID およびパスワードが含まれます。UID およびパスワードが共有されるため、Access Manager はエージェントを区別できません。そのため、セッション Cookie が横取りされる可能性があります。

この弱点は、認証、承認、およびユーザーに関するプロファイル情報がアイデンティティープロバイダによって、サードパーティーまたは企業内の未承認のグループによって開発されたアプリケーションまたはサービスプロバイダに提供される場合に存在するようになることがあります。考えられるセキュリティー上の問題を次に示します。

すべてのアプリケーションは同一の HTTP セッション Cookie を共有します。このため、不正なアプリケーションがセッション Cookie をハイジャックし、そのユーザーが偽装によって別のアプリケーションにアクセスできるようになります。
アプリケーションが HTTPS プロトコルを使用していない場合、セッション Cookie はネットワーク盗聴される傾向があります。
1 つでもアプリケーションがハッキングされる可能性がある場合、インフラストラクチャー全体のセキュリティーが危険にさらされます。
不正なアプリケーションは、セッション Cookie を使用してユーザーのプロファイル属性を取得することができ、変更することも考えられます。ユーザーが管理権限を持っている場合、そのアプリケーションはさらに多くの損害を与える可能性があります。

一意のポリシーエージェントアイデンティティーを作成する

手順

Access Manager 管理コンソールを使用して、エージェントごとにエントリを作成します。

エージェントの作成時に入力したパスワードに次のコマンドを実行します。このコマンドは、エージェントがインストールされているホストで起動してください。

AccessManager-base/SUNWam/agents/bin/crypt_util agent123

次の出力が得られます。

WnmKUCg/y3l404ivWY6HPQ==

新しい値を反映するように AMAgent.properties を変更し、エージェントを再起動します。例:

# The username and password to use for the Application 
authentication module.

com.sun.am.policy.am.username = agent123
com.sun.am.policy.am.password = WnmKUCg/y3l404ivWY6HPQ==

# Cross-Domain Single Sign On URL
# Is CDSSO enabled.
com.sun.am.policy.agents.cdsso-enabled=true

# This is the URL the user will be redirected to after successful login
# in a CDSSO Scenario.
com.sun.am.policy.agents.cdcservletURL = http://server.example.com:port
/amserver/cdcservlet

新しい値を反映するように、Access Manager がインストールされている AMConfig.properties を変更し、Access Manager を再起動します。例:

com.sun.identity.enableUniqueSSOTokenCookie=true
com.sun.identity.authentication.uniqueCookieName=sunIdentityServerAuthNServer
 
com.sun.identity.authentication.uniqueCookieDomain=.example.com

Access Manager コンソールで、「設定」、「プラットフォーム」の順に選択します。

「Cookie ドメイン」リストで、次のように Cookie ドメイン名を変更します。
1. デフォルトの iplanet.com ドメインを選択し、「消去」をクリックします。
2. Access Manager インストールのホスト名を入力し、「追加」をクリックします。
  
  例: server.example.com
  
  次に示すように 2 つの Cookie がブラウザに設定されます。
  - iPlanetDirectoryPro – server.example.com (ホスト名)
  - sunIdentityServerAuthNServer – example.com (ホスト名)

フィルタロール

フィルタロールは、LDAP フィルタを使用して作成される動的なロールです。ユーザーはすべてフィルタを通してまとめられ、ロールの作成時にそのロールに割り当てられます。フィルタはエントリの属性と値のペア (ca=user* など) を検索して、その属性を含むユーザーをロールに自動的に割り当てます。

フィルタロールを作成する

手順

ナビゲーション区画で、ロールを作成する組織に移動します。

「新規」をクリックします。

フィルタロールの名前を入力します。

検索条件を入力します。

例を示します。
(&(uid=user1)(|(inetuserstatus=active)(!(inetuserstatus=*))))
フィルタを空白のままにすると、次のロールが作成されます。
(objectclass = inetorgperson)

「作成」をクリックして、フィルタ条件に基づく検索を開始します。フィルタ条件によって定義されたアイデンティティーは、ロールに自動的に割り当てられます。

フィルタロールが作成されたら、ロールの名前をクリックして、そのロールに属するユーザーを表示します。「サービス」タブをクリックして、ロールにサービスを追加することもできます。

ロール

ロールのメンバーは、ロールを所有する LDAP エントリです。ロール自体の基準は、属性を持つ LDAP エントリとして定義されます。このエントリは、エントリの識別名 (DN) 属性で特定されます。ロールが作成されたら、サービスとユーザーを手動で追加できます。

ロールを作成または変更する

手順

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

「ロール」リストで「新規」をクリックします。

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

「作成」をクリックします。

ユーザーをロールまたはグループに追加する

手順

ユーザーを追加するロールまたはグループの名前をクリックします。

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

追加するユーザーを「利用可能」リストから選択して「追加」をクリックします。

ユーザーが「選択」リストに表示されたら、「保存」をクリックします。

グループ

グループは、共通の職務、特徴、または興味を持つユーザーの集合を表現します。通常、このグループ分けに権限は関連付けられません。グループは組織の内部とほかの管理対象グループの内部の 2 つのレベルで定義できます。

グループを作成または変更する

手順

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

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

グループの名前を入力します。

「作成」をクリックします。

グループを作成したら、グループ名、「ユーザー」タブの順にクリックして、ユーザーをグループに追加できます。

パート II アクセス制御

第 4 章 Access Manager コンソール

管理ビュー

レルムモードのコンソール

図 4–1 レルムモードの管理ビュー

旧バージョンモードのコンソール

図 4–2 旧バージョンモードの管理ビュー

旧バージョンモード 6.3 コンソール

図 4–3 6.3 ベースのコンソールの管理ビュー

ユーザープロファイルビュー

図 4–4 ユーザープロファイルビュー

第 5 章 レルムの管理

レルムの作成と管理

新しいレルムを作成する

手順

一般プロパティー

認証

サービス

サービスをレルムに追加する

手順

権限

第 6 章 データストア

LDAPv3 データストア

新しい LDAPv3 データストアを作成する

手順

LDAPv3 リポジトリプラグインの属性

プライマリ LDAP サーバー

LDAP バインド DN

LDAP バインドパスワード

LDAP バインドパスワード (確認)

LDAP 組織 DN

LDAP SSL を有効

LDAP 接続プールの最小サイズ

LDAP 接続プールの最大サイズ

検索で返される結果の最大数

検索タイムアウト

LDAP の従う参照

LDAPv3 リポジトリプラグインクラス名

属性名マッピング

LDAPv3 プラグインでサポートされるタイプおよび操作

LDAP ユーザー検索属性

LDAP ユーザー検索フィルタ

LDAP ユーザーオブジェクトクラス

LDAP ユーザー属性

LDAP グループ検索属性

LDAP グループ検索フィルタ

LDAP グループコンテナネーミング属性

LDAP グループコンテナ値

LDAP グループオブジェクトクラス

LDAP グループ属性

グループメンバーシップの属性名

グループメンバーの属性名

グループメンバー URL の属性名

LDAP ピープルコンテナネーミング属性

LDAP ピープルコンテナ値

LDAP エージェント検索属性

LDAP エージェントコンテナネーミング属性

LDAP エージェントコンテナ値

LDAP エージェント検索フィルタ

LDAP エージェントオブジェクトクラス

LDAP エージェント属性

持続検索ベース DN

再起動前の持続検索の最大アイドル時間

エラーコードのあとの再試行の最大数

再試行の間の遅延時間

再試行する LDAPException エラーコード

AMSDK リポジトリプラグイン

新しい AMSDK リポジトリプラグインを作成する

手順

第 7 章 認証の管理

認証の設定

認証モジュールタイプ

コア

Active Directory

匿名 (anonymous)

証明書

HTTP 基本

JDBC

LDAP

メンバーシップ

第 5 章レルムの管理

第 6 章データストア

第 7 章認証の管理