| Oracle® Fusion Middleware Oracle Access Manager管理者ガイド 11g リリース1（11.1.1） B62265-01 |
|
 戻る |
 次へ |
この章では、ポリシーの作成および管理方法を説明し、これらのポリシーを制御するリソースを確認します。この章では、タスクに対するOracle Access Manager 11g管理コンソールの使用に焦点を当て、次の内容を説明します。
この項の内容は次のとおりです。
OAM 11gにポリシー施行エージェントを登録すると、ポリシーを自動的に作成できます。エージェントに指定された詳細に基づいて、アプリケーション・ドメインおよびホスト識別子が自動的に作成されます。ドメインは、デフォルトのリソースとデフォルトの認証および認可ポリシーでシードされます。
各アプリケーション・ドメインは、特定のホストの単一のアプリケーションを表すリソースの集合です。構成可能な認証および認可ポリシーを使用して、ドメインのリソースへのアクセスを許可または拒否できます。
エージェントの登録中、エージェントが保護するアプリケーションと同じWebサーバーにあると仮定します。ただし、エージェントをプロキシWebサーバー、アプリケーションを異なるホストに配置できます。
|
注意: IDMDomainAgentは、同じ名前のアプリケーション・ドメインを提供してOracle Fusion Middlewareコンソールなどを保護する事前登録されたJavaエージェント・フィルタです。 |
詳細は、「アプリケーション・ドメインおよびポリシーの詳細分析」を参照してください。
新しいアプリケーションが既存のエージェントの背後に配置される場合、管理者は、個別のアプリケーション・ドメインおよびポリシーまたは既存のアプリケーション・ドメインおよびポリシーで保護するかどうかを決定する必要があります。
管理者は、同じWebサーバーに存在して様々な方法で相互に密接に関連付けられている場合でも、リソースの異なるアプリケーション・ドメインを定義できます。たとえば、管理者は、財務アプリケーションおよび売掛金勘定アプリケーションの単一のアプリケーション・ドメインを作成するか、それぞれに異なるアプリケーション・ドメインを使用できます。
|
注意: 新しいリソースをアプリケーション・ドメインに追加する前に、リソースが既存のアプリケーションおよびポリシーに属するかどうかまたは固有の特定のポリシーを使用する新しいアプリケーションとして定義するかどうかを検討します。 |
次のタスクの概要では、新しいアプリケーション・ドメインを手動で作成するために実行する必要がある手順について説明します。
|
注意: タスク3〜6を実行すると、管理者は既存のアプリケーション・ドメインを管理できます。 |
タスクの概要: アプリケーション・ドメインの手動の作成
「アプリケーション・ドメインおよびポリシーの詳細分析」を確認します。
アプリケーション・ドメインの登録を開始します（「新しいアプリケーション・ドメインの作成」を参照してください）。
1つ以上のリソースをドメインに追加します（「ポリシーで使用するリソース定義の追加および管理」を参照してください）。
ドメインの1つ以上の認証ポリシーを構成します（「特定のリソースの認証ポリシーの定義」を参照してください）。
ドメインの1つ以上の認可ポリシーをに構成します（「特定のリソースの認可ポリシーの定義」を参照してください）。
1つ以上のSSOレスポンスをポリシーに定義します（「SSOのポリシー・レスポンスの追加および管理」を参照してください）。
1つ以上の認可制約を定義します（「認可ポリシー制約の定義」を参照してください）。
SSOエンジンの設定を構成します（「共通のSSOエンジンの管理」を参照してください）。
ドメインの操作を検証します（「アプリケーション・ドメインの認証および認可の検証」を参照してください）。
明示的にアクセスできるポリシーでリソースが保護されない場合、OAM 11gのデフォルトの動作でアクセスが拒否されます。
|
注意: アクセス・サーバーへのWebGate問合せの数を制限するためにアクセスを明示的に拒否したルールまたはポリシーでリソースが保護されなかった場合、OAM 10gのデフォルトの動作ではアクセスが許可されていました。 |
OAM 11gを使用する場合、管理者は、特定のリソースのアクセスを認可される認証ユーザーおよび認可されないユーザーを区別するポリシーを定義して、リソースにアクセス可能なユーザーを制御します。各アプリケーション・ドメインを作成して、全体のアプリケーションのデプロイメント、特定の層のデプロイメントまたは単一のホストに関連するポリシー要素を含めることができます。アプリケーション・ドメインは、相互に階層の関係がありません。
図9-1は、Oracle Access Manager 11gポリシー・モデルのアプリケーション・ドメイン固有のコンポーネントを示しています。
エージェントの登録中に自動的に作成されるアプリケーション・ドメインは、エージェントに基づく名前が付けられ、エージェント名に基づいてデフォルトのリソースおよびデフォルトのポリシー（認証および認可）でシードされます。最初は、すべてのリソースがデフォルトの認証および認可ポリシーで保護されます。
エージェントの登録に使用される管理コンソールまたはリモート登録ツールにかかわらず、次の内容のとおり、アプリケーション・ドメインの要素は同じです。
図9-2は、「アプリケーション・ドメイン」ノードのナビゲーション・ツリーにハイライト表示されるアプリケーション・ドメイン名および名前と説明を含むアプリケーション・ドメイン・ページを示しています。
ナビゲーション・ツリーのアプリケーション・ドメイン名の下にデフォルトのリソース定義およびポリシーがあります。
管理者はアプリケーション・ドメインを変更して、リソースの追加およびポリシー、レスポンスおよび認可制約の定義を実行できます。
図9-3は、生成されたアプリケーション・ドメインのデフォルトのリソース定義を示しています。ホスト識別子は、登録中に指定されたエージェント名と一致します。デフォルトのリソース・タイプはHTTPですが、デフォルトのリソースURLは/.../*です。
1つの認証ポリシーでのみ、各リソースを保護できます。管理者がアプリケーション・ドメインを手動で作成する場合、すべてのポリシーを手動で作成する必要もあります。ただし、アプリケーションが自動的に生成されると、次の認証ポリシーが自動的に生成されます。
保護されたリソース・ポリシー
パブリック・リソース・ポリシー
保護されたリソース・ポリシーを図9-4に示します。説明には、ドメイン作成中に設定されるポリシー。リソースをこのポリシーに追加して保護します。と示されています。デフォルトのポリシーは、デフォルトの認証スキーム（この場合はLDAPScheme認証スキーム）を使用します。保護されたリソースは、HostIdentifier/.../*として「リソース」タブで識別されます。管理者は、認証スキームの変更、成功および失敗URLの指定、他のリソースの追加および認証レスポンスの定義を実行できます。
認証ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。他のリソースにポリシーを導出または適用できません。
|
注意: 最初は、すべてのリソースが保護されます。成功および失敗URLとレスポンスを手動で追加する必要があり、デフォルト値は提供されません。 |
認証のパブリック・リソース・ポリシー: デフォルトの認証スキームとしてAnonymousSchemeを使用する2番目の認証ポリシーも作成されます。管理者に対する説明には、ドメイン作成中に設定されるポリシー。リソースをこのポリシーに追加してすべてのアクセスを許可します。と示されています。このパブリック・リソース・ポリシーは、最初にリソースを保護しません。
1つの認可ポリシーでのみ、各リソースを保護できます。アプリケーション・ドメインを手動で作成する管理者は、すべてのポリシーを手動で作成する必要があります。ただし、アプリケーションが自動的に生成されると、次の認可ポリシーが自動的に生成されます。
保護されたリソース・ポリシー
パブリック・リソース・ポリシー
|
注意: 最初は、すべてのリソースが保護され、アクセスが拒否されます。成功および失敗URLと制約およびレスポンスを手動で追加する必要があり、デフォルト値は提供されません。 |
認可の保護されたリソース・ポリシーを図9-5に示します。説明には、ドメイン作成中に設定されるポリシー。リソースをこのポリシーに追加して保護します。と示されています。保護されたリソースは、HostIdentifier/.../*として「リソース」タブで識別されます。管理者は、成功および失敗URLの指定、他のリソースの追加および認可制約およびレスポンスの定義を実行できます。
認可のパブリック・リソース・ポリシー: 2番目の認可ポリシーも作成されます。説明には、ドメイン作成中に設定されるポリシー。リソースをこのポリシーに追加してすべてのアクセスを許可します。と示されています。このパブリック・リソース・ポリシーは、最初にリソースを保護しません。
この項の内容は次のとおりです。
アプリケーション・ドメインの管理には、一般的な設定およびリソース関連設定と認証および認可ポリシーの追加、変更、コピーまたは削除が含まれます。コピーには、元の名前に基づくデフォルト名を使用します。たとえば、AppDom3というアプリケーション・ドメインをコピーする場合、コピー名はcopy of AppDom3になります。コピーされたドメインの他のすべての設定は、コピーに保持されます。
管理コンソールを使用してアプリケーション・ドメインを作成または編集する場合、いくつかのページが含まれます。最初は、図9-6に示されているフォームに一般詳細（名前およびオプションの説明）を追加します。
各アプリケーション・ドメインには、エージェント名と一致する一意の名前を使用する必要があります。新しいアプリケーション・ドメインの名前とオプションの説明を適用した後、アプリケーション・ドメインが作成され、名前が「ポリシー構成」タブのナビゲーション・ツリーの「アプリケーション・ドメイン」ノードに追加されます。リストには、コンテナのフラット・リストとしてすべてのアプリケーション・ドメイン名が含まれます。
「アプリケーション・ドメイン」ノードを拡張して、新しいドメインを含むすべてのドメインを明らかにできます。図9-7は、「アプリケーション・ドメイン」ナビゲーション・ツリーおよびリソースと認証および認可ポリシーのIDMDomainAgent関連コンテナを示しています。
ナビゲーション・ツリーのドメイン名を選択すると、この章の他の項に示されているように個々の要素を追加、変更または削除できます。
有効なOAM管理者の資格証明を持つユーザーは、次のタスクを実行してOAM管理コンソールでアプリケーション・ドメインを手動で作成できます。
アプリケーション・ドメインを手動で作成し、リソースおよびポリシーを手動で追加して、同じエージェントを使用して複数のアプリケーションを保護できます。
前提条件
新しいアプリケーション・ドメインが必要かどうか、またはリソースを既存のアプリケーション・ドメインに追加できるかどうかを決定します。
|
注意: テンプレートとして使用する既存のドメインを複製し、コピーを編集して一意の識別子（リソース名およびリソースURL）を定義できます（「アプリケーション・ドメインの表示または編集」を参照してください）。 |
新しいアプリケーション・ドメインを作成するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから「アプリケーション・ドメイン」ノードをクリックして、ツールバーの「作成」コマンド・ボタンをクリックします。
または、ようこそページのポリシー・パネルで、「アプリケーション・ドメインの追加」リンクをクリックして新しいページを開きます。
新しいアプリケーション・ドメイン・ページで、ドメインの一意の名前およびオプションの説明を追加して、「適用」をクリックして確認ウィンドウを閉じます。
ツールバーの「リフレッシュ」ボタンをクリックして、新しいアプリケーション・ドメインがナビゲーション・ツリーに表示されていることを確認します。
ナビゲーション・ツリーで、新しいアプリケーション・ドメインを拡張して、次のノードを表示および管理します。
リソース: 「ポリシーで使用するリソース定義の追加および管理」を参照してください。
認証ポリシー: 「特定のリソースの認証ポリシーの定義」を参照してください。
認可ポリシー: 「特定のリソースの認可ポリシーの定義」を参照してください。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して特定のアプリケーション・ドメインを検索できます。
アプリケーション・ドメインを検索するには、次の手順を実行します。
「ポリシー構成」タブをアクティブ化します。
検索タイプ・リストから「アプリケーション・ドメイン」を選択して、検索を定義します。
テキスト・フィールドで、検索するインスタンスの正確な名前を入力します。次に例を示します。
my_App_Domain_Name
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効なOAM管理者の資格証明を持つユーザーは、次のタスクを実行してOAM管理コンソールでアプリケーション・ドメイン（リソース、ポリシー、制約およびレスポンスを含む）を表示または変更できます。
|
注意: テンプレートとして使用する既存のドメインを複製し、コピーを編集して一意の識別子（リソース名およびリソースURL）を定義できます。 |
類似するアプリケーションを同じアプリケーション・ドメインにグループ化することをお薦めします。アプリケーション・ドメインを編集する場合、異なるアプリケーションが同じドメインを使用していることに注意してください。説明およびドメイン名の編集がサポートされます。
アプリケーション・ドメインおよびその内容を表示または変更するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
次の各ノードを拡張して、次の特定の内容を追加、表示、変更または削除します。
リソース: 「ポリシーで使用するリソース定義の追加および管理」を参照してください。
認証ポリシー: 「特定のリソースの認証ポリシーの定義」を参照してください。
認可ポリシー: 「特定のリソースの認可ポリシーの定義」を参照してください。
「適用」をクリックして変更を送信します（または変更を適用しないでページを閉じます）。
有効なOAM管理者の資格証明を持つユーザーは、次のタスクを実行してOAM管理コンソールでアプリケーション・ドメイン（リソース、ポリシー、制約およびレスポンスを含む）を削除できます。
|
警告: 削除する前に、アプリケーション・ドメインを空にする必要があります。ドメイン自体を削除する前に、すべての認証および認可ポリシーとリソースを削除する必要があります。ドメインの削除によってドメインで使用されるホスト識別子は自動的に削除されません。 |
前提条件
削除するドメインのリソースが保護するために別のアプリケーション・ドメインに配置されていることを確認します。
アプリケーション・ドメインを削除するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
すべての認証ポリシーを削除します。
「認証ポリシー」ノードを拡張して、既存のポリシーを明らかにします。
ポリシー名をクリックし、ツールバーの「削除」ボタンをクリックして、確認ウィンドウで削除を確認します。
手順a〜cを繰り返して、すべての認証ポリシーを削除します。
すべての認可ポリシーを削除します。
「認可ポリシー」ノードを拡張して、既存のポリシーを明らかにします。
ポリシー名をクリックし、ツールバーの「削除」ボタンをクリックして、確認ウィンドウで削除を確認します。
手順a〜cを繰り返して、すべての認可ポリシーを削除します。
ドメインのすべてのリソースを削除します。
「リソース」ノードを拡張して、既存のリソース名を明らかにします。
リソース名をクリックし、ツールバーの「削除」ボタンをクリックして、確認ウィンドウで削除を確認します。
手順a〜cを繰り返して、アプリケーション・ドメインからすべてのリソースを削除します。
ナビゲーション・ツリーで、アプリケーション・ドメイン名をクリックし、ツールバーの「削除」ボタンをクリックします。
確認ウィンドウで、「削除」をクリックします（または「取消」をクリックしてウィンドウを閉じます）。
ナビゲーション・ツリーで、アプリケーション・ドメインが削除されていることを確認します。
リソースの保護には、特定のリソース定義を含むアプリケーション・ドメインが必要です。OAMを使用すると、次のような様々なタイプのリソースを保護できます。
すべての外部Webサイト
Webサイトの特定のページ
パートナ・ポータル
部品注文アプリケーション
請求書アプリケーション
多くの国の企業のWebサーバーの福利厚生加入アプリケーション
この項の内容は次のとおりです。
アプリケーション・ドメイン内で、リソース定義はオブジェクトのフラットな集合として存在します。各リソースは、特定のリソース・タイプおよびサーバーに格納されて多くのユーザーがアクセスできるドキュメントまたはエンティティを識別するURL接頭辞として定義されます。既存の共有ホスト識別子を使用して、場所を指定します。
各リソースがアプリケーション・ドメインで個別に定義されます。図9-8は、事前構成されたIDMDomainAgentアプリケーション・ドメインの1つのリソースの詳細を示す通常のリソース定義ページを示しています。
表9-1は、リソース・ページで指定する必要がある要素を示しています。
表9-1 リソース定義の要素
| 要素 | 説明 |
|---|---|
|
タイプ |
HTTPタイプがデフォルトです。HTTPまたはHTTPSプロトコルを使用してアクセスするリソースを扱います。特定のリソースを制御するポリシーがすべての操作に適用されます。 「リソース・タイプの管理」も参照してください。 |
|
説明 |
このリソースのオプションの一意の説明。 |
|
ホスト識別子 |
共有コンポーネントとして定義されたすべての識別子を含むホスト識別子のリストを使用できます。ホスト識別子を選択して、リソースを割り当てる必要があります。 注意: リソース定義を構成するホスト識別子およびURL文字列の組合せをすべてのアプリケーション・ドメインで一意にする必要があります。 関連項目: 「ホスト識別子の管理」 |
|
リソースURL |
「/」文字で区切られた一連の階層レベルで構成される完全なURLのパス・コンポーネントを表す単一の相対URLとして、URL値を表現する必要があります。リソースのURL値は/で始まり、選択されたホスト識別子のリソース値と一致する必要があります。 問合せ文字列やフラグメントなどの他のコンポーネントは使用されません。内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。含まれる場合、パターン定義に使用できる特殊文字は次のとおりです。
表9-2も参照してください。 |
表9-2は、リソースのサンプルのURL値を示しています。詳細は、「リソースURLについて」を参照してください。
表9-2 HTTPリソースのサンプルのURL値
| リソース | サンプルのURL値 |
|---|---|
|
ディレクトリ |
|
|
|
|
Webアプリケーション |
|
リソースの追加後、名前が付けられたアプリケーション・ドメインの「リソース」ノードにグループ化されます。認証および認可ポリシーを作成すると、ドメインに定義されたすべてのリソースがリストに表示されるので、ポリシーに含める1つ以上のリソースを選択できます。
リソース定義の詳細は、次の各項を参照してください。
リソース定義をアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択する必要があります。
HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加します。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、ポリシーがすべてのHTTP操作に適用されます。
HTTP以外のリソース・タイプに名前が付けられ、URLに関連付けられません。HTTP以外のタイプのリソース定義を追加する場合、管理者は「リソースURL」フィールドにタイプの名前を入力する必要があります。
管理機能は、リソースが存在するホストおよびリソースURLでアプリケーション・ドメインのリソースを確認します。
|
注意: HTTP以外のリソース・タイプにホスト識別子は関連付けられません。かわりに、管理者は、リソース定義ページの「リソースURL」フィールドにタイプの名前を入力する必要があります。 |
ホスト識別子は各リソースのコンテキストを作成するので、同じURLパスまたは異なるコンピュータのリソースを追加する場合に役立ちます。管理機能により、同じアプリケーション・ドメイン内のこれらのすべてのリソースを同じ方法で保護できます。一連のリソースを区別する唯一の違いは、ホスト・コンピュータの識別です。
すべての定義されたホスト識別子がリソース・ページの「ホスト識別子」リストに表示されます。リソースをアプリケーション・ドメインに追加する場合、管理機能でリソースをホストするコンピュータの1つのホスト識別子を選択する必要があります。
OAMでリソースのURLを識別できるように、OAMはリソースのホスト・コンピュータを参照する様々な方法を認識する必要があります。
自動的なアプリケーション・ドメインの生成中、すべてのリソースが保護されるURL接頭辞が定義されます。リソースは線形で階層ではありません。リソースの定義は、完全なURLとして扱われます。
|
注意: HTTP以外のリソース・タイプに関連付けられるホスト識別子またはURLはありません。 |
管理機能は、特定のリソースURLを使用して、アプリケーション・ドメインの個々のリソースを識別します。個々のリソースURLをドメイン間で一意にする必要はありません。ただし、リソースURLおよびホスト識別子の組合せをドメイン間で一意にする必要があります。
HTTPタイプのリソースは、パスを表す単一の相対URL文字列として表現されます。文字列は、「/」文字で区切られた一連の階層レベルで構成されます。内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。
URL接頭辞
ポリシー・モデルはリソース接頭辞をサポートしません。ポリシーが/mydirectory/projects/に定義されている場合、そのURLにのみ適用されます（/mydirectory/projects/index.htmlなどには適用されません）。つまり、ポリシーの継承はありません。同じ接頭辞文字列を使用したすべてのリソースのポリシーが必要な場合、特殊文字（/mydirectory/projects/.../*などの3つのピリオド...（省略記号）または*（アスタリスク））を使用してリソースを定義できます。
URLパターン
管理者は、詳細なURLパターンを作成して、リソースのネームスペースの詳細な部分を指定できます。
機能が制限された次の2つのパターンでのみ、パターン照合が実行されます。
… *
3つのピリオド（省略記号）は、バックスラッシュ文字（/）で開始および終了する一連の1つ以上の文字と一致します。0（ゼロ）個以上の一連の中間レベルを表し、複数のディレクトリにまたがることができます。終端レベルを除く任意のレベルのパスで、省略記号（...）をURLに一度だけ使用できます。省略記号により、アプリケーション・ドメイン内の各リソースを保護できます。
最下位の終端レベルのパスにのみ、アスタリスク（*）を使用できます。これは、0（ゼロ）個以上の文字と一致します。URLパターンの各文字は、次の2つの例外を除いてURLパスの対応する文字と完全に一致する必要があります。
パターンの最後の/*は、以降の一連の文字と一致します。
パターン*拡張子は、名前が付いた拡張子で終わるファイル名と一致します。
|
注意: 他のワイルド・カードはサポートされていません。パターンの他の位置のアスタリスクはワイルド・カードではありません。 |
たとえば、次のURLパターンなどです。
/.../update.html
次のリソースと一致します。
/humanresources/benefits/update.html /corporate/news/update.html update.html
表9-3は、単一のアプリケーション・ドメイン内の多くのリソース定義を示しています。ホスト識別子およびリソースURLに従って、アルファベット順で編成されます。
リソースのリクエストを処理する場合、リソースに適切なポリシーが起動していることを確認する評価が実行されます。
ユーザーは、リクエストしたリソースのURLを指定します。
ホスト識別子およびURLに基づいて、OAMはURLパターンを含む完全修飾URLを作成します。
OAMは、リクエストしたリソースの着信URLとアプリケーション・ドメイン情報およびポリシーのURLパターンから構築された完全修飾URLを比較します。
一致すると、様々なポリシーが評価され、リクエスタのリソースへのアクセスを許可または拒否するかどうかが決定されます。
リクエスタのアクセスが許可されると、リソースがユーザーに提供されます。
表9-4は、可能性のある結果を示しています。
表9-4 リソース評価の結果
| 結果 | 説明 |
|---|---|
|
最善一致 |
最善一致は、リソース定義がランタイム・リソースの他の可能性のある一致と比較して最小のリソース・スコープの場合です。リソース・スコープは、特定のリソース定義を使用した一致する可能性のあるすべてのリソースを表します。 |
|
一致なし |
一致なしの場合、デフォルトの評価結果はFAILUREです。評価されたポリシーの種類によっては、認証が実行されなかったり、リソースのアクセス権が付与されなかったりすることを意味する場合があります。 |
検索メカニズムの例
生成されたアプリケーション・ドメインのデフォルトのリソースURLは、使用可能な最大範囲の内容を定義します（すべてのディレクトリと次のディレクトリ）。
/.../*
パターン/.../index.htmlは、次のURLと一致します。
/index.html/oracle/index.html/oracle/sales/index.htmlindex.html
xyzindex.htmlなどは一致しません。
/oracle/.../*.htmlは、次のURLと一致します。
/oracle/index.html/oracle/sales/order.htmlなど
リソース・スコープの例
次のリソース定義のリソース・スコープ（アスタリスクを含む）
/mybank/…/*
「/mybank/」という接頭辞が付いたすべてのURLを含みます。
次のリソース定義のリソース・スコープ（定義に特殊文字を含まない）
/mybank/account.html
1つのURL「/mybank/account.html」のみ含みます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して保護するリソース定義を対応するアプリケーション・ドメインに追加できます。
|
注意: 無効なホスト識別子の値を指定すると、失敗する場合があります。チャレンジURLが無効であることを示すエラーが通知されます。 |
前提条件
共有コンポーネントとしてリソース・タイプを定義する必要があります。詳細は、「リソース・タイプの管理」を参照してください。
リソース定義をアプリケーション・ドメインに追加するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
「リソース」ノードをクリックし、ツールバーの「作成」ボタンをクリックします。
リソース定義ページで、次の手順を実行します。
単一のリソースの次の詳細を追加します。
「適用」をクリックして、このリソースをアプリケーション・ドメインに追加します。
ナビゲーション・ツリーで、「リソース」を拡張して追加が成功したことを確認します（またはツールバーの「リフレッシュ」ボタンをクリックします）。
この手順を繰り返して、他のリソースをこのアプリケーション・ドメインに追加します。
次の項の手順に従って、リソースを特定のポリシーに追加します。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して特定のリソース定義を検索できます。
特定のリソース定義を検索するには、次の手順を実行します。
「ポリシー構成」タブをアクティブ化します。
検索タイプ・リストから「リソース」を選択して、検索を定義します。
テキスト・フィールドで、検索するインスタンスの正確な名前を入力します。次に例を示します。
my_Resource_Name
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して特定のアプリケーション・ドメイン内のリソース定義を変更できます。
前提条件
目的のリソース・タイプを共有コンポーネントとして定義する必要があります。詳細は、「リソース・タイプの管理」を参照してください。
アプリケーション・ドメインのリソース定義を表示または変更するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。
目的のリソース定義をダブルクリックしてページを開いて、次に進みます。
表示のみ: 終了する場合はページを閉じます。
変更: 必要に応じて定義を変更して、「適用」をクリックして変更を送信します（または変更を適用しないでページを閉じます）。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインからリソースを削除できます。
前提条件
削除するリソース定義がポリシーで使用されないことを確認します。
アプリケーション・ドメインからリソース定義を削除するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
オプション: 目的のリソース定義をダブルクリックして削除対象であることを確認し、ページを閉じます。
目的のリソース定義の名前をクリックして、ツールバーの「削除」ボタンをクリックします。
確認ウィンドウで、「削除」をクリックします（または「取消」をクリックしてウィンドウを閉じます）。
必要に応じてこの手順を繰り返して、アプリケーション・ドメインの他のリソースを削除します。
1つの認証ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認証ポリシーの変更、新しいポリシーの追加および認証ポリシーへのリソースの割当てを開始できます。
自動的に生成されたアプリケーション・ドメインでは、次の認証ポリシーがデフォルトとしてシードされ、管理者のタスクを効率化できます。
保護されているリソース
パブリック・リソース
この項の内容は次のとおりです。
管理者は、認証ポリシーを使用して特定のリソースを保護できます。認証ポリシーは、ポリシーで制御されたリソースの唯一の認証方式を提供します。
各認証ポリシーにより、Oracle Access Managerの十分な信頼レベルを提供してリクエストを実行するユーザーにアクセス権を付与するために実行する必要がある検証のタイプが定義されます。
認証ポリシーはローカルです。単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。Oracle Entitlement Serverを使用する場合のようなポリシーの継承はありません。他のリソースにポリシーを適用できません。
図9-9は、アプリケーション・ドメイン内の認証ポリシー・ページを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。これは、IDMDomainAgentアプリケーション・ドメインの例です。
表9-5は、認証ポリシーの要素を示しています。IDMDomainAgentアプリケーション・ドメインが例として示されています。
表9-5 認証ポリシーの要素および説明
| 要素 | 説明 |
|---|---|
|
名前 |
ナビゲーション・ツリーの識別子として使用される一意の名前。 |
|
説明 |
認証ポリシーを説明するオプションの一意のテキスト。 |
|
認証スキーム |
ユーザー認証のためにポリシーで使用される単一の事前定義された認証スキーム。関連項目: 詳細は、「認証スキームの管理」を参照してください。 |
|
成功URL |
認証の成功時に使用されるリダイレクトURL。 |
|
失敗URL |
認証の失敗時に使用されるリダイレクトURL。 |
|
リソース |
リストから選択されたリソースのURL。リストされているURLは、以前にアプリケーション・ドメインに追加されました。認証ポリシーで保護する1つ以上のリソースを追加できます。リソース定義は、ポリシーに含める前にアプリケーション・ドメイン内に存在する必要があります。 関連項目: 「認証ポリシーのリソースについて」 |
|
レスポンス |
Webエージェントで実行される必須処理（認証後のアクション）。認証に成功すると、保護されたアプリケーションをホストするアプリケーション・サーバーは、これらのレスポンスに基づいてユーザー・アイデンティティをアサートできる必要があります。認証に失敗すると、ブラウザはリクエストを事前構成されたURLにリダイレクトします。 関連項目: 「SSOのポリシー・レスポンスの概要」 |
認証ポリシーで保護する1つ以上のリソースを追加できます。認証ポリシー・ページの「リソース」タブには、リソースURLを入力できる表が用意されています。アプリケーション・ドメイン内の定義されたリソースから選択できるリストも用意されています。
リソースを追加するには、「+」ボタンをクリックして、リストから選択します。リソースを削除するには、「リソース」表から名前を選択して、表の「削除」ボタンをクリックします。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して認証ポリシーおよびリソースをアプリケーション・ドメインに追加できます。認証ポリシーの事前構成された認証スキームまたはカスタム認証スキームを使用できます。
前提条件
ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。
特定のリソースの認証ポリシーを追加するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
ツールバーの「作成」ボタンをクリックして、新しいページを開きます。
次の一般的なポリシーの詳細を追加します。
名前
認証スキーム
グローバル・ポリシーの要素を追加します（表9-5を参照してください）。
説明（オプション）
成功URL
失敗URL
リソースを追加します。
認証ポリシー・ページの「リソース」タブをクリックします。
タブの「追加」ボタンをクリックします。
リストからURLをクリックします。
必要に応じてこれらの手順を繰り返して、リソースを追加します。
「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。
ポリシーのレスポンスを追加します（「SSOのポリシー・レスポンスの追加および管理」を参照してください）。
終了する場合はページを閉じます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して特定の認証ポリシーを検索できます。
アプリケーション・ドメインの認証ポリシーを検索するには、次の手順を実行します。
「ポリシー構成」タブをアクティブ化します。
検索タイプ・リストから「認証ポリシー」を選択して、検索を定義します。
テキスト・フィールドで、検索するポリシーの正確な名前を入力します。次に例を示します。
my_AuthNPolicy
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」コマンド・ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインの認証ポリシーを変更できます。これには、認証スキームの変更、リソースやレスポンスの追加または削除および成功または失敗URLの変更が含まれます。
認証ポリシーを表示または変更するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
目的の認証ポリシー名をダブルクリックします。
認証ポリシーが開いて、「リソース」タブを使用できます。
一般的なポリシー要素は次のとおりです。
名前
認証スキーム
グローバル・ポリシー要素: 必要に応じて編集します（表9-5を参照してください）。
説明
成功URL
失敗URL
リソース: 「リソース」タブをクリックして、必要に応じて次のタスクを実行します。
追加: 「リソース」表の「追加」ボタン、リストのURL、「適用」の順にクリックします。
削除: 「リソース」表のURLをクリックして、表の「削除」ボタンをクリックします。
「適用」をクリックして変更を送信し、確認ウィンドウを閉じます（または変更を適用しないでページを閉じます）。
レスポンス: レスポンスを表示または編集します（「SSOのポリシー・レスポンスの追加および管理」を参照してください）。
終了する場合はページを閉じます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインから認証ポリシーを削除できます。
ポリシーを削除する場合、すべてのリソース定義がアプリケーション・ドメイン内に残ります。ただし、ポリシーおよびすべてのレスポンスが削除されます。
次の手順は、全体のポリシーの削除方法を示しています。ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。
認証ポリシーを削除するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
オプション: 目的のポリシー名をダブルクリックして内容を確認し、ページを閉じます。
すべてのレスポンスを削除します（「SSOのポリシー・レスポンスの追加および管理」を参照してください）。
ナビゲーション・ツリーで、認証ポリシーの名前をクリックし、ツールバーの「削除」ボタンをクリックします。
確認ウィンドウで、確認して「削除」をクリックします（または「取消」をクリックしてウィンドウを閉じます）。
このポリシーで制御されたリソースが別のポリシーに追加されていることを確認します。
1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。
自動的に生成されるアプリケーション・ドメインでは、デフォルトとして次の認可ポリシーがシードされます。
保護されているリソース
パブリック・リソース
リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認可ポリシーの変更、新しいポリシーの追加および認可ポリシーへのリソースの追加を開始できます。この項の内容は次のとおりです。
管理者は、認証されたユーザーまたは環境の属性に基づいて、1つ以上のリソースへのアクセスを保護する認可ポリシーを作成できます。認可ポリシーは、ポリシーに含まれるリソースの唯一の認可保護を提供します。
認可ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。他のリソースにポリシーを導出または適用できません。
単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認可ポリシーでのみ、各リソースを保護できます。
図9-10は、アプリケーション・ドメイン内の認可ポリシー・ページを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。IDMDomainAgentアプリケーション・ドメインが例として示されています。
表9-6は、認可ポリシーの要素を示しています。ドメインに関係なく要素は同じで、詳細のみ異なります。IDMDomainAgentアプリケーション・ドメインが例として示されています。
表9-6 認可ポリシーの要素および説明
| 要素 | 説明 |
|---|---|
|
名前 |
ナビゲーション・ツリーの識別子として使用される一意の名前。 |
|
説明 |
認可ポリシーを説明するオプションの一意のテキスト。 |
|
成功URL |
認可の成功時に使用されるリダイレクトURL。 |
|
失敗URL |
認可の失敗時に使用されるリダイレクトURL。 |
|
暗黙的な制約の使用 |
アクセスを許可（または拒否）します。認可ポリシーで設定して、特定のクラスの認可制約がない場合のアクセスを許可します。 デフォルト: 選択（有効） 「認可制約の概要」も参照してください。 |
|
「リソース」タブ |
認可ポリシーで保護される1つ以上の事前定義されたリソースURL。 |
|
「制約」タブ |
「認可制約の概要」も参照してください。 |
|
「レスポンス」タブ |
「SSOのポリシー・レスポンスの概要」も参照してください。 |
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーをアプリケーション・ドメインに追加できます。
前提条件
ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。
認可ポリシーおよびリソースを追加するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
ツールバーの「作成」ボタンをクリックします。
認可ポリシーの一意の名前を追加します。
グローバル・ポリシー要素: 固有の詳細を入力します（表9-6を参照してください）。
説明（オプション）
成功URL
失敗URL
暗黙的な制約の使用
リソース
「リソース」タブで、「追加」ボタンをクリックします。
提供されたリストから、リソースURLをクリックします。
これらの手順を繰り返して、リソースをポリシーに追加します。
「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。
制約: 認可制約を追加します（「認可ポリシー制約の定義」を参照してください）。
レスポンス: SSOのレスポンスを追加または編集します（「SSOのポリシー・レスポンスの追加および管理」を参照してください）。
終了する場合はページを閉じます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して特定の認可ポリシーを検索できます。
認可ポリシーを検索するには、次の手順を実行します。
「ポリシー構成」タブをアクティブ化します。
検索タイプ・リストから「認証ポリシー」を選択して、検索を定義します。
テキスト・フィールドで、検索するポリシーの正確な名前を入力します。次に例を示します。
my_AuthZPolicy
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメイン内の認可ポリシーを表示または変更できます。
認可ポリシーを表示または編集するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
目的のポリシー名をダブルクリックして、詳細を表示します。
グローバル要素: 必要に応じて編集します（表9-6を参照してください）。
説明（オプション）
成功URL
失敗URL
暗黙的な制約の使用
リソース: 「リソース」タブをクリックして、必要に応じて次のタスクを実行します。
追加: 「リソース」表の「追加」ボタン、リストのURL、「適用」の順にクリックします。
削除: 「リソース」表のURLをクリックして、表の「削除」ボタンをクリックします。
「適用」をクリックして変更を送信し、確認ウィンドウを閉じます（または変更を適用しないでページを閉じます）。
制約: これらの制約を表示または編集します（「認可ポリシー制約の表示、編集または削除」を参照してください）。
レスポンス: これらのレスポンスを表示または編集します（「SSOのポリシー・レスポンスの表示、編集または削除」を参照してください）。
終了する場合はページを閉じます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーまたはポリシー内のリソースを削除できます。
全体のポリシーを削除する場合、すべてのリソース定義がアプリケーション・ドメイン内に残ります。ただし、アクセスを制御する認可ポリシー、制約およびレスポンスが削除されます。
前提条件
ポリシーを削除する前または後に、ポリシーで制御されたリソースを別の認可ポリシーに割り当てます。
認可ポリシーを削除するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
オプション: ポリシー名をダブルクリックして内容を確認し、終了したらページを閉じます。
ポリシー名をクリックし、ツールバーの「削除」ボタンをクリックします。
確認ウィンドウで、「削除」をクリックします（または「取消」をクリックしてウィンドウを閉じます）。
ポリシーがナビゲーション・ツリーにリストされていないことを確認します。
各ポリシーは、1つ以上の認証または認可レスポンスあるいはその両方をオプションで含むことができます。レスポンスは、Webエージェントで実行される後処理のアクション（必須処理）です。
この項の内容は次のとおりです。
管理者は、認証または認可が成功した後に実行する必要があるアクションを宣言するレスポンスを定義できます。認証および認可データがクライアント（通常はWebエージェント）に戻されます。
ポリシー・レスポンスにより、情報をセッションまたはアプリケーションに挿入し、SSOを有効化するために後で情報を抽出できます。たとえば、アイデンティティ・マッピングを顧客アプリケーションに挿入するか、エージェントまたはアプリケーションでアクションを実行できます。
認証または認可の成功および失敗に応じて指定されるレスポンスによっては、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を通じてユーザー情報が他のアプリケーションに渡されたりする場合があります。
|
注意: OAM 10gでは、特定の順序のURLのリダイレクトでのみ、アプリケーションのデータの経路を提供しました。 |
デフォルトのレスポンスは提供されません。図9-11は、OAM管理コンソールの管理者に定義された認可ポリシー・レスポンスを示しています。認可レスポンスは、認可制約と組み合せて操作できます。
各レスポンスは、2つの入力（タイプおよび式）と1つの出力（評価された式の値）で構成されます。式は、式を処理する場合の値の構築方法を宣言します。レスポンス・タイプは、値文字列を使用して実行するアクションの形式を定義します。
認証ポリシーは、ユーザーのアイデンティティを決定します。各認証ポリシーには、認証スキームおよびレスポンス（式）が必要です。
認可ポリシーは、リソースへのユーザーのアクセス権を付与するかどうかを決定します。各認可ポリシーには、認可制約およびレスポンス（式）が必要です。
管理者は、管理コンソールのレスポンスを設定します（表9-7を参照してください）。
表9-7 レスポンス要素
| 要素 | 説明 |
|---|---|
|
名前 |
このレスポンスと同じメカニズム（タイプ）を使用する他のレスポンスを区別する一意の名前。 |
|
タイプ |
レスポンスを伝達するために使用されるメカニズム。値文字列を使用して実行するアクションの形式。
|
|
値 |
変数として設定されるレスポンスの式。 詳細は、「ポリシー・レスポンスの言語について」を参照してください。 |
次の2つの主な構造とともに非常に小規模なドメイン固有言語（DSL）を使用して、OAM 11g認証および認可レスポンスを定義します。
リテラル文字列: This is a valid expressionなどです。
変数の参照
ドル記号の接頭辞（$）を使用して宣言します。
ネームスペース$namespace.var_nameでスコープされます。
|
注意: 変数に$ns.name.attribute属性が含まれる場合があります。 |
ネームスペース・メカニズムを使用すると、次の変数タイプがサポートされ、シングル・サインオンが有効化します。
リクエスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報
セッション: ユーザー・セッションの詳細
ユーザー: ユーザーの詳細（ユーザーID、グループおよび属性情報）
詳細は、次の表を参照してください。
表9-8 シングル・サインオンのネームスペース・リクエスト変数
| ネームスペース | 説明 |
|---|---|
|
agent_id |
リクエストしているエージェントの名前 |
|
client_ip |
ユーザー・ブラウザのIPアドレス |
|
policy_appdomain |
リクエストに一致するポリシーを保持するアプリケーション・ドメインの名前 |
|
policy_res |
リクエストに一致するリソース・ホストIDおよびURLパターン |
|
res_policy |
リクエストに一致する特定のポリシーの名前 |
|
res_host |
リクエストしたリソースのホスト名 |
|
res_port |
リクエストしたリソースのポート番号 |
|
res_type |
リクエストしたリソースのタイプ |
|
res_url |
リクエストしたリソースURL |
この項の内容は次のとおりです。
レスポンス・タイプとネームスペースおよび変数を決定した後、管理コンソールでレスポンス属性を入力します。図9-12に示すように、単純なレスポンスはいくつかの認可レスポンスのいずれかのようになります。
単純なレスポンスはスタンドアロンです。それぞれの先頭にドル記号（$）が付けられ、変数値とドット（.）で区切られるネームスペースがその後に付けられます。次に例を示します。
$namespace1.var1
表9-11は、いくつかの単純なレスポンスおよびそれぞれに戻される内容の説明を示しています。
表9-11 単純なレスポンスおよび説明
| 名前 | タイプ | 値（単純な$ネームスペース.変数） | 戻される環境変数および値 |
|---|---|---|---|
oam_literal |
ヘッダー |
これはレスポンス文字列です。 |
HTTP_OAM_LITERAL これはレスポンス文字列です。 |
|
oam_sessioncount |
ヘッダー |
$session.count |
HTTP_OAM_SESSIONCOUNT 整数 |
|
oam_userid |
ヘッダー |
$user.userid |
HTTP_OAM_USERID 名前 |
|
oam_ipaddress |
ヘッダー |
$request.client_ip |
HTTP_OAM_IPADDRESS nnn.nn.nn.nnn |
複合的または複雑なポリシー・レスポンスを作成する場合、管理者は、中括弧{}を使用してリテラルおよび変数を任意に結合して式を構築できます。コロン（:）はセパレータとして使用されます。次に例を示します。
${namespace1.var1}:${namespace2.var2}
リテラル文字列（LS）: ${namespace1.var1}:${namespace2.var2}
LS: ${namespace1.var1}, LS:${namespace2.var2}
図9-13は、管理者によって定義されるいくつかの複雑なレスポンスを示しています。すべてがヘッダー・タイプ・レスポンスで、ダウンストリーム・アプリケーションで利用されるHTTPリクエストのヘッダー変数の値が設定されます。
表9-12は、図9-13のような複雑なレスポンスを示しています。
表9-12 複雑なレスポンス
| 名前 | 値 | 戻される環境変数および値 |
|---|---|---|
|
oam_resinfo |
ランタイム・リソース: ${request.res_host}:${request.res_port}${request.res_url} |
HTTP_OAM_RESINFO ランタイム・リソース: myhost.domain.com:1234/cgi-bin/myres3 |
|
oam_clientinfo |
ランタイム・クライアント: エージェントID: ${request.agent_id}、ブラウザIP: $request.client_ip |
HTTP_OAM_CLIENTINFO ランタイム・クライアント: エージェントID: RREG_OAM、ブラウザIP: 123.45.67.891 |
|
oam_userinfo |
${user.userid}のグループ: ${user.groups}、説明: ${user.attr.description} |
HTTP_OAM_USERINFO WebLogicのグループ: 管理者、説明: このユーザーはデフォルトの管理者です。 |
|
oam_sessioninfo |
セッションの作成/有効期間/数: ${session.creation}/${session.expiration}/${session.count} |
HTTP_OAM_SESSIONINFO セッションの作成/有効期間/数: Tue Feb 23 17:47:42 PST 2010/Wed Feb 24 01:47:42 PST 2010/7 |
|
oam_app_user |
$user.userid |
HTTP_OAM_USERID 名前 |
詳細は、「ポリシー・レスポンス処理について」を参照してください。
ポリシー・レスポンス処理は、認証レスポンスを再実行する認可リクエストの実行中に発生します。変数の参照に適切な値が入力され、すべての変数に値が設定されて認可値で一貫して設定できることを確認します。
一連の手順を実行して、レスポンスの式を処理します。
スキャナ/トークナイザ
パーサー
インタープリタ
解釈中、値の変数の参照が解決します。処理後の結果は単純な文字列値で、エージェントに伝播されるか、将来の使用に備えてセッション内に保存されます。
最初の適用される認可リクエストの認可レスポンスとともに認証の成功レスポンスが保存され、“再実行”されます。
認可レスポンスの式は、式の評価（成功、失敗または未確定）に応じて実行されるアクションを作成します。
|
注意: OAM 10gは、“認証WebGate”構成と同じ動作を示します。これは、10g WebGateを使用するOAM 11gでも採用されます。10g WebGateは、認証WebGateと同様に機能するOAM 11g資格証明コレクタに常にリダイレクトします。 |
変数を参照すると、値または次の内容が戻されます。
変数が設定されていない場合、NOT FOUNDが戻されます。
変数がnull値に設定されている場合、NULLが戻されます。
|
注意: 次のレスポンスを確認します。
|
処理のないパススルー
処理しないでパススルーを実行する必要がある値は、\を使用して識別できます。次に例を示します。
\$1000
値$1000の結果が戻される値に表示されます。
ポリシーおよびレスポンスを使用してシングル・サインオンを有効化し、他のディレクティブを上書きできます。この項のアクティビティを開始する前に、「SSOのポリシー・レスポンスの概要」を確認してください。
特に指定のないかぎり、この項の情報が認証および認可レスポンスに同等に適用されます。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して認証または認可のポリシー・レスポンスを追加できます。
前提条件
認可レスポンスを作成する前に認可制約を分析して、レスポンスによって適切なアクションが実行されることを確認します。既存の認証または認可ポリシーを使用するアプリケーション・ドメインが必要です。
ポリシー・レスポンスを追加するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
目的のポリシー名をダブルクリックして、ページを開きます。
「レスポンス」タブをクリックしてアクティブ化し、「追加」ボタンをクリックします。
「名前」フィールドに、このレスポンスの一意の名前を入力します。
「タイプ」リストから、レスポンス・タイプ（セッション、ヘッダーまたはCookie）を選択します。
「値」フィールドに、このレスポンスの値を入力します。たとえば、$namespace1.var1などです。
必要に応じて繰り返します。
「適用」をクリックして、確認ウィンドウを閉じます。
終了する場合はページを閉じます。
定義に基づいて、次のレスポンスを確認します。
ヘッダー
セッション
Cookie: ブラウザのプラグイン・ツールを使用するか、ブラウザの「Cookieを表示する」設定をオンにします。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して認証または認可のポリシー・レスポンスを表示または編集できます。
前提条件
既存の認証または認可ポリシーを使用するアプリケーション・ドメインが必要です。
ポリシー・レスポンスを表示、変更または削除するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
目的のポリシー名をダブルクリックして、ページを開きます。
レスポンス: 「レスポンス」タブをクリックして、必要に応じて先に進みます。
レスポンスを追加します（「SSOのポリシー・レスポンスの追加」を参照してください）。
編集: 目的のレスポンスの名前、タイプまたは値をクリックして、必要に応じて編集して「適用」をクリックします。
削除: 目的のレスポンスをクリックして、「レスポンス」表の「削除」ボタンをクリックします。
レスポンス: 次のようにレスポンスを編集します。
「レスポンス」タブをクリックします。
目的のレスポンスの名前、タイプまたは値をクリックします。
目的の変更を実行します。
必要に応じて繰り返し、終了したら「適用」をクリックします。
「適用」をクリックして、確認ウィンドウを閉じます。
終了する場合はページを閉じます。
定義に基づいて、次のレスポンスを確認します。
ヘッダー
セッション
Cookie: ブラウザのプラグイン・ツールを使用するか、ブラウザの「Cookieを表示する」設定をオンにします。
アプリケーション・ドメインの特定の認可ポリシー内のすべてのリソースに認可制約を適用するには、管理者が認可制約を指定する必要があります。
認可制約は、リソースのリクエストのコンテキストに基づいて特定のリソースのアクセスを付与または拒否するルールです。認可制約は、クライアントのリクエストに応答する前に満たす必要がある必須処理（要件）を定義します。
制約の評価により、認可ポリシーを着信リクエストに適用するかどうかが決定されます。認証に成功した後、適切な必須処理が有効になり、定義された認可レスポンスと連携して動作します。着信リクエストごとに、認可ポリシーによって制約が存在するかどうかが決定されます。認可中に制約が評価されます。
許可または拒否タイプの制約
各認可ポリシーは、リクエストしたリソースのアクセスを付与または拒否するかどうかを決定する1つ以上の認可制約を含むことができます。
認可制約は次のとおりです。
保護されたリソースへのアクセスを認可されるユーザーを指定する許可タイプの条件。
保護されたリソースへのアクセスを拒否されるユーザーを明示的に指定する拒否タイプの条件。
|
注意: 特定のポリシー内の制約を定義する場合、1つの結果（許可または拒否）のみが許可されます。 |
制約クラス
異なる制約クラスを使用すると、同じ認可ポリシー内に異なる制約を構成できます。たとえば、次の目的で制約を構成できます。
保護されたリソースのアクセスを許可または拒否するユーザーまたはユーザー・グループの識別。
保護されたリソースのアクセスを許可または拒否するIPアドレスの範囲の指定。
|
注意: ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。 |
制約を適用する期間を定義する時間の設定。
この項の内容は次のとおりです。
各認可制約により、許可または拒否タイプの結果を含むことができます。「暗黙的な制約の使用」オプションを認可ポリシーに設定して、認可制約がない場合のアクセスを許可できます。
アクセスの許可条件がユーザーに適用されない場合、ユーザーがポリシーの対象外となり、デフォルトでリクエストしたリソースへのユーザーのアクセスが拒否されます。
|
注意: 制約が定義されていない場合および「暗黙的な制約の使用」が有効ではない場合、アクセスが拒否されます。 |
ユーザーおよびグループを分析して明示的にアクセスを許可または拒否するユーザーを決定する場合、ポリシーおよび制約に同じ情報を使用することをお薦めします。たとえば、特定のユーザー・グループ（アイデンティティ・クラス）に制約される認可ポリシーがある場合、特定の時間（一時的クラス）に制約される認可ポリシーがある可能性があります。
|
注意: 任意の条件でアクセスを拒否されるユーザーについては気にしないでください。制約が適用されない場合、デフォルトでアクセスが拒否されます。 |
ユーザーを分類する場合、ユーザーおよびユーザー・グループを異なる条件が適用されるグループに分割することをお薦めします。たとえば、制約を使用して、ユーザーがリソースにアクセスできる時間やリクエストを実行する必要があるコンピュータなどを決定できます。
マーケティング・グループのユーザーが特定のプロジェクト・グループに属し、人事管理グループのユーザーもプロジェクト・グループに属する場合などの一部のユーザーが複数のカテゴリに該当する場合、両方のカテゴリにユーザーを配置します。ユーザーは、2つの制約の条件を満たす必要があります。
制約クラスごとに、認可されたユーザーに発生するレスポンス・アクションを検討します。たとえば、次のようにユーザー・プロファイル情報を戻してその情報をダウンストリーム・アプリケーションに渡すシステムを使用できます。
ユーザーが認可されている場合、アプリケーションでカスタマイズされたメッセージをユーザーに表示できるように、ユーザーのcn（共通名）を別のアプリケーションに渡すことができます。
ユーザーが認可されていない場合、セキュリティ目的でユーザーの情報を戻すこともできます。
管理者が制約を認可ポリシーに追加すると、制約の名前、クラスおよび結果タイプを取得する図9-15のウィンドウが表示されます。送信されると、この情報を使用して、管理者が指定する必要がある制約詳細のコンテナを作成します。
表9-14は、「制約の追加」ウィンドウ要素を示しています。
表9-14 「制約の追加」ウィンドウの要素
| 要素 | 説明 |
|---|---|
|
名前 |
この制約の一意の名前。 |
|
クラス |
1つのクラス（アイデンティティ、IP4範囲または一時的）のみを指定できます。 |
|
タイプ |
結果タイプ: アクセスを許可または拒否します。 |
|
選択済の追加 |
このボタンをクリックして、制約コンテナの作成を開始します。 |
一般的な詳細を指定した後、図9-16に示すように、制約コンテナがポリシー・ページに追加および表示されます。ここでは、名前、クラスおよびタイプが表示されます。ただし、ウィンドウ・コントロール（図の赤い円）により、管理者は選択された制約の詳細を指定できるウィンドウを開くことができます。
次の項に示すように、制約の詳細は選択された制約クラスに固有です。
アイデンティティ制約クラスを使用する場合、管理者はユーザー移入を制約に追加する必要があります。制約コンテナを開いた後、定義されたユーザー移入が表示されます。他の制約のように、アイデンティティ制約および一時制約と組み合せてこれを使用できます。
ユーザー移入が指定されない場合、図9-18のような画面が表示されます。
図9-18は、「選択したユーザーとグループ」表の「追加」ボタンをクリックすると表示される「ユーザー移入エントリの追加」ウィンドウを示しています。この表でいくつかの移入（ユーザー、グループまたはすべて）から選択できます。
表9-15は、「ユーザー移入エントリの追加」要素を示しています。
表9-15 アイデンティティ・クラス制約の詳細
| 要素 | 説明 |
|---|---|
|
検索 |
使用可能な検索タイプのリスト: ユーザー、グループまたはすべて |
|
テキスト・フィールド |
特定のユーザーまたはグループの名前を入力して、矢印ボタンをクリックします。 |
|
結果表 |
選択する検索結果を表示します。 |
|
選択済の追加 |
結果表から制約詳細ページに選択したユーザーまたはグループを追加します。 |
1つ以上の移入を選択した後に「選択済の追加」ボタンをクリックすると、図9-19のような画面が表示されます。
制約としてこれらの詳細を保存するには、詳細ページの右上の「保存」ボタンをクリックします。
IP4Range制約クラスを使用する場合、管理者は、アクセスを許可または拒否するIPアドレスの範囲を追加する必要があります。他の制約のように、アイデンティティ制約および一時制約と組み合せてこれを使用できます。
図9-20に示すように、999.999.999.999形式で各IPアドレスを指定する必要があります。
一時制約クラスを使用する場合、管理者は、開始時間、終了時間および曜日を追加する必要があります。他の制約のように、アイデンティティ制約およびIP4Range制約と組み合せてこれを使用できます。
図9-18では何も選択されていませんが、デフォルトですべての曜日が有効です。
グリニッジ標準時（GMT）の24時間制に基づくHH:MM:SS（時間、分、秒）形式で期間を指定する必要があります。深夜は00:00:00（開始）に指定します。24:59:59で1日が終了します。
表9-16 一時制約クラスの詳細
| 要素 | 説明 |
|---|---|
|
タイプ |
結果タイプ: アクセスを許可または拒否します。 |
|
開始時間 注意: 完全な24時間の範囲で時間を指定します。たとえば、深夜を00:00:00に指定して、午後11時を23:00:00に指定します。 |
この制約が開始される時間、分および秒を指定します。 注意: 時間はグリニッジ標準時（GMT）に基づいています。GMTは、夏時間またはサマー・タイムの調整がなく1年中同じです。 |
|
終了時間 |
この制約が終了する時間、分および秒を指定します。 |
|
日 |
このポリシーがアクティブな日を指定します。 デフォルト: すべての日（ただし、ここでは選択されていません。） |
このページを閉じる前に、詳細を保存します。
この項の内容は次のとおりです。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してアイデンティティ・クラス制約をアプリケーション・ドメインに追加できます。
|
注意: 別の制約を追加または選択する前に、個々に各制約定義を保存する必要があります。 |
前提条件
アプリケーション・ドメインがすでに存在する必要があります。
アイデンティティ・クラス制約を認可ポリシーに追加するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
目的のポリシー名をダブルクリックして、ページを開きます（または、ツールバーの「編集」コマンド・ボタンをクリックします）。
「制約」タブをクリックします。
「制約」タブの「追加」ボタンをクリックして、「制約の追加」ウィンドウ（表9-14）を表示します。
「名前」フィールドに、この制約の一意の名前を入力します。
「クラス」リストから、制約タイプとして「アイデンティティ」を選択します。
「タイプ」の横のオプション・ボタン（「許可」または「拒否」）をクリックします。
「制約の追加」ウィンドウの「選択済の追加」をクリックします。
表の新しい制約をハイライト表示して、詳細表の「追加」ボタンをクリックします。
ユーザー移入エントリの追加: 「ユーザー」、「グループ」または「すべて」を選択します。目的の検索基準を入力して、目的の結果を選択し、「選択済の追加」をクリックします。
詳細ウィンドウをスクロールして定義を確認し、「保存」をクリックします。
必要に応じて繰り返します。
「適用」をクリックして、確認ウィンドウを閉じます。
終了する場合はページを閉じます。
制約を確認します。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してIP4範囲クラス制約をアプリケーション・ドメインに追加できます。
|
注意: ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。 |
前提条件
アプリケーション・ドメインが存在する必要があります。
|
注意: 別の制約を追加または選択する前に、個々に各制約定義を保存する必要があります。 |
IP4範囲クラス制約を認可ポリシーに追加するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
目的のポリシー名をダブルクリックして、ページを開きます。
「制約」タブをクリックします。
「制約」タブの「追加」ボタンをクリックして、「制約の追加」ウィンドウ（表9-14）を表示します。
「名前」フィールドに、この制約の一意の名前を入力します。
「クラス」リストから「IP4範囲」を選択します。
「タイプ」の横のオプション・ボタン（「許可」または「拒否」）をクリックします。
「制約の追加」ウィンドウの「選択済の追加」をクリックします。
目的のIPアドレス範囲を追加します（表9-15を参照してください）。
「開始」フィールドに範囲の開始を入力します。
「終了」フィールドに範囲の終了を入力します。
「タイプ」の横のオプション・ボタン（「許可」または「拒否」）をクリックします。
「保存」をクリックします。
「適用」をクリックして、確認ウィンドウを閉じます。
IP4範囲制約を確認します。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用して一時的クラス制約をアプリケーション・ドメインに追加できます。
|
注意: 別の制約を追加または選択する前に、個々に各制約定義を保存する必要があります。 |
前提条件
アプリケーション・ドメインが存在する必要があります。
一時的クラス制約を認可ポリシーに追加するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
目的のポリシー名をダブルクリックして、ページを開きます。
「制約」タブをクリックします。
「制約」タブの「追加」ボタンをクリックして、「制約の追加」ウィンドウを表示します。
「名前」フィールドに、この制約の一意の名前を入力します。
「クラス」リストから、「一時的」を選択します（表9-14を参照してください）。
「タイプ」の横のオプション・ボタン（「許可」または「拒否」）をクリックします。
「制約の追加」ウィンドウの「選択済の追加」をクリックします。
一時的な詳細の追加（表9-16）: 制約の名前をダブルクリックして、詳細パネルを拡張します。
制約タイプの横のオプション・ボタン（「許可」または「拒否」）をクリックします。
開始時間を入力します。
終了時間を入力します。
この制約を適用する曜日をクリックします（またはすべてを空白にして毎日を指定します）。
「保存」をクリックします。
必要に応じて繰り返します。
「適用」をクリックして、確認ウィンドウを閉じます。
一時制約を確認します。
有効なOAM管理者の資格証明を持つユーザーは、次の手順を使用してアイデンティティ・クラス制約をアプリケーション・ドメインに追加できます。
前提条件
アプリケーション・ドメインおよび認可ポリシーがすでに存在します。
認可ポリシーの制約を表示、編集または削除するには、次の手順を実行します。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを拡張します。
目的のポリシー名をダブルクリックして、ページを開きます。
「制約」タブをクリックします。
制約詳細の表示: 制約名を含む行をクリックして、下部のパネルの詳細を表示します。
制約の編集: 制約名を含む行をクリックして、次の項に従って詳細を変更およびすぐに保存します。
制約の削除: 削除する制約をクリックして、「制約」タブの「削除」ボタンをクリックします。
「適用」をクリックして、確認ウィンドウを閉じます。
終了する場合はページを閉じます。
リソースにアクセスして結果を評価して、制約を確認します。
SSOエンジンは、ユーザー・セッションのコントローラです。SSOエンジン設定は、管理ドメインのすべてのOAMサーバーに共通です。
この項の内容は次のとおりです。
SSOエンジンは、ユーザー・セッションのコントローラです。SSOエンジン設定はグローバルで、WebLogic管理ドメインのすべてのOAMサーバーに共通です。
図9-22は、すべてのOracle Access Managerサーバー・インスタンスで共有される共通のSSOエンジン設定を示しています。
表9-17は、タイプ（テキスト文字列）および値を含む共通のSSOエンジン設定を示しています。
有効なOAM管理者の資格証明を持つユーザーは、次のタスクを実行してOAM管理コンソールで共通のSSOエンジンの詳細を変更できます。
共通のSSOエンジンの詳細を表示または編集するには、次の手順を実行します。
「システム構成」タブのナビゲーション・ツリーから、サーバー・インスタンスをダブルクリックして、サーバー共通プロパティ・ページを表示します。
サーバー共通プロパティ・ページで、「SSOエンジン」タブをクリックします。
表示のみ: 終了する場合はページを閉じます。
変更: 残りの手順を実行して、共通のSSOエンジン構成を編集します。
表9-17の詳細に基づいて、デプロイメントの必要に応じて、設定を編集します。
「適用」をクリックして変更を送信します（または変更を適用しないでページを閉じます）。
確認ウィンドウを閉じます。
ここでの手順は、エージェント登録と認証および認可ポリシーを操作できることを確認するいくつかの方法を示しています。手順は、OAMエージェントおよびOSSOエージェント（mod_osso）でほとんど同じです。ただし、OSSOエージェントは認証ポリシーのみ使用し、認可ポリシーは使用しません。
前提条件
アクセス権を付与されるユーザーおよびグループは、OAM 11gに登録されるプライマリLDAPユーザー・アイデンティティ・ストアに存在する必要があります。
OAM 11gで操作するためにエージェントを登録する必要があります。登録後、管理サーバーまたは管理対象サーバーを再起動することなく適切な認証とともに保護されたリソースにアクセスできる必要があります。
アプリケーション・ドメイン、認証ポリシーおよび認可ポリシーを構成する必要があります。
認証およびアクセスを確認するには、次の手順を実行します。
Webブラウザを使用すると、登録されたエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します（認証リダイレクトURLが適切に指定されたことが証明されます）。次に例を示します。
http://myWebserverHost.us.abc.com:8100/resource1.html
ログイン・ページにリダイレクトしていることを確認します。
サインイン・ページで、求められた場合に有効なユーザー名およびパスワードを入力し、「サインイン」をクリックします。
リソースにリダイレクトしていることを確認し、先に進みます。
成功: 正しく認証され、リソースへのアクセスが付与された場合、構成が正常に動作します。
失敗: ログイン中にエラーを受け取った場合またはリソースへのアクセスが拒否された場合、次の項目を確認します。
失敗した認証: 有効な資格証明を使用して再度サインインします。
URL...のアクセスの拒否: このリソースのアクセスにこのユーザーIDが認可されていません。
使用不能なリソース: リソースが使用できることを確認します。
不正なリダイレクトURL: 管理コンソールのリダイレクトURLを確認します。
