| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
リソースの保護には、特定のリソースの定義を含むアプリケーション・ドメインが必要です。
OAMでは、次のような非HTTP/HTTPSベースのリソースおよびHTTP/HTTPSベースのリソースを含む様々なタイプのリソースを保護できます。
すべての外部Webサイト
Webサイトの特定のページ
パートナのポータル
部品注文アプリケーション
請求書アプリケーション
多くの国の企業のWebサーバーの福利厚生加入アプリケーション
このコンテナでリソースを定義すると、そのリソースをアプリケーション・ドメインのポリシーに追加できます。この項では次のトピックを記載しています:
既存の共有ホスト識別子を使用して、場所を指定します。
ノート:
明示的に「除外」とマークされていないリソースがポリシーに関連付けられていない場合、一致するポリシーがないため、すべてのユーザーのアクセスが拒否されます。
リソース定義のガイドライン
URL接頭辞はありません。リソースの定義は、完全なURLとして扱われます。
機能が制限された次のパターン一致
'*'および'...'がサポートされます。
リソースをドメイン間で一意にする必要はありません。
HTTP URLの問合せ文字列保護。
各HTTPリソースはURLパスとして定義され、ホスト識別子と関連付けられます。ただし、他のタイプのリソースは、(ホスト識別子ではなく)特定の名前と関連付けられます。
特定の操作の定義によって、HTTP以外のリソース・タイプがサポートされます。HTTP以外のリソース・タイプにホスト識別子は関連付けられません。
リソースは、「保護」、「非保護」または「除外」として指定されます。
カスタム・リソース・タイプが許可されます。
図25-10は、「リソースの作成」ページを示しています。
表25-1では、リソース定義を構成する要素を示しています。
表25-1 リソース定義の要素
| 要素 | 説明 |
|---|---|
タイプ |
『Oracle Platform Security Servicesによるアプリケーションの保護』で説明しているように、Fusion Middlewareアプリケーション・シナリオには 「TokenServiceRPタイプのリソースの管理」で説明しているように、 リソース定義を追加(またはリソースを検索)すると、定義されたすべてのカスタム・リソース・タイプがデフォルトのリソース・タイプとともにリストされます。 関連項目: 「リソース定義のリソース・タイプ」。 |
説明 |
このリソースのオプションの一意の説明。 |
ホスト識別子 |
共有コンポーネントとして定義されたすべての識別子を含むホスト識別子のリストを使用できます。ホスト識別子を選択して、リソースを割り当てる必要があります。 ノート: リソース定義を構成するホスト識別子およびURL文字列の組合せは、すべてのアプリケーション・ドメインで一意にする必要があります。 関連項目: 「ホスト識別子の管理」。 |
「URI」セクション |
情報は選択したリソース・タイプによって異なります。 |
問合せ 名前と値のリスト |
HTTPリソース・タイプの場合のみ。アクセス・ポリシーで使用する名前と値のペアのリストを提供できます。 関連項目: 「リソース定義の問合せ文字列の名前と値のパラメータ」。 |
問合せ 文字列 |
HTTPリソースの場合、問合せ文字列を提供し、アクセス・ポリシー内の完全一致するリテラル文字列を検索できます。 関連項目: 「リソース定義のリテラル問合せ文字列」。 |
リソースURL |
「/」文字で区切られた一連の階層レベルで構成される完全なURLのパス・コンポーネントを表す単一の相対URL文字列として、値を表現する必要があります。リソースのURL値は/で始まり、選択されたホスト識別子のリソース値と一致する必要があります。 内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。含まれる場合、パターン定義に使用できる特殊文字は次のとおりです。
表25-2も参照してください。 |
「操作」セクション |
許可される特定の操作を定義して、独自のリソース定義をカスタマイズできます。 ノート: Oracle提供のリソース・タイプは読取り専用です。Oracle提供のリソース・タイプに関連付けられた操作は定義する必要がなく、変更もできません。開発されOracle提供のリソース・タイプに適用されたポリシーは、すべての操作に適用されます。 |
使用可能な操作 |
このリソース定義で許可されるすべてのHTTP操作を識別します。開発され、このカスタマイズされたリソースに適用されたポリシーは、識別した操作にのみ適用されます。特に明記しないかぎり、使用可能な次の操作は、すべてHTTPリソース・タイプのみを対象としています。
ノート: エージェントの登録時に、リソース定義自体に操作が指定されなかった場合は、そのリソース・タイプのすべての操作がサポートされます。 関連項目: 「リソース・タイプおよびその使用」。 |
保護 |
リソース定義のこのセクションのコントロールを使用すると、このリソースに適用する保護レベルを識別し、使用するポリシーに名前を付けることができます。 |
保護レベル |
適切な保護レベルを次のオプションから選択します。
|
認証ポリシー |
指定したリソース保護レベルに基づく認証ポリシーのリストが使用可能になりました。このドメイン内にあり、指定した保護レベルに一致するポリシーのみがリストされます。 |
認可ポリシー |
ドメインで定義された認可ポリシーのリストが使用可能になり、そこからこのリソースを保護するためのポリシーを選択できるようになります。 |
リソースの追加後、名前が付けられたアプリケーション・ドメインの「リソース」ノードにグループ化されます。ポリシーを作成すると、ドメインに定義されたすべてのリソースがリストされ、そこからポリシーに含める1つ以上のリソースを選択できます。
リソース定義内の様々な仕様の詳細は、次のトピックを参照してください:
リソース定義をアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択する必要があります。ネイティブ・リソース・タイプは読取り専用で、変更または削除できません。HTTP、TokenserviceRP、wl_authenなどがあります。
関連項目:
HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加します。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、ポリシーがすべてのHTTP操作に適用されます。
表25-2は、リソースのサンプルのURL値を示しています。詳細は、「リソースURL、接頭辞およびパターン」を参照してください。
表25-2 HTTPリソースのサンプルのURL値
| リソース | サンプルのURL値 |
|---|---|
ディレクトリ |
|
ページ |
|
Webアプリケーション |
|
管理機能は、リソースが存在するホストおよびリソースURLでアプリケーション・ドメインのリソースを識別します。
ノート:
HTTP以外のリソース・タイプにホスト識別子は関連付けられません。かわりに、管理者は、リソース定義ページの「リソースURL」フィールドにタイプの名前を入力する必要があります。
ホスト識別子は各リソースのコンテキストを作成するので、同じURLパスまたは異なるコンピュータのリソースを追加する場合に役立ちます。管理機能により、同じアプリケーション・ドメイン内のこれらのすべてのリソースを同じ方法で保護できます。一連のリソースを区別する唯一の違いは、ホスト・コンピュータの識別です。
すべての定義されたホスト識別子がリソース・ページの「ホスト識別子」リストに表示されます。リソースをアプリケーション・ドメインに追加する場合、管理機能でリソースをホストするコンピュータの1つのホスト識別子を選択する必要があります。
Access Managerは、リソースの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個以上の文字の連続に一致します。 このパターンを使用すると、特定の名前付きディレクトリの下にあるパスを保護できます。 ノート: これは既存の10gワイルドカードではありません。10gでは、/.../*パターンによって、パターンが定義されたレベルのルートを含まない排他的な一致が返されました。たとえば、/foo/.../*は/foo/barおよびルート・ディレクトリ/foo/自体と一致しますが、foo/にも/foo/にも一致しませんでした。10gでは接頭辞(ルート)が認識されるため、ほとんどの評価は接頭辞を取り除いた後に実行されました。 |
· /** 一致する内容 /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 |
いいえ |
ポリシー・モデルでは、リソース・パターン定義での問合せ文字列の名前と値のパラメータの使用がサポートされます。
名前: 記号などの任意の文字を含むことができる文字列リテラル。すべての文字がリテラルとして扱われます。
値: 任意の文字を含む文字列リテラルを指定できます。連続する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つ目およびそれに続くパターンでは、次のパラメータ・リストが使用されます。
表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 aba a*異なる形式で指定された同じリソースURL: URLが同じで問合せ文字列に同じ文字を含んでいても、コンソール内で異なる形式で(1つはキーおよび値として、もう1つは単一の文字列として)指定されたリソースは、異なるリソースと見なされ、許可されます。たとえば、次の2つのリソース・パターンは、異なるものと見なされます。
/test.htmlarea=*&dept=*/test.htmlarea *dept *ポリシー評価中のリソースの一致: 名前と値のペアは、実行時にどの順序で到着しても問題ありません。すべての名前と値が問合せ文字列に一致すれば、一致は成功します。着信リクエストには、定義されたものよりも多くの名前と値のパラメータが含まれる場合がありますが、その場合も一致は成功します。
例1: 他のパターンが同じURL、問合せ文字列変数および追加問合せ文字列変数(revenue=1000)で定義されていない場合、次のパターンが着信URLに一致します。
/test.html?area=emea&dept=engg&revenue=1000/test.html area emea dept engg例1: 同じリソースURLおよび問合せ文字列を含むリソースがあり、1つが単一の文字列、もう1つが名前と値のペアとして定義されている場合、ポリシー評価の一致では、リテラル問合せ文字列が優先され、次に名前と値のペアが検討されます。たとえば、次の例では、a)に一致します。
/test.html?area=emea&dept=engg/test.htmlarea=emea&dept=engg/test.html area emea dept engg最善一致、複数のリソース: 複数のリソースが問合せ文字列の名前と値のペアで定義されている場合、リソースの最善一致は、最も多い数の問合せ文字列のパラメータに一致するパターンです。ワイルドカード値が使用された場合、それに次ぐ基準として各パラメータ値の一致率が使用されます。
たとえば、次の2つの問合せ文字列パターンが定義されているとします。
area e* dept e* area em* dept en* area emea dept engg図25-11は、リソース定義ページを示しています。ここに示される、「rev*」は有効な名前です(アスタリスク文字は許可され、リテラル文字として扱われます。これは10gと同等の動作です)。Oracle Access Managementコンソールを使用すると、問合せ文字列を名前と値のペアとして追加できます。問合せ文字列をリテラル文字列として追加することもできます。リテラル問合せ文字列を選択した場合、名前と値のオプションは無効になります。リテラル問合せ文字列を選択しなかった場合、このオプションは有効になります。
Access Managerに移行するときの動作: Access Managerに(10gから)アップグレードする場合、以前の問合せ文字列は(単一の文字列であるか名前と値のペアであるかにかかわらず)11gに適切に作成されます。適切なタイプの問合せ文字列がAccess Managerに作成されます。
ポリシー・モデルでは、アクセス・ポリシー内の完全なリテラル問合せ文字列ベースのHTTPリソース定義に対する一致に基づく、リソースの保護がサポートされます。入力問合せ文字列全体に一致する単一の問合せ文字列パターン(問合せ文字列の一部(選択された名前と値のペア)のみに一致とは異なります)。
次に例を示します。
status=active&adminrole=*
次の追加機能を持つ標準のフリー・フォーム文字列として指定された問合せ文字列パターン。
オプション: 0(ゼロ)個以上の文字と一致する特殊文字(*)が、実行時問合せ文字列の名前のセットに適用されます。
URLベース・パス・パターンが同じで問合せ文字列パターンが異なる2つのリソース定義が存在できます。これらの2つは独立しており、別個のリソースです。たとえば、次の定義はすべて有効で、同時に存在できます。
/foo /foo?bar=true /foo?bar=false
問合せ文字列は、フォーマットや文字に関する制限がないフリー・フォームです。問合せ文字列をキー/値ペアとして指定する必要はありません。
実行時、HTTP GETリクエストの一部である問合せ文字列のみが処理されます。問合せ文字列パターンはHTTP POSTデータには適用されません。
実行時のリソース一致:
ベースURLパスが一致し、次に問合せ文字列が一致します。
一致する問合せ文字列を含む複数のリソース・パターン: 最善一致は、トークンの数('*'で区切られるパターン)および各位置のトークンの長さに基づいて決まります。まず、より長いトークンを持つパターン、次により多くのトークンが含まれるパターンの順で優先されます。(トークンの数が同じで各位置の長さも同じ一致パターンがある場合、その一致は失敗します。)
競合:
スーパー・セット: 入力リソース定義に、ポリシー・ストア内の既存のリソース定義のパターンのスーパー・セットである一連の名前値問合せ文字列パターンが含まれています。
重複: 入力リソース仕様に、ポリシー・ストア内の既存のリソース定義の一連のパターンと重複する一連の名前値問合せ文字列パターンが含まれています。
リモート登録: OAMエージェントでは、リモート登録ツール(oamreg)が問合せ文字列ベースのHTTPリソース定義を受け入れ、これらのリソースのアクセスを保護するために関連するポリシー・オブジェクトを生成します。ポリシー・プロビジョニング中に競合が発生した場合、競合のないリソースのポリシーのみがプロビジョニングされます。かわりに、単一の認証スキームがアプリケーションの全リソースに適用されます。
リソースのリクエストを処理する場合、リソースに適切なポリシーが起動していることを確認する評価が実行されます。
関連項目:
次の項に記載されているその他の処理の詳細
プロセスの概要: リソースの評価
ユーザーは、リクエストしたリソースのURLを指定します。
Access Managerでは、ホスト識別子およびURLに基づいて、URLパターンを含む完全修飾URLが作成されます。
Access Managerは、リクエストしたリソースの着信URLとアプリケーション・ドメイン情報およびポリシーのURLパターンから構築された完全修飾URLを比較します。
一致すると、様々なポリシーが評価され、リクエスタのリソースへのアクセスを許可または拒否するかどうかが決定されます。
リクエストしたユーザーがアクセスを許可された場合、リソースが提供されます。
表25-7は、可能性のある結果を示しています。
表25-7 リソース評価の結果
| 結果 | 説明 |
|---|---|
最善一致 |
最善一致は、リソース定義がランタイム・リソースの他の可能性のある一致と比較して最小のリソース・スコープの場合です。リソース・スコープは、特定のリソース定義を使用した一致する可能性のあるすべてのリソースを表します。 |
一致なし |
一致なしの場合、デフォルトの評価結果は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」のみ含みます。
有効な管理者の資格証明を持つユーザーは、保護するリソース定義を対応するアプリケーション・ドメインに追加できます。
個別の問合せパラメータのリストに基づくリソースの保護は、リテラル問合せ文字列よりもセキュアで管理が容易です。問合せパラメータ(文字列および名前と値のペア)を含むリソースURLに基づいてポリシーを作成することが必要な場合があります。
ノート:
無効なホスト識別子の値を指定すると、次のエラーが発生する場合があります。チャレンジURLが無効です。
前提条件
共有コンポーネントとしてリソース・タイプを定義する必要があります。リソース定義ページのいくつかの要素は、定義および選択されたリソース・タイプに基づいています。詳細は、「リソース・タイプの管理」を参照してください。
関連項目:
リソース定義をアプリケーション・ドメインに追加するには
「既存のアプリケーション・ドメインの検索」の説明に従って、Oracle Access Managementコンソールで目的のアプリケーション・ドメインを検索および表示します。
「アプリケーション・ドメイン」で、「リソース」タブをクリックし、「検索」ページの右上隅にある「新規リソース」ボタンをクリックします。
リソース定義ページで、次の手順を実行します。
次の項の説明に従って、アプリケーション・ドメイン内の特定のポリシーに定義済リソースを追加します。
この項では次のトピックを記載しています:
デフォルトを使用して「検索」ボタンをクリックすることも、リソースを検索するのに必要な情報を指定して検索を絞り込むこともできます。
表25-8 アプリケーション・ドメイン内のリソースの検索要素
| 検索要素 | 説明 |
|---|---|
リソース・タイプ |
定義されたリソース・タイプのリストから選択できます。空白にしておくこともできます。 デフォルト値: HTTP |
ホスト識別子 |
必要に応じて、ホスト識別子をここに入力します。ここは空白のままにできます。 デフォルト値: 空白 |
リソースURL |
必要に応じて、リソースURLを入力します。ここは空白のままにできます。 デフォルト値: 空白 |
問合せ文字列 |
リソースの問合せ文字列を入力するか、空白のままにします。アプリケーション・ドメインへの追加時に、リソースの問合せ文字列が定義されている場合は、この要素を検索条件に含めることができます。 デフォルト値: 空白 |
認証ポリシー |
このアプリケーション・ドメインに定義された認証ポリシーのリストが表示されます。1つ選択するか、空白のままにします。 デフォルト値: 空白 |
認可ポリシー |
このアプリケーション・ドメインに定義された認可ポリシーのリストが表示されます。1つ選択するか、空白のままにします。 デフォルト値: 空白 |
「リセット」をクリックしてフォームをクリアするか、「検索」をクリックして検索を開始します。リストされている各リソースには、ドメインへの追加時に指定したすべての要素が含まれています。表では「アクション」メニューおよび「表示」メニューを使用できます。また、「作成」コマンド・ボタンをクリックして、このドメインに新規リソース定義を追加することもできます。
有効な管理者の資格証明を持つユーザーは、特定のアプリケーション・ドメイン内のリソース定義を変更できます。
ポリシーに関連付けられているリソースの保護レベルが「保護」から「除外」に変更された場合、その変更は失敗します。まずポリシーからリソースを削除してから、変更を加えて、リソースをポリシーに追加してください。
ノート:
リソースがポリシーに関連付けられている場合、削除中にアラートが表示されます。ポリシーに関連付けられていない場合、リソースは削除されます。
前提条件
目的のリソース・タイプを共有コンポーネントとして定義する必要があります。詳細は、「リソース・タイプの管理」を参照してください。
関連項目:
リソース定義を表示、変更または削除するには
