25 リソースの保護およびSSOの有効化ポリシーの管理
Access Managerアプリケーション・ドメインおよびポリシーへのアクセス、およびこれらの管理は、Oracle Access Managementコンソールから行うことができます。
次の各トピックでは、ポリシーの作成および管理方法について説明し、それらのポリシーを制御するリソースを確認します。
25.1 ポリシーの管理およびリソースの保護のための前提条件
ポリシーの管理とリソースの保護を続行する前に、システム・レベル要件が満たされていることを確認します。
次に、この章のタスクを実行するための要件を示します。
-
OAMサーバーが実行されている必要があります。
-
保護されたリソースにアクセスできるユーザーおよびグループがOracle Access Managementに関連付けられたユーザー・アイデンティティ・ストアにすでに作成されている必要があります。
-
ポリシー強制エージェントが登録されている必要があります。
-
任意のアプリケーション・ドメインで使用する共有コンポーネントが定義されている必要があります。
25.2 アプリケーション・ドメインおよびポリシーの作成の概要
アプリケーション・ドメインは、Access Manager 11gポリシー・モデルの最上位の構造です。各アプリケーション・ドメインでは、リソースまたはリソースのセットに対する論理コンテナと、特定の保護リソースにアクセスできるユーザーを示す、関連付けられたポリシーが提供されます。
各アプリケーション・ドメイン内では、特定の共有コンポーネントが使用されます。各アプリケーション・ドメインは、特定のホスト上の単一のアプリケーションを表します。または、管理者が、同じWebサーバー上にあって互いに緊密に連携しているリソースに対してそれぞれ異なるアプリケーション・ドメインを定義できます。たとえば、管理者は、財務アプリケーションおよび売掛金勘定アプリケーション用に単一のアプリケーション・ドメインを作成することも、各アプリケーション用に異なるアプリケーション・ドメインを使用することもできます。構成可能なポリシーを使用して、リソースへのアクセスを許可または拒否できます。
ノート:
セキュリティ強化のため、Access Managerは、デフォルトで、リソースがアクセスを明示的に許可するポリシーによって保護されていない場合、アクセスを拒否します。
各Access Managerのアプリケーション・ドメインには次の情報が含まれています。
-
リソース定義
アプリケーション・ドメインの各リソース定義には、リソース・タイプ、ホスト識別子(HTTPリソースの場合)および特定のリソースへのURLが必要です。アプリケーション・ドメインには必要なだけリソース定義を含めることができます。
-
認証ポリシーおよび特定のリソースへのレスポンス
それぞれの認証ポリシーには、一意の名前、ひとつの認証スキーム、成功および失敗のURL、このポリシーが適用される1つまたは複数のリソース、認証が成功した後に適用される管理者が定義したレスポンスが含まれます。
ノート:
認証または認可の成功と失敗に指定されたポリシーのレスポンスに応じて、エンド・ユーザー特定のURLにリダイレクトされたり、ユーザー情報がヘッダー変数やcookieの値を通じて他のアプリケーションに渡されることがあります。
-
特定のリソースに対する認可ポリシー、条件、ルールおよびレスポンス
それぞれの認可ポリシーには、一意の名前、成功および失敗のURL、このポリシーが適用される1つまたは複数のリソースが含まれます。さらに、管理者は認可が成功するために満たされなければならない特定の条件と、認可が成功した後で適用されるレスポンスを定義できます。
-
ポリシー順序付け
ポリシー順序付けとは、同じアプリケーション・ドメイン内のポリシーが保護リソースへのアクセス着信リクエストと一致する順序を管理者が手動で指定できる新しい機能です。以前のバージョンのAccess Managerでは、この目的における最善一致アルゴリズムが使用されていました。
新しいアプリケーションを既存のエージェントの背後に配置する場合、管理者は、アプリケーションを個別の(新しい)アプリケーション・ドメインおよびポリシーで保護するのか、既存のアプリケーション・ドメインおよびポリシーで保護するのかを決定する必要があります。この項には、次の項の情報が含まれています。
25.2.1 アプリケーション・ドメインおよびポリシーの自動生成について
Access Managerでポリシー強制エージェントを登録するときに、ドメインとポリシーを自動生成することを選択(または拒否)できます。
自動的に作成されるアプリケーション・ドメインには、エージェントに基づく名前が付けられ、デフォルトのリソースおよび基本ポリシー(認証および認可)でシードされます。空のコンテナが提供されますが、トークン発行ポリシーは定義されません。
エージェントの登録中、保護するアプリケーションと同じWebサーバー上にエージェントがあると仮定します。ただし、エージェントをプロキシWebサーバー、アプリケーションを異なるホストに配置できます。デフォルトのリソースは、管理者がリソースを追加したり、ポリシーを変更または追加するまで、基本ポリシーによって保護されます。
25.2.2 アプリケーション・ドメインとポリシーのリモート管理について
Access Managerには、付属のエージェントを登録または変更せずにアプリケーション・ドメインとそのポリシーを管理する2つのモードがあります。
リモート・ポリシーおよびアプリケーション・ドメイン管理でサポートされるのは、作成および更新の機能のみです。リモート管理では、アプリケーション・ドメインやポリシーの削除はサポートされていません。詳細は、「ポリシーおよびアプリケーション・ドメインのリモート管理の理解」を参照してください。
25.3 アプリケーション・ドメインおよびポリシーの管理の理解
エージェントの登録時に、手動でアプリケーション・ドメインを作成しても、ポリシーの自動生成を受け入れても、アプリケーション・ドメインの要素は同じになります。すべてのポリシーおよびアプリケーション・ドメインは、Oracle Access Managementコンソールを使用して管理します。
詳細は、次のトピックを参照してください:
25.3.1 アプリケーション・ドメインのページ
図25-1は、アプリケーション・ドメインの検索ページ、コントロール、および独自のツール・バーを含む「検索結果」表を示しています。
25.3.2 アプリケーション・ドメインの「サマリー」ページ
検索結果で、アプリケーション・ドメインの名前をクリックすると、「サマリー」タブに、名前、オプションの説明、ポリシー順序付け構成が表示されます。
他の情報は次のタブに表示されます。
-
リソース
-
認証ポリシー
-
認可ポリシー
-
トークン発行ポリシー
-
管理
図25-2は、一般的な「アプリケーション・ドメイン」ページのスクリーンショットです。生成されたアプリケーション・ドメインの場合、次のように「名前」および「説明」が移入されます。手動でアプリケーション・ドメインを作成する場合、「説明」は管理者によって入力されます。
25.3.3 アプリケーション・ドメインのリソース・コンテナ
アプリケーション・ドメインの「リソース」タブには、そのドメインのすべてのリソース定義のコンテナが表示されます。「リソース」タブをクリックして表示すると、特定の定義をすばやく検索できる「検索」コントロールが使用可能になります。
図25-3は、リソース定義の検索結果を絞り込むことができる「検索」コントロールを示しています。右上隅には「新規リソース」ボタンも表示されます。「検索結果」表では、検索された各定義の主要な情報が提供されます。
デフォルトのリソース・タイプはHTTPですが、デフォルトのリソースURLは/**です。HTTPリソース定義を使用すると、そのリソース用に定義された問合せ文字列に基づいて検索を実行できます。この問合せ文字列に使用できるのはベースURLのみで、一連のURLを示すオプションのパターン一致特殊文字を含めることができます。この生成されたドメインでは、「ホスト識別子」が、登録されたHTTPエージェントの名前に一致します。ポリシーの基本情報も提供されます。
関連項目:
25.3.4 認証ポリシーのページ
「認証ポリシー」タブでは、検索コントロールを使用することなく、定義または生成されたポリシーにアクセスできます。
管理者がアプリケーション・ドメインを手動で作成する場合、その管理者はポリシーもすべて手動で作成する必要があります。生成されたアプリケーション・ドメインでは、図25-5のように、2つの認証ポリシーが自動的に作成されます。
-
認証ポリシー: Protected Resource Policy
-
認証ポリシー: パブリック・リソース・ポリシー
認証ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。1つの認証ポリシーでのみ、各リソースを保護できます。
図25-5は、「保護されたリソース・ポリシー」、およびポリシーの「リソース」タブに自動的に表示される情報の列を示しています。「レスポンス」タブが使用可能です。
ノート:
最初は、すべてのリソースが保護されます。成功および失敗URLとレスポンスを手動で追加する必要があり、デフォルト値は提供されません。
自動生成時に次のような説明が提供されます。
"Policy set during domain creation. Add resources to this policy to protect them."
この生成されたポリシーでは、LDAPSchemeが認証スキームとして使用されます。ただし、ポリシーのオプション要素はまだ定義されていません。
保護されているリソースは、HostIdentifier/**として「リソース」タブで識別されます。
ノート:
管理者は、認証スキームの変更、成功URLと失敗URLの指定、他のリソースの追加およびSSOレスポンスの定義を行うことができます。
パブリック・リソース・ポリシー: 2つ目の認証ポリシーも自動生成されます。このポリシーでは、AnonymousSchemeが認証のデフォルト・スキームとして使用され、すべてのアクセスが許可されます。
このパブリック・リソース・ポリシーは、最初はいずれのリソースも含まず、いずれのリソースも提供しません。「説明」で管理者は要件を確認します。
Policy set during domain creation. Add resources to this policy to allow anyone access.関連項目:
25.3.5 認可ポリシーのページ
「認可ポリシー」タブでは、検索コントロールを使用することなく、定義または生成されたポリシーにアクセスできます。
生成されたアプリケーション・ドメインでは、次の2つの認可ポリシーが自動的に作成されますが、各リソースは1つの認可ポリシーによってのみ保護できます。
-
保護対象リソース・ポリシー
-
パブリック・リソース・ポリシー
図25-7は、「認可ポリシー」タブを示しています。このタブで、ポリシーを選択して新しいポリシーを編集または作成できます。
図25-7は、「認可ポリシー」ページを示しています。提供されるいくつかのタブでは、この認可ポリシーの様々なコンポーネントを定義できます。最初は、すべてのリソースが保護され、アクセスが拒否されます。成功URLと失敗URL、条件、ルールおよびレスポンスを手動で追加する必要があります(デフォルト値は提供されません)。
図25-8は、「認可ポリシー・リソース」タブを示しています。このページを使用し、このポリシーのリソースを追加(または削除)します。
管理者は、このポリシーの条件、ルールおよびレスポンスも定義できます。自動生成されるものはありません。
25.4 コンソールを使用したアプリケーション・ドメインの管理
アプリケーション・ドメインの管理には、一般的な設定とポリシー、およびリソース関連の設定とポリシーの追加、変更または削除が含まれます。
各アプリケーション・ドメインには、エージェント名と一致する一意の名前を使用する必要があります。新しいアプリケーション・ドメインの名前とオプションの説明を入力したら、「適用」をクリックして作成します。この手動作成により、一連のタブ(「サマリー」、「リソース」、「認証ポリシー」、「認可ポリシー」、「トークン発行ポリシー」)がすべて使用可能になります。
ノート:
リモート登録を使用してアプリケーション・ドメインが作成された場合、またはエージェントの登録中に作成された場合は、基本ポリシー情報も生成されます。詳細は、「ポリシーおよびアプリケーション・ドメインのリモート管理の理解」および「ポリシーおよびアプリケーション・ドメインのリモート管理」を参照してください。
この項では、Oracle Access Managementコンソールを使用してアプリケーション・ドメインを作成および管理する方法を説明します。次のトピックが含まれています:
25.4.1 新しいアプリケーション・ドメインの作成
新しいアプリケーション・ドメインが必要かどうか、またはリソースを既存のアプリケーション・ドメインに追加できるかどうかを決定します。単一のアプリケーション・ドメインを手動で作成し、リソースおよびポリシーを手動で追加すると、同じエージェントを使用して複数のアプリケーションを保護できます。
前提条件
この章の始めにある「ポリシーの管理およびリソースの保護のための前提条件」を参照してください。
新規アプリケーション・ドメインを作成する手順:
25.4.2 既存のアプリケーション・ドメインの検索
有効な管理者の資格証明を持つユーザーは、特定のアプリケーション・ドメインを検索できます。
ノート:
この検索操作では、大文字と小文字が区別されます。
アプリケーション・ドメインを検索するには
25.4.3 アプリケーション・ドメインの表示または編集
有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して、アプリケーション・ドメイン(そのリソース、ポリシー、条件およびレスポンスを含む)を表示または変更できます。
類似するアプリケーションを同じアプリケーション・ドメインにグループ化することをお薦めします。アプリケーション・ドメインを編集する場合、異なるアプリケーションが同じドメインを使用していることに注意してください。説明およびドメイン名の編集がサポートされます。
アプリケーション・ドメインおよびその内容を表示または変更するには
25.4.4 アプリケーション・ドメインおよびその内容の削除
有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して、アプリケーション・ドメイン(そのリソース、ポリシー、条件およびレスポンスを含む)を削除できます。
アプリケーション・ドメインおよびその内容を削除すると、エージェント登録など、参照されているすべてのオブジェクトが削除されます。この方法を使用すると、後から同じエージェントの再登録が必要になった場合、その操作が可能になります。これは、以前のアプリケーション・ドメインおよびその内容の参照が残っていないためです。
ノート:
削除操作中、アプリケーション・ドメインにポリシー要素が含まれている場合、アラートが表示されます。
前提条件
削除するドメインのリソースを別のアプリケーション・ドメインに配置して、保護されていることを確認します。
アプリケーション・ドメインを削除するには
- 「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。
- 削除するドメインのリソースを別のアプリケーション・ドメインに配置して、保護されていることを確認します。
- 「検索結果」表で、目的の名前の横にある「シリアル番号」をクリックし、ツール・バーの「削除」(x)ボタンをクリックします。
- 警告ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。
- 結果表で、アプリケーション・ドメインが削除されていることを確認します。
25.5 ポリシー・リソース定義の追加および管理
リソースの保護には、特定のリソースの定義を含むアプリケーション・ドメインが必要です。
OAMでは、次のような非HTTP/HTTPSベースのリソースおよびHTTP/HTTPSベースのリソースを含む様々なタイプのリソースを保護できます。
-
すべての外部Webサイト
-
Webサイトの特定のページ
-
パートナ・ポータル
-
部品注文アプリケーション
-
請求書アプリケーション
-
多くの国の企業のWebサーバーの福利厚生加入アプリケーション
このコンテナでリソースを定義すると、そのリソースをアプリケーション・ドメインのポリシーに追加できます。この項では次のトピックを記載しています:
25.5.1 アプリケーション・ドメインのリソース
既存の共有ホスト識別子を使用して、場所を指定します。
ノート:
明示的に「除外」とマークされていないリソースがポリシーに関連付けられていない場合、一致するポリシーがないため、すべてのユーザーのアクセスが拒否されます。
リソース定義のガイドライン
-
URL接頭辞はありません。リソースの定義は、完全なURLとして扱われます。
-
機能が制限された次のパターン一致
' * 'および'...'がサポートされます。
-
リソースをドメイン間で一意にする必要はありません。
-
HTTP URLの問合せ文字列保護。
-
各HTTPリソースはURLパスとして定義され、ホスト識別子と関連付けられます。ただし、他のタイプのリソースは、(ホスト識別子ではなく)特定の名前と関連付けられます。
-
特定の操作の定義によって、HTTP以外のリソース・タイプがサポートされます。HTTP以外のリソース・タイプにホスト識別子は関連付けられません。
-
リソースは、「保護」、「非保護」または「除外」として指定されます。
-
カスタム・リソース・タイプが許可されます。
図25-10は、「リソースの作成」ページを示しています。
表25-1では、リソース定義を構成する要素を示しています。
表25-1 リソース定義の要素
| 要素 | 説明 |
|---|---|
|
タイプ |
『Oracle Platform Security Servicesによるアプリケーションの保護』で説明しているように、Fusion Middlewareアプリケーション・シナリオには リソース定義を追加(またはリソースを検索)すると、定義されたすべてのカスタム・リソース・タイプがデフォルトのリソース・タイプとともにリストされます。 関連項目: 「リソース定義のリソース・タイプ」。 |
|
説明 |
このリソースのオプションの一意の説明。 |
|
ホスト識別子 |
共有コンポーネントとして定義されたすべての識別子を含むホスト識別子のリストを使用できます。ホスト識別子を選択して、リソースを割り当てる必要があります。 ノート: リソース定義を構成するホスト識別子およびURL文字列の組合せは、すべてのアプリケーション・ドメインで一意にする必要があります。 関連項目: 「ホスト識別子の管理」。 |
|
「URI」セクション |
情報は選択したリソース・タイプによって異なります。 |
|
問合せ 名前と値のリスト |
HTTPリソース・タイプの場合のみ。アクセス・ポリシーで使用する名前と値のペアのリストを提供できます。 関連項目: 「リソース定義の問合せ文字列の名前と値のパラメータ」。 |
|
問合せ 文字列 |
HTTPリソースの場合、問合せ文字列を提供し、アクセス・ポリシー内の完全一致するリテラル文字列を検索できます。 関連項目: 「リソース定義のリテラル問合せ文字列」。 |
|
リソースURL |
「/」文字で区切られた一連の階層レベルで構成される完全なURLのパス・コンポーネントを表す単一の相対URL文字列として、値を表現する必要があります。リソースのURL値は/で始まり、選択されたホスト識別子のリソース値と一致する必要があります。 内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。含まれる場合、パターン定義に使用できる特殊文字は次のとおりです。
表25-2も参照してください。 |
|
「操作」セクション |
許可される特定の操作を定義して、独自のリソース定義をカスタマイズできます。 ノート: Oracle提供のリソース・タイプは読取り専用です。Oracle提供のリソース・タイプに関連付けられた操作は定義する必要がなく、変更もできません。開発されOracle提供のリソース・タイプに適用されたポリシーは、すべての操作に適用されます。 |
|
使用可能な操作 |
このリソース定義で許可されるすべてのHTTP操作を識別します。開発され、このカスタマイズされたリソースに適用されたポリシーは、識別した操作にのみ適用されます。特に明記しないかぎり、使用可能な次の操作は、すべてHTTPリソース・タイプのみを対象としています。
ノート: エージェントの登録時に、リソース定義自体に操作が指定されなかった場合は、そのリソース・タイプのすべての操作がサポートされます。 関連項目: 「リソース・タイプおよびその使用」。 |
|
保護 |
リソース定義のこのセクションのコントロールを使用すると、このリソースに適用する保護レベルを識別し、使用するポリシーに名前を付けることができます。 |
|
保護レベル |
適切な保護レベルを次のオプションから選択します。
|
|
認証ポリシー |
指定したリソース保護レベルに基づく認証ポリシーのリストが使用可能になりました。このドメイン内にあり、指定した保護レベルに一致するポリシーのみがリストされます。 |
|
認可ポリシー |
ドメインで定義された認可ポリシーのリストが使用可能になり、そこからこのリソースを保護するためのポリシーを選択できるようになります。 |
リソースの追加後、名前が付けられたアプリケーション・ドメインの「リソース」ノードにグループ化されます。ポリシーを作成すると、ドメインに定義されたすべてのリソースがリストされ、そこからポリシーに含める1つ以上のリソースを選択できます。
リソース定義内の様々な仕様の詳細は、次のトピックを参照してください:
25.5.1.1 リソース定義のリソース・タイプ
リソース定義をアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択する必要があります。ネイティブ・リソース・タイプは読取り専用で、変更または削除できません。HTTP、TokenserviceRP、wl_authenなどがあります。
関連項目:
HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加します。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、ポリシーがすべてのHTTP操作に適用されます。
表25-2は、リソースのサンプルのURL値を示しています。詳細は、「リソースURL、接頭辞およびパターン」を参照してください。
表25-2 HTTPリソースのサンプルのURL値
| リソース | サンプルのURL値 |
|---|---|
|
ディレクトリ |
|
|
ページ |
|
|
Webアプリケーション |
|
25.5.1.2 リソース定義のホスト識別子
管理機能は、リソースが存在するホストおよびリソースURLでアプリケーション・ドメインのリソースを識別します。
ノート:
HTTP以外のリソース・タイプにホスト識別子は関連付けられません。かわりに、管理者は、リソース定義ページの「リソースURL」フィールドにタイプの名前を入力する必要があります。
ホスト識別子は各リソースのコンテキストを作成するので、同じURLパスまたは異なるコンピュータのリソースを追加する場合に役立ちます。管理機能により、同じアプリケーション・ドメイン内のこれらのすべてのリソースを同じ方法で保護できます。一連のリソースを区別する唯一の違いは、ホスト・コンピュータの識別です。
すべての定義されたホスト識別子がリソース・ページの「ホスト識別子」リストに表示されます。リソースをアプリケーション・ドメインに追加する場合、管理機能でリソースをホストするコンピュータの1つのホスト識別子を選択する必要があります。
Access Managerは、リソースのURLを認識できるよう、そのリソースのホスト・コンピュータを参照するために使用される様々な方法を認識できる必要があります。
25.5.1.3 リソースURL、接頭辞およびパターン
自動的なアプリケーション・ドメインの生成中、すべてのリソースが保護されるURL接頭辞が定義されます。Access Managerポリシー・モデルでは、リソース接頭辞がサポートされません。管理者は、詳細なURLパターンを作成できます。
リソースは線形で階層ではありません。リソースの定義は、完全なURLとして扱われます。
ノート:
非HTTPリソース・タイプに関連付けられるホスト識別子はありません。
管理機能は、特定のリソースURLを使用して、アプリケーション・ドメインの個々のリソースを識別します。個々のリソースURLをドメイン間で一意にする必要はありません。ただし、リソースURL、問合せ文字列およびホスト識別子の組合せをドメイン間で一意にする必要があります。
HTTPタイプのリソースは、パスを表す単一の相対URL文字列として表現されます。文字列は、「/」文字で区切られた一連の階層レベルで構成されます。内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。
URL接頭辞
Access Managerポリシー・モデルでは、リソース接頭辞がサポートされません。つまり、ポリシーの継承はありません。
ポリシーが/mydirectory/projects/に定義されている場合、そのURLにのみ適用されます(/mydirectory/projects/index.htmlなどには適用されません)。
同じ接頭辞文字列を使用したすべてのリソースのポリシーが必要な場合、特殊文字(/mydirectory/projects/.../*などの3つのピリオド...(省略記号)または*(アスタリスク))を使用してリソースを定義できます。
ノート:
Access Managerポリシー・モデルでは、ポリシーの継承はありません。
URLパターン、一致および優先順位
詳細なURLパターンにより、リソースのネームスペースの詳細な部分を指定します。すべての照合で、大文字/小文字が区別されます。
表25-3 リソースURLパターンでサポートされるワイルドカード(優先順)
| パターン | 説明 | 例 |
|---|---|---|
|
/** |
デフォルト。スラッシュ(/)で始まる0個以上の文字の連続に一致します。 このパターンを使用すると、特定の名前付きディレクトリの下にあるパスを保護できます。 ノート: これは既存の12cワイルドカードではありません。12cでは、/.../*パターンによって、パターンが定義されたレベルのルートを含まない排他的な一致が返されました。たとえば、/foo/.../*は/foo/barおよびルート・ディレクトリ/foo/自体と一致しますが、foo/にも/foo/にも一致しませんでした。12cでは接頭辞(ルート)が認識されるため、ほとんどの評価は接頭辞を取り除いた後に実行されました。 |
· /** 一致する内容 /foo/bar /foo/ |
|
リテラル |
リソースのパターンには、特殊文字が含まれません。 |
|
|
{パターン1,パターン2,...} |
パターン集合の1つに一致します。 中カッコ内部のパターン自体には、その他の特殊文字を含めることができます(中カッコは除きます。パターン集合はネストできません)。 |
|
|
[範囲またはセット] |
文字集合の1つに一致します。 集合は、リテラル文字列または文字範囲として指定できます。文字範囲とは、ハイフン(-)で結ばれた任意の2文字間のすべての文字です。 文字範囲とは、ハイフン(-)で結ばれた任意の2文字間のすべての文字です。 スラッシュ(/)は、集合に入れることができない無効な文字です。 文字集合は、/を含んだ範囲が指定されている場合でも、/には一致しません。 |
|
|
単一文字のワイルドカード? |
?(疑問符)は、「/」以外の任意の1文字に一致します。これは問合せ文字列のデリミタとしては扱われません。 |
a?bは、aabとazbには一致しますが、a/bには一致しません。 |
|
ワイルドカード* |
* (アスタリスク)ワイルドカードは、連続する0個以上の文字に一致します。ただし、* (アスタリスク)は前方のスラッシュ(/)には一致しません。 |
a*bは、ab、azb、azzzzzzbには一致しますが、a/bには一致しません。 |
|
* |
* (アスタリスク)は、最下位の終端レベルのパスにのみ使用できます。0(ゼロ)または1つ以上の文字に相当します。 URLパターン内のすべての文字は対応するURLパス内の文字に正確に一致する必要があります。 例外:
|
次のURLパターン: /.../update.html 一致する内容: /humanresources/benefits/update.html /corporate/news/update.html update.html 関連項目: 表25-4 |
|
/.../階層 /.../* ホスト全体 |
スラッシュ(/)で囲まれた1つ以上の文字の連続に一致します。 評価はルート「/」から下の階層に向かって実行されます。各ディレクトリ・レベルで、最も高い優先レベルに一致するリソースが次の評価候補として選択された後、1つ下のレベルに進みます。これは、パス情報のみに基づく、可能な最善一致を表すリソースが取得されるまで続きます。 ホスト全体とは、パターン全体を意味します。 |
|
|
\ |
円記号は、特殊文字をエスケープするために使用します。前に円記号を付けた任意の1文字は、その文字自体に一致します。
|
|
表25-4は、ホスト識別子およびリソースURLに基づいてアルファベット順に整理された、アプリケーション・ドメイン内のいくつかのリソース定義を示しています。表25-4の右側の列は、形式が正しいかどうかを示しています。
表25-4 サンプル・リソースURL
| リソースURL | フォームが正しいかどうか |
|---|---|
|
/bank/accounts/* |
はい |
|
/bank/accounts/*.jsp |
はい |
|
/bank/accounts/checking |
はい |
|
/bank/.../checking.jsp |
はい |
|
/.../*.jsp |
はい |
|
/bank/accounts/checking*.jsp |
いいえ |
|
/bank/accounts/c*.jsp |
いいえ |
|
/bank/.../accounts/def.gif |
いいえ |
25.5.1.4 リソース定義の問合せ文字列の名前と値のパラメータ
ポリシー・モデルでは、リソース・パターン定義での問合せ文字列の名前と値のパラメータの使用がサポートされます。
-
名前: 記号などの任意の文字を含むことができる文字列リテラル。すべての文字がリテラルとして扱われます。
-
値: 任意の文字を含む文字列リテラルを指定できます。連続する0個以上の文字に一致させるには、ワイルドカード(*のみ)を含めます。アスタリスク(*)はワイルドカードとして扱われます。
-
量: 問合せ文字列に指定できる名前と値のペアの数に制限はありません。ただし、単一のリソースの場合、ペアは2、3個になります。
-
順序: 名前と値のペアには任意の順序を使用できます。実行時、これらのペアは問合せ文字列の一部として、任意の順序で処理される場合があります。
リソースの一致および優先順位: 問合せ文字列の名前および値のパラメータ
Access Managerでは、まず最も一致率の低いリソースを検出し、それよりも一致率の高いリソースを検出していくアルゴリズムが使用されます。単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、単一の文字列で定義された候補が優先されます。
パラメータ・リストを含むリソースの場合、次のように最善一致が決定されます。
-
パス一致: Access Managerによって、リクエストされたリソースのパスへの一致が試行されます。問合せコンポーネントや宣言された操作が異なる、複数の候補に一致する場合があります。
-
問合せ文字列一致: 取得した一致に対して、Access Managerによって、問合せ文字列(リクエストしたURL内に存在する場合)への一致が試行されます。単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、リテラル文字列で定義された候補が優先されます。操作が異なる複数の候補が残る場合があります。
-
操作一致: 取得した一致に対して、リクエストされた操作への一致が試行されます。完全一致が存在しない場合は、特定の操作が定義されていないリソースを確認します。つまり、リソース・タイプの一部として定義されているすべての操作に適用されます。いずれの場合も、これによって単一の最善一致が検出されます。
パス一致: 定義済リソースが、リクエストされたURLのパス・コンポーネントに対して評価され、一致が検索されます。使用される優先順位は、次のとおりです。
-
リテラル(リソースのパターンに特殊文字が含まれていない場合など)
-
選択肢: {パターン1,パターン2,...}。それぞれ自体に次の特殊文字が含まれる場合があり、同じ優先順位を使用して順番に評価されます。
-
範囲: [ ]
-
単一文字のワイルドカード: ?
-
ワイルドカード: *
-
階層: /.../
-
ホスト全体: /…/*はパターンの全体です。
評価はルート「/」から下の階層に向かって実行されます。各ディレクトリ・レベルで、最も高い優先レベルに一致するリソースが、次の評価候補として選択された後、1つ下のレベルに進みます。これは、パス情報のみに基づく、可能な最善一致を表すリソースが取得されるまで続きます。
ノート:
11gのすべての照合は、以前と同様に大文字/小文字が区別されます。
表25-5は、リクエストされたいくつかのURLの、それぞれの一致パターンを示しています。
表25-5 リクエストされたURLのパターン一致
| リクエストされたURL | 一致パターン |
|---|---|
|
/oam/sales/oam/page8.html |
/oam/.../*.html |
|
/oam/Dept1/page8.html |
/oam/Dept?/page8.html |
|
/oam/DeptQ/page8.html |
/oam/Dept[A-Z]/page[1-8].html |
|
/oam/DeptQ/page8.html |
/oam/Dept[A-Z]/page?.html |
|
/oam/saals/foo/aba/zzz/indexp.html |
/oam/sa{*,le,l?,a[k-m],[a-f-m]}s/.../{*b,?a}{a,/../ii}/.../{index,test}[pa].?tml |
問合せ文字列一致:
単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、単一の文字列で定義された候補が優先されます。単一の問合せ文字列のスコアは、すでに説明したアルゴリズムを使用して決定されます。
パラメータ・リストを含むリソースの場合、次のように最善一致が決定されます。
-
パラメータ値にワイルドカードが含まれていないリソースの優先順位は高くなります。そのようなリソースのセットの中で、最善一致はパラメータの名前と値を組み合せた長さを使用して決定されます。
-
問合せ文字列リテラルについては、組み合せた長さが等しい複数の一致が検出された場合、一致は失敗します。
-
次に検討されるのは、パラメータ値にワイルドカードが含まれているリソースです。そのようなリソースの中で、最善一致は各リソース内のワイルドカードの合計数を使用して決定されます。ワイルドカード数が等しい複数の一致が検出された場合、パラメータの名前と値を組み合せた長さによって最善一致が決定されます。
-
組み合せた長さが等しい複数のリソースが検出された場合、一致は失敗します。
問合せ文字列一致パターン: 2つ目およびそれに続くパターンでは、次のパラメータ・リストが使用されます。
- /oam/index.html::a=*d (単一の問合せ文字列)
- /oam/index.html::a:b
- /oam/index.html::a:b,c:d
- /oam/index.html::a:b
- /oam/index.html::a:b*,c:d
- /oam/index.html::a:b*,c:d*
- /oam/index.html::a:b*,c:*d*
表25-6は、リクエストされたいくつかのURLの、それぞれの一致パターンを示しています。
表25-6 問合せ文字列一致: 例
| リクエストされたURL | URLの一致パターン | 問合せ文字列の一致パターン |
|---|---|---|
|
/oam/index.html?a=b&c=d |
/oam/index.html |
a=*d |
|
/oam/index.html?a=b1&c=d |
/oam/index.html |
a:b*,c:d |
|
/oam/index.html?a=b1,c=d1 |
/oam/index.html |
a:b*,c:d* |
|
/oam/index.html?a=b1,c=1d1 |
/oam/index.html |
a:b*,c:*d* |
操作一致の例: リクエスト処理のこの時点で、1つ以上の候補リソースがあり、これらはすべて、リクエストされたURLパスおよび問合せ文字列コンポーネントに等しく一致します。Access Managerでは、リクエストされた操作をそれらの候補のいずれかに一致させます。ここで一致するのは、特にその操作を(他の特定の操作と同様に)保護するよう定義されているリソースです。特定の操作を保護するよう定義できるリソースは1つのみであるため、これで単一の最善一致が決まります。
ノート:
これで一致が決まらない場合は、操作をすべて保護して(つまり、「すべて」を使用して定義し、特定の操作の保護はしない)候補が存在することを確認します。
実行時の評価: 名前と値のペアは、実行時に次のように評価されます。
- 名前 値
-
a ab -
a a*
異なる形式で指定された同じリソースURL: URLが同じで問合せ文字列に同じ文字を含んでいても、コンソール内で異なる形式で(1つはキーおよび値として、もう1つは単一の文字列として)指定されたリソースは、異なるリソースと見なされ、許可されます。たとえば、次の2つのリソース・パターンは、異なるものと見なされます。
- リソースURL:
/test.html - 問合せ文字列:
area=*&dept=* - リソースURL:
/test.html - 問合せの名前と値
-
area * -
dept *
ポリシー評価中のリソースの一致: 名前と値のペアは、実行時にどの順序で到着しても問題ありません。すべての名前と値が問合せ文字列に一致すれば、一致は成功します。着信リクエストには、定義されたものよりも多くの名前と値のパラメータが含まれる場合がありますが、その場合も一致は成功します。
例1: 他のパターンが同じURL、問合せ文字列変数および追加問合せ文字列変数(revenue=1000)で定義されていない場合、次のパターンが着信URLに一致します。
- 着信URL =>
/test.html?area=emea&dept=engg&revenue=1000 - resource pattern =>
/test.html - 問合せ文字列の名前と値
-
area emea -
dept engg
例1: 同じリソースURLおよび問合せ文字列を含むリソースがあり、1つが単一の文字列、もう1つが名前と値のペアとして定義されている場合、ポリシー評価の一致では、リテラル問合せ文字列が優先され、次に名前と値のペアが検討されます。たとえば、次の例では、a)に一致します。
- 実行時リクエスト: URL =>
/test.html?area=emea&dept=engg - リソース・パターン:
- a)
- リソース:
/test.html - 問合せ文字列:
area=emea&dept=engg - b)
- リソース:
/test.html - 問合せ文字列の名前と値
-
area emea -
dept engg
最善一致、複数のリソース: 複数のリソースが問合せ文字列の名前と値のペアで定義されている場合、リソースの最善一致は、最も多い数の問合せ文字列のパラメータに一致するパターンです。ワイルドカード値が使用された場合、それに次ぐ基準として各パラメータ値の一致率が使用されます。
たとえば、次の2つの問合せ文字列パターンが定義されているとします。
- 問合せ文字列の名前と値
-
area e* -
dept e* - および
-
area em* -
dept en* - 実行時の問合せ文字列のパラメータ:
-
area emea -
dept engg - 結果: 2つ目の名前と値のパターンの方が一致順位が高くなります。
図25-11は、リソース定義ページを示しています。ここに示される、「rev*」は有効な名前です(アスタリスク文字は許可され、リテラル文字として扱われます。これは12cと同等の動作です)。Oracle Access Managementコンソールを使用すると、問合せ文字列を名前と値のペアとして追加できます。問合せ文字列をリテラル文字列として追加することもできます。リテラル問合せ文字列を選択した場合、名前と値のオプションは無効になります。リテラル問合せ文字列を選択しなかった場合、このオプションは有効になります。
25.5.1.5 リソース定義のリテラル問合せ文字列
ポリシー・モデルでは、アクセス・ポリシー内の完全なリテラル問合せ文字列ベースのHTTPリソース定義に対する一致に基づく、リソースの保護がサポートされます。入力問合せ文字列全体に一致する単一の問合せ文字列パターン(問合せ文字列の一部(選択された名前と値のペア)のみに一致とは異なります)。
たとえば:
status=active&adminrole=*
次の追加機能を持つ標準のフリー・フォーム文字列として指定された問合せ文字列パターン。
-
オプション: 0(ゼロ)個以上の文字と一致する特殊文字(*)が、実行時問合せ文字列の名前のセットに適用されます。
-
URLベース・パス・パターンが同じで問合せ文字列パターンが異なる2つのリソース定義が存在できます。これらの2つは独立しており、別個のリソースです。たとえば、次の定義はすべて有効で、同時に存在できます。
/foo /foo?bar=true /foo?bar=false
問合せ文字列は、フォーマットや文字に関する制限がないフリー・フォームです。問合せ文字列をキー/値ペアとして指定する必要はありません。
実行時、HTTP GETリクエストの一部である問合せ文字列のみが処理されます。問合せ文字列パターンはHTTP POSTデータには適用されません。
実行時のリソース一致:
-
ベースURLパスが一致し、次に問合せ文字列が一致します。
-
一致する問合せ文字列を含む複数のリソース・パターン: 最善一致は、トークンの数('*'で区切られるパターン)および各位置のトークンの長さに基づいて決まります。まず、より長いトークンを持つパターン、次により多くのトークンが含まれるパターンの順で優先されます。(トークンの数が同じで各位置の長さも同じ一致パターンがある場合、その一致は失敗します。)
競合:
-
スーパー・セット: 入力リソース定義に、ポリシー・ストア内の既存のリソース定義のパターンのスーパー・セットである一連の名前値問合せ文字列パターンが含まれています。
-
重複: 入力リソース仕様に、ポリシー・ストア内の既存のリソース定義の一連のパターンと重複する一連の名前値問合せ文字列パターンが含まれています。
リモート登録: OAMエージェントでは、リモート登録ツール(oamreg)が問合せ文字列ベースのHTTPリソース定義を受け入れ、これらのリソースのアクセスを保護するために関連するポリシー・オブジェクトを生成します。ポリシー・プロビジョニング中に競合が発生した場合、競合のないリソースのポリシーのみがプロビジョニングされます。かわりに、単一の認証スキームがアプリケーションの全リソースに適用されます。
25.5.1.6 実行時リソース評価
リソースのリクエストを処理する場合、リソースに適切なポリシーが起動していることを確認する評価が実行されます。
関連項目:
次の項に記載されているその他の処理の詳細
プロセスの概要: リソースの評価
-
ユーザーは、リクエストしたリソースのURLを指定します。
-
Access Managerでは、ホスト識別子およびURLに基づいて、URLパターンを含む完全修飾URLが作成されます。
-
Access Managerは、リクエストしたリソースの着信URLとアプリケーション・ドメイン情報およびポリシーのURLパターンから構築された完全修飾URLを比較します。
-
一致すると、様々なポリシーが評価され、リクエスタのリソースへのアクセスを許可または拒否するかどうかが決定されます。
-
リクエストしたユーザーがアクセスを許可された場合、リソースが提供されます。
-
表25-7は、可能性のある結果を示しています。
表25-7 リソース評価の結果
| Outcome | 説明 |
|---|---|
|
最善一致 |
最善一致は、リソース定義がランタイム・リソースの他の可能性のある一致と比較して最小のリソース・スコープの場合です。リソース・スコープは、特定のリソース定義を使用した一致する可能性のあるすべてのリソースを表します。 |
|
一致なし |
一致なしの場合、デフォルトの評価結果はFAILUREです。評価されたポリシーの種類によっては、認証が実行されなかったり、リソースのアクセス権が付与されなかったりすることを意味する場合があります。 |
検索メカニズムの例
-
アプリケーション・ドメインのデフォルトのリソースURLは、使用可能な最大範囲の内容を定義します(すべてのディレクトリと次のディレクトリ)。
/.../* -
パターン/.../index.htmlは、次と一致します。
/index.html /oracle/index.html /oracle/sales/index.html
たとえば
xyzindex.htmlには一致しません。 -
/oracle/.../*.htmlは次のものに一致します。
/oracle/index.html /oracle/sales/order.html and so on
リソース・スコープの例
-
次のリソース定義のリソース・スコープ(アスタリスクを含む)
/mybank/…/*
「/mybank/」という接頭辞が付いたすべてのURLを含みます。
-
次のリソース定義のリソース・スコープ(定義に特殊文字を含まない)
/mybank/account.html
1つのURL「/mybank/account.html」のみ含みます。
25.5.2 アプリケーション・ドメインのリソースの定義
有効な管理者の資格証明を持つユーザーは、保護するリソース定義を対応するアプリケーション・ドメインに追加できます。
個別の問合せパラメータのリストに基づくリソースの保護は、リテラル問合せ文字列よりもセキュアで管理が容易です。問合せパラメータ(文字列および名前と値のペア)を含むリソースURLに基づいてポリシーを作成することが必要な場合があります。
ノート:
無効なホスト識別子の値を指定すると、次のエラーが発生する場合があります。チャレンジURLが無効です。
Prerequisites
共有コンポーネントとしてリソース・タイプを定義する必要があります。リソース定義ページのいくつかの要素は、定義および選択されたリソース・タイプに基づいています。詳細は、「リソース・タイプの管理」を参照してください。
関連項目:
リソース定義をアプリケーション・ドメインに追加するには
-
「既存のアプリケーション・ドメインの検索」の説明に従って、Oracle Access Managementコンソールで目的のアプリケーション・ドメインを検索および表示します。
-
「アプリケーション・ドメイン」で、「リソース」タブをクリックし、「検索」ページの右上隅にある「新規リソース」ボタンをクリックします。
-
リソース定義ページで、次の手順を実行します。
-
次の項の説明に従って、アプリケーション・ドメイン内の特定のポリシーに定義済リソースを追加します。
25.5.3 リソース定義の検索
この項では次のトピックを記載しています:
25.5.3.1 アプリケーション・ドメイン内のリソース定義の検索要素および検索結果
デフォルトを使用して「検索」ボタンをクリックすることも、リソースを検索するのに必要な情報を指定して検索を絞り込むこともできます。
表25-8 アプリケーション・ドメイン内のリソースの検索要素
| 検索要素 | 説明 |
|---|---|
|
リソース・タイプ |
定義されたリソース・タイプのリストから選択できます。空白にしておくこともできます。 デフォルト値: HTTP |
|
ホスト識別子 |
必要に応じて、ホスト識別子をここに入力します。ここは空白のままにできます。 デフォルト値: 空白 |
|
リソースURL |
必要に応じて、リソースURLを入力します。ここは空白のままにできます。 デフォルト値: 空白 |
|
問合せ文字列 |
リソースの問合せ文字列を入力するか、空白のままにします。アプリケーション・ドメインへの追加時に、リソースの問合せ文字列が定義されている場合は、この要素を検索条件に含めることができます。 デフォルト値: 空白 |
|
認証ポリシー |
このアプリケーション・ドメインに定義された認証ポリシーのリストが表示されます。1つ選択するか、空白のままにします。 デフォルト値: 空白 |
|
認可ポリシー |
このアプリケーション・ドメインに定義された認可ポリシーのリストが表示されます。1つ選択するか、空白のままにします。 デフォルト値: 空白 |
「リセット」をクリックしてフォームをクリアするか、「検索」をクリックして検索を開始します。リストされている各リソースには、ドメインへの追加時に指定したすべての要素が含まれています。表では「アクション」メニューおよび「表示」メニューを使用できます。また、「作成」コマンド・ボタンをクリックして、このドメインに新規リソース定義を追加することもできます。
25.5.4 リソース定義の表示、編集または削除
有効な管理者の資格証明を持つユーザーは、特定のアプリケーション・ドメイン内のリソース定義を変更できます。
ポリシーに関連付けられているリソースの保護レベルが「保護」から「除外」に変更された場合、その変更は失敗します。まずポリシーからリソースを削除してから、変更を加えて、リソースをポリシーに追加してください。
ノート:
リソースがポリシーに関連付けられている場合、削除中にアラートが表示されます。ポリシーに関連付けられていない場合、リソースは削除されます。
Prerequisites
目的のリソース・タイプを共有コンポーネントとして定義する必要があります。詳細は、「リソース・タイプの管理」を参照してください。
関連項目:
リソース定義を表示、変更または削除するには
25.6 特定のリソースに対する認証ポリシーの定義
1つの認証ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認証ポリシーの変更、新しいポリシーの追加、および認証ポリシーへのリソースの割当てを開始できます。
自動的に生成されたアプリケーション・ドメインでは、次の認証ポリシーがデフォルトとしてシードされ、管理者のタスクを効率化できます。
-
保護されているリソース
-
パブリック・リソース
この項では次のトピックを記載しています:
25.6.1 認証ポリシー・ページ
管理者は、認証ポリシーを使用して特定のリソースを保護できます。認証ポリシーは、ポリシーで制御されたリソースの唯一の認証方式を提供します。
各認証ポリシーにより、Access Managerの十分な信頼レベルを提供してリクエストを実行するユーザーにアクセス権を付与するために実行する必要がある検証のタイプが定義されます。
認証ポリシーはローカルです。単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。
認証ポリシーのガイドライン
-
認証ポリシーには、リソース、成功レスポンスおよび認証スキームが含まれます。
-
認証および認可ポリシーを成功または失敗で評価できます。
-
クエリー・ビルダーおよびLDAPフィルタのサポート(特定の表示タイプの属性に基づく一致を取得する場合など)。
-
決められた範囲内で使用できるリソース/…/*のポリシーを定義できます。
-
トークン発行ポリシーは、リソースおよびユーザー・ベースまたはパートナに基づく条件を使用して定義できます。
図25-13は、アプリケーション・ドメインの「認証ポリシー」ページを示しています。
図25-14は、特定の認証ポリシーを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。
表25-9は、認証ポリシーの要素を示しています。
表25-9 認証ポリシーの要素および説明
| 要素 | 説明 |
|---|---|
|
名前 |
識別子として使用される一意の名前。 |
|
説明 |
認証ポリシーを説明するオプションの一意のテキスト。 |
|
認証スキーム |
ユーザー認証のためにポリシーで使用される単一の事前定義された認証スキーム。関連項目: 詳細は、「認証スキームの管理」を参照してください。 |
|
成功URL |
認証の成功時に使用されるリダイレクトURL。 |
|
失敗URL |
認証の失敗時に使用されるリダイレクトURL。 |
|
リソース |
リストから選択されたリソースのURL。リストされるURLは、以前にアプリケーション・ドメインに追加されたものです。認証ポリシーで保護する1つ以上のリソースを追加できます。リソース定義は、ポリシーに含める前にアプリケーション・ドメイン内に存在する必要があります。 関連項目: 「認証ポリシーのリソース」。 |
|
レスポンス |
Webエージェントで実行される必須処理(認証後のアクション)。認証に成功すると、保護されたアプリケーションをホストするアプリケーション・サーバーは、これらのレスポンスに基づいてユーザー・アイデンティティをアサートできる必要があります。認証に失敗すると、ブラウザはリクエストを事前構成されたURLにリダイレクトします。 関連項目: 「SSOのポリシー・レスポンスの概要」。 |
25.6.2 特定のリソース用の認証ポリシーの作成
有効な管理者の資格証明を持つユーザーは、認証ポリシーおよびリソースをアプリケーション・ドメインに追加できます。認証ポリシーの事前構成された認証スキームまたはカスタム認証スキームを使用できます。
関連項目:
前提条件
ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。
特定のリソースの認証ポリシーを追加するには、次の手順を実行します。
25.6.4 認証ポリシーの表示または編集
有効な管理者の資格証明を持つユーザーは、アプリケーション・ドメインの認証ポリシーを変更できます。
これには、認証スキームの変更、リソースやレスポンスの追加または削除および成功または失敗URLの変更が含まれます。
関連項目:
認証ポリシーを表示または変更するには、次の手順を実行します。
25.6.5 認証ポリシーの削除
有効な管理者の資格証明を持つユーザーは、アプリケーション・ドメインから認証ポリシーを削除できます。
ポリシーを削除しても、すべてのリソース定義はアプリケーション・ドメイン内に残ります。ただし、ポリシーおよびすべてのレスポンスが削除されます。
ノート:
削除操作中、ポリシーの削除を確認するアラートが表示されます。操作を完了するには確認が必要です。
次の手順は、全体のポリシーの削除方法を示しています。ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。
関連項目:
認証ポリシーを削除するには、次の手順を実行します。
- 「認証ポリシーの検索」の説明に従って、目的のポリシーを検索します。
- 目的のポリシー名をクリックして、この構成を表示および確認します。
- このポリシーで制御されたリソースが別のポリシーに追加されていることを確認します。
- 「SSOのポリシー・レスポンスの追加および管理」の説明に従って、すべてのレスポンスを削除します。
- 「認証ポリシー」タブで、ポリシーの横にある「シリアル番号」をクリックし、ツールバーの「削除」ボタンをクリックします。
- 確認ウィンドウで、確認して「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。
25.7 特定のリソースの認可ポリシーの定義
1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。
自動的に生成されるアプリケーション・ドメインでは、デフォルトとして次の認可ポリシーがシードされます。
-
保護されているリソース
-
パブリック・リソース
リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認可ポリシーの変更、新しいポリシーの追加および認可ポリシーへのリソースの追加を開始できます。この項では次のトピックを記載しています:
25.7.1 特定のリソースの認可ポリシー
管理者は、認証されたユーザーまたは環境の属性に基づいて、1つ以上のリソースへのアクセスを保護する認可ポリシーを作成できます。認可ポリシーは、ポリシーに含まれるリソースの唯一の認可保護を提供します。認可ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。他のリソースにポリシーを導出または適用できません。
単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認可ポリシーでのみ、各リソースを保護できます。
図25-15は、アプリケーション・ドメイン内の「認可ポリシー」ページを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。
表25-10は、認可ポリシーの要素を示しています。ドメインに関係なく要素は同じで、詳細のみ異なります。
表25-10 認可ポリシーの要素および説明
| 要素 | 説明 |
|---|---|
|
名前 |
ナビゲーション・ツリーの識別子として使用される一意の名前。 |
|
説明 |
認可ポリシーを説明するオプションの一意のテキスト。 |
|
成功URL |
認可の成功時に使用されるリダイレクトURL。 |
|
失敗URL |
認可の失敗時に使用されるリダイレクトURL。 |
|
サマリー |
一般情報(通常は「名前」およびオプションの「説明」)。 |
|
リソース |
認可ポリシーで保護される1つ以上の事前定義されたリソースURL。 |
|
条件 |
「認可ポリシー・ルールおよび条件の概要」も参照してください。 |
|
ルール |
「認可ポリシー・ルールおよび条件の概要」も参照してください。 |
|
レスポンス |
「SSOのポリシー・レスポンスの概要」も参照してください。 |
25.7.4 認可ポリシーおよびリソースの表示または編集
有効な管理者の資格証明を持つユーザーは、アプリケーション・ドメイン内の認可ポリシーを表示または変更できます。
関連項目:
認可ポリシーを表示または編集するには、次の手順を実行します。
25.7.5 認可ポリシー全体の削除
有効な管理者の資格証明を持つユーザーは、認可ポリシーの削除またはポリシー内のリソースのみの削除ができます。
ノート:
削除操作中、ポリシーの削除を確認するアラートが表示されます。操作を完了するには確認が必要です。
全体のポリシーを削除しても、すべてのリソース定義はアプリケーション・ドメイン内に残ります。ただし、アクセスを制御する認可ポリシー、条件およびルールが削除されます。
ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。
関連項目:
前提条件
ポリシーを削除する前または後に、ポリシーで制御されたリソースを別の認可ポリシーに割り当てます。
認可ポリシーを削除するには、次の手順を実行します。
- 「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。
- オプション: ポリシー名をダブルクリックして内容を確認し、終了したらページを閉じます。
- 削除: ポリシー名をクリックし、ツールバーの「削除」ボタンをクリックします。
- 確認ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。
- ポリシーがナビゲーション・ツリーにリストされていないことを確認します。
25.8 認可ポリシーの成功および失敗のURLの構成
認可の成功または失敗のリダイレクトURLが設定されている場合、エンド・ユーザーがアクセスを必要としているターゲットURLをパラメータまで渡す必要があります。
次の情報は、認可ポリシーの成功および失敗のURLを構成する場合に重要になります。
-
成功または失敗のURLにリダイレクトする前に、元のリソースの場所はエンコードされたURLになり、値としてoam_res問合せパラメータに追加されます。次のルールはoam_res値を作成する場合に重要になります。認可コール中にはHostIdentifierのみが渡されるため、完全修飾のホストおよびポートでURLを作成することも必要になります。2つの例を次に示します。
HostIdentifierを使用して、完全修飾の最初のhost:portエントリを検索し、それでURLを構成します。エントリの残りは、問合せパラメータとしてリソースURLに追加されます。たとえば:
HostList = [Host hostName:="adc00oyf.us.example.com", port=7777", Host hostName:="11gAgent", port=null", Host hostName:="adc00oyf.us.example.com", port=80"] , HostIdentifier = 11gAgent
作成されるURLは次のとおりです。
HTTP://adc00oyf.us.example.com:7777/index.html?Host1=adc00oyf.us.example.com:80
この2つ目の例:
HostList =[Host hostName:="adc00oyf.us.example.com", port=7777", Host hostName:="11gAgent", port=null] , HostIdentifier = 11gAgent
作成されるURLは次のとおりです。
HTTP://adc00oyf.us.example.com:7777/index.html
-
セキュリティ上の理由でリソースURLのハッシュ値を送信するには、
displayAuthZCallBackKey()WLSTコマンドを実行します。これにより、生成されたAES 128キーのBase64エンコード文字列値が返されます。このキーは、OAMサーバーおよび受信アプリケーションで使用できます。これは、oam-config.xmlに格納されます。oam-config.xmlのエントリは、/DeployedComponent/Server/NGAMServer/Profileにあります。<Setting Name="AuthZCallBack" Type="htf:map"> <Setting Name="AuthZHashKey" Type="xsd:string">1E8461DFA32AD746AF28BAAAA9F327327941C14CAC216DCFA9AC17985E09 7A0DD603EC1DF5C6D9F5C904ED44952A5D5F</Setting> <Setting Name="AuthZCallBackEnabled" Type="xsd:boolean">true</Setting> </Setting>
ノート:
displayAuthZCallBackKey()WLSTコマンドの詳細は、「Access Manager WLSTコマンド」を参照してください。 -
ステップ2のWLSTが有効になっている場合は、元のリソースURLのハッシュ値もoam_res_hash問合せパラメータの値として送信します。たとえば:
http://adc00oyf.us.example.com:7001/SampleLoginWAR/pages/MFALogin.jsp? oam_res=HTTP%3A%2F%2Fadc00oyf.us.example.com%3A0%2Findex.html%3FHost1 %3D11gAgent%3Anull&oam_res_hash=45438D536865B256681D328AA1BFD47D5D4D0039
25.9 認可ポリシー・ルールおよび条件の概要
Access Manager 11gでは、各認可ポリシーに、そのポリシーによって保護されるリソースへのアクセスを許可するか拒否するかを定義するルールが含まれます。ルールでは、アクセスを許可または拒否されるユーザーや移入を定義する条件、および認可に関するその他の考慮事項が参照されます。認可ルールおよび条件は、特定の認可ポリシー内のすべてのリソースに適用されます。
条件およびルールの評価により、認可ポリシーを着信リクエストに適用するかどうかが決定されます。認証に成功した後、適切な必須処理が有効になり、定義された認可ルール、条件およびレスポンスと連携して動作します。着信リクエストごとに、認可ポリシーによって、適用される条件が存在するかどうかが決定されます。その場合、これらの条件が評価されます。
この項では次のトピックを記載しています:
25.9.1 許可または拒否ルールについて
認可ポリシーでは、そのポリシー用に定義されたすべての条件(またはサブセット)がルールに含まれます。ルールの影響によって、ポリシーの影響が決まります。ポリシーごとに、1つ以上のルールの影響(結果)を設定できます。ただし、結果ごとに指定できるルールは1つのみです。
次の結果を認可およびトークン発行ポリシーに適用できます。
-
認可されたユーザーによる、保護されたリソースへのアクセスを許可します。許可条件がユーザーに適用されない場合、ユーザーがポリシーの対象外となり、デフォルトでリクエストしたリソースへのユーザーのアクセスが拒否されます。
-
認可されたユーザーによる、保護されたリソースへのアクセスを拒否します。
単一条件に依存する単純なルールを作成するか、式を使用して複数の条件に基づくより複雑なルールを定義します。詳細は、「式および式ベースのポリシー」を参照してください。
25.9.2 認可ポリシー条件
条件は、アクセス・リクエストで満たす必要がある1つ以上の基準を指定する要素です。各認可ポリシーには1つ以上の条件を含めることができます。
条件の構造は制約と似ています(11.1.1.3および11.1.1.5を参照)。ただし、以前の制約に含まれていた許可および拒否ルールは、個別に「ルール」タブで指定されます。
様々な条件タイプを使用すると、次のことが可能になります。
-
保護されたリソースへのアクセスが(ルールに基づいて)許可または拒否されるユーザーまたはユーザー・グループの識別。
-
保護されたリソースのアクセスを許可または拒否するIPアドレスの範囲の指定。
ノート:
ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。
-
条件の適用期間を定義する時間の設定。
-
リクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性の評価を実行する属性の指定。
「条件」タブでは、図25-16のように、名前別に整理された定義済条件の表、および選択した条件の詳細を示す表が提供されます。
表25-11は、「条件」タブの要素およびコントロールを示しています。
表25-11 認可ポリシーの「条件」タブ
| 要素 | 説明 |
|---|---|
|
「条件」の表の要素 |
このポリシー用に定義されたすべての条件をリストします。 |
|
名前 |
条件の識別子として使用される一意の名前。 |
|
タイプ |
使用する条件の種類。次のタイプから1つのみ指定できます。
|
|
説明 |
この条件を説明するオプションの一意のテキスト。 |
|
「条件詳細」セクション |
この表の情報は、選択した条件のタイプによって異なります。詳細は、次を参照してください。 |
25.9.3 条件のユーザーおよびグループの分類について
ユーザーおよびグループを分析して明示的にアクセスを許可または拒否するユーザーを決定する場合、ポリシーおよび条件に同じ情報を使用することをお薦めします。
たとえば、特定のユーザー・グループ(アイデンティティ・タイプ)に制約される認可ポリシーがある場合、特定の時間(一時的タイプ)に制約される認可ポリシーがある可能性があります。
ノート:
任意の条件でアクセスを拒否されるユーザーについては気にしないでください。どのアクセス条件も満たしていない場合、デフォルトでユーザーのアクセスは拒否されます。
ユーザーを分類する場合、ユーザーおよびユーザー・グループを異なる条件が適用されるグループに分割することをお薦めします。たとえば、ユーザーがリソースにアクセスできる時間帯や、ユーザーがリクエストを行う場合に使用する必要があるコンピュータなどの条件を指定できます。
マーケティング・グループのユーザーが特定のプロジェクト・グループに属し、人事管理グループのユーザーもプロジェクト・グループに属する場合などの一部のユーザーが複数のカテゴリに該当する場合、両方のカテゴリにユーザーを配置します。ユーザーが2つの条件を満たすことを必須にできます。
アプリケーション・ドメイン内でリソースのサブセットに対してポリシーを作成し、そのサブセットを別の認可ルールおよび条件で保護するには、同じ情報、つまり、このポリシーによって保護されるリソースへのアクセスをどのユーザーに許可し、どのような条件でリソースへのアクセスを明示的に許可または拒否するのかを検討します。
25.10 認可ポリシー条件の定義
条件を追加するメカニズムは、どのタイプを選択しても同じです。
認可ポリシー内で条件を使用する目的は、次のとおりです。
-
ユーザー名、ロールまたは、ユーザーが満たす必要のある基準を含むLDAPフィルタによって、ユーザーを識別します。
-
ユーザーがリソースへのアクセスに使用できるコンピュータを指定します。
-
ルールが適用される時間帯を設定します。
-
リクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性の評価を実行する属性の指定。
表示されたダイアログ・ボックスで、名前およびタイプを定義して条件のコンテナを作成します。その後、提供されたコントロールを使用して条件の詳細を定義します。
この項の内容は次のとおりです。
25.10.1 条件タイプの選択
この項では次のトピックを記載しています:
25.10.1.1 条件のウィンドウと要素
ポリシー内では、特定の条件タイプのインスタンスを複数保持できます。
管理者が条件を認可ポリシーに追加すると、名前、タイプおよびオプションの説明を入力できるウィンドウ(図25-17)が表示されます。送信されると、この情報を使用して、同じく指定する必要がある条件詳細のコンテナが作成されます。
表25-12は、「条件の追加」の要素を説明しています。
表25-12 「条件の追加」ウィンドウの要素
| 要素 | 説明 |
|---|---|
|
名前 |
この条件の一意の名前。 |
|
タイプ |
次のタイプから1つのみ指定できます。
|
|
説明 |
オプション。 |
コンテナを追加すると、図25-18のように、そのコンテナが「条件」タブに表示されます。「名前」、「タイプ」および「説明」は、タブの最上部にある「結果」表に表示されます。下部のパネルには、条件の詳細が含まれます。
関連項目:
詳細および手順は、「認可ポリシー条件の定義」を参照してください。
25.10.2 アイデンティティ条件の定義
この項では、アイデンティティ条件に関するすべての情報を提供します。内容は次のとおりです。
25.10.2.1 アイデンティティ条件について
アイデンティティ条件を定義する場合、1つ以上のユーザー・アイデンティティ・ストアから、ユーザー移入の1つ以上のメンバーを追加する必要があります。
ユーザー移入は、ユーザーまたはグループのリストとして追加できます。また、実行時に使用するLDAP検索フィルタを追加して、ユーザー移入を識別することもできます。LDAP検索フィルタを使用すると、アイデンティティ・ストア(ディレクトリ・サーバー)内に新しいグループを再編成または作成することなく、ターゲット・アイデンティティの移入を簡単に指定できます。詳細は、次を参照してください。
25.10.2.1.1 アイデンティティ条件およびユーザー移入
条件コンテナを開いた後、定義されたユーザー移入が表示されます。他の条件タイプと同様、アイデンティティ・タイプはアイデンティティ条件および一時的条件と組み合せて使用できます。
アイデンティティ条件を追加する場合、「追加」(+)ボタンの横にあるポップアップ・メニューを開き(図25-19の1)、「ユーザーとグループの追加」または「検索フィルタの追加」(2)を選択します。図25-19は、ポップアップ・メニューおよび表示される「アイデンティティの追加」ウィンドウ(3)を示しています。目的のアイデンティティを検索したら、それらを選択し、「選択済の追加」(4)をクリックします。
表25-13は、「アイデンティティの追加」の要素を示しています。
表25-13 「アイデンティティの追加」の要素
| 要素 | 説明 |
|---|---|
|
ストア名 |
この検索に使用するLDAPストアを、登録されたLDAPストアのリストから選択します。 |
|
エンティティ・タイプ |
「ユーザー」、「グループ」または「すべて」を選択して、検索基準を定義します。 |
|
エンティティ名 |
情報を入力して検索基準をさらに絞り込みます。 |
|
検索 |
検索基準が定義されたときにこのボタンをクリックします。 |
|
結果表 |
検索結果を表示します。 |
|
選択済の追加 |
クリックして、選択したユーザーまたはグループを結果表から条件の詳細に追加します。 |
1つ以上のアイデンティティを選択し、「選択済の追加」ボタンをクリックすると、「条件」タブは図25-20のようになります。
条件としてこれらの詳細を保存するには、タブの右上の「保存」ボタンをクリックします。
25.10.2.1.2 アイデンティティ条件でのLDAP検索フィルタのサポート
Access Manager 11gの認可条件では、許可または拒否されるアイデンティティの一部として、ユーザー、グループおよびLDAP検索フィルタのリストが受け入れられます。LDAPフィルタは、検索操作の特定の基準を表現するテキスト文字列です。LDAP検索フィルタを使用すると、アイデンティティ・ストア(ディレクトリ・サーバー)内に新しいグループを再編成または作成することなく、ターゲット移入を簡単に指定できます。
Access Manager 11gでは、次の条件およびリソース・タイプ用のLDAP検索フィルタ・データが受け入れられます。
-
アイデンティティ条件
-
トークン・リクエスタ・アイデンティティ条件
-
すべてのリソース・タイプ(HTTP、TokenServiceRPおよびその他のカスタム・リソース・タイプ)
ユーザーがLDAP検索フィルタを含む条件によって保護されているリソースへのアクセスを試行すると、Access Managerによって、フィルタの一部として指定されたアイデンティティ・ドメイン(アイデンティティ・ストア)に対するディレクトリ検索(LDAP検索)が実行されます。検索結果はキャッシュされるため、ディレクトリ・サーバー検索が繰り返し実行されることはありません。
「検索フィルタの追加」を選択すると、図25-21のようなコントロールが表示されます。複数のLDAP検索フィルタを認可ルールに追加し、実行時の評価に使用できます。LDAP検索フィルタを入力したフィールドは、許可または拒否されるユーザーの識別に使用されます。
表25-14は、検索フィルタの追加に関連付けられている要素を示しています。
表25-14 「検索フィルタの追加」の要素
| 要素 | 説明 |
|---|---|
|
Domain |
実行時に検索する必要があるアイデンティティ・ドメイン(登録されたユーザー・アイデンティティ・ストア)。各フィルタは特定のユーザー・アイデンティティ・ストアに関連付けられている必要があります。Access Manager 11gでは、指定されたアイデンティティ・ドメイン(アイデンティティ・ストア)に対してのみディレクトリ検索(LDAP検索)が実行されます。 |
|
検索フィルタ |
LDAP検索フィルタを入力するフィールド。たとえば: ((|dept=sales)(dept=support)) 関連項目: 「LDAP検索フィルタの構文」 |
|
テスト・フィルタ |
このボタンを使用すると、LDAP検索フィルタをテストして、予想した結果が返されるかどうかを確認できます。 |
|
テスト結果 |
フィルタ・テストの結果は、独自に指定した次の内容とともに表示されます。
|
|
フィルタの追加 |
このアイデンティティ条件にフィルタを追加するときにクリックします。 |
|
取消 |
フィルタを追加せずに「検索フィルタの追加」ダイアログを閉じるときにクリックします。 |
図25-22は、LDAP検索フィルタの追加後に表示される、アイデンティティ条件の詳細ページを示しています。
25.10.2.1.3 LDAP検索フィルタの構文
LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。正確な構文はアイデンティティ・ストアによって異なるため、ベンダーのドキュメントを参照してください。
表25-15は、Access ManagerのLDAP検索フィルタの例を示しています。
表25-15 Access ManagerのLDAP検索フィルタの例
| フィルタ・タイプおよび演算子 | 説明 | 構文の例 |
|---|---|---|
|
静的LDAP検索フィルタ |
静的検索フィルタの実装では、すべての検索結果が固定値に一致する必要があります。たとえば、ディレクトリ・プロファイルの組織単位がSalesの人々のみを戻すように検索を制限できます。 単純な静的フィルタの例として、seeAlso属性でセレクタ検索を使用する場合を検討します。このフィルタにより、ディレクトリ・プロファイルにbusinessCategory値としてdealershipを含む人々のみが検索結果として戻されます。 |
(attribute=value) たとえば: (businessCategory=dealership) |
|
ワイルド・カードを使用した静的検索 |
ワイルド・カードを使用する静的フィルタの例として、セレクタを使用した検索時にManagerという語を含む役職の人々のみを戻す場合を検討します。アスタリスク(*)ワイルドカードを使用して文字列Managerを検索するフィルタを作成できます。 |
(attribute=*value*) たとえば: (title=*manager*) |
|
動的LDAP検索フィルタ |
動的フィルタにより、ユーザー・プロファイルに基づいた検索結果を戻すことができます。動的フィルタは、フィルタ置換構文を使用する従来のLDAP検索フィルタです。 |
(attribute=$attribute$) |
|
置換構文 |
置換構文は、タスクを実行するユーザーに応じて動的に評価されます。たとえば、置換構文を入力すると、ソースDN(アプリケーションにログインしているユーザー)の属性値が代入され、ターゲットDN(参照しようとしているエントリ)に対して評価されます。 ノート: 検索ベースを設定すると深刻な管理オーバーヘッドが発生する可能性があります。置換構文で指定されるフィルタ・ベース・アプローチにより提供される機能は、よりスケーラブルで簡易化された設計と同一です。 置換構文を使用すると、ディレクトリ構造の上位検索を開始する関数を作成できますが、この関数は、検索イニシエータのレコードの情報の属性(たとえば、置換 ノート: 選択された検索ベースでは、ユーザーは自分と同じ |
(attribute=$attribute$) たとえば、次のフィルタでは、同じ組織単位に属するすべてのエントリが、アプリケーションにログインしているユーザーとして検索されます。 (ou=$ou$) |
|
ワイルド・カードを使用した動的検索 |
動的フィルタでは、ワイルドカードがサポートされます。 たとえば、organizationalUnitオブジェクトのcontactPerson属性を指定する場合を検討します。contactPerson属性により、organizationalUnitオブジェクトと同じ郵便番号の人々を戻す必要があります。organizationalUnitプロファイルにzipCodeという属性が含まれており、postalAddressディレクトリ属性の最後に郵便番号が指定されている場合があります。 |
(attribute=*$attribute$) たとえば: (postalAddress=*$zipCode$) |
|
否定演算子(!)を使用した検索 |
フィルタの構築時には、否定演算子がサポートされます。最適化されたアルゴリズムを使用する場合、フィルタ(!(sn=white))では期待した結果は得られません。 |
((!(sn=white))(objectclass=personOC)) |
関連項目:
関連項目:
『Oracle Internet Directoryのアップグレード』
25.10.3 IP4範囲条件の定義
この項では、次の情報について説明します。
25.10.3.1 IP4範囲条件タイプ
IP4範囲条件タイプを使用すると、管理者はアクセスを許可または拒否されるIPアドレス範囲のリストを指定できます。他の認可条件と同様、IP4範囲条件タイプはアイデンティティ条件および一時的条件と組み合せて使用できます。
明示的なアドレス: 指定する各IPアドレスは、明示的で有効なアドレス(形式nnn.nnn.nnn.nnn)である必要があります。たとえば、192.2.2.2のように指定します。
IP4範囲: 「開始」(開始)および「終了」(範囲の終了)にアドレスを入力することによって、範囲を定義します。指定する各IPアドレスは、明示的で有効なアドレス(形式nnn.nnn.nnn.nnn)である必要があります。たとえば、192.2.2.2のように指定します。「終了」フィールドには、「開始」フィールドよりも値の大きいアドレスを指定する必要があります。認可中、Access Managerによって、クライアントのIPアドレスが「開始」(開始)および「終了」(範囲の終了)に指定したアドレスの範囲に含まれているかどうかが確認されます。複数の重複する範囲が指定され、クライアントのIPアドレスがその範囲の1つにでも含まれている場合、条件によってtrueと評価され、その条件に設定された条件に基づいてアクセスが許可(または拒否)されます。
複数の重複する範囲が指定され、クライアントのIPアドレスがそのいずれかの範囲に含まれている場合は、条件によってtrueと評価され、その条件に基づいてアクセスが許可(または拒否)されます。
ノート:
「開始」のIPアドレスが「終了」のアドレスよりも大きい場合、条件はどのクライアントのIPアドレスにも一致しません。
図25-23は、開始および終了が指定されたサンプルIP4範囲を含むIP4範囲条件の表を示しています。無効な値を指定すると、そのことが通知され、値は保存できません。
25.10.4 一時的条件の定義
25.10.4.1 一時的条件
一時的条件タイプを使用する場合、管理者は、開始時間、終了時間および曜日を追加する必要があります。他の条件のように、アイデンティティ条件およびIP4範囲条件と組み合せてこれを使用できます。
図25-24では何も選択されていませんが、デフォルトですべての曜日が有効です。
グリニッジ標準時(GMT)の24時間制に基づくHH:MM:SS(時間、分、秒)形式で期間を指定する必要があります。深夜は00:00:00(開始)に指定します。24:59:59で1日が終了します。
表25-16 一時的条件の詳細
| 要素 | 説明 |
|---|---|
|
開始時間 ノート: 完全な24時間の範囲で時間を指定します。たとえば、深夜を00:00:00に指定して、午後11時を23:00:00に指定します。 |
この条件が開始する時間、分および秒を指定します。 ノート: 時間はグリニッジ標準時(GMT)に基づいています。GMTは、夏時間またはサマー・タイムの調整がなく1年中同じです。 |
|
終了時間 |
この条件が終了する時間、分および秒を指定します。 |
|
日 |
このポリシーがアクティブな日を指定します。 デフォルト: すべての日(すべての曜日が未選択の場合を含む) |
このページを閉じる前に、詳細を保存します。
関連項目:
25.10.5 属性条件の定義
この項では次のトピックを記載しています:
25.10.5.1 属性タイプ条件
属性タイプ条件では、アプリケーション・ドメイン内のすべてのリソース・タイプおよび認可ポリシーに関連する許可または拒否アクセスのリクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性が評価されます。
属性タイプ条件を定義すると、アクセスは次の項目によってスコープ指定される、名前と値のペアのリストに基づきます。
-
リクエスト・コンテキスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報。
-
セッション: ユーザーがセッションを確立したときのユーザー・セッションの詳細(事前定義済のセッション属性または任意のセッション属性の参照)。
-
ユーザー: ユーザー属性の情報(LDAP属性の参照)。この条件は、ユーザーの任意のLDAP属性の参照に対する条件を定義する場合のみ使用されます。ただし、userIDまたはgroupIDに基づく条件は、アイデンティティ条件を使用して定義されます。
アクセスが表25-17で説明されているいずれかの状況に基づく場合は、属性タイプ条件が必要です。
表25-17 属性タイプ条件を必要とするアクセス条件
| アクセスが基づく内容 | 説明 |
|---|---|
|
セッション属性 |
ユーザーにリソースへのアクセスが認可されるのは、セッション属性「認証レベル」がxx、セッション属性s1がv1およびセッションの開始時間がxxxxである場合です。 関連項目: 表25-20 |
|
リクエストされたリソース |
ホスト名およびポート番号 関連項目: 表25-19 |
|
ユーザーの詳細 |
ユーザーにリソースへのアクセスが認可されるのは、そのリソースのEmpnoがxxxxである(department=salesなど)場合です。 関連項目: 表25-21 |
|
セッション属性に基づくトークン発行 |
リクエスタ・パートナでは、要求に含まれる属性SessionActiveTimeが15000である場合、リライイング・パーティにトークンを発行できます。 トークン発行ポリシーの要求ベースの条件は、セッション・データを使用して作成されたアサーションに基づいて定義します。 |
属性タイプ条件を定義する管理者は、組込み属性および既知の属性のフィールドにデータを入力します。属性名は、テキスト・フィールドに入力するか、値のリストから選択できます。実行する条件は、その条件にANDまたはOR接続詞を使用して構築されます。図25-25は、属性条件のページを示しています。
図25-26は、「属性条件の追加」ダイアログ・ボックスを示しています。各属性条件は、表25-18で説明されているフィールドによって定義されます。
関連項目:
表25-18 属性条件の要素
| Condition | 説明 |
|---|---|
|
ネームスペース |
サポートされるネームスペース:
|
|
名前 |
属性名。次の内容に従って追加できます。 |
|
演算子 |
許可される演算子:
|
|
値 |
特殊なワイルドカード文字を含まないリテラル値。 |
組込みリクエスト
表25-19は、組込みリクエストの組込み属性名のリストを示しています。
表25-19 組込みリクエストの属性名
| 属性名 | 説明 |
|---|---|
|
agent_id |
リクエストしているエージェントの名前。 |
|
client_ip |
ユーザー・ブラウザのIPアドレス。 |
|
Policy_appdomain |
リクエストに一致するポリシーを保持するアプリケーション・ドメインの名前。 |
|
Policy_res |
リクエストに一致するリソース・ホストIDおよびURLパターン。 |
|
policy_name |
リクエストに一致する特定のポリシーの名前。 |
|
res_host |
リクエストしたリソースのホスト名。 |
|
res_port |
リクエストしたリソースのポート番号。 |
|
res_type |
リクエストしたリソースのタイプ。 |
|
res_url |
リクエストしたリソースURL。 |
組込みセッション
表25-20は、セッション・ベースの属性タイプ条件の属性名のリストを示しています。
表25-20 組込みセッションの属性名
| 属性名 | 説明 |
|---|---|
|
認証レベル |
セッションの現在の認証レベル。 |
|
認証スキーム |
現在の認証レベルを実現するために実行される認証スキームの名前。 |
|
セッション数 |
セッションにバインドされたユーザーのセッション数。 |
|
セッション作成時間 |
セッションの作成時間。 |
|
セッション有効期限時間 |
セッションの有効期間。 |
例: 属性条件のデータ(条件の集約)
表25-21は、許容できる各ネームスペースのサンプル条件データを示しています。
表25-21 属性条件のデータ(条件の集約)
| ネームスペース | 名前 | 演算子 | 値 |
|---|---|---|---|
|
組込みリクエスト |
Res_host |
Equals |
7777 |
|
組込みセッション |
Authn_level |
Equals |
2 |
|
Session |
Sessionattr1 |
Contains |
Foo |
|
ユーザー |
department |
Equals |
sales |
25.11 認可ポリシー・ルールの定義
アクセスの許可ルール、アクセスの拒否ルールまたはこの両方が指定されていて、ユーザーがこれらの条件に該当しない場合、ユーザーはルールの対象外とされ、リクエストしたリソースへのアクセスをデフォルトで拒否されます。
ルールでは、リソースへのアクセスをユーザーに許可するか否かを指定するために次のことができます。
-
ユーザー名、ロールまたは、ユーザーが満たす必要のある基準を含むLDAPフィルタによって、ユーザーを識別します。
-
ユーザーがリソースへのアクセスに使用できるコンピュータを指定します。
-
ルールが適用される時間帯を設定します。
この項では次のトピックを記載しています:
25.11.1 認可ポリシーのルール
ルールはAccess Manager 11gポリシー・モデルの新しい構造です。ルールによって、条件の評価結果を組み合せる方法が指定されます。また、各ルールには、全体的なポリシーの結果を決定するルール効果(ALLOWまたはDENY)が含まれます。
認可ルールでは、ポリシー、条件およびルールの評価中に実行するアクションと、その結果に基づく必要な操作が定義されます。結果は次の3つのいずれかになります。
-
True (アクセスの許可): アクセスの許可条件を満たす場合、ユーザーはルールのアクセスの許可部分の対象になります。
-
False (アクセスの拒否): アクセスの拒否条件を満たす場合、ユーザーはルールのアクセスの拒否部分の対象になります。
-
未確定: アクセスの許可条件もアクセスの拒否条件も満たさない場合、ルールはそのユーザーにとって対象外と呼ばれます。これは、ユーザーがルールの対象外であることと同じ意味です。ルールを評価した結果、ユーザーが対象外となった場合、ユーザーはそのルールに基づいてリソースへのアクセスを拒否されます。
場合によっては、単一の認可ルールが、アプリケーション・ドメインまたはポリシーのリソースを保護するための唯一の要件となります。ルールを構成して、そのルールによって保護されるリソースへのアクセスが許可されるユーザー、アクセスが拒否されるユーザー、およびこれらの制御が適用される条件(いつどのコンピュータから適用されるかなど)を識別できます。認可ルールに含まれるアクセスの許可条件およびアクセスの拒否条件で、すべてのユーザーを対象にする必要はありません。ルールによって保護されるリソースへのアクセスをリクエストしたが、いずれの条件も満たしていないユーザーは、そのリソースへのアクセスを拒否されます。
または、複数の認可条件からルールを構成してリソースを保護することが必要な場合もあります。異なるユーザーに対して複雑な条件を設けることもできます。たとえば、様々な認可条件を含むルールを定義し、それらの条件の1つ以上をユーザーが満たしているときにのみ、保護されているリソースへのアクセスを許可(または拒否)できます。たとえば、ユーザーがリソースへのアクセス権を付与されるには、2つの条件(あるグループに属し、かつ特定のIPアドレスが割り当てられているコンピュータを使用している、など)を満たす必要があると指定することもできます。
Oracle Access Managementコンソールを使用すると、認可ルールの式を簡単に作成できます。条件はルールの外部で宣言され、ルールの内部で参照されます。評価結果は、簡易モードと式モードのいずれかで結合されます。図25-27は、認可ポリシーの「ルール」タブを示しています。
表25-22は、簡易モードの評価の「ルール」タブに表示される要素およびコントロールを示しています。
表25-22 認可ポリシーの「ルール」の要素
| 要素 | 説明 |
|---|---|
|
ルール・モード |
条件およびルールの評価に使用される次の方法。
|
|
ルールの許可 |
ルールの評価および「選択した条件」リストの評価に基づいてアクセスを許可するルール。 |
|
ルールの拒否 |
ルールの評価および「選択した条件」リストの評価に基づいてアクセスを拒否するルール。 |
|
一致 |
「選択した条件」リストのすべての条件に一致させるか、「選択した条件」リストのいずれかの条件に一致させるかを選択する基準。 |
|
使用可能な条件 |
この認可ポリシー用に定義されたすべての条件のリスト。 |
|
選択した条件 |
ポリシーの評価プロセス用に構築する特定の条件のリスト。「使用可能な条件」リストからこのリストに項目を移動することによって構築します。 |
|
矢印型のコントロール |
矢印型のコントロールを使用すると、条件を「選択した条件」リストに追加できます(またはその逆に、選択されている条件を削除できます)。 |
25.11.2 式および式ベースのポリシー
ユーザーがリソースへのアクセスをリクエストし、そのリソースが認可条件およびルールで保護されている場合、そのユーザーに関する情報がルールのとおりであるかどうかを確認します。条件にその他の情報(条件が適用される時間帯や日時など)が指定されている場合は、その情報も確認されます。このプロセスは、ルールの評価と呼ばれます。
認可条件式は、単一のルール、またはより複雑な条件を表現するために組み合せた複数ルールのグループから構成されます。たとえば、ユーザーがリソースへのアクセス権を付与されるために2つのルールのアクセスの許可条件を満たすことを要求する式を作成できます。このような式を作成するには、Oracle Access Managementコンソールを使用します。式には次の要素が含まれます。
-
認可条件。認可ポリシー内で定義されている、使用可能な条件から選択します。
-
ルールを組み合せるための演算子。ルールの組合せにより、必要な認可保護を提供します(表25-24)。
複数の条件を含む式に対しては、ユーザーは式のどの条件の対象にもならない場合や、1つの条件の対象になる場合、または複数のルールの条件の対象になる場合があります。ユーザーにリソースへのアクセスが許可されるか拒否されるかは、常に式の評価結果(1つの条件ではなく、すべての条件とその組合せ)によって決まります。
認可条件式の最終結果について: Access Managerでは、最終的な結果を得られるまで、式に含まれる各ルールを評価します。認可条件式の評価では、最終結果として、アクセスの許可、アクセスの拒否または未確定のいずれかが戻されます。
図25-28は、式をルール・モードとして使用したときの「ルール」タブを示しています。
表25-23は、式モードの「ルール」タブに表示される要素を示しています。
表25-23 式モードの「ルール」タブ
| 要素 | 説明 |
|---|---|
|
ルール・モード |
条件およびルールの評価に使用される次の方法。
関連項目: 表25-24 |
|
ルールの許可 |
ルールの評価および「選択した条件」リストの評価に基づいてアクセスを許可するルール。 |
|
ルールの拒否 |
ルールの評価および「選択した条件」リストの評価に基づいてアクセスを拒否するルール。 |
|
条件 |
この認可ポリシー用に定義されたすべての条件のリストが提供されます。 |
|
挿入条件 |
選択した条件が式ウィンドウに追加されます。 |
|
検証 |
自動的に式の妥当性がテストされ、結果がレポートされます。 |
表25-24は、認可条件式の作成時に使用できる演算子を示しています。
表25-24 認可ルールの式の演算子
| 演算子 | 説明 |
|---|---|
|
( ) |
デフォルトでは、AND演算子で2つのルールを組み合せたものが、AND論理積条件になります。OR演算子の両側にあるルールは、少なくとも一方が満たされれば条件は成立します。カッコを使用してルールをグループ化しない場合は、AND演算子がOR演算子より優先されます。 カッコを使用すると、式のルールをグループ化するデフォルトの方法をオーバーライドできます。評価は引き続き左から右に実行されますが、ルールはカッコを使用して作成した組合せおよびグループ内で編成されます。 |
|
& |
AND演算子。認可ルールを組み合せて論理積条件を作成するのに使用します。AND演算子を使用すると、任意の数のルールを組み合せ、ユーザーが認可要件を満たすために従う必要がある一連の条件を実装できます。ただし、AND句の最終的な結果を得るには、ユーザーは、論理積条件の全ルールで同様の条件(アクセスの許可またはアクセスの拒否)を満たす必要があります。 認可条件式には、ANDで組み合されたルールの組合せまたはグループを複数個含めることができます。たとえば、複数のAND句を含めて、それぞれの句をOR演算子で接続できます。 |
|
| |
AND演算子。認可条件式には、複数の代替可能な認可条件が含まれる複合ルールを含めることができます。論理和条件を構成する認可ルールは、OR演算子を使用して組み合せます。OR論理和条件で指定した各認可ルールは、独立したルールになります。AND演算子を使用する論理積条件とは異なり、ユーザーは、OR演算子で接続された認可ルールのうち、ただ1つのルールの条件に対してのみ対象になる必要があります。 認可条件式には、保護するリソースに対して認可ポリシーを表すのに必要な数の認可ルールをOR演算子で接続して含めることができます。OR演算子は、アクセスの拒否条件のみを持つ認可ルール同士、アクセスの許可条件のみを持つ認可ルール同士、またはアクセスの拒否条件とアクセスの許可条件を組み合せて指定した認可ルール同士を接続するのに使用できます。ORを使用して1つのルールを1つのルールに接続できるのみでなく、ANDで組み合されたルールを含む句に1つのルールを接続することもできます。 |
25.11.2.1 認可ルールの式の評価
認可ルールの評価結果(式に複数の認可ルールが含まれている場合は、それらの認可ルールとも組み合せた評価結果)により、リクエストしたリソースへのアクセス権がユーザーに付与されるかどうかが判定されます。
ルールの評価は、次のように実行されます。
-
式に指定された各認可ルールは、左から右に評価されます。結果は以前に評価されたルールと順次組み合されます。
-
評価結果が、それ以上他のルールを評価することなく、全体的なポリシーの結果を判断できるほど良好である場合、評価は終了し、全体的な結果が返されます。
-
各評価結果は、True、False、未確定のいずれかになります。
認可成功: この場合、ユーザーはリクエストしたリソースにアクセスできます。この結果は、式のアクセスの許可条件に関連付けられています。
認可失敗: この場合、ユーザーはリクエストしたリソースにアクセスできません。この結果は、式のアクセスの拒否条件に関連付けられています。
認可未確定: この場合、式のルールにより矛盾する結果がいくつか生成され、ユーザーはリソースへのアクセスを拒否されます。アイデンティティ、IP4アドレスまたはタイミング条件の一致が失敗した場合、式の評価は終了し、全体的な評価の結果は未確定と判断されます。ただし、式に含まれる他のルールによっては、この結果が全体的なポリシーの評価に影響を与えない場合があります。
たとえば、次のような式があります。
(Rule1 AND Rule 2) OR (Rule 3 AND Rule 4)
生成される結果は次のとおりです。
-
Rule1 - INCONCLUSIVE
-
Rule2 - FALSE
-
Rule3 - TRUE
-
Rule4 - TRUE
-
全体: TRUE (許可)
次のサンプル式では、(タイプ順)アイデンティティ、一時的、IP4範囲および属性条件を使用します。
(IsEMEAemployee & IsEMEAWorkingHours & !(ConnectedOverVPN |NotReadDisclaimer))
スペース、タブまたは特殊文字を含む条件名(式を定義するときに正しくエスケープされている場合)は、正しく処理されます。
25.11.3 認可ポリシーのルールの定義
有効な管理者の資格証明を持つユーザーは、ルールを認可ポリシーに追加できます。
前提条件
関連項目:
認可ポリシー・ルールを定義するには
-
「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。
-
「ルール」タブをクリックします。
-
Expression:
-
簡易ルール・モード:
-
「ルール・モード」で「簡易」をクリックします。
-
ルールの許可:
一致させる次のいずれかの内容をクリックします。
- 選択したすべての条件
- 選択したいずれかの条件
「ルールの許可」または「ルールの拒否」の矢印を使用して、「使用可能な条件」列から「選択した条件」列に目的の条件を移動します。
「適用」をクリックします。
-
「ルールの拒否」でステップbを繰り返します。
-
-
「適用」をクリックして、確認ウィンドウを閉じます。
-
リソースにアクセスして結果を評価することによって、ルールを検証します。
25.12 ポリシー順序付けの構成
以前のバージョンのAccess Managerでは、着信リソースURLをアプリケーション・ドメイン内の保存パターンと一致させるポリシー・マッチング・アルゴリズムが使用されていました。最善一致は、事前定義済のアルゴリズムに基づきます。(このアルゴリズムは変更できません。)複数のパターンが着信URLと一致すると、最善一致パターンが選択され、その関連付けられているポリシーが評価されます。
この11gR2 PS2リリースでは、最善一致アルゴリズムではなく、管理者が、アプリケーション・ドメイン内のポリシー順序付けを手動で指定します。ポリシー順序付けを有効にするには、管理者がまず、アプリケーション・ドメインに1つ以上のリソース・プレフィックスを追加する必要があります。これらを追加した後、「ポリシー順序付けの有効化」フラグをクリックできるようになります。(図25-2を参照。)
ノート:
リソース・プレフィックスを作成し、ポリシー順序付けを有効にしないこともできます。この場合、リソース・プレフィックスが無視され、最善一致アルゴリズムが使用されます。
図25-29は、「リソース・プレフィックス」の構成ポップアップのスクリーンショットです。
実行中、保護されているリソースの着信URLがチェックされ、このURLがアプリケーション・ドメインで定義されているリソース・プレフィックスで開始されているかどうかが判断されます。URLがリソース・プレフィックスと一致すると、そのリソース・プレフィックスで構成されているアプリケーション・ドメイン内のポリシーが(管理者によって定義されている順序で)チェックされ、そのポリシー内のリソースが着信リソースと一致しているかどうかの確認が行われます。着信リソースが特定のポリシーと一致する場合、評価が行われ、結果が戻されます。他のポリシーはチェックされません。
ポリシー順序付けを構成する手順は次のとおりです。
25.13 SSOのポリシー・レスポンスの概要
各ポリシーは、1つ以上の認証または認可レスポンスあるいはその両方をオプションで含むことができます。レスポンスは、Webエージェントで実行される後処理のアクション(必須処理)です。
ノート:
トークン発行ポリシーにはレスポンスがありません。
この項では、次の情報について説明します。
25.13.1 SSOの認証および認可ポリシーのレスポンス
管理者は、認証または認可が成功した後に実行する必要があるアクションを宣言するレスポンスを定義できます。認証および認可データがクライアント(通常はWebエージェント)に戻されます。
ポリシー・レスポンスにより、情報をセッションまたはアプリケーションに挿入し、SSOを有効化するために後で情報を抽出できます。たとえば、アイデンティティ・マッピングを顧客アプリケーションに挿入するか、エージェントまたはアプリケーションでアクションを実行できます。
認証または認可の成功および失敗に応じて指定されるレスポンスによっては、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を通じてユーザー情報が他のアプリケーションに渡されたりする場合があります。
デフォルトのレスポンスは提供されません。図25-30に、Oracle Access Managementコンソールの管理者に定義された認可ポリシー・レスポンスを示します。認可レスポンスは、認可条件と組み合せて操作できます。
各レスポンスは、2つの入力(タイプおよび式)と1つの出力(評価された式の値)で構成されます。式は、式を処理する場合の値の構築方法を宣言します。レスポンス・タイプは、値文字列を使用して実行するアクションの形式を定義します。
-
認証ポリシーは、ユーザーのアイデンティティを決定します。各認証ポリシーには、認証スキームおよびレスポンス(式)が必要です。
-
認可ポリシーは、リソースへのユーザーのアクセス権を付与するかどうかを決定します。各認可ポリシーには、認可条件およびレスポンス(式)が必要です。
レスポンスのガイドライン
-
Cookie、ヘッダーおよびセッション・レスポンスがサポートされます。
-
URLリダイレクトを設定できます。
-
レスポンス定義は、各ポリシーの一部です。レスポンス値は、リテラル文字列の場合も、リクエスト、ユーザーおよびセッション属性から値を取得する追加的な埋込み式を含む場合もあります。
管理者は、表25-25で説明されているとおり、Oracle Access Managementコンソールのレスポンスを設定します。
表25-25 レスポンス要素
| 要素 | 説明 |
|---|---|
|
名前 |
このレスポンスと同じメカニズム(タイプ)を使用する他のレスポンスを区別する一意の名前。 |
|
タイプ |
レスポンスを伝達するために使用されるメカニズム。値文字列を使用して実行するアクションの形式。
|
|
値 |
変数として設定されるレスポンスの式。 詳細は、「ポリシー・レスポンスの言語について」を参照してください。 |
25.13.2 ポリシー・レスポンスの言語について
2つの主な構造とともに非常に小規模なドメイン固有言語(DSL)を使用して、Access Manager認証および認可レスポンスを定義します。
-
リテラル文字列:
This is a valid expressionなどです。 -
変数の参照
-
ドル記号の接頭辞(
$)を使用して宣言します。 -
ネームスペース$
namespace.var_nameでスコープされます。ノート:
変数に
$ns.name.attribute属性が含まれる場合があります。
-
25.13.3 ポリシー・レスポンスのネームスペースおよび変数名
ネームスペース・メカニズムを使用すると、次の変数タイプでシングル・サインオンが有効化します。
-
リクエスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報
-
セッション: ユーザー・セッションの詳細
-
ユーザー: ユーザーの詳細(ユーザーID、グループおよび属性情報)
詳細は、次の表を参照してください。
表25-26 シングル・サインオンのネームスペース・リクエスト変数
| ネームスペース | 説明 |
|---|---|
|
agent_id |
リクエストしているエージェントの名前 |
|
client_ip |
ユーザー・ブラウザのIPアドレス |
|
policy_appdomain |
リクエストに一致するポリシーを保持するアプリケーション・ドメインの名前 |
|
policy_eval_success_conditions |
trueに評価されるポリシー条件のリスト。コロンまたは構成済レスポンス区切り文字で区切られています。 |
|
policy_eval_failure_conditions |
falseに評価されるポリシー条件のリスト。コロンまたは構成済レスポンス区切り文字で区切られています。 |
|
policy_res |
リクエストに一致するリソース・ホストIDおよびURLパターン |
|
policy_name |
リクエストに一致する特定のポリシーの名前 |
|
res_host |
リクエストしたリソースのホスト名 |
|
res_port |
リクエストしたリソースのポート番号 |
|
res_type |
リクエストしたリソースのタイプ |
|
res_url |
リクエストされたリソースURLパス |
|
res_complete_url |
問合せ文字列を含む、リクエストされたリソースURLパス |
表25-27 シングル・サインオンのネームスペース・セッション変数
| ネームスペース | 説明 |
|---|---|
|
attr |
名前が変数属性として渡される任意のセッション属性の参照。前のリクエストでセッション・レスポンスを実行することで、値がセッションにバインドされています。 |
|
authn_level |
セッションの現在の認証レベル |
|
authn_scheme |
現在の認証レベルを実現するために実行される認証スキームの名前 |
|
count |
セッションにバインドされたユーザーのセッション数 |
|
creation |
セッションの作成時間 |
|
expiration |
セッションの有効期間 |
表25-28 ネームスペース・ユーザー変数
| ネームスペース | 説明 |
|---|---|
|
attr.<attrName> |
ユーザー変数attrNameの値attrNameが複数値の場合、コロンまたは構成済レスポンス区切り文字で区切られた値のリスト。 |
|
groups |
コロンまたは構成済レスポンス区切り文字で区切られた、ユーザーのグループ・メンバーシップのリスト。 |
|
userid |
ユーザーID |
|
user.id_domain |
ユーザーのアイデンティティ・ドメイン(基本的にアイデンティティ・ストアと同じ) |
|
guid |
アイデンティティ・ストアでユーザー・エントリを特定する一意の識別子 |
25.13.4 SSOのポリシー・レスポンスの構築について
25.13.4.1 単純なレスポンス
レスポンス・タイプとネームスペースおよび変数を決定した後、Oracle Access Managementコンソールでレスポンス属性を入力します。
図25-31に示すように、単純なレスポンスはいくつかの認可レスポンスのいずれかのようになります。
単純なレスポンスはスタンドアロンです。それぞれの先頭にドル記号($)が付けられ、変数値とドット(.)で区切られるネームスペースがその後に付けられます。たとえば:
$namespace1.var1
表25-29は、いくつかの単純なレスポンスおよびそれぞれに戻される内容の説明を示しています。
表25-29 単純なレスポンスおよび説明
| 名前 | タイプ | 値(単純な$ネームスペース.変数) | 戻される環境変数および値 |
|---|---|---|---|
|
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 |
|
oam_literal |
ヘッダー |
これはレスポンス文字列です。 |
HTTP_OAM_LITERAL これはレスポンス文字列です。 |
25.13.4.2 複合的および複雑なレスポンス
複合的または複雑なポリシー・レスポンスを作成する場合、管理者は、中括弧{}を使用してリテラルおよび変数を任意に結合して式を構築できます。コロン(:)はセパレータとして使用されます。
たとえば:
${namespace1.var1}:${namespace2.var2}
リテラル文字列(LS): ${namespace1.var1}:${namespace2.var2}
LS: ${namespace1.var1}, LS:${namespace2.var2}
図25-32は、管理者によって定義されるいくつかの複雑なレスポンスを示しています。すべてがヘッダー・タイプ・レスポンスで、ダウンストリーム・アプリケーションで利用されるHTTPリクエストのヘッダー変数の値が設定されます。
表25-30 複雑なレスポンス
| 名前 | 値 | 戻される環境変数および値 |
|---|---|---|
|
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 Oct 23 17:47:42 PST 2011/Wed Oct 24 01:47:42 PST 2011/7 |
|
oam_app_user |
$user.userid |
HTTP_OAM_USERID 名前 |
詳細は、「ポリシー・レスポンス処理について」を参照してください。
25.13.4.3 複数値のレスポンス
Access Manager 11gは、複数値を持つレスポンスをサポートします。これらには、複数値のユーザー属性レスポンス、ユーザーのグループ・メンバーシップ・レスポンスなどがあります。複数値のレスポンスの場合、Access Managerでは、区切り文字としてコロンを、エスケープ文字として円記号を使用します。
たとえば、ユーザー属性genTypeは、値としてGold、PlatinumおよびSilverを持ちます。$user.attr.genTypeに対するポリシー・レスポンスは、次のようになります。
"Gold:Platinum:Silver"
コロンが属性値に出現すると、円記号でエスケープされます。たとえば、Administrators、Special:Usersなどのグループ・メンバーシップを持つユーザーの場合、$user.groupsに対するポリシー・レスポンスは、次のようになります。
"Administrators:Special\:Users"
configurePolicyResponses(responseSeparator, responseEscapeChar) WLSTコマンドを使用すると、デフォルトの区切り文字およびエスケープ文字を変更できます。
25.13.5 ポリシー・レスポンス処理について
ポリシー・レスポンス処理は、認証レスポンスを再実行する認可リクエストの実行中に発生します。変数の参照に適切な値が入力され、すべての変数に値が設定されて認可値で一貫して設定できることを確認します。
一連のステップを実行して、レスポンスの式を処理します。
-
スキャナ/トークナイザ
-
パーサー
-
インタープリタ
解釈中、値の変数の参照が解決します。処理後の結果は単純な文字列値で、エージェントに伝播されるか、将来の使用に備えてセッション内に保存されます。
最初の適用される認可リクエストの認可レスポンスとともに認証の成功レスポンスが保存され、再実行されます。
認可レスポンスの式は、式の評価(成功、失敗または未確定)に応じて実行されるアクションを作成します。
変数を参照すると、値または次の内容が戻されます。
-
変数が設定されていない場合、NOT FOUNDが戻されます。
-
変数がnull値に設定されている場合、NULLが戻されます。
ノート:
レスポンスを検証してください。
処理のないパススルー:
処理しないでパススルーを実行する必要がある値は、\を使用して識別できます。たとえば:
\$1000
値$1000の結果が戻される値に表示されます。
25.14 SSOのポリシー・レスポンスの追加および管理
ポリシーおよびレスポンスを使用してシングル・サインオンを有効化し、他のディレクティブをオーバーライドできます。
この項のアクティビティを開始する前に、「SSOのポリシー・レスポンスの概要」を確認してください。
特に指定のないかぎり、この項の情報が認証および認可レスポンスに同等に適用されます。
25.14.1 SSOのポリシー・レスポンスの追加
有効な管理者の資格証明を持つユーザーは、認証または認可のポリシー・レスポンスを保護されたリソース・ポリシーに追加できます。
たとえば、Oracle Internet Directoryをインストールしたときに作成される、レルムのDNを収集できます。
前提条件
認可レスポンスを作成する前に目的の条件を分析して、レスポンスによって適切なアクションが実行されることを確認します。認証または認可ポリシーが存在しているアプリケーション・ドメインが必要です。
関連項目:
ポリシー・レスポンスを追加するには
25.15 アプリケーション・ドメインの認証および認可の検証
前提条件
-
アクセス権を付与されるユーザーおよびグループは、Oracle Access Managementに登録されるプライマリLDAPユーザー・アイデンティティ・ストアに存在する必要があります。
-
Access Managerで操作するためにエージェントを登録する必要があります。登録後、管理サーバーまたは管理対象サーバーを再起動することなく適切な認証とともに保護されたリソースにアクセスできる必要があります。
-
アプリケーション・ドメイン、認証ポリシーおよび認可ポリシーを構成する必要があります。
-
ログアウトは、「OAM Webゲートが関与するセッションの集中ログアウトの構成」の説明に従って構成されている必要があります
認証およびアクセスを確認するには、次の手順を実行します。
25.16 ポリシーおよびアプリケーション・ドメインのリモート管理の理解
いくつかのリモート管理モードで、管理者は既存のエージェント登録を更新、検証または削除できます。
この項では次のトピックを記載しています:
25.16.1 リモート・ポリシー管理のモード、テンプレートおよびフラグ
Access Managerには、付属のエージェントを登録または変更せずにアプリケーション・ドメインとそのポリシーを管理する2つのモードがあります。リモート・ポリシーおよびアプリケーション・ドメイン管理でサポートされるのは、作成および更新の機能のみです。リモート管理では、アプリケーション・ドメインやポリシーの削除はサポートされていません。
ノート:
アプリケーション・ドメインの削除は手動のタスクであり、Oracle Access Managementコンソールを使用して実行する必要があります。
表25-31に、リモート・アプリケーション・ドメイン管理のモードを示します。ここでもコマンドのパラメータには、モード、$OAM_REG_HOMEに対する相対パスを使用する入力*Request.xmlファイル、入力ファイルの優先ロケーションが含まれます。
./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value
表25-31 リモート・ポリシー管理のモード、テンプレートおよびフラグ
| モードおよびテンプレート | 説明 |
|---|---|
|
policyCreate $OAM_REG_HOME/input/ CreatePolicyRequest.xml |
管理者が、エージェントを登録せずにホスト識別子とアプリケーション・ドメインを作成できます。 ./bin/oamreg.sh policyCreate input/myCreatePolicyRequest.xml関連項目: 「ポリシー作成のリクエスト・テンプレート」 |
|
policyUpdate $OAM_REG_HOME/input/ UpdatePolicyRequest.xml |
管理者が、エージェントを更新せずに既存のホスト識別子とアプリケーション・ドメインを更新できます。 ./bin/oamreg.sh policyUpdate input/UpdatePolicyRequest.xml 関連項目: 「ポリシー更新のリクエスト・テンプレート」 |
|
フラグ |
オプション |
|
[prompt_flag] value: [-noprompt] |
- $OAM_REG_HOMEロケーションからの例 (echo username; echo password; echo webgate_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt component.oam.conf (echo username; echo password; echo webgate_password; echo httpscert_trust_prompt;) | ./bin/oamreg.sh inband input/Request.xml -noprompt (echo username; echo password; echo webgate_password; echo cert_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt (echo username; echo password; echo webgate_password; echo httpscert_trust_prompt; echo cert_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt |
|
component.oam.config_file |
オプション。リモート登録は、URIリストを引数に持つ構成ファイルを受け取ります。component.oam.config_fileには、任意の数の保護URIまたはパブリックURIを含むファイルへのフルパスを定義します。このファイルでは次の構文および形式が使用されていることを確認します。
ノート: 次の形式を使用して、ポリシーに対して認証スキームを構成できます(ポリシー名と認証スキーム名はタブ文字で区切る必要があります)。 <Policy Name> 'tab' <Authentication Scheme Name> たとえば: ######################## protected_uris ######################## protected policy1 Basic Over LDAP /finance/protected1/** /finance/protected2/** protected policy2 Client Certificate /finance/protected3/*.js,*.png,*.gif ######################## public_uris ######################## /finance/public /finance/test1/public |
25.16.2 ポリシー作成のリクエスト・テンプレート
CreatePolicyRequest.xmlファイルをリモートpolicyCreateモードで使用すると、管理者はエージェント登録を作成または更新することなく、ホスト識別子とアプリケーション・ドメインを作成できます。
-
複数の
hostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を作成します。 -
アプリケーション・ドメインを作成します。
-
複数の保護リソース、パブリック・リソース、除外リソースを追加します。リソースは、問合せ文字列の有無にかかわらずどちらもサポートされます。
-
カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを作成します。
前述のとおり、CreatePolicyRequest.xmlファイルと、拡張された(完全な)エージェント登録テンプレートには、同じパラメータが多数存在します。CreatePolicyRequest.xmlファイルには、認証および認可のポリシーおよびリソースの要素があります(<agentName>要素はない)。
CreatePolicyRequest.xmlファイルのパラメータの一部は新規であり、エージェント登録XMLファイル全体には含まれず、元のエージェント登録ファイルの特定の要素を使用して作成または更新されます。ただし、同じ要素もあります。CreatePolicyRequest.xml固有の主な違いは、次のとおりです。
-
認証および認可のポリシーおよびリソースの要素があります。
-
<agentName>要素または関連する要素はありません。
関連項目:
25.16.3 ポリシー更新のリクエスト・テンプレート
UpdatePolicyRequest.xmlとCreatePolicyRequest.xmlの内容は、ほぼ同じです。どちらも同じ要素を提供しますが、例外は<protectedAuthnScheme>要素です。
関連項目:
UpdatePolicyRequest.xmlを使用して、管理者は次の操作が可能です。
-
複数の
hostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を更新します。 -
アプリケーション・ドメインを更新します。
-
問合せ文字列の有無にかかわらず、複数の保護リソース、パブリック・リソース、除外リソースを追加します。
-
カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを更新します。
-
次を含む、カスタマイズしたポリシーを作成します。
-
ポリシーの表示名
-
ポリシーの説明
-
認証スキーム(認証ポリシーのみ)およびポリシーに関連付けられるリソースのサブセット
-
25.16.4 リモート・ポリシー管理テンプレートの要素
このトピックでは、CreatePolicyRequest.xmlファイルおよびUpdatePolicyRequest.xmlファイルにある、アプリケーション・ドメイン管理に関する一意のリモート管理要素について説明します。
表25-32 リモート管理テンプレートの要素
| 要素 | 説明 | 例 |
|---|---|---|
<rregAuthenticationPolicies> <rregAuthenticationPolicy> |
認証ポリシーの名前と説明を指定します(新規ポリシーの作成または既存ポリシーの更新時に使用)。 |
<rregAuthenticationPolicies>
<rregAuthenticationPolicy>
<name>AuthenticationPolicy1</name>
<description>Authentication policy
created using policyUpdate mode of
rreg tool</description>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies> |
<authnSchemeName> |
認証ポリシーで使用する認証スキームを指定します。 |
<rregAuthenticationPolicies>
.
.
authnSchemeName>LDAPScheme
</authnSchemeName>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies> |
|
<uriList> |
ポリシーを使用する認証を必要とするリソースを識別します。 |
<rregAuthenticationPolicies>
.
.
<uriList>
- <uriResource>
<uri>/res1</uri>
<queryString />
</uriResource>
</uriList>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies> |
<rregAuthorizationPolicies> <rregAuthorizationPolicy> |
認可ポリシーの名前と説明を指定します(新規作成または既存ポリシーの更新時に使用)。 |
<rregAuthorizationPolicies>
<rregAuthorizationPolicy>
<name>AuthorizationPolicy1</name>
<description>Authorization policy
created using policyUpdate mode of
rreg tool</description>
.
.
</rregAuthorizationPolicy>
</rregAuthorizationPolicies> |
|
<uriList> |
認可ポリシーを使用する認可を必要とするリソースを識別します。 |
<rregAuthorizationPolicies>
.
.
<uriList>
- <uriResource>
<uri>/res1</uri>
<queryString />
</uriResource>
</uriList>
.
.
</rregAuthorizationPolicy>
</rregAuthorizationPolicies> |
25.18 アプリケーションおよびアプリケーション・タイプ
アプリケーションは、起動URL、アイコン、説明および他のメタデータを含んでおり、SSOエージェント、フェデレーション・サービス・プロバイダ・パートナおよびフォーム入力の各アプリケーションをサポートしています。
アプリケーションには次の要素が含まれています。
-
launch-url (アプリケーションのエンド・ユーザーが使用)
-
アイコン、その説明、および(ユーザー向け)アプリケーション・ポータルでこのアイコンが表示される際に使用されるその他のメタデータ
次のアプリケーション・タイプがサポートされています。
-
SSOエージェント・アプリケーション(Webゲートにより保護)
-
フェデレーション・サービス・プロバイダ・パートナ・アプリケーション(Federationを使用してサードパーティのパートナ・アプリケーションを起動)
-
フォーム入力アプリケーション(アクセス・ポータル・アプリケーションのテンプレートに基づいたアプリケーション)
アプリケーションには、SSOによってそのアプリケーションを有効にするために必要な構成が含まれている必要があります。ただし、PS2の場合、フォーム入力アプリケーションとFederation SPアプリケーションにのみ、アプリケーション内にその構成が含まれます。SSOアプリケーションには、起動URLのみが含まれます。以降のリリースでは、新しい機能が追加されています。
ノート:
アプリケーション登録は、ESSOが構成されて有効になっている場合のみ機能します。アプリケーションを登録するには、アプリケーションのポリシー情報はESSOディレクトリ・ストアに格納されているため、ESSO IDSプロファイルが作成されている必要があります。