| Oracle® Fusion Middleware Oracle Access Manager管理者ガイド 11g リリース1（11.1.1） B62265-01 |
|
 戻る |
 次へ |
共有ポリシー・コンポーネントをOAMポリシーで使用できます。この章では、管理者によるポリシー・コンポーネントの管理方法について説明します。
この章の内容は次のとおりです。
OAM管理コンソールおよび少なくとも1つのOAMサーバーをインストールして、WebLogic Serverドメイン内で実行する必要があります。
この章のアクティビティを実行する前に、次の内容を確認することをお薦めします。
ポリシー・モデルおよびコンポーネントの詳細は、「OAM 11gポリシー・モデルの概要」を参照してください。
現在のポリシー・モデルと他のモデルの比較を確認するには、「OAM 11gポリシー・モデルとOAM 10gの比較」を参照してください。
管理コンソールおよびコントロールの詳細は、第2章「OAM管理およびナビゲーションの開始」を参照してください。
この項では、Oracle Access Manager 11gポリシー・モデルおよびそのグローバル・コンポーネントを説明します。
Oracle Access Manager 11gポリシー・モデルは、OAMアプリケーション・ドメインのコンテキスト内で認証および認可サービスを提供します。ポリシー・モデルは、全体のシステム構成の一部である外部ユーザー・アイデンティティ・ストアおよび認証モジュールに基づいています。
|
注意: 以前のリリースのOracle Access Managerでは、OAMポリシー・ドメインのコンテキスト内で認証および認可サービスを提供していました。OracleAS SSO 10gは認証のみ提供します。 |
図8-1は、Oracle Access Manager 11gのポリシー・モデル内の異なる要素を示しています。Oracle Access Manager 11gポリシー・モデルの最上位レベルの構造は、OAMアプリケーション・ドメインです。詳細は、図を参照してください。
ポリシー・コンポーネント: アプリケーション・ドメインで使用できるグローバル認証スキーム、リソース・タイプおよびホスト識別子。ポリシー・コンポーネントの管理については、この章全体で説明します。
アプリケーション・ドメイン: リソース（または一連のリソース）および特定のリソースにアクセス可能なユーザーを指示する関連付けられた認証および認可ポリシーの論理コンテナ。アプリケーション・ドメインのサイズおよび数は、管理者に依存します。詳細は、第9章「リソースを保護してSSOを有効化するポリシーの管理」を参照してください。
この項の内容は次のとおりです。
リソースをアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択して、特定のURLを入力する必要があります。HTTPタイプ・リソースには、ホスト識別子を含めます。HTTP以外のリソース・タイプには、タイプ名を使用します。
デフォルトのリソース・タイプのHTTPは、HTTPおよびHTTPSプロトコルと一緒に使用されます。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、作成されてリソースに適用されたポリシーがすべての操作に適用されます。
HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加する必要があります。
管理者は、HTTP以外のリソースのリソース・タイプを定義できます。HTTP以外のリソース・タイプに関連付けられたホスト識別子はありません。HTTP以外のリソースをアプリケーション・ドメインに追加する場合、管理者はタイプ名をポインタとして「リソースURL」フィールドに入力する必要があります。名前とホスト識別子は一致しません。これは、相対的なHTTP URLではありません。
たとえば、wl_authenというHTTP以外のリソース・タイプをWebLogicコンテナでデプロイされたリソースとともに使用できます。wl_authenリソース・タイプには、カスタム・アクセス・ゲートが必要です。Oracle WebLogic ServerのURLを使用して、保護されたリソースにアクセスします。
OAM管理コンソールでは、図8-2に示すように、「ポリシー構成」タブでリソース・タイプが他のコンポーネントとともに編成されます。左側のナビゲーション・ツリーは、インターネット・プロトコルのHTTPおよびWebLogicコンテナにデプロイされたリソースのwl_authenの2つのデフォルトのリソース・タイプを示しています。
HTTPリソース・タイプは、Oracle Access Manager 11gで保護されたWebアプリケーションに使用されます。
wl_authenリソース・タイプは、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドで示すように、Oracle Access Manager 11gおよび次のOAM認証プロバイダ構成のいずれかと組み合せたFusion Middlewareアプリケーション・シナリオで使用されます。
オーセンティケータ
Oracle Web Services Managerを使用するアイデンティティ・アサータ
表8-1は、リソース・タイプ定義の要素を示しています。
表8-1 リソース・タイプの定義
| 要素 | 説明 |
|---|---|
|
名前 |
必須。最大30文字の英数字の一意の名前。 注意: HTTP以外のリソース・タイプ名とホスト識別子は一致しません。 |
|
説明 |
オプション。このフィールドを使用して、このリソース・タイプの目的を最大200文字の英数字で説明します。 たとえば、WebLogic認証スキームを表すリソースなどです。 |
次に、リソース・タイプの作成、変更および削除方法を説明します。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して、「リソース・タイプおよびその使用について」に示すようにHTTP以外のリソースの新しいリソース・タイプ定義を作成できます。
この場合、リソース・タイプに関連付けられたホスト識別子はありません。かわりに、名前をフィールドに入力する必要があります。HTTP以外の名前のリソース・タイプは、HTTP以外とみなされます。
HTTP以外のリソース・タイプを作成するには、次の手順を実行します。
「ポリシー構成」タブ、ナビゲーション・ツリー、「共有コンポーネント」ノードから、「リソース・タイプ」をクリックし、ツールバーの「作成」コマンド・ボタンをクリックします。
リソース・タイプ・ページのフィールドに入力して、この新しいタイプを識別します。
名前
説明（オプション）
「適用」をクリックして新しいリソース・タイプを送信します（または変更を適用しないでページを閉じます）。
確認ウィンドウを閉じます。
リソース・タイプ・ページを閉じます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してHTTP以外のリソース・タイプを検索できます。
リソース・タイプを検索するには、次の手順を実行します。
「ポリシー構成」タブをアクティブ化します。
検索タイプ・リストから「リソース・タイプ」を選択して、検索を定義します。
テキスト・フィールドで、検索するインスタンスの正確な名前を入力します。次に例を示します。
my_resource_type
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してHTTP以外のリソース・タイプのみを削除できます。アプリケーション・ドメインのリソースで使用されているリソース・タイプを削除しようとすると、検証エラーが発生します。
前提条件
アプリケーション・ドメインの各リソースには、割り当てられたタイプがあります。割り当てられたリソース・タイプを削除する場合、そのリソース・タイプを使用するアプリケーション・ドメインのリソース定義を最初に変更する必要があります。
|
注意: デフォルトのリソース・タイプのHTTPおよびwl_authenは削除できません。 |
リソース・タイプを削除するには、次の手順を実行します。
「ポリシー構成」タブ、「共有コンポーネント」ノードから、リソース・タイプの名前をダブルクリックして定義を確認し、ページを閉じます。
ナビゲーション・ツリーの名前をクリックし、ツールバーの「削除」ボタンをクリックして、確認ウィンドウで削除を確認します。
リソース・タイプが削除されていることを確認します。
この項では、ホスト識別子とその使用方法およびホスト識別子の作成、変更または削除方法を説明します。次に内容を示します。
ポリシーは、コンピュータ・ホストのリソースを保護します。Oracle Access Manager内で、ホスト識別子を使用してコンピュータ・ホストを個別に指定します。
定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。
登録されたエージェントは、ポリシーで使用されるホスト識別子に定義されたアドレス指定方法と一致するすべてのリクエストを保護します。リストのアドレスに送信されたリクエストが公式のホスト名にマップされるので、OAMはリソースを保護するポリシーを適用できます。
OAM管理コンソールまたはリモート登録ツールでエージェント（およびアプリケーション）が登録されると、ホスト識別子が自動的に作成されます。アプリケーションおよびリソースがマップされたホスト識別子のないホストに存在する場合、管理者はホスト識別子を手動で追加できます。また、管理者は、新しいホスト名バリエーションに追加するために既存のホスト識別子を変更できます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加するには、新しいホスト名バリエーションが必要です。
詳細は、次の項を参照してください。
設計時に、特定のアプリケーション・ドメインに属するリソースを定義する場合、ホスト識別子を使用できます。リソースのホスト識別子（HTTP）またはタイプ（HTTP以外）を使用して、リソースをスコープします。この組合せにより、Oracle Access Managerで一意に識別されます。
|
注意: 各リソースは、すべてのアプリケーション・ドメインで一意である必要があります。各リソースおよびホスト識別子の組合せは、すべてのアプリケーション・ドメインで一意である必要があります。 |
実行時の使用方法
実行時に、OAMエージェントからのアクセス問合せのWebサーバー・ホスト情報がホスト識別子にマップされ、ユーザーがアクセスしているリソースに関連付けられます。OAMエージェントは、次のいずれかの方法でWebサーバー・ホスト情報を取得します。
仮想Webホスト・サポートに優先ホスト・パラメータが構成されている場合（「仮想Webホストについて」を参照してください）、指定されたリクエストのWebサーバー・ホスト情報がWebサーバーから取得されます。
優先ホスト・パラメータで直接Webサーバー・ホスト情報を指定する場合、Webサーバー固有のホスト情報と関係なく常に使用されます。
これにより、Webサーバーの現在のデプロイメントと一致するホスト名ではなくホスト識別子の論理ホスト名でリソースを指定できます。
aseng-wikiにアクセスするユーザーは、次の内容を入力します。
http://aseng-wiki.us.oracle.com/mywikipage
この「mywikipage」はリソースURLで、「aseng-wiki.us.oracle.com」はホストです。このホストおよびポート（ポートは80）を照合して、ホスト識別子を示します。
優先ホスト
通常、OAMエージェントの優先ホスト文字列を設定して、Webサーバー・ホスト情報を取得します。エージェントが複数の仮想ホストをアクティブに保護する場合、この文字列をserver_nameに設定して、実際のリクエスト・ホスト名がWebサーバーのリクエスト・オブジェクトから正しく選択されていることを確認します。詳細は、「仮想Webホストについて」を参照してください。
ホストの認証および認証スキームのチャレンジ・リダイレクト
ユーザーが保護されたリソースURLにアクセスしようとすると、認証スキームの「チャレンジ・リダイレクト」フィールドに指定されたサーバーにリダイレクトします。認証チャレンジを別のホストで処理する場合、そのホストの名前を定義して、「ホスト識別子」リストで使用可能にする必要があります。たとえば、ユーザーが認証用のSSL対応サーバーにリダイレクトすると、ホスト識別子としてそのサーバーを定義する必要があります。
|
注意: 認証スキームの「チャレンジ・リダイレクト」フィールドにホスト名を入力する場合、ホスト識別子として定義する必要があります。 |
各ホスト識別子を定義して、1つ以上のWebサーバー・ホストを表すことができます。ホスト識別子のいくつかの重要なガイドラインは、次のとおりです。
各ホスト名を一意にする必要があります。
各ホスト名:ポート・ペアを一意にする必要があります。
各ホスト名:ポート・ペアは、1つのホスト識別子にのみ属する必要があります。
各ホスト名:ポート・ペアは、エンド・ユーザーのエントリと完全に一致する必要があります。
ホスト識別子名とHTTP以外のリソース・タイプ名は一致しません。
各リソースおよびホスト識別子の組合せをすべてのアプリケーション・ドメインで一意にする必要があります。
詳細は、「ホスト識別子のバリエーション」を参照してください。
すべての使用可能なホスト名バリエーションを定義してWebサーバー・ホストのアイデンティティを簡易化するには、ホスト識別子を使用します。ホスト識別子は、すべてのURLアドレス指定方法のリストで構成されます。Oracle Access Managerで保護する各Webサイトまたは仮想Webサイトにホスト識別子を構成する必要があります。
コンピュータ名やIPアドレスの入力などの様々な方法で、Oracle Access ManagerへのWebサーバー・ホストを識別できます。次に、同じホストのアドレス指定方法の例を示します。
site.com
site.com:80
www.site.com
www.site.com:80
216.200.159.58
216.200.159.58:80
仮想ホストは、複数のNICカード（IPベース）または複数の名前（同じIPを解決するabc.comやdef.comなど）に基づいて使用される複数のサイトが同じホストに存在する状況を示します。
次に示すように、OAMサーバーのリバース・プロキシとして動作するOHSサーバーに構成される2つの仮想ホストが存在するユースケースを検討します。
1つの仮想ホストが双方向SSLモードで構成されています。
1つの仮想ホストが非SSLモードで構成されています。
異なる認証スキームで保護される2つのリソースとアプリケーション・ドメインがあると仮定します。
/resource1は、チャレンジURL（資格証明コレクションURLを定義するため）のhttps://sslvhost:port/を使用するX509Schemeで保護されます。
ユーザーが/resource1にアクセスすると、認証用のSSLポートのOHSサーバーにリダイレクトされ、X.509証明書を求められます。
/resource2は、チャレンジ・リダイレクトのhttp://host:port/を使用する2番目の仮想ホストのLDAPSchemeで保護されます。
ユーザーが/resource2にアクセスすると、非SSLモード（または必要に応じて一方向SSLモード）の2番目の仮想ホストにリダイレクトされます。LDAP認証のログイン・フォームが表示されます。
|
注意: 10g mod_ossoを使用したX.509およびフォーム認証がデプロイメントでサポートされます。ただし、1つのSSOサーバーにのみ、mod_ossoを構成できます。この場合、エージェントは、非SSL仮想ホストのOracle Access Managerにリダイレクトします。資格証明コレクタは、リソースの認証スキームのチャレンジURLパラメータを確認し、X509認証のHTTPS仮想ホストにリダイレクトします。 |
仮想Webホストをサポートするには、次に示すようにOAMエージェント登録の優先HTTPホスト・フィールドに特定の値を指定する必要があります。次に、仮想サーバーの構成をまとめます。
Apacheベースのサーバー以外のほとんどのWebサーバーの仮想ホストをサポートするには、優先HTTPホスト値をHOST_HTTP_HEADERに設定する必要があります。
この値を指定すると、ユーザーのブラウザがリクエストを送信する場合にWebGateが優先HTTPホストの値をリクエストのホスト値に設定します。たとえば、ユーザーがURLにmyweb2という文字列を入力するとします。
http://myweb2
WebサーバーのWebサイトのいずれかにmyweb2というホストが存在する場合、リクエストが一致する仮想サイトで使用されます。
Apache、Apache 2、IBM HTTP Server、Oracle HTTP ServerなどのApacheベースのサーバーでは、優先HTTPホスト値をSERVER_NAMEに設定する必要があります。
|
注意: SERVER_NAME値は、Apacheベースのサーバー以外のホストでサポートされません。この値をApacheベース以外のサーバーに設定すると、ユーザーはそのWebサーバーのWebGateで保護されるリソースにアクセスできません。かわりに、ユーザーはWebGate構成が正しくないことを示すエラーを受け取ります。hostNameとともに「ServerName」ディレクティブを明示的に7777に設定する必要があります。これは、「Listen」ディレクティブが正しく設定されているかどうかに関係しません。サーバーは、自身を識別するためにこの値を明示的に必要とすることがあります。ほとんどの場合、自動的に自身を識別できます。 |
OAM管理コンソールまたはリモート登録ツールでエージェント（およびアプリケーション）が登録されると、ホスト識別子が自動的に作成されます。エージェントに登録されるアプリケーション・ドメインでは、ホスト識別子が自動的に使用されます。
管理者はコンソールを使用して、ホスト識別子を作成および管理できます。OAM管理コンソール内で、ホスト識別子は、「ポリシー構成」タブのナビゲーション・ツリーの「共有コンポーネント」に編成されます。管理者は、新しいホスト識別子定義の手動の作成、定義の変更、定義の削除またはテンプレートとして使用する既存の定義のコピーを実行できます。コピーの名前は、元の定義名に基づきます。たとえば、host3という定義をコピーする場合、コピー名はcopy of host3になります。
図8-3は、管理コンソールの通常のホスト識別子構成ページを示しています。ここでは、ホストの正規の名前およびユーザーが同じホストを表現できる他のすべての名前を入力します。
|
注意: 各ホスト識別子を一意にする必要があります。同じホスト名およびポートは他のホスト識別子定義で使用できません。 |
表8-2は、ホスト識別子の定義を示しています。
表8-2 ホスト識別子の定義
| プロパティ | 説明 |
|---|---|
|
名前 |
この定義の一意の名前。大文字および小文字の英字のみ使用します。句読点および特殊文字は使用できません。 |
|
説明 |
この構成の使用を示す200文字までのオプションの説明。 |
|
操作 |
|
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を作成できます。マップされているホスト識別子がないホストにアプリケーションおよびリソースを手動で追加した場合に必要になります。
|
注意: テンプレートとして使用する既存の定義をコピーする場合、コピーのすべての一意の識別子を変更する必要があります。 |
「ポリシー構成」タブのナビゲーション・ツリーから「共有コンポーネント」を拡張します。
「ホスト識別子」をクリックし、ツールバーの「作成」コマンド・ボタンをクリックします。
または、「ホスト識別子」ノードを拡張して、テンプレートとして使用する定義の名前をダブルクリックし、「複製」ボタンをクリックしてcopyofnameという名前のコピーを作成します。
ホスト識別子ページで、次の内容を入力します。
名前
説明
操作: 「操作」リストのホスト名およびポート・バリエーションを追加（または削除）します。
追加: プラス記号（+）をクリックして、新しいホスト名およびポートの組合せを入力します。
削除: ホスト名をクリックし、「削除」ボタンをクリックして削除します。
必要に応じて手順3cを繰り返して、ユーザーがアクセスできるこのホストのすべてのバリエーションを識別します。
「適用」をクリックして新しい定義を送信します（または変更を適用しないでページを閉じます）。
確認ウィンドウを閉じて、新しい定義がナビゲーション・ツリーにリストされていることを確認します。
有効なOAM管理者の資格証明を持つユーザーは、次のタスクを実行して特定のホスト識別子を検索できます。
「ポリシー構成」タブをアクティブ化します。
検索タイプ・リストから「ホスト識別子」を選択して、検索を定義します。
テキスト・フィールドで、検索するインスタンスの正確な名前を入力します。次に例を示します。
my_host_identifier
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を変更できます。これには、個々のホスト識別子の定義の追加、変更または削除が含まれます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加する場合、既存のホスト識別子定義を変更して新しいホスト名バリエーションを追加する必要がある場合があります。
前提条件: ホスト識別子を参照するインベントリ・アプリケーション・ドメイン
|
注意: 設定の参照後、ページを閉じるか、必要に応じて設定を変更できます。 |
ホスト識別子を表示または変更するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。
「共有コンポーネント」ノード
「ホスト識別子」ノード
目的の定義名をダブルクリックします。
ホスト識別子ページを表示し、必要に応じて情報を変更します（表8-2を参照してください）。
名前
説明
操作: 「操作」リストのホスト名およびポート・バリエーションを追加または削除します。
プラス記号（+）をクリックして、新しいホスト名およびポートの組合せを追加します。
既存のホスト名をクリックし、「削除」ボタンをクリックして削除します。
必要に応じて手順3cを繰り返して、バリエーションを追加または削除します。
「適用」をクリックして変更を送信します（または変更を適用しないでページを閉じます）。
確認ウィンドウを閉じて、終了する場合はページを閉じます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の全体の定義を削除できます。リソースで使用されているホスト識別子を削除しようとすると、検証エラーが発生します。
前提条件
アプリケーション・ドメインの各リソースは、特定のホスト識別子に関連付けられます。ホスト識別子を削除する場合、ホスト識別子を使用するアプリケーション・ドメインのリソース定義を最初に変更する必要があります。
「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。
「共有コンポーネント」ノード
「ホスト識別子」ノード
オプション: リストで、目的の名前をダブルクリックして定義を表示し、ページを閉じます。
ナビゲーション・ツリーで、目的の定義名をクリックします。
ツールバーの「削除」ボタンをクリックして、確認ウィンドウで削除を確認します。
ナビゲーション・ツリーを確認して、定義が削除されたことを確認します。
Oracle Access Manager 11gでは、各認証スキームに認証モジュールが必要です。この項では、用意されている事前構成済認証モジュールおよび管理者によるカスタム・モジュールの定義方法を説明します。内容は次のとおりです。
Oracle Access Manager管理コンソールでは、「システム構成」タブで事前構成済認証モジュールが他のシステムレベル・コンポーネントとともに編成されます。
次の事前構成済認証モジュール・タイプのみが認証スキームで許可されます。ただし、既存のタイプの新しいモジュールを作成して認証スキームで使用できます。詳細は、次の項を参照してください。
事前構成済Kerberos認証モジュールを図8-4に示します。詳細は、図を参照してください。
表8-3は、Kerberos認証モジュールの定義を示しています。既存の事前構成済Kerberos認証モジュールを使用するか、独自のモジュールを作成できます。
表8-3 Kerberos認証モジュールの定義
| 要素 | 説明 |
|---|---|
|
名前 |
大文字および小文字の英字、数値および空白を使用できるこのモジュールの一意のID。 |
|
キー・タブ・ファイル |
キー配布センター（KDC）の認証に必要となる、ホストのキーの暗号化されたローカルのディスク上のコピーへのパス。たとえば、/etc/krb5.keytabなどです。 KDCは、リクエストしているユーザーを認証し、ユーザーにリクエストされたサービスのアクセスが認可されていることを確認します。認証されたユーザーがすべての所定の条件を満たしている場合、KDCはサーバー・キーに基づくアクセスを許可するチケットを発行します。クライアントはチケットを受け取り、適切なサーバーに送信します。サーバーは、送信されたチケットを確認し、送信したユーザーにアクセス権を付与できます。 キー・タブ・ファイルは、ルートでのみ読取り可能にし、マシンのローカル・ディスクにのみ存在する必要があります。バックアップ・データのアクセスがマシンのルート・パスワード自体のアクセスと同じように厳重に保護されていないかぎり、バックアップの一部として使用しないようにする必要があります。 |
|
プリンシパル |
ホストのキータブの生成を有効化するKerberosデータベースのプリンシパルのHTTPホストを識別します。 |
|
KRB構成ファイル |
Kerberosインストールの特定の側面を制御する構成ファイルのパスを識別します。krb5.confファイルは、Kerberosを実行している各UNIXコードの/etcディレクトリに存在する必要があります。 krb5.confには、Kerberos V5ライブラリに必要な構成情報が含まれます（デフォルトのKerberosレルムおよび既知のレルムのKerberosキー配布センターの場所）。 |
事前構成済LDAP認証モジュールを図8-4に示します。詳細は、図を参照してください。
表8-4は、LDAP認証モジュールの要素を示しています。同じ要素がLDAPNoPasswordAuthnModuleでも使用されます。
Oracle Access Managerは、デフォルトとして事前定義済X509認証モジュールを用意しています。管理者は、新しいX509認証モジュールも作成できます。暗号化の表現のX.509は、シングル・サインオン（SSO）に使用されるデジタル公開鍵証明書の標準です。X.509では、特に公開鍵証明書、証明書失効リストおよび属性証明書の標準形式を指定します。
X.509デジタル証明書を使用すると、証明書を発行する認証局（CA）の厳密な階層システムを取得できます。X.509システムで、CAは、特定の識別名または電子メール・アドレスやDNSエントリなどの代替名に公開鍵をバインドする証明書を発行します。
企業のPKIシステムで使用できるように、企業の信頼されたルート証明書をすべての従業員に配布できます。SSL証明書をすぐに使用できるように、特定のWebブラウザは、事前インストールされたルート証明書を用意しています。
Oracle Access Managerは、オンライン証明書ステータス・プロトコル（OCSP）インターネット・プロトコルを使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスします。OCSPは、X.509デジタル証明書の失効ステータスの取得に使用されます。OCSPは、証明書ステータスを含むサーバーおよびそのステータスを通知されるクライアント・アプリケーション間で使用される通信構文を指定します。
ユーザーがサーバーにアクセスしようとすると、OCSPは証明書ステータス情報のリクエストを送信します。OCSPは、特定のネットワーク・ホストが特定の時間に特定の証明書を使用していたことをリクエスタに公開します。サーバーは、現在、期限切れまたは不明のレスポンスを戻します。OCSPは、期限が切れた証明書を使用するユーザーに更新前の指定された期間にサーバーにアクセスできる構成可能な猶予期間を与えます。
OCSPメッセージはASN.1で暗号化され、HTTPで一般的に転送されます。OCSPのリクエストおよびレスポンス特性では、OCSPサーバーを参照する場合に「OCSP応答者」という用語を使用します。Oracle Access Managerを使用する場合、OAM管理コンソールをホストするコンピュータはOCSP応答者です。
OCS応答者は、リクエストで指定された証明書が適正、失効または不明であることを示す署名されたレスポンスを戻すことができます。OCSPがリクエストを処理できない場合、エラー・コードを戻すことができます。
表8-5は、X509認証モジュールの要件を示しています。
表8-5 X509認証モジュールの定義
| 要素 | 説明 |
|---|---|
|
名前 |
一意の名前でこのモジュール定義を識別します。 |
|
一致するLDAP属性 |
使用されるLDAP識別名属性を定義します。たとえば、cnなどです。 |
|
X509証明書属性 |
公開鍵のバインドに使用される証明書属性を定義します。たとえば、SUBJECT.cnなどです。 |
|
証明書検証有効 |
X.509証明書の検証を有効化（選択されていない場合は無効化）します。 |
|
OCSP有効 |
オンライン証明書ステータス・プロトコルを有効化（選択されていない場合は無効化）します。 注意: 「OCSP有効」を選択した場合のみ、OCSPサーバー別名、OCSP応答者URLおよびOCSP応答者タイムアウトが必要です。 |
|
OCSPサーバー別名 |
OSCSP応答者の別名--別名およびOSCSP応答者インスタンスの実際のインスタンス名またはIPアドレスのマッピング。 |
|
OCSP応答者URL |
オンライン証明書ステータス・プロトコル応答者のURLを入力します。 |
|
OCSP応答者タイムアウト |
証明書の更新前の限定された期間にOAMサーバーにアクセスできる期限が切れた証明書を使用するユーザーの猶予期間を指定します。 |
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して既存のタイプの新しい認証モジュールを作成できます。テンプレートとして使用する事前構成済モジュールは複製できません。
|
注意: テンプレートとして使用する事前構成済モジュールは複製できません。 |
新しい認証モジュールを作成するには、次の手順を実行します。
「システム構成」タブのナビゲーション・ツリーから「認証モジュール」ノードを拡張します。
ナビゲーション・ツリーから目的のモジュール・タイプをクリックします。
ツールバーの「作成」ボタンをクリックします。
新しい認証モジュールの詳細を追加します。
「適用」をクリックして新しい定義を送信し、確認ウィンドウを閉じます（または変更を適用しないでページを閉じます）。
ナビゲーション・ツリーでエントリを確認し、終了する場合はページを閉じます。
「認証スキームの作成」の手順に従って、認証モジュールを1つ以上の認証スキームに追加します。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を実行して管理コンソールで特定の認証モジュールを検索できます。
前提条件
認証モジュールをOracle Access Manager管理コンソールに登録する必要があります。
特定の認証モジュールを検索するには、次の手順を実行します。
「システム構成」タブをアクティブ化します。
検索タイプ・リストから、次のモジュール・タイプのいずれかを選択して検索を定義します。
LDAP認証モジュール
X509認証モジュール
Kerberos認証モジュール
テキスト・フィールドで、検索するインスタンスの正確な名前を入力します。次に例を示します。
my_authn_module
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証モジュールを変更できます。これには、既存のモジュール名の変更および他の属性の変更が含まれます。
前提条件
別の認証モジュールを使用するには、変更されるモジュールを参照する各認証スキームを変更します。
認証モジュールを表示または編集するには、次の手順を実行します。
このモジュールを参照する各認証スキームの別の認証モジュールに変更します。
「システム構成」タブのナビゲーション・ツリーから次の項目を拡張します。
「認証モジュール」ノード
モジュール・タイプ・ノードを拡張します。
目的のモジュール名をダブルクリックして、構成を表示します。
オプション: 表示の確認のみであれば、ページを閉じます。
認証モジュール・ページで、必要に応じて情報を変更します。
「適用」をクリックして変更を送信し、確認ウィンドウを閉じます（または変更を適用しないでページを閉じます）。
「認証スキームの作成」の手順に従って、更新された認証モジュールを認証スキームに追加します。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して認証モジュールを削除できます。
前提条件
このモジュールを参照する各認証スキームでは、別の認証モジュールを指定します。
認証モジュールを削除するには、次の手順を実行します。
このモジュールを参照する各認証スキームでは、別の認証モジュールを指定します。
「システム構成」タブのナビゲーション・ツリーから次の項目を拡張します。
「認証モジュール」ノード
モジュール・タイプ・ノードを拡張します。
オプション: モジュール名をダブルクリックして構成を表示し、ウィンドウを閉じます。
目的のモジュール名をクリックし、「削除」ボタンをクリックします。
削除を確認します（またはモジュールを保持する確認ウィンドウを閉じます）。
この項の内容は次のとおりです。
リソースまたはリソースのグループへのアクセスは、認証スキームという単一の認証プロセスで制御できます。認証スキームは、ユーザーの認証に必要なチャレンジ・メカニズムを定義する名前の付いたコンポーネントです。各認証スキームは、定義された認証モジュールも含む必要があります。
管理コンソールまたはリモート登録ツールを使用してパートナを登録する場合、作成されるアプリケーション・ドメインは、デフォルト・スキームとして設定される認証スキームを使用するポリシーでシードされます。ポリシー作成中に使用されるデフォルトとして、既存の認証スキームを選択できます。
新しい認証スキームの作成、テンプレートとして使用する既存の定義のコピー、定義の変更または定義の削除も実行できます。コピーには、元の名前に基づくデフォルト名を使用します。たとえば、KerbSchemeというスキームをコピーする場合、コピー名はcopyofKerbSchemeになります。
すべての認証スキームには、異なる値を使用した同じ要素が含まれます。図8-7は、例としてデフォルトのLDAPSchemeページを示しています。「認証スキーム」ナビゲーション・ツリーは、提供される他のデフォルト・スキームを示しています。
表8-6は、認証スキームのそれぞれの要素および値の情報を示しています。「デフォルトとして設定」ボタンを使用して、これをデフォルト・スキームにします。
表8-6 認証スキームの定義
| 要素 | 説明 |
|---|---|
|
名前 |
ナビゲーション・ツリーに表示されるこのスキームの一意の名前。 関連項目: 「事前構成済認証スキーム」 |
|
説明 |
このスキームの使用を示す200文字までのオプションの説明。 |
|
認証レベル |
認証スキームの信頼レベル。ユーザーからの資格証明のトランスポートの保護に使用されるチャレンジ・メソッドおよび信頼度が反映されます。 信頼レベルは、0（信頼なし）から99（最高の信頼レベル）の整数値で表現されます。 注意: 指定されたレベルのリソースにユーザーが認証された後、リソースが元のリソースと同等またはそれ以下の信頼レベルである場合に同じアプリケーション・ドメインまたは異なるアプリケーション・ドメインの他のリソースでユーザーが自動的に認証されます。 関連項目: 「マルチレベル認証について」 |
|
デフォルト |
「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックス。 |
|
チャレンジ・メソッド |
次の選択可能な項目から1つのチャレンジ・メソッドを選択する必要があります。
関連項目: 「チャレンジ・メソッドについて」 |
|
チャレンジ・リダイレクトURL |
処理するためにユーザー・リクエストを別のサーバーにリダイレクトする場合の「チャレンジ・リダイレクト」フィールドに指定されたサーバーのURL。 関連項目: 「ホスト識別子について」 |
|
認証モジュール |
ユーザーに資格証明を要求するために使用する事前構成済認証モジュール。
"デフォルト認証モジュール・ページについて」も参照してください。 |
|
フォーム、X509またはDAPチャレンジ・メソッドを使用したスキーム |
フォーム、X509またはDAPチャレンジ・メソッドを使用したスキームのみ、これらの追加要素が含まれます。他のスキームは、変更する必要がないデフォルトを使用します。 |
|
チャレンジURL |
資格証明コレクションのために資格証明コレクタがリダイレクトするURL。 フォーム・ベースの即時利用可能な認証スキーム（LDAPSchemeおよびLDAPNoPasswordValidationScheme）の場合、デフォルトのチャレンジURLは「/pages/login.jsp」です。最後のURLを作成するには、コンテキスト・タイプおよびコンテキスト値を使用します。 |
|
コンテキスト・タイプ |
次の使用可能な値に基づいて資格証明コレクタの最後のURLを作成するために使用されます。
|
|
コンテキスト値 |
資格証明コレクタの最後のURLを作成するために使用されます。デフォルト値は/oamです。 |
カスタム・ログイン・ページについて
フォーム、X509またはDAPチャレンジ・メソッドを使用したスキームのみ、表8-6の最後に示されている追加要素が含まれます。すべてのカスタム・ログイン・ページで次の要件を満たす必要があります。
カスタム・ログイン・ページには、2つのフォーム・フィールド（ユーザー名およびパスワード）が必要です。Oracle Access Managerは、2つのフィールドを使用した認証フォームのみサポートします。
CustomWarおよび外部コンテキスト・タイプでは、次の2つのタスクを実行するカスタム・ログイン・ページ内のロジックが必要になります。
Oracle Access Managerサーバーから受け取ったページにリクエストIDを送信します。たとえば、String reqId = request.getParameter("request_id"); <input type="hidden" name="request_id" value="<%=reqId%>">などです。
OAMサーバーにエンド・ポイント「/oam/server/auth_cred_submit」を戻します。たとえば、<form action="/oam/server/auth_cred_submit">または「http://oamserverhost:port/oam/server/auth_cred_submit」などです。
詳細は、次の各項を参照してください。
表8-7は、Oracle Access Manager 11gで使用できる事前構成済認証スキームおよびそれぞれの固有の詳細を示しています。
表8-7 事前構成済認証スキーム
認証には、リソースへのアクセスのリクエスト、HTTPを介した資格証明の収集および資格証明の検証結果に基づくHTTPレスポンスの応答の実行時にユーザーが指定する必要がある資格証明の決定が含まれます。Oracle Access Manager 11gは、認証スキームに使用する次の資格証明チャレンジ・メソッドを提供します。
フォーム
Basic
X509
WNA
なし
DAP
OAM10g
フォーム
この認証チャレンジは、ユーザー資格証明のために1つ以上のテキスト入力フィールドを含むHTMLフォームを使用します。通常のフォームベース・チャレンジで、ユーザーはフォームの2つのテキスト・ボックスにユーザー名とパスワードを入力します。最も一般的な資格証明の選択はユーザー名とパスワードですが、ユーザー名、パスワード、ドメインなどの任意のユーザー属性を使用できます。
「送信」ボタンを使用して、フォームのコンテンツを転送します。ユーザーが「送信」ボタンをクリックすると、フォーム・データがWebサーバーに転送されます。OAMおよびOSSOエージェントは、フォーム・データを捕捉および処理します。フォームで収集されたユーザー資格証明の検証時に、ユーザーが認証されます。
|
注意: このチャレンジ・メソッドは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに基づいています。 |
次のような理由でフォームベースの認証チャレンジを使用できます。
一貫性のあるユーザー操作性: フォームベースのログインおよび標準化されたログインを使用すると、ログインおよびログアウト機能のユーザー操作性がブラウザ間で一貫して実現します。
カスタム・フォーム: 認証プロセスで組織のルック・アンド・フィールを適用できます。
たとえば、Basic認証で使用される標準のユーザー名およびパスワード・ウィンドウのかわりに、カスタム・フォームに企業ロゴおよびようこそメッセージを含めることができます。
追加情報: ログイン時に追加情報を収集できます。
追加機能: 紛失したパスワードを管理するページのリンクなど、ログイン手順とともに追加機能を提供できます。
Basic
この組込みのWebサーバー・チャレンジ・メカニズムは、ユーザーにログインIDおよびパスワードの入力を要求します。提供された資格証明は、LDAPディレクトリ・サーバーのユーザー定義と比較されます。
|
注意: Basicチャレンジは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに基づいています。 |
X509
X509証明書チャレンジ・メソッドを使用する場合、認証を実行するには、エージェントを通じてOAMサーバーに送信するSSLを介したX.509デジタル証明書をユーザーのブラウザで指定する必要があります。
|
注意: X509は、X509Schemeのチャレンジ・メソッドです。ユーザーの組織は、証明書の取得方法を決定できます。 |
認証するX.509クライアント証明書の妥当性を確認するには、OAMプロキシおよびOAMサーバーで使用されるキー・ストアの信頼されたCAに対してX.509クライアント証明書を確認する必要があります。
OAM 11gに関連付けられているユーザー・アイデンティティ・ストアに対して、X.509証明書の次の属性を検証できます。
SubjectDN
SubjectUniqueID
CN
ユーザー・エントリを取得するには、X509認証モジュールで検証されるX.509証明書の属性名および検索が起動するLDAP属性を取得します。予期される結果は、基準と一致する1つのユーザー・エントリです。検索でユーザー・エントリが戻らない場合または複数のエントリが戻る場合、認証に失敗します。認証スキーム・パラメータはoam-policy.xmlにあります。
|
注意: X509認証の場合、管理者はリバース・プロキシとしてOracle HTTP Server（またはwl-proxyプラグインを使用するサーバー）を構成する必要があります。Oracle HTTP Serverを双方向SSLモードで構成して、認証するX.509証明書を取得する必要があります。CRL検証にもOracle HTTP Serverを構成できます。 |
オンライン証明書ステータス・プロトコル（OCSP）機能も提供されます。X.509証明書ベースの認証に渡される証明書は、OCSPリクエストを使用して検証します。管理者は、1つ以上のOCSPサーバーと通信するシステムを構成して、証明書ステータスを取得できます。
OCSP応答者URLのX509認証モジュール構成は、OCSP検証を実行するかどうかを示します。指定されている場合、値は、OCSPを使用してX.509クライアント証明書を検証するURLを示します。値がない場合、OCSP検証はありません。
WNA
Active DirectoryのWindows固有の認証およびKerberos認証モジュールを使用します。
|
注意: KerbSchemeは、WNAチャレンジ・メソッドおよびKerberos認証モジュールに基づいています。 |
|
関連項目: 統合のWindows固有の認証の詳細は、Oracle Fusion Middleware Oracle Access Manager統合ガイドを参照してください。 |
なし
なしチャレンジ・メソッドでは、ユーザーが要求されないので資格証明を入力する必要がありません。保護しないOracle Access Manager固有のURLにアクセスできるAnonymousScheme認証スキームで使用されます。
DAP
新しい委任認証プロトコル（DAP）チャレンジ・メソッドは、DAP認証モジュールおよび外部コンテキスト・タイプを使用したOIFScheme（Oracle Identity Federation統合）に必要になります（表8-6を参照してください）。DAPチャレンジ・メカニズムでは、外部オプションを使用する標準チャレンジのフォーム・メカニズムと異なり、OAMが受け取ったトークンのアサーションを実行します。
DAPModuleは新しいアサーション・モジュールですが、このアプリケーションに特化され、OAM管理コンソールの認証モジュールのリストに表示されません。この統合ではOSSO 10gがOAM11gに置き換えられ、OIF側の変更はありません。
DAPチャレンジ・メカニズムは、認証をサード・パーティ（この場合はOIF）に委任します。challenge_urlは、OIFサーバーURLを参照します。リソースがこのスキームで保護される場合、OAMサーバーが資格証明コレクションのためにOIFサーバーURLにリダイレクトします。この場合、OAMサーバーは、資格証明の収集または検証を実行しません。OIFは、資格証明を収集し、ユーザー・アイデンティティ・ストアに対してユーザーを認証して、ユーザー名を構成するアサーション・トークンをOAMサーバーに戻します。OAMは、このトークンを受信および復号化し、OAMのプライマリ・アイデンティティ・ストアでユーザーが有効かどうか確認します。ユーザーが有効な場合、OAMはリソースのアクセス権を付与します。
DAPTokenは、OAMおよびOIF間で共有されるキーで暗号化および復号化します。DAPTokenは、OAM側から作成されます。
OIF管理EMコンソールは、OAM 11gおよびOIF間の通信の保護に使用される暗号化鍵を含むキー・ストアを生成する方法を提供します。OAMは、OIFストアで生成されたキーストアの場所を特定し、キーを取得してOAM側に格納するWLSTコマンド（registerOIFDAPPartner）を提供します。
OAM10g
このチャレンジ・メソッドは、OSSO 10g統合クラシック・アプリケーション（PortalやDiscoなど）も含むドメインを保護するOAM 10gを使用している場合の信頼性を高めるため、LDAPNoPasswordAuthModuleを使用したOAM10gSchemeに必要です。この新しいメカニズムは、OAM 10g共存のために作成されます。
OAM10gが常に認証/認可プロバイダとして動作するように、OSSO10gはWebGateを通じてOAM10gで保護されます。
統合の促進: OSSO 10g統合クラシック・アプリケーションをアサータとしてのみ動作するOAM 11gにアップグレードできます。OAM 11gは、mod_ossoで使用できるトークンを作成して、これらのアプリケーションへのアクセスを実現します。mod_ossoアプリケーションは、新しい「OAM10gScheme」で保護されます。OAM 10gアクセス・サーバーに対して構成されたOAM 11gサーバーのフロント・エンド処理を行うWebGateがあります。
設定: リソースにアクセスする場合、WebGateはリクエストを捕捉し、認証するためにOAM 10gアクセス・サーバーに送信します。OAM 10gは、資格証明を収集し、アイデンティティ・ストアに対して検証し、ヘッダー変数（OAM_REMOTE_USER）としてユーザー名を設定します。リクエストは、OAM10gSchemeを使用してヘッダー変数のユーザー名を検索するOAM 11gサーバーに移動します。OAM 11gは、ヘッダー変数を取得し、プライマリ・アイデンティティ・ストアに対してユーザーの存在をアサートします。存在する場合、必要なCookie（OAM_ID）が生成され、リソースにリダイレクトされます。
Oracle Access Manager 11gでは、各認証スキームに認証モジュールが必要です。管理者は、既存のタイプの新しい認証モジュールを作成できます。ただし、すぐに利用するためにいくつかのデフォルトの認証モジュールを使用できます。
LDAP: このモジュールは、LDAPディレクトリ・サーバーに格納されたユーザー定義にリソースをリクエストするユーザーの資格証明（ユーザー名およびパスワード）と一致します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。
X509: LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示す追加プロパティを使用したLDAPと似ています。
Kerberosモジュール: リソースを暗号化された「チケット」にリクエストするユーザーの資格証明（ユーザー名およびパスワード）と一致する資格証明マッピング・モジュール。
各認証スキームに強度レベルが必要になります。この数値が低いほど、スキームが厳密ではなくなります。高いレベルの数値は、よりセキュアな認証メカニズムを示します。
LDAPScheme authLevel=1
KerbScheme authLevel=2
|
注意: マルチレベル認証は、X.509証明書の認証に影響を与えず、X.509証明書の認証を否定または変更しません。 |
SSO機能により、ユーザーは2つ以上の保護されたリソースまたはアプリケーションにシングル・サインオンでアクセスできます。特定のレベルのユーザーの認証に成功した後、ユーザーは、1つ以上のアプリケーション・ドメインで保護された1つ以上のリソースにアクセスできます。ただし、アプリケーション・ドメインで使用される認証スキームは、同じレベル（または下位のレベル）にする必要があります。ユーザーが現在のSSOトークンのレベルを超える認証レベルで保護されたリソースにアクセスする場合、再認証されます。ステップアップ認証の場合、高いレベルで示されるチャレンジに失敗しても、ユーザーは現在のレベルのアクセスを維持します。これは「追加認証」です。
|
注意: レベル3のリソースへのアクセスを認証されているユーザーは、3以下のレベルで保護されたリソースにアクセスできます。ただし、ユーザーがレベル2のリソースのアクセスを認証され、レベル3で保護されたリソースにアクセスする場合、ユーザーの再認証が求められます（これはステップアップ認証と呼ばれます）。 |
Oracle Access Manager 11gポリシーにより、同じアプリケーションの異なるリソースを別の認証レベルで保護できます。ただし、mod_ossoプラグインは、異なる信頼レベルの同じアプリケーションの2つのリソースをサポートしません。
|
注意: mod_ossoは、認証をOAMに委任します。mod_ossoで保護されたリソースをOAM認証レベルで保護することをお薦めします。 |
その場合、アプリケーションはそのレベルを適用し、再認証するために動的ディレクティブをmod_ossoに送信する必要があります。動的ディレクティブを受信すると、適切なレベルで再認証するためにmod_ossoがOracle Access Managerにリダイレクトします。
詳細は、次の項を参照してください。
登録されたエージェントは、次に示すように認証レベルを検出します。
mod_ossoは、動的ディレクティブから認証レベルを検出します（「OSSOエージェント（mod_osso 10g）を使用したマルチレベル認証のリクエスト・フロー」を参照してください）。
OAMエージェントは、OAMサーバーから不十分なレベルのエラー・メッセージを受け取ります（「OAMエージェントによる不十分な認証レベルの検出」を参照してください）。
両方のエージェント・タイプでユーザーがOAMサーバーにリダイレクトされ、再認証されます。リソースのポリシーに構成された認証スキームのレベルに応じて、チャレンジが示されます。
ユーザーが高いレベルの認証スキームで保護されるリソースをリクエストすると、次のプロセスが発生します。
プロセスの概要: OAMエージェントによる不十分なユーザー・セッション・レベルの検出
OAMエージェントはリクエストをOAMプロキシに送信し、保護されたリソースのスキーム詳細を取得します。
OAMエージェントは、セッション情報のリクエストをOAMプロキシに送信します。
OAMプロキシは、認証されたレベルのObSSOCookieを含むObSSOCookieの詳細を戻します。
OAMエージェントは、ObSSOCookieのレベルを認証スキームのレベルと比較します。
不十分な場合、エージェントは認証プロセスを再起動します。
十分な場合、アクセス権が付与されます。
サーバー側で認証レベルの確認は行われません。
OAMエージェントとは対照的に、ホスト（または仮想ホスト）のmod_ossoで保護されたすべてのリソースが同じレベルで保護されます。
mod_ossoでは、ユーザーがレベル2でmod_ossoホスト（または仮想ホスト）ですでに認証され、レベル3で別のmod_ossoで保護されたホスト（または仮想ホスト）にアクセスする場合にマルチレベル認証が適用されます。
プロセスの概要: OSSOエージェントのマルチレベル認証フロー
ユーザーは、レベル2のhost1のmod_ossoで保護されたリソースにアクセスします。
OSSOエージェントはリクエストをOAMプロキシに送信し、保護されたリソースの認証スキーム詳細を取得します。
SSOサーバーのOAM_ID Cookieおよびhost1のホスト・ベースCookie「HOST_port」が設定され、認証レベル情報が格納されます。
認証後、ユーザーは、高いレベルの認証で保護されるhost2のリソースにアクセスします。
host2の最初のアクセスなので、認証するためにユーザーがOAMサーバーにリダイレクトされます。
OAMサーバー（OSSOプロキシ）は、host2のリソースのアクセスに不十分なレベルのOAM_ID Cookieを受け取ります。
レベルが不十分な場合、OAMサーバー（OSSOプロキシ）は再認証を要求します。
レベルが十分な場合、アクセス権が付与されます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインで使用される新しい認証スキームを追加できます。
前提条件
認証モジュールを定義して使用可能にする必要があります。
認証スキームを作成するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから「共有コンポーネント」ノードを拡張します。
「認証スキーム」ノードをクリックし、ツールバーの「作成」ボタンをクリックします。
新しい認証スキーム・ページに入力します（表8-6を参照してください）。
名前
説明
認証レベル
デフォルト
チャレンジ・メソッド
チャレンジ・リダイレクト
認証モジュール
「適用」をクリックして新しいスキームを送信します（または変更を適用しないでページを閉じます）。
確認ウィンドウを閉じます。
オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。
ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。
有効なOAM管理者の資格証明を持つユーザーは、次のタスクを実行して特定の認証スキームを検索できます。
認証スキームを検索するには、次の手順を実行します。
「ポリシー構成」タブをアクティブ化します。
検索タイプ・リストから「認証スキーム」を選択して、検索を定義します。
テキスト・フィールドで、検索するインスタンスの正確な名前を入力します。次に例を示します。
my_AuthnScheme
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証スキームを表示または変更できます。
前提条件
この認証スキームを使用してアプリケーション・ドメインを確認し、異なるスキームを指定します。
認証スキームを表示または変更するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。
「共有コンポーネント」ノード
「認証スキーム」ノード
変更するスキームの名前をダブルクリックします。
認証スキーム・ページで、必要に応じて値を変更します（表8-6を参照してください）。
「適用」をクリックして変更を送信します（または変更を適用しないでページを閉じます）。
確認ウィンドウを閉じます。
オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。
終了する場合はページを閉じます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証スキームを削除できます。
前提条件
この認証スキームを使用してアプリケーション・ドメインを確認し、異なるスキームを指定します。
認証スキームを削除するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。
「共有コンポーネント」ノード
「認証スキーム」ノード
オプション: スキームの名前をダブルクリックして削除対象のスキームを確認し、ページを閉じます。
ナビゲーション・ツリーで、スキームの名前をクリックし、ツールバーの「削除」ボタンをクリックします。
削除を確認します（または確認ウィンドウを閉じます）。
ナビゲーション・ツリーで、インスタンスが削除されていることを確認します。
