| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
Access Managerアプリケーション・ドメインおよびポリシーへのアクセス、およびこれらの管理は、Oracle Access Managementコンソールを通じて行うことができます。この章では、ポリシーの作成および管理方法を説明し、これらのポリシーを制御するリソースを確認します。次のトピックが含まれます:
プレビュー:
この章のタスクのシステム・レベル要件は次のとおりです。
アプリケーション・ドメインは、Access Manager 11gポリシー・モデルの最上位の構造です。各アプリケーション・ドメインでは、リソースまたはリソースのセットに対する論理コンテナと、特定の保護リソースにアクセスできるユーザーを示す、関連付けられたポリシーが提供されます。各アプリケーション・ドメイン内では、特定の共有コンポーネントが使用されます。各アプリケーション・ドメインは、特定のホスト上の単一のアプリケーションを表します。または、管理者が、同じWebサーバー上にあって互いに緊密に連携しているリソースに対してそれぞれ異なるアプリケーション・ドメインを定義できます。たとえば、管理者は、財務アプリケーションおよび売掛金勘定アプリケーション用に単一のアプリケーション・ドメインを作成することも、各アプリケーション用に異なるアプリケーション・ドメインを使用することもできます。構成可能なポリシーを使用して、リソースへのアクセスを許可または拒否できます。
|
注意: セキュリティ強化のため、Access Managerは、デフォルトで、リソースがアクセスを明示的に許可するポリシーによって保護されていない場合、アクセスを拒否します。 |
各Access Managerのアプリケーション・ドメインには次の情報が含まれています。
リソース定義
アプリケーション・ドメインの各リソース定義には、リソース・タイプ、ホスト識別子(HTTPリソースの場合)および特定のリソースへのURLが必要です。アプリケーション・ドメインには必要なだけリソース定義を含めることができます。
認証ポリシーおよび特定のリソースへのレスポンス
それぞれの認証ポリシーには、一意の名前、ひとつの認証スキーム、成功および失敗のURL、このポリシーが適用される1つまたは複数のリソース、認証が成功した後に適用される管理者が定義したレスポンスが含まれます。
特定のリソースに対する認可ポリシー、条件、ルールおよびレスポンス
それぞれの認可ポリシーには、一意の名前、成功および失敗のURL、このポリシーが適用される1つまたは複数のリソースが含まれます。さらに、管理者は認可が成功するために満たされなければならない特定の条件と、認可が成功した後で適用されるレスポンスを定義できます。
特定のリソースのトークン発行ポリシー、条件およびルール
トークン発行ポリシーは、クライアントがリクエスタ・パートナであるかエンド・ユーザーであるかにかかわらず、そのクライアントのアイデンティティに基づいて、リソース(リライイング・パーティ・パートナ)に対してセキュリティ・トークン・サービスがトークンを発行する際に従うルールを定義します。
ポリシー順序付け
ポリシー順序付けとは、同じアプリケーション・ドメイン内のポリシーが保護リソースへのアクセス着信リクエストと一致する順序を管理者が手動で指定できる新しい機能です。以前のバージョンのAccess Managerでは、この目的における最善一致アルゴリズムが使用されていました。
新しいアプリケーションを既存のエージェントの背後に配置する場合、管理者は、アプリケーションを個別の(新しい)アプリケーション・ドメインおよびポリシーで保護するのか、既存のアプリケーション・ドメインおよびポリシーで保護するのかを決定する必要があります。この項には、次の項の情報が含まれています。
Access Managerでポリシー強制エージェントを登録するときに、ドメインとポリシーを自動生成することを選択(または拒否)できます。自動的に作成されるアプリケーション・ドメインには、エージェントに基づく名前が付けられ、デフォルトのリソースおよび基本ポリシー(認証および認可)でシードされます。空のコンテナが提供されますが、トークン発行ポリシーは定義されません。
エージェントの登録中、保護するアプリケーションと同じWebサーバー上にエージェントがあると仮定します。ただし、エージェントをプロキシWebサーバー、アプリケーションを異なるホストに配置できます。デフォルトのリソースは、管理者がリソースを追加したり、ポリシーを変更または追加するまで、基本ポリシーによって保護されます。
|
注意: IAMSuiteAgentは、Oracle Fusion Middlewareコンソールやその他のコンソールを保護するためのアプリケーション・ドメイン(IAMSuite)を提供する、事前登録されたJavaエージェント・フィルタです。詳細は、「バンドルされた10g IAMSuiteAgentアーティファクト」を参照してください。 |
Access Managerには、付属のエージェントを登録または変更せずにアプリケーション・ドメインとそのポリシーを管理する2つのモードがあります。リモート・ポリシーおよびアプリケーション・ドメイン管理でサポートされるのは、作成および更新の機能のみです。リモート管理では、アプリケーション・ドメインやポリシーの削除はサポートされていません。詳細は、「ポリシーおよびアプリケーション・ドメインのリモート管理の理解」を参照してください。
次に示す概要では、アプリケーション・ドメインとポリシーを手動で作成または管理するために実行する必要のある手順について、簡単に説明しています。また、各手順を完了するための説明が記載された項目についても示しています。
タスクの概要: アプリケーション・ドメインの管理
次の詳細を理解します。
次の項の説明に従って、この章の前提タスクをすべて実行します。
次の項の説明に従って、新しいアプリケーション・ドメインを作成します(または既存のアプリケーション・ドメインを表示します)。
次の項の説明に従って、リソース定義をアプリケーション・ドメインに追加します。
次の項の説明に従って、認証ポリシーを定義します。
次の項の説明に従って、認可ポリシーを定義します。
次の項の説明に従って、トークン発行ポリシーを定義します。
次の項の説明に従って、SSO設定およびポリシー評価キャッシュを構成します。
次の項の説明に従って、ポリシーおよび構成を検証します。
エージェントの登録時に、手動でアプリケーション・ドメインを作成しても、ポリシーの自動生成を受け入れても、アプリケーション・ドメインの要素は同じになります。すべてのポリシーおよびアプリケーション・ドメインは、Oracle Access Managementコンソールを使用して管理します。詳細は、次のトピックを参照してください:
どの作成方法を選択してアプリケーション・ドメインを作成するかにかかわらず、一意の名前を識別子として使用する必要があります。「アプリケーション・ドメイン」をクリックすると、「検索」ページが表示されます。右上隅の「アプリケーション・ドメインの作成」ボタンを使用すると、新しいドメインの定義を開始できます。または、名前を入力し(または「名前」フィールドを空白のまま残し)、「検索」ボタンをクリックし、既存のアプリケーション・ドメインをリストします。図20-1は、アプリケーション・ドメインの検索ページ、コントロール、および独自のツールバーを含む「検索結果」表を示しています。
検索結果で、アプリケーション・ドメイン名をクリックして、そのアプリケーション・ドメインを表示すると、「サマリー」タブに、名前、オプションの説明、ポリシー順序付け構成が表示されます。他の情報は次のタブに表示されます。
リソース
認証ポリシー
認可ポリシー
トークン発行ポリシー
管理
図20-2は、Acme Applicationアプリケーション・ドメインの「アプリケーション・ドメイン」ページのスクリーンショットです。生成されたアプリケーション・ドメインの場合、次のように「名前」および「説明」が移入されます。手動でアプリケーション・ドメインを作成する場合、「説明」は管理者によって入力されます。
アプリケーション・ドメインの「リソース」タブには、そのドメインのすべてのリソース定義のコンテナが表示されます。「リソース」タブが表示されると、特定の定義をすばやく検索できる「検索」コントロールが使用可能になります。
図20-3は、リソース定義の検索結果を絞り込むことができる「検索」コントロールを示しています。右上隅には「新規リソース」ボタンも表示されます。「検索結果」表では、検索された各定義の主要な情報が提供されます。
デフォルトのリソース・タイプはHTTPですが、デフォルトのリソースURLは/**です。HTTPリソース定義を使用すると、そのリソース用に定義された問合せ文字列に基づいて検索を実行できます。この問合せ文字列に使用できるのはベースURLのみで、一連のURLを示すオプションのパターン一致特殊文字を含めることができます。この生成されたドメインでは、「ホスト識別子」が、登録されたHTTPエージェントの名前に一致します。ポリシーの基本情報も提供されます。
「認証ポリシー」タブでは、検索コントロールを使用することなく、定義または生成されたポリシーにアクセスできます。管理者がアプリケーション・ドメインを手動で作成する場合、その管理者はポリシーもすべて手動で作成する必要があります。生成されたアプリケーション・ドメインでは、図20-5のように、2つの認証ポリシーが自動的に作成されます。
認証ポリシー: Protected Resource Policy
認証ポリシー: パブリック・リソース・ポリシー
認証ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。1つの認証ポリシーでのみ、各リソースを保護できます。
図20-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.
「認可ポリシー」タブでも、検索コントロールを使用することなく、定義または生成されたポリシーにアクセスできます。生成されたアプリケーション・ドメインでは、次の2つの認可ポリシーが自動的に作成されますが、各リソースは1つの認可ポリシーによってのみ保護できます。
保護されたリソース・ポリシー
パブリック・リソース・ポリシー
図20-7は、「認可ポリシー」タブを示しています。このタブで、ポリシーを選択して新しいポリシーを編集または作成できます。
図20-7は、「認可ポリシー」ページを示しています。提供されるいくつかのタブでは、この認可ポリシーの様々なコンポーネントを定義できます。最初は、すべてのリソースが保護され、アクセスが拒否されます。成功URLと失敗URL、条件、ルールおよびレスポンスを手動で追加する必要があります(デフォルト値は提供されません)。
図20-8は、「認可ポリシー・リソース」タブを示しています。このページを使用し、このポリシーのリソースを追加(または削除)します。
管理者は、このポリシーの条件、ルールおよびレスポンスも定義できます。自動生成されるものはありません。
生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。リソース、条件、ルールおよびレスポンスはすべて手動で追加する必要があります。
このポリシー・タイプの詳細は、次を参照してください:
この項では、Oracle Access Managementコンソールを使用してアプリケーション・ドメインを作成および管理する方法を説明します。次のトピックが含まれます:
アプリケーション・ドメインの管理には、一般的な設定とポリシー、およびリソース関連の設定とポリシーの追加、変更または削除が含まれます。
Oracle Access Managementコンソールを使用してアプリケーション・ドメインを作成または編集する場合は、複数のページを扱うことになります。最初は、図20-10に示されているフォームに一般詳細(名前およびオプションの説明)を追加します。
各アプリケーション・ドメインには、エージェント名と一致する一意の名前を使用する必要があります。新しいアプリケーション・ドメインの名前とオプションの説明を適用した後、そのアプリケーション・ドメインが作成されます。手動による作成の場合、一連のタブ(「サマリー」、「リソース」、「認証ポリシー」、「認可ポリシー」、「トークン発行ポリシー」)がすべて使用可能になります。リモート登録を使用して作成された場合、またはエージェントの登録中に作成された場合は、基本ポリシー情報も生成されます。
新しいアプリケーション・ドメインが必要かどうか、またはリソースを既存のアプリケーション・ドメインに追加できるかどうかを決定します。単一のアプリケーション・ドメインを手動で作成し、リソースおよびポリシーを手動で追加すると、同じエージェントを使用して複数のアプリケーションを保護できます。
有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して次のタスクを実行すると、アプリケーション・ドメインを手動で作成できます。
また、第15章および第16章で説明したように、エージェント登録時にアプリケーション・ドメインを自動的に生成することもできます。
前提条件
この章の始めにある「前提条件」を参照してください。
新しいアプリケーション・ドメインを作成するには
Oracle Access Managementコンソールで「アプリケーション・ドメイン」をクリックし、次に「作成」ボタンをクリックします。
「アプリケーション・ドメインの作成」ページで、一意の名前、オプションの説明、その他の詳細を追加して、「適用」をクリックして確認ウィンドウを閉じます。
「ポリシー順序付けの構成」を参照してください。
「アプリケーション・ドメイン」コンテナ内に、次のコンテナ(タブ)を表示し、管理します。
リソース: 「ポリシー・リソース定義の追加および管理」を参照してください。
認証ポリシー: 「特定のリソースの認証ポリシーの定義」を参照してください。
認可ポリシー: 「特定のリソースの認可ポリシーの定義」を参照してください。
トークン発行ポリシー: 「トークン発行ポリシー、条件およびルールの管理」を参照してください。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のアプリケーション・ドメインを検索できます。
|
注意: この検索操作では、大文字と小文字が区別されます。 |
アプリケーション・ドメインを検索するには
Oracle Access Managementコンソールで「アプリケーション・ドメイン」をクリックします。
提供されたフィールドに、検索するアプリケーション・ドメインの名前を入力します(名前の一部とワイルドカード(*)を入力したり、すべてのドメインを取得するためにフィールドを空白のまま残すこともできます)。例:
DesiredDomain
「検索」ボタンをクリックして検索を開始します。
「検索結果」表で名前を選択し、必要なタスクを実行します。次に例を示します。
編集: ツールバーの「編集」ボタンをクリックして構成ページを表示し、「アプリケーション・ドメインの表示または編集」を参照します。
削除: 「アプリケーション・ドメインおよびその内容の削除」を参照してからこのタスクを実行します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して次のタスクを実行すると、アプリケーション・ドメイン(そのリソース、ポリシー、条件およびレスポンスを含みます)を表示または変更できます。
類似するアプリケーションを同じアプリケーション・ドメインにグループ化することをお薦めします。アプリケーション・ドメインを編集する場合、異なるアプリケーションが同じドメインを使用していることに注意してください。説明およびドメイン名の編集がサポートされます。
アプリケーション・ドメインおよびその内容を表示または変更するには
「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。
次の各タブをクリックして開き、特定の詳細を追加、表示、変更または削除します。
リソース: 「ポリシー・リソース定義の追加および管理」を参照してください。
認証ポリシー: 「特定のリソースの認証ポリシーの定義」を参照してください。
認可ポリシー: 「特定のリソースの認可ポリシーの定義」を参照してください。
トークン発行ポリシー: 「トークン発行ポリシー、条件およびルールの管理」を参照してください。
有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して次のタスクを実行すると、アプリケーション・ドメイン(そのリソース、ポリシー、条件およびレスポンスを含みます)を削除できます。
アプリケーション・ドメインおよびその内容を削除すると、エージェント登録など、参照されているすべてのオブジェクトが削除されます。この方法を使用すると、後から同じエージェントの再登録が必要になった場合、その操作が可能になります。これは、以前のアプリケーション・ドメインおよびその内容の参照が残っていないためです。
|
注意: 削除操作中、アプリケーション・ドメインにポリシー要素が含まれている場合、アラートが表示されます。 |
前提条件
削除するドメインのリソースを別のアプリケーション・ドメインに配置して、保護されていることを確認します。
アプリケーション・ドメインを削除するには
「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。
削除するドメインのリソースを別のアプリケーション・ドメインに配置して、保護されていることを確認します。
「検索結果」表で、目的の名前の横にある「シリアル番号」をクリックし、ツールバーの「削除」(x)ボタンをクリックします。
警告ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。
結果表で、アプリケーション・ドメインが削除されていることを確認します。
以前のバージョンのAccess Managerでは、着信リソースURLをアプリケーション・ドメイン内の保存パターンと一致させるポリシー・マッチング・アルゴリズムが使用されていました。最善一致は、事前定義済のアルゴリズムに基づきます。(このアルゴリズムは変更できません。)複数のパターンが着信URLと一致すると、最善一致パターンが選択され、その関連付けられているポリシーが評価されます。
この11gR2 PS2リリースでは、最善一致アルゴリズムではなく、管理者が、アプリケーション・ドメイン内のポリシー順序付けを手動で指定します。ポリシー順序付けを有効にするには、管理者がまず、アプリケーション・ドメインに1つ以上のリソース・プレフィックスを追加する必要があります。これらを追加した後、「ポリシー順序付けの有効化」フラグをクリックできるようになります。(図20-2「Acme Applicationの「アプリケーション・ドメイン」ページ」を参照してください。)
|
注意: リソース・プレフィックスを作成し、ポリシー順序付けを有効にしないこともできます。この場合、リソース・プレフィックスが無視され、最善一致アルゴリズムが使用されます。 |
図20-11は、「リソース・プレフィックス」の構成ポップアップのスクリーンショットです。
実行中、保護されているリソースの着信URLがチェックされ、このURLがアプリケーション・ドメインで定義されているリソース・プレフィックスで開始されているかどうかが判断されます。URLがリソース・プレフィックスと一致すると、そのリソース・プレフィックスで構成されているアプリケーション・ドメイン内のポリシーが(管理者によって定義されている順序で)チェックされ、そのポリシー内のリソースが着信リソースと一致しているかどうかの確認が行われます。着信リソースが特定のポリシーと一致する場合、評価が行われ、結果が戻されます。他のポリシーはチェックされません。
ポリシー順序付けを構成する手順は次のとおりです。
Oracle Access Managementコンソールで「アプリケーション・ドメイン」をクリックし、次に「作成」ボタンをクリックします。
「アプリケーション・ドメインの作成」ページで、一意の名前とオプションの説明を追加します。
「追加」をクリックして、リソース・プレフィックスを追加します。
「ポリシー順序付けの有効化」ボックスを選択します。
ドロップダウン・リストから「リソース・タイプ」を選択します。
デフォルトのリソース・タイプの定義については、表20-1を参照してください。
オプションのホスト識別子を追加します。
ホスト識別子はHTTPリソース・タイプには必須です。
リソース・プレフィックスを追加します。
たとえば、保護されているポリシー・リソースが/em/**である場合、リソース・プレフィックスは/emです。保護されているポリシー・リソースが/blog/**である場合、リソース・プレフィックスは/blogです。
「追加」をクリックします。
各アプリケーション・ドメインには、リソース定義のコンテナである「リソース」タブが含まれます。このコンテナでリソースを定義すると、そのリソースをアプリケーション・ドメインのポリシーに追加できます。
リソースの保護には、特定のリソース定義を含むアプリケーション・ドメインが必要です。OAMでは、次のような非HTTP/HTTPSベースのリソースおよびHTTP/HTTPSベースのリソースを含む様々なタイプのリソースを保護できます。
すべての外部Webサイト
Webサイトの特定のページ
パートナ・ポータル
部品注文アプリケーション
請求書アプリケーション
多くの国の企業のWebサーバーの福利厚生加入アプリケーション
この項では次のトピックを記載しています:
各リソースをアプリケーション・ドメインで個別に定義する必要があります。アプリケーション・ドメイン内で、リソース定義はオブジェクトのフラットな集合として存在します。各リソースは、特定のタイプ、およびサーバーに格納されて多くのユーザーがアクセスできるリソース(ドキュメントまたはエンティティ)を識別するURL接頭辞として定義されます。既存の共有ホスト識別子を使用して、場所を指定します。
|
注意: 明示的に「除外」とマークされていないリソースがポリシーに関連付けられていない場合、一致するポリシーがないため、すべてのユーザーのアクセスが拒否されます。 |
リソース定義のガイドライン
URL接頭辞はありません。リソースの定義は、完全なURLとして扱われます。
機能が制限された次のパターン一致
' * 'および'...'がサポートされます。
リソースをドメイン間で一意にする必要はありません。
HTTP URLの問合せ文字列保護。
各HTTPリソースはURLパスとして定義され、ホスト識別子と関連付けられます。ただし、他のタイプのリソースは、(ホスト識別子ではなく)特定の名前と関連付けられます。
特定の操作の定義によって、HTTP以外のリソース・タイプがサポートされます。HTTP以外のリソース・タイプにホスト識別子は関連付けられません。
リソースは、「保護」、「非保護」または「除外」として指定されます。
カスタム・リソース・タイプが許可されます。
図20-12は、新しい「リソース」定義ページを示しています。
表20-1は、リソース定義を構成する要素を示しています。
表20-1 リソース定義の要素
| 要素 | 説明 |
|---|---|
|
リソース・タイプ |
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明しているように、Fusion Middlewareアプリケーション・シナリオでは 「TokenServiceRPタイプのリソースの管理」で説明するように、 リソース定義を追加(またはリソースを検索)すると、定義されたすべてのカスタム・リソース・タイプがデフォルトのリソース・タイプとともにリストされます。 関連項目: 「リソース定義のリソース・タイプについて」 |
|
ホスト識別子 |
共有コンポーネントとして定義されたすべての識別子を含むホスト識別子のリストを使用できます。ホスト識別子を選択して、リソースを割り当てる必要があります。 注: リソース定義を構成するホスト識別子およびURL文字列の組合せは、すべてのアプリケーション・ドメインで一意にする必要があります。 関連項目: 「ホスト識別子の管理」 |
|
説明 |
このリソースのオプションの一意の説明。 |
|
「URI」セクション |
情報は選択したリソース・タイプによって異なります。 |
|
問合せ 名前と値のリスト |
HTTPリソース・タイプの場合のみ。アクセス・ポリシーで使用する名前と値のペアのリストを提供できます。 |
|
問合せ 文字列 |
HTTPリソースの場合、問合せ文字列を提供し、アクセス・ポリシー内の完全一致するリテラル文字列を検索できます。 関連項目: 「リソース定義のリテラル問合せ文字列について」 |
|
リソースURL |
「/」文字で区切られた一連の階層レベルで構成される完全なURLのパス・コンポーネントを表す単一の相対URL文字列として、値を表現する必要があります。リソースのURL値は/で始まり、選択されたホスト識別子のリソース値と一致する必要があります。 内容に基づいて、リテラルまたはワイルド・カード・パターンとして着信リクエストの応答がURLと一致します。含まれる場合、パターン定義に使用できる特殊文字は次のとおりです。
表20-2も参照してください。 |
|
「操作」セクション |
許可される特定の操作を定義して、独自のリソース定義をカスタマイズできます。 注意: Oracle提供のリソース・タイプは読取り専用です。Oracle提供のリソース・タイプに関連付けられた操作は定義する必要がなく、変更もできません。開発されOracle提供のリソース・タイプに適用されたポリシーは、すべての操作に適用されます。 |
|
使用可能な操作 |
このリソース定義で許可されるすべてのHTTP操作を識別します。開発され、このカスタマイズされたリソースに適用されたポリシーは、識別した操作にのみ適用されます。特に明記しないかぎり、使用可能な次の操作は、すべてHTTPリソース・タイプのみを対象としています。
注: エージェントの登録時に、リソース定義自体に操作が指定されなかった場合は、そのリソース・タイプのすべての操作がサポートされます。 関連項目: 「リソース・タイプおよびその使用法について」 |
|
保護 |
リソース定義のこのセクションのコントロールを使用すると、このリソースに適用する保護レベルを識別し、使用するポリシーに名前を付けることができます。 |
|
保護レベル |
適切な保護レベルを次のオプションから選択します。
|
|
認証ポリシー |
指定したリソース保護レベルに基づく認証ポリシーのリストが使用可能になりました。このドメイン内にあり、指定した保護レベルに一致するポリシーのみがリストされます。 |
|
認可ポリシー |
ドメインで定義された認可ポリシーのリストが使用可能になり、そこからこのリソースを保護するためのポリシーを選択できるようになります。 |
リソースの追加後、名前が付けられたアプリケーション・ドメインの「リソース」ノードにグループ化されます。ポリシーを作成すると、ドメインに定義されたすべてのリソースがリストされ、そこからポリシーに含める1つ以上のリソースを選択できます。
リソース定義内の様々な仕様の詳細は、次のトピックを参照してください:
リソース定義をアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択する必要があります。ネイティブ・リソース・タイプは読取り専用で、変更または削除できません。HTTP、TokenserviceRP、wl_authenなどがあります。
HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加します。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、ポリシーがすべてのHTTP操作に適用されます。
表20-2は、リソースのサンプルのURL値を示しています。詳細は、「リソースURL、接頭辞およびパターンについて」を参照してください。
管理機能は、リソースが存在するホストおよびリソースURLでアプリケーション・ドメインのリソースを識別します。
|
注意: HTTP以外のリソース・タイプにホスト識別子は関連付けられません。かわりに、管理者は、リソース定義ページの「リソースURL」フィールドにタイプの名前を入力する必要があります。 |
ホスト識別子は各リソースのコンテキストを作成するので、同じURLパスまたは異なるコンピュータのリソースを追加する場合に役立ちます。管理機能により、同じアプリケーション・ドメイン内のこれらのすべてのリソースを同じ方法で保護できます。一連のリソースを区別する唯一の違いは、ホスト・コンピュータの識別です。
すべての定義されたホスト識別子がリソース・ページの「ホスト識別子」リストに表示されます。リソースをアプリケーション・ドメインに追加する場合、管理機能でリソースをホストするコンピュータの1つのホスト識別子を選択する必要があります。
Access Managerは、リソースのURLを認識できるよう、そのリソースのホスト・コンピュータを参照するために使用される様々な方法を認識できる必要があります。
自動的なアプリケーション・ドメインの生成中、すべてのリソースが保護される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パターンを作成して、リソースのネームスペースの詳細な部分を指定できます。すべての照合で、大文字/小文字が区別されます。
表20-3 リソースURLパターンでサポートされるワイルドカード(優先順)
| パターン | 説明 | 例 |
|---|---|---|
|
/** |
デフォルトです。スラッシュ(/)で始まる0個以上の文字の連続に一致します。 このパターンを使用すると、特定の名前付きディレクトリの下にあるパスを保護できます。 注: これは既存の10gワイルドカードではありません。10gでは、/.../*パターンによって、パターンが定義されたレベルのルートを含まない排他的な一致が返されました。たとえば、/foo/.../*は/foo/barに一致しますが、ディレクトリ/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 関連項目: 表20-4 |
|
/.../階層 /.../*ホスト全体 |
スラッシュ(/)で囲まれた1つ以上の文字の連続に一致します。 評価はルート「/」から下の階層に向かって実行されます。各ディレクトリ・レベルで、最も高い優先レベルに一致するリソースが次の評価候補として選択された後、1つ下のレベルに進みます。これは、パス情報のみに基づく、可能な最善一致を表すリソースが取得されるまで続きます。 ホスト全体とは、パターン全体を意味します。 |
|
|
\ |
円記号は、特殊文字をエスケープするために使用します。前に円記号を付けた任意の1文字は、その文字自体に一致します。
|
|
表20-4は、ホスト識別子およびリソースURLに基づいてアルファベット順に整理された、アプリケーション・ドメイン内のいくつかのリソース定義を示しています。表20-4の右側の列は、形式が正しいかどうかを示しています。
ポリシー・モデルでは、リソース・パターン定義での問合せ文字列の名前と値のパラメータの使用がサポートされます。
名前: 記号などの任意の文字を含むことができる文字列リテラル。すべての文字がリテラルとして扱われます。
値: 任意の文字を含む文字列リテラルを指定できます。連続する0個以上の文字に一致させるには、ワイルドカード(*のみ)を含めます。アスタリスク(*)はワイルドカードとして扱われます。
量: 問合せ文字列に指定できる名前と値のペアの数に制限はありません。ただし、単一のリソースの場合、ペアは2、3個になります。
順序: 名前と値のペアには任意の順序を使用できます。実行時、これらのペアは問合せ文字列の一部として、任意の順序で処理される場合があります。
リソースの一致および優先順位: 問合せ文字列の名前および値のパラメータ
Access Managerでは、まず最も一致率の低いリソースを検出し、それよりも一致率の高いリソースを検出していくアルゴリズムが使用されます。単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、単一の文字列で定義された候補が優先されます。
パラメータ・リストを含むリソースの場合、次のように最善一致が決定されます。
パス一致: Access Managerによって、リクエストされたリソースのパスへの一致が試行されます。問合せコンポーネントや宣言された操作が異なる、複数の候補に一致する場合があります。
問合せ文字列一致: 取得した一致に対して、Access Managerによって、問合せ文字列(リクエストしたURL内に存在する場合)への一致が試行されます。単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、リテラル文字列で定義された候補が優先されます。操作が異なる複数の候補が残る場合があります。
操作一致: 取得した一致に対して、リクエストされた操作への一致が試行されます。完全一致が存在しない場合は、特定の操作が定義されていないリソースを確認します。つまり、リソース・タイプの一部として定義されているすべての操作に適用されます。いずれの場合も、これによって単一の最善一致が検出されます。
パス一致: 定義済リソースが、リクエストされたURLのパス・コンポーネントに対して評価され、一致が検索されます。使用される優先順位は、次のとおりです。
リテラル(リソースのパターンに特殊文字が含まれていない場合など)
選択肢: {パターン1,パターン2,...}。それぞれ自体に次の特殊文字が含まれる場合があり、同じ優先順位を使用して順番に評価されます。
範囲: [ ]
単一文字のワイルドカード: ?
ワイルドカード: *
階層: /.../
ホスト全体: /…/*はパターンの全体です。
評価はルート「/」から下の階層に向かって実行されます。各ディレクトリ・レベルで、最も高い優先レベルに一致するリソースが、次の評価候補として選択された後、1つ下のレベルに進みます。これは、パス情報のみに基づく、可能な最善一致を表すリソースが取得されるまで続きます。
|
注意: 11gのすべての照合は、以前と同様に大文字/小文字が区別されます。 |
表20-5は、リクエストされたいくつかのURLの、それぞれの一致パターンを示しています。
表20-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 |
sa{*,le,l?,a[k-m],[a-f-m]}s/.../{*b,?a}{a,/../ii}/.../{index,test}[pa].?tml |
問合せ文字列一致
単一の問合せ文字列と問合せパラメータの両方で定義された候補がある場合、単一の文字列で定義された候補が優先されます。単一の問合せ文字列のスコアは、すでに説明したアルゴリズムを使用して決定されます。
パラメータ・リストを含むリソースの場合、次のように最善一致が決定されます。
パラメータ値にワイルドカードが含まれていないリソースの優先順位は高くなります。そのようなリソースのセットの中で、最善一致はパラメータの名前と値を組み合せた長さを使用して決定されます。
問合せ文字列リテラルについては、組み合せた長さが等しい複数の一致が検出された場合、一致は失敗します。
次に検討されるのは、パラメータ値にワイルドカードが含まれているリソースです。そのようなリソースの中で、最善一致は各リソース内のワイルドカードの合計数を使用して決定されます。ワイルドカード数が等しい複数の一致が検出された場合、パラメータの名前と値を組み合せた長さによって最善一致が決定されます。
組み合せた長さが等しい複数のリソースが検出された場合、一致は失敗します。
問合せ文字列一致パターン: 2つ目およびそれに続くパターンでは、次のパラメータ・リストが使用されます。
表20-6は、リクエストされたいくつかのURLの、それぞれの一致パターンを示しています。
表20-6 問合せ文字列一致: 例
| リクエストされた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.htmlarea emeadept engg例1: 同じリソースURLおよび問合せ文字列を含むリソースがあり、1つが単一の文字列、もう1つが名前と値のペアとして定義されている場合、ポリシー評価の一致では、リテラル問合せ文字列が優先され、次に名前と値のペアが検討されます。たとえば、次の例では、a)に一致します。
/test.html?area=emea&dept=engg/test.htmlarea=emea&dept=engg/test.htmlarea emeadept engg最善一致、複数のリソース: 複数のリソースが問合せ文字列の名前と値のペアで定義されている場合、リソースの最善一致は、最も多い数の問合せ文字列のパラメータに一致するパターンです。ワイルドカード値が使用された場合、それに次ぐ基準として各パラメータ値の一致率が使用されます。
たとえば、次の2つの問合せ文字列パターンが定義されているとします。
area e*dept e*area em*dept en*area emeadept engg図20-13は、リソース定義ページを示しています。ここに示される、「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リソース定義を受け入れ、これらのリソースのアクセスを保護するために関連するポリシー・オブジェクトを生成します。ポリシー・プロビジョニング中に競合が発生した場合、競合のないリソースのポリシーのみがプロビジョニングされます。この機能は10g OSSOエージェント・ベースのパートナおよびアプリケーションには適用されません。OSSOエージェントには、リソースごとに認証スキームを施行する機能はありません。かわりに、単一の認証スキームがアプリケーションの全リソースに適用されます。
リソースのリクエストを処理する場合、リソースに適切なポリシーが起動していることを確認する評価が実行されます。
|
関連項目: 次の項に記載されているその他の処理の詳細 |
ユーザーは、リクエストしたリソースのURLを指定します。
Access Managerでは、ホスト識別子およびURLに基づいて、URLパターンを含む完全修飾URLが作成されます。
Access Managerは、リクエストしたリソースの着信URLとアプリケーション・ドメイン情報およびポリシーのURLパターンから構築された完全修飾URLを比較します。
一致すると、様々なポリシーが評価され、リクエスタのリソースへのアクセスを許可または拒否するかどうかが決定されます。
リクエストしたユーザーがアクセスを許可された場合、リソースが提供されます。
表20-7は、可能性のある結果を示しています。
表20-7 リソース評価の結果
| 結果 | 説明 |
|---|---|
|
最善一致 |
最善一致は、リソース定義がランタイム・リソースの他の可能性のある一致と比較して最小のリソース・スコープの場合です。リソース・スコープは、特定のリソース定義を使用した一致する可能性のあるすべてのリソースを表します。 |
|
一致なし |
一致なしの場合、デフォルトの評価結果はFAILUREです。評価されたポリシーの種類によっては、認証が実行されなかったり、リソースのアクセス権が付与されなかったりすることを意味する場合があります。 |
検索メカニズムの例
アプリケーション・ドメインのデフォルトのリソースURLは、使用可能な最大範囲の内容を定義します(すべてのディレクトリと次のディレクトリ)。
/.../*
パターン/.../index.htmlは、次と一致します。
/index.html /oracle/index.html /oracle/sales/index.html 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コンソールで目的のアプリケーション・ドメインを検索および表示します。
「アプリケーション・ドメイン」で、「リソース」タブをクリックし、「検索」ページの右上端にある「新規リソース」ボタンをクリックします。
リソース定義ページで、次の手順を実行します。
次の項の説明に従って、アプリケーション・ドメイン内の特定のポリシーに
定義済リソースを追加します。
この項では次のトピックを記載しています:
図20-14は、アプリケーション・ドメイン内のリソース定義のデフォルトの検索要素および検索結果の表を示しています。
デフォルトを使用して「検索」ボタンをクリックするか、リソースを探すために表20-8に示す情報を必要に応じてできるだけ多く、またはできるだけ少なく指定して検索を絞り込みます。
表20-8 アプリケーション・ドメイン内のリソースの検索要素
| 検索要素 | 説明 | |
|---|---|---|
|
リソース・タイプ |
定義されたリソース・タイプのリストから選択できます。空白にしておくこともできます。 デフォルト値: HTTP |
|
|
ホスト識別子 |
必要に応じて、ホスト識別子をここに入力します。ここは空白のままにできます。 デフォルト値: 空白 |
|
|
リソースURL |
必要に応じて、リソースURLを入力します。ここは空白のままにできます。 デフォルト値: 空白 |
|
|
問合せ文字列 |
リソースの問合せ文字列を入力するか、空白のままにします。アプリケーション・ドメインへの追加時に、リソースの問合せ文字列が定義されている場合は、この要素を検索条件に含めることができます。 デフォルト値: 空白 |
|
|
認証ポリシー |
このアプリケーション・ドメインに定義された認証ポリシーのリストが表示されます。1つ選択するか、空白のままにします。 デフォルト値: 空白 |
|
|
認可ポリシー |
このアプリケーション・ドメインに定義された認可ポリシーのリストが表示されます。1つ選択するか、空白のままにします。 デフォルト値: 空白 |
「リセット」をクリックしてフォームをクリアするか、「検索」をクリックして検索を開始します。結果表を例20-0に示します。リストされている各リソースには、ドメインへの追加時に指定したすべての要素が含まれています。表では「アクション」メニューおよび「表示」メニューを使用できます。また、「作成」コマンド・ボタンをクリックして、このドメインに新規リソース定義を追加することもできます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のリソース定義を検索できます。
リソース定義を検索する手順は次のとおりです。
「既存のアプリケーション・ドメインの検索」の説明に従って、Oracle Access Managementコンソールで目的のアプリケーション・ドメインを検索および表示します。
「リソース」タブをクリックしてリソース検索コントロールを表示します。
検索条件を入力し(表20-8)、「検索」ボタンをクリックします。
「検索結果」表で、目的のリソース定義をクリックし、必要なアクションを実行します。
「アクション」メニュー: 項目を選択して、選択したリソースを作成、編集または削除します。
「表示」メニュー: 項目を選択して、結果表の外観を変更します。
「編集」ボタン: ツールバー内のこのボタンをクリックして、構成ページを表示します。
「削除」: 「リソース定義の表示、編集または削除」を参照してください。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定のアプリケーション・ドメイン内のリソース定義を変更できます。
ポリシーに関連付けられているリソースの保護レベルが「保護」から「除外」に変更された場合、その変更は失敗します。まずポリシーからリソースを削除してから、変更を加えて、リソースをポリシーに追加してください。
|
注意: リソースがポリシーに関連付けられている場合、削除中にアラートが表示されます。ポリシーに関連付けられていない場合、リソースは削除されます。 |
前提条件
目的のリソース・タイプを共有コンポーネントとして定義する必要があります。詳細は、「リソース・タイプの管理」を参照してください。
リソース定義を表示、変更または削除するには
「リソース定義の検索」で説明したように、リソースを検索します。
表示のみ: 終了する場合はページを閉じます。
変更: 必要に応じて定義を変更し、「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。
削除:
目的のリソース定義を開いて削除対象であることを確認し、ページを閉じます。
目的のリソース定義の名前をクリックして、ツールバーの「削除」ボタンをクリックします。
確認ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。
リソースがポリシーに関連付けられている場合、まずリソースをそのポリシーから削除します。
必要に応じてこの手順を繰り返し、アプリケーション・ドメインの他のリソースを削除します。
1つの認証ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認証ポリシーの変更、新しいポリシーの追加、および認証ポリシーへのリソースの割当てを開始できます。
自動的に生成されたアプリケーション・ドメインでは、次の認証ポリシーがデフォルトとしてシードされ、管理者のタスクを効率化できます。
保護されているリソース
パブリック・リソース
この項では次のトピックを記載しています:
管理者は、認証ポリシーを使用して特定のリソースを保護できます。認証ポリシーは、ポリシーで制御されたリソースの唯一の認証方式を提供します。
各認証ポリシーにより、Access Managerの十分な信頼レベルを提供してリクエストを実行するユーザーにアクセス権を付与するために実行する必要がある検証のタイプが定義されます。
認証ポリシーはローカルです。単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。
認証ポリシーのガイドライン
認証ポリシーには、リソース、成功レスポンスおよび認証スキームが含まれます。
認証および認可ポリシーを成功または失敗で評価できます。
クエリー・ビルダーおよびLDAPフィルタのサポート(特定の表示タイプの属性に基づく一致を取得する場合など)。
決められた範囲内で使用できるリソース/…/*のポリシーを定義できます。
トークン発行ポリシーは、リソースおよびユーザー・ベースまたはパートナに基づく条件を使用して定義できます。
図20-16は、アプリケーション・ドメインの「認証ポリシー」ページを示しています。
図20-17は、特定の認証ポリシーを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。この例は、IAM Suiteアプリケーション・ドメインのものです。
表20-9は、認証ポリシーの要素を示しています。IAM Suiteアプリケーション・ドメインが例として示されています。
表20-9 認証ポリシーの要素および説明
| 要素 | 説明 |
|---|---|
|
名前 |
識別子として使用される一意の名前。 |
|
説明 |
認証ポリシーを説明するオプションの一意のテキスト。 |
|
認証スキーム |
ユーザー認証のためにポリシーで使用される単一の事前定義された認証スキーム。関連項目: 詳細は、「認証スキームの管理」を参照してください。 |
|
成功URL |
認証の成功時に使用されるリダイレクトURL。 |
|
失敗URL |
認証の失敗時に使用されるリダイレクトURL。 |
|
リソース |
リストから選択されたリソースのURL。リストされるURLは、以前にアプリケーション・ドメインに追加されたものです。認証ポリシーで保護する1つ以上のリソースを追加できます。リソース定義は、ポリシーに含める前にアプリケーション・ドメイン内に存在する必要があります。 関連項目: 「認証ポリシーのリソースについて」 |
|
レスポンス |
Webエージェントで実行される必須処理(認証後のアクション)。認証に成功すると、保護されたアプリケーションをホストするアプリケーション・サーバーは、これらのレスポンスに基づいてユーザー・アイデンティティをアサートできる必要があります。認証に失敗すると、ブラウザはリクエストを事前構成されたURLにリダイレクトします。 関連項目: 「SSOのポリシー・レスポンスの概要」 |
認証ポリシーで保護する1つ以上のリソースを追加できます。認証ポリシー・ページの「リソース」タブには、リソースURLを入力できる表が用意されています。アプリケーション・ドメイン内の定義済リソースから選択できるリストも用意されています。
リソースを追加するには、「+」ボタンをクリックして、リストから選択します。リソースを削除するには、「リソース」表から名前を選択して、表の「削除」ボタンをクリックします。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証ポリシーおよびリソースをアプリケーション・ドメインに追加できます。認証ポリシーの事前構成された認証スキームまたはカスタム認証スキームを使用できます。
前提条件
ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。
特定のリソースの認証ポリシーを追加するには、次の手順を実行します。
「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。
「認証ポリシー」タブをクリックし、次に「認証ポリシーの作成」ボタンをクリックして、新しいページを開きます。
必須要素: このポリシーの情報を追加します。
名前
認証スキーム
オプション要素(表20-9): ポリシーに必要な場合は追加します。
説明(オプション)
成功URL
失敗URL
リソースの追加: リソースを特定のポリシーに追加するには、そのリソースをアプリケーション・ドメイン内で定義する必要があります。
認証ポリシー・ページの「リソース」タブをクリックします。
「リソース」タブの「追加」ボタンをクリックします。
「Search」ボタンをクリックします。
「結果」表内のURLをクリックし、「選択済の追加」をクリックします。
必要に応じてこれらの手順を繰り返して、リソースを追加します。
「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。
レスポンス: 「SSOのポリシー・レスポンスの追加および管理」の説明に従って、ポリシーのレスポンスを追加します。
終了する際はページを閉じます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定の認証ポリシーを検索できます。
アプリケーション・ドメインの認証ポリシーを検索するには
「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。
「認可ポリシー」タブをクリックし、次の操作を実行します。
編集: 「認証ポリシーの表示または編集」を参照してください。
削除: 「認証ポリシーの削除」
表の連結解除: 表を1ページ全面に展開するには、ツールバーの「連結解除」をクリックします。
「表示」メニュー: メニュー項目を選択して、結果表の外観を変更します。
有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインの認証ポリシーを変更できます。これには、認証スキームの変更、リソースやレスポンスの追加または削除および成功または失敗URLの変更が含まれます。
認証ポリシーを表示または変更するには、次の手順を実行します。
「認証ポリシーの検索」の説明に従って、目的のポリシーを検索します。
目的のポリシー名をクリックして、その構成を表示します。
ポリシー要素を編集します(表20-9)。
リソース: 「リソース」タブをクリックし、次の操作を実行します。
追加: 「リソース」表の「追加」ボタン、リストのURL、「適用」の順にクリックします。
削除: 「リソース」表のURLをクリックして、表の「削除」ボタンをクリックします。
「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。
レスポンス: レスポンスを表示または編集します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。
終了する際はページを閉じます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインから認証ポリシーを削除できます。
ポリシーを削除しても、すべてのリソース定義はアプリケーション・ドメイン内に残ります。ただし、ポリシーおよびすべてのレスポンスが削除されます。
|
注意: 削除操作中、ポリシーの削除を確認するアラートが表示されます。操作を完了するには確認が必要です。 |
次の手順は、全体のポリシーの削除方法を示しています。ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。
認証ポリシーを削除するには、次の手順を実行します。
「認証ポリシーの検索」の説明に従って、目的のポリシーを検索します。
目的のポリシー名をクリックして、この構成を表示および確認します。
このポリシーで制御されたリソースが別のポリシーに追加されていることを確認します。
すべてのレスポンスを削除します(「SSOのポリシー・レスポンスの追加および管理」を参照してください)。
「認証ポリシー」タブで、ポリシーの横にある「シリアル番号」をクリックし、ツールバーの「削除」ボタンをクリックします。
確認ウィンドウで、確認して「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。
1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。
自動的に生成されるアプリケーション・ドメインでは、デフォルトとして次の認可ポリシーがシードされます。
保護されているリソース
パブリック・リソース
リソース定義をアプリケーション・ドメインに追加した後、管理者は、デフォルトの認可ポリシーの変更、新しいポリシーの追加および認可ポリシーへのリソースの追加を開始できます。この項では次のトピックを記載しています:
管理者は、認証されたユーザーまたは環境の属性に基づいて、1つ以上のリソースへのアクセスを保護する認可ポリシーを作成できます。認可ポリシーは、ポリシーに含まれるリソースの唯一の認可保護を提供します。
認可ポリシーがローカルなので、各ポリシーがポリシーで指定されたリソースにのみ適用されます。他のリソースにポリシーを導出または適用できません。
単一のポリシーを定義して、アプリケーション・ドメインの1つ以上のリソースを保護できます。ただし、1つの認可ポリシーでのみ、各リソースを保護できます。
図20-18は、アプリケーション・ドメイン内の「認可ポリシー」ページを示しています。このポリシーに割り当てられたリソースがポリシーの「リソース」タブに表示されます。
表20-10は、認可ポリシーの要素を示しています。ドメインに関係なく要素は同じで、詳細のみ異なります。
表20-10 認可ポリシーの要素および説明
| 要素 | 説明 |
|---|---|
|
名前 |
ナビゲーション・ツリーの識別子として使用される一意の名前。 |
|
説明 |
認可ポリシーを説明するオプションの一意のテキスト。 |
|
成功URL |
認可の成功時に使用されるリダイレクトURL。 |
|
失敗URL |
認可の失敗時に使用されるリダイレクトURL。 |
|
サマリー |
一般情報(通常は「名前」およびオプションの「説明」)。 |
|
リソース |
認可ポリシーで保護される1つ以上の事前定義されたリソースURL。 |
|
条件 |
|
|
ルール |
|
|
レスポンス |
「SSOのポリシー・レスポンスの概要」も参照してください。 |
有効な管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーをアプリケーション・ドメインに追加できます。
前提条件
ポリシーに追加するリソースは、ポリシーと同じアプリケーション・ドメイン内で定義する必要があります。
認可ポリシーおよびリソースを作成するには
「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。
「認可ポリシー」タブをクリックし、次に「認可ポリシーの作成」ボタンをクリックして、新しいページを開きます。
「サマリー」タブ: 情報を「サマリー」タブに追加します(表20-10)。
リソースの追加: リソースを特定のポリシーに追加するには、そのリソースをアプリケーション・ドメイン内で定義する必要があります。
「認可ポリシー」ページの「リソース」タブをクリックします。
「リソース」タブの「追加」ボタンをクリックします。
「検索」ボタンをクリックします。
「結果」表内のURLをクリックし、「選択済の追加」をクリックします。
これらの手順を繰り返して、さらにリソースを追加します。
「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。
レスポンス: 「SSOのポリシー・レスポンスの追加および管理」の説明に従って、ポリシーのレスポンスを追加します。
条件: 「認可ポリシー条件の定義」の説明に従って、認可条件を追加します。
条件: 「認可ポリシー・ルールの定義」の説明に従って、認可ルールを追加します。
終了する際はページを閉じます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して特定の認可ポリシーを検索できます。
認可ポリシーを検索するには、次の手順を実行します。
「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。
「認可ポリシー」タブをクリックし、次の操作を実行します。
編集: 「認可ポリシーおよびリソースの表示または編集」を参照してください。
削除: 「認可ポリシー全体の削除」を参照してください。
表の連結解除: 表を1ページ全面に展開するには、ツールバーの「連結解除」をクリックします。
「表示」メニュー: メニュー項目を選択して、結果表の外観を変更します。
有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメイン内の認可ポリシーを表示または変更できます。
認可ポリシーを表示または編集するには、次の手順を実行します。
「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。
サマリー: 必要に応じて編集します(表20-10)。
リソース: 「リソース」タブをクリックし、必要に応じて次のようにリソースを追加または削除します。
追加: 「リソース」表の「追加」ボタン、リストのURL、「適用」の順にクリックします。
削除: 「リソース」表のURLをクリックし、表の「削除」ボタンをクリックした後、確認します。
「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。
条件: 「認可ポリシー条件の表示、編集または削除」を参照してください。
ルール: 「認可ポリシー・ルールの定義」を参照してください。
レスポンス: 「SSOのポリシー・レスポンスの表示、編集または削除」を参照してください。
終了する際はページを閉じます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーまたはポリシー内のリソースを削除できます。
|
注意: 削除操作中、ポリシーの削除を確認するアラートが表示されます。操作を完了するには確認が必要です。 |
全体のポリシーを削除しても、すべてのリソース定義はアプリケーション・ドメイン内に残ります。ただし、アクセスを制御する認可ポリシー、条件およびルールが削除されます。
ポリシーの要素を変更するには、「認証ポリシーの表示または編集」を参照してください。
前提条件
ポリシーを削除する前または後に、ポリシーで制御されたリソースを別の認可ポリシーに割り当てます。
認可ポリシーを削除するには、次の手順を実行します。
「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。
オプション: ポリシー名をダブルクリックして内容を確認し、終了したらページを閉じます。
削除: ポリシー名をクリックし、ツールバーの「削除」ボタンをクリックします。
確認ウィンドウで、「削除」をクリックします(または「取消」をクリックしてウィンドウを閉じます)。
ポリシーがナビゲーション・ツリーにリストされていないことを確認します。
各ポリシーは、1つ以上の認証または認可レスポンスあるいはその両方をオプションで含むことができます。レスポンスは、Webエージェントで実行される後処理のアクション(必須処理)です。
|
注意: トークン発行ポリシーにはレスポンスがありません。 |
この項では次の情報を提供します:
管理者は、認証または認可が成功した後に実行する必要があるアクションを宣言するレスポンスを定義できます。認証および認可データがクライアント(通常はWebエージェント)に戻されます。
ポリシー・レスポンスにより、情報をセッションまたはアプリケーションに挿入し、SSOを有効化するために後で情報を抽出できます。たとえば、アイデンティティ・マッピングを顧客アプリケーションに挿入するか、エージェントまたはアプリケーションでアクションを実行できます。
認証または認可の成功および失敗に応じて指定されるレスポンスによっては、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を通じてユーザー情報が他のアプリケーションに渡されたりする場合があります。
|
注意: Oracle Access Manager 10gでは、特定の順序のURLのリダイレクトでのみ、アプリケーションのデータの経路を提供しました。 |
デフォルトのレスポンスは提供されません。図20-20は、Oracle Access Managementコンソールで管理者によって定義された認可ポリシー・レスポンスを示しています。認可レスポンスは、認可条件と組み合せて操作できます。
各レスポンスは、2つの入力(タイプおよび式)と1つの出力(評価された式の値)で構成されます。式は、式を処理する場合の値の構築方法を宣言します。レスポンス・タイプは、値文字列を使用して実行するアクションの形式を定義します。
認証ポリシーは、ユーザーのアイデンティティを決定します。各認証ポリシーには、認証スキームおよびレスポンス(式)が必要です。
認可ポリシーは、リソースへのユーザーのアクセス権を付与するかどうかを決定します。各認可ポリシーには、認可条件およびレスポンス(式)が必要です。
レスポンスのガイドライン
Cookie、ヘッダーおよびセッション・レスポンスがサポートされます。
URLリダイレクトを設定できます。
レスポンス定義は、各ポリシーの一部です。レスポンス値は、リテラル文字列の場合も、リクエスト、ユーザーおよびセッション属性から値を取得する追加的な埋込み式を含む場合もあります。
管理者は、表20-11で説明されているとおり、Oracle Access Managementコンソールのレスポンスを設定します。
表20-11 レスポンス要素
| 要素 | 説明 |
|---|---|
|
名前 |
このレスポンスと同じメカニズム(タイプ)を使用する他のレスポンスを区別する一意の名前。 |
|
タイプ |
レスポンスを伝達するために使用されるメカニズム。値文字列を使用して実行するアクションの形式。
|
|
値 |
変数として設定されるレスポンスの式。 詳細は、「ポリシー・レスポンスの言語について」を参照してください。 |
|
IDアサーション |
IDアサーションは、エンド・ユーザー(およびそのAccess Managerセッション)を表す、Access Managerから発行されたトークンのID伝播に必要です。 リライイング・パーティ(ID伝播ユースケース)へのプロキシ・アクセスを得るためにトークンをリクエストするAccess Managerによって保護されるWebアプリケーションであるセキュリティ・トークン・サービス・クライアントでは、エンド・ユーザーを表すAccess Manager IDアサーションを渡す必要があります。 IDアサーション・トークンは、正常に認証された後に生成され、ポリシー・レスポンス(名前が「OAM_IDENTITY_ASSERTION」で値がSAMLトークンというHTTPヘッダー)として返されます。 (「アサートされた属性」以外のタイプの)レスポンスを追加するたびに、 関連項目: |
次の2つの主な構造とともに非常に小規模なドメイン固有言語(DSL)を使用して、Access Manager認証および認可レスポンスを定義します。
リテラル文字列: This is a valid expressionなどです。
変数の参照
ドル記号の接頭辞($)を使用して宣言します。
ネームスペース$namespace.var_nameでスコープされます。
|
注意: 変数に$ns.name.attribute属性が含まれる場合があります。 |
ネームスペース・メカニズムを使用すると、次の変数タイプでシングル・サインオンが有効化します。
リクエスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報
セッション: ユーザー・セッションの詳細
ユーザー: ユーザーの詳細(ユーザーID、グループおよび属性情報)
詳細は、次の表を参照してください。
表20-12 シングル・サインオンのネームスペース・リクエスト変数
| ネームスペース | 説明 |
|---|---|
|
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 |
この項の内容は次のとおりです。
レスポンス・タイプとネームスペースおよび変数を決定した後、Oracle Access Managementコンソールでレスポンス属性を入力します。図20-21に示すように、単純なレスポンスはいくつかの認可レスポンスのいずれかのようになります。
単純なレスポンスはスタンドアロンです。それぞれの先頭にドル記号($)が付けられ、変数値とドット(.)で区切られるネームスペースがその後に付けられます。例:
$namespace1.var1
表20-15は、いくつかの単純なレスポンスおよびそれぞれに戻される内容の説明を示しています。
表20-15 単純なレスポンスおよび説明
| 名前 | タイプ | 値(単純な$ネームスペース.変数) | 戻される環境変数および値 |
|---|---|---|---|
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}
図20-22は、管理者によって定義されるいくつかの複雑なレスポンスを示しています。すべてがヘッダー・タイプ・レスポンスで、ダウンストリーム・アプリケーションで利用されるHTTPリクエストのヘッダー変数の値が設定されます。
表20-16は、図20-22のような複雑なレスポンスを示しています。
表20-16 複雑なレスポンス
| 名前 | 値 | 戻される環境変数および値 |
|---|---|---|
|
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 名前 |
詳細は、「ポリシー・レスポンス処理について」を参照してください。
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コマンドを使用すると、デフォルトの区切り文字およびエスケープ文字を変更できます。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
ポリシー・レスポンス処理は、認証レスポンスを再実行する認可リクエストの実行中に発生します。変数の参照に適切な値が入力され、すべての変数に値が設定されて認可値で一貫して設定できることを確認します。
一連の手順を実行して、レスポンスの式を処理します。
スキャナ/トークナイザ
パーサー
インタープリタ
解釈中、値の変数の参照が解決します。処理後の結果は単純な文字列値で、エージェントに伝播されるか、将来の使用に備えてセッション内に保存されます。
最初の適用される認可リクエストの認可レスポンスとともに認証の成功レスポンスが保存され、再実行されます。
認可レスポンスの式は、式の評価(成功、失敗または未確定)に応じて実行されるアクションを作成します。
|
注意: Oracle Access Manager 10gでは、認証Webゲート構成内と同じ動作を示します。これはAccess Manager 11gで10g Webgateを使用した場合にも適用されます。10g Webgateは常に、認証Webgateのような働きをするAccess Manager 11g資格証明コレクタにリダイレクトします。 |
変数を参照すると、値または次の内容が戻されます。
変数が設定されていない場合、NOT FOUNDが戻されます。
変数がnull値に設定されている場合、NULLが戻されます。
|
注意: レスポンスを検証してください。 |
処理のないパススルー
処理しないでパススルーを実行する必要がある値は、\を使用して識別できます。例:
\$1000
値$1000の結果が戻される値に表示されます。
詳細は、第48章「アイデンティティ・コンテキストの使用」を参照してください。
ポリシーおよびレスポンスを使用してシングル・サインオンを有効化し、他のディレクティブをオーバーライドできます。この項のアクティビティを開始する前に、「SSOのポリシー・レスポンスの概要」を確認してください。
特に指定のないかぎり、この項の情報が認証および認可レスポンスに同等に適用されます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証または認可のポリシー・レスポンスを保護されたリソース・ポリシーに追加できます。
たとえば、Oracle Internet Directoryをインストールしたときに作成される、レルムのDNを収集できます。オプションとして、Oracle Internet Directory内のサブスクライバのグローバル・ユーザーIDや、サブスクライバ名(デフォルトの会社ではなく)を構成することもできます(表20-17を参照)。
表20-17 新しいOSSOのインストール: 保護されたポリシー・レスポンス(ヘッダー)
| レスポンスのパラメータ | OIDがインストールされたときにレルムDNを収集する | OID内のサブスクライバのGUIDを別の会社に構成する | OID内のサブスクライバのGUIDをデフォルトの会社に構成する |
|---|---|---|---|
|
名前 |
osso-subscriber-dn (小文字) |
osso-subscriber (オプション) |
osso-subscriber-guid (オプション) |
|
タイプ |
ヘッダー |
ヘッダー |
ヘッダー |
|
値 |
dc=country,dc=example,dc=com |
dc=country_or_region,dc=com |
,dc=default_company,dc=com サブスクライバDN(たとえば、Oracle Internal Directory内)に移動して、値(たとえば、そのDNのorclguid)を検出します。 |
前提条件
認可レスポンスを作成する前に目的の条件を分析して、レスポンスによって適切なアクションが実行されることを確認します。認証または認可ポリシーが存在しているアプリケーション・ドメインが必要です。
ポリシー・レスポンスを追加するには
「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。
個々のポリシー・ページで、「レスポンス」タブをクリックしてアクティブ化し、「追加」ボタンをクリックした後、次の操作を実行します。
「名前」フィールドに、このレスポンスの一意の名前を入力します。
「タイプ」リストから、レスポンス・タイプ(セッション、ヘッダーまたはCookie)を選択します。
「値」フィールドに、このレスポンスの値を入力します。たとえば、$namespace1.var1などです。
必要に応じて繰り返します。
「適用」をクリックして、確認ウィンドウを閉じます。
終了する際はページを閉じます。
定義内容に基づいて、レスポンスを検証します。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証または認可のポリシー・レスポンスを表示または編集できます。
前提条件
認証または認可ポリシーが存在しているアプリケーション・ドメインが必要です。
ポリシー・レスポンスを表示、変更または削除するには、次の手順を実行します。
「既存のアプリケーション・ドメインの検索」の説明に従って、目的のアプリケーション・ドメインを検索します。
「認証ポリシー」(または「認可ポリシー」)タブをクリックし、目的のポリシー名をクリックします。
個々のポリシー・ページで、「レスポンス」タブをクリックし、必要に応じて先に進みます。
追加: 「SSOのポリシー・レスポンスの追加」を参照してください。
編集: 目的のレスポンスの名前、タイプまたは値をクリックし、必要に応じて編集して「適用」をクリックします。
削除: 目的のレスポンスをクリックして、「レスポンス」表の「削除」ボタンをクリックします。
確認ウィンドウを閉じます。
終了する際はページを閉じます。
定義に基づいて、次のレスポンスを確認します。
ヘッダー
セッション
Cookie: ブラウザのプラグイン・ツールを使用するか、ブラウザの「Cookieを表示する」設定をオンにします。
アサーションの要求
Access Manager 11gでは、各認可ポリシーに、そのポリシーによって保護されるリソースへのアクセスを許可するか拒否するかを定義するルールが含まれます。ルールでは、アクセスを許可または拒否されるユーザーや移入を定義する条件、および認可に関するその他の考慮事項が参照されます。認可ルールおよび条件は、特定の認可ポリシー内のすべてのリソースに適用されます。
条件およびルールの評価により、認可ポリシーを着信リクエストに適用するかどうかが決定されます。認証に成功した後、適切な必須処理が有効になり、定義された認可ルール、条件およびレスポンスと連携して動作します。着信リクエストごとに、認可ポリシーによって、適用される条件が存在するかどうかが決定されます。その場合、これらの条件が評価されます。
この項では次のトピックを記載しています:
認可ポリシーでは、そのポリシー用に定義されたすべての条件(またはサブセット)がルールに含まれます。ルールの影響によって、ポリシーの影響が決まります。
ポリシーごとに、1つ以上のルールの影響(結果)を設定できます。ただし、結果ごとに指定できるルールは1つのみです。次の結果を認可およびトークン発行ポリシーに適用できます。
認可されたユーザーによる、保護されたリソースへのアクセスを許可します。許可条件がユーザーに適用されない場合、ユーザーがポリシーの対象外となり、デフォルトでリクエストしたリソースへのユーザーのアクセスが拒否されます。
認可されたユーザーによる、保護されたリソースへのアクセスを拒否します。
単一条件に依存する単純なルールを作成するか、式を使用して複数の条件に基づくより複雑なルールを定義します。詳細は、「式および式ベースのポリシー評価について」を参照してください。
条件は、アクセス・リクエストで満たす必要がある1つ以上の基準を指定する要素です。条件の構造は制約と似ています(11.1.1.3および11.1.1.5を参照)。ただし、以前の制約に含まれていた許可および拒否ルールは、個別に「ルール」タブで指定されます。
各認可ポリシーには1つ以上の条件を含めることができます。様々な条件タイプを使用すると、次のことが可能になります。
保護されたリソースへのアクセスが(ルールに基づいて)許可または拒否されるユーザーまたはユーザー・グループの識別。
保護されたリソースのアクセスを許可または拒否するIPアドレスの範囲の指定。
|
注意: ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。 |
条件の適用期間を定義する時間の設定。
リクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性の評価を実行する属性の指定。
「条件」タブでは、図20-23のように、名前別に整理された定義済条件の表、および選択した条件の詳細を示す表が提供されます。
表20-18は、「条件」タブの要素およびコントロールを示しています。
表20-18 認可ポリシーの「条件」タブ
| 要素 | 説明 |
|---|---|
|
「条件」の表の要素 |
このポリシー用に定義されたすべての条件をリストします。 |
|
名前 |
条件の識別子として使用される一意の名前。 |
|
タイプ |
使用する条件の種類。次のタイプから1つのみ指定できます。
|
|
説明 |
この条件を説明するオプションの一意のテキスト。 |
|
「条件詳細」セクション |
この表の情報は、選択した条件のタイプによって異なります。詳細は、次のドキュメントを参照してください。 |
ユーザーおよびグループを分析して明示的にアクセスを許可または拒否するユーザーを決定する場合、ポリシーおよび条件に同じ情報を使用することをお薦めします。たとえば、特定のユーザー・グループ(アイデンティティ・タイプ)に制約される認可ポリシーがある場合、特定の時間(一時的タイプ)に制約される認可ポリシーがある可能性があります。
|
注意: 任意の条件でアクセスを拒否されるユーザーについては気にしないでください。どのアクセス条件も満たしていない場合、デフォルトでユーザーのアクセスは拒否されます。 |
ユーザーを分類する場合、ユーザーおよびユーザー・グループを異なる条件が適用されるグループに分割することをお薦めします。たとえば、ユーザーがリソースにアクセスできる時間帯や、ユーザーがリクエストを行う場合に使用する必要があるコンピュータなどの条件を指定できます。
マーケティング・グループのユーザーが特定のプロジェクト・グループに属し、人事管理グループのユーザーもプロジェクト・グループに属する場合などの一部のユーザーが複数のカテゴリに該当する場合、両方のカテゴリにユーザーを配置します。ユーザーが2つの条件を満たすことを必須にできます。
アプリケーション・ドメイン内でリソースのサブセットに対してポリシーを作成し、そのサブセットを別の認可ルールおよび条件で保護するには、同じ情報、つまり、このポリシーによって保護されるリソースへのアクセスをどのユーザーに許可し、どのような条件でリソースへのアクセスを明示的に許可または拒否するのかを検討します。
認可ポリシー内で条件を使用する目的は、次のとおりです。
ユーザー名、ロールまたは、ユーザーが満たす必要のある基準を含むLDAPフィルタによって、ユーザーを識別します。
ユーザーがリソースへのアクセスに使用できるコンピュータを指定します。
ルールが適用される時間帯を設定します。
リクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性の評価を実行する属性の指定。
条件を追加するメカニズムは、どのタイプを選択しても同じです。表示されたダイアログ・ボックスで、名前およびタイプを定義して条件のコンテナを作成します。その後、提供されたコントロールを使用して条件の詳細を定義します。
この項の内容は次のとおりです。
この項では次のトピックを記載しています:
ポリシー内では、特定の条件タイプのインスタンスを複数保持できます。
管理者が条件を認可ポリシーに追加すると、名前、タイプおよびオプションの説明を入力できるウィンドウ(図20-24)が表示されます。送信されると、この情報を使用して、同じく指定する必要がある条件詳細のコンテナが作成されます。
表20-19は、「条件の追加」の要素を説明しています。
表20-19 「条件の追加」ウィンドウの要素
| 要素 | 説明 |
|---|---|
|
名前 |
この条件の一意の名前。 |
|
タイプ |
次のタイプから1つのみ指定できます。
|
|
説明 |
オプション。 |
コンテナを追加すると、図20-25のように、そのコンテナが「条件」タブに表示されます。「名前」、「タイプ」および「説明」は、タブの最上部にある「結果」表に表示されます。下部のパネルには、条件の詳細が含まれます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して認可ポリシーの条件クラスを選択できます。
|
注意: ポリシー内では、特定の条件クラスのインスタンスを複数保持できます。 |
前提条件
アプリケーション・ドメインが存在している必要があります。
条件クラスを選択するには
「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。
ポリシー名をクリックして、その構成を開きます。
個々のポリシー・ページで、「条件」タブをクリックします。
「追加」(+)ボタンをクリックし、次の操作を実行します(表20-19)。
名前: 一意の名前を入力します。
「タイプ」リスト: 条件の種類を選択します(「アイデンティティ」など)。
「選択済の追加」ボタンをクリックします。
次のいずれかの項に進み、定義を完了します。
この項では、アイデンティティ条件に関するすべての情報を提供します。内容は次のとおりです。
アイデンティティ条件を定義する場合、1つ以上のユーザー・アイデンティティ・ストアから、ユーザー移入の1つ以上のメンバーを追加する必要があります。ユーザー移入は、ユーザーまたはグループのリストとして追加できます。また、実行時に使用するLDAP検索フィルタを追加して、ユーザー移入を識別することもできます。LDAP検索フィルタを使用すると、アイデンティティ・ストア(ディレクトリ・サーバー)内に新しいグループを再編成または作成することなく、ターゲット・アイデンティティの移入を簡単に指定できます。詳細は、次の各項を参照してください。
条件コンテナを開いた後、定義されたユーザー移入が表示されます。他の条件タイプと同様、アイデンティティ・タイプはアイデンティティ条件および一時的条件と組み合せて使用できます。
アイデンティティ条件を追加する場合、「追加」(+)ボタンの横にあるポップアップ・メニューを開き(図20-26の1)、「ユーザーとグループの追加」または「検索フィルタの追加」(2)を選択します。図20-26は、ポップアップ・メニューおよび表示される「アイデンティティの追加」ウィンドウ(3)を示しています。目的のアイデンティティを検索したら、それらを選択し、「選択済の追加」(4)をクリックします。
表20-20は、「アイデンティティの追加」の要素を示しています。
表20-20 「アイデンティティの追加」の要素
| 要素 | 説明 |
|---|---|
|
ストア名 |
この検索に使用するLDAPストアを、登録されたLDAPストアのリストから選択します。 |
|
エンティティ・タイプ |
「ユーザー」、「グループ」または「すべて」を選択して、検索基準を定義します。 |
|
エンティティ名 |
情報を入力して検索基準をさらに絞り込みます。 |
|
検索 |
検索基準が定義されたときにこのボタンをクリックします。 |
|
結果表 |
検索結果を表示します。 |
|
選択済の追加 |
クリックして、選択したユーザーまたはグループを結果表から条件の詳細に追加します。 |
1つ以上のアイデンティティを選択し、「選択済の追加」ボタンをクリックすると、「条件」タブは図20-27のようになります。
条件としてこれらの詳細を保存するには、タブの右上の「保存」ボタンをクリックします。
Access Manager 11gの認可条件では、許可または拒否されるアイデンティティの一部として、ユーザー、グループおよびLDAP検索フィルタのリストが受け入れられます。LDAPフィルタは、検索操作の特定の基準を表現するテキスト文字列です。LDAP検索フィルタを使用すると、アイデンティティ・ストア(ディレクトリ・サーバー)内に新しいグループを再編成または作成することなく、ターゲット移入を簡単に指定できます。
Access Manager 11gでは、次の条件およびリソース・タイプ用のLDAP検索フィルタ・データが受け入れられます。
アイデンティティ条件
トークン・リクエスタ・アイデンティティ条件
すべてのリソース・タイプ(HTTP、TokenServiceRPおよびその他のカスタム・リソース・タイプ)
ユーザーがLDAP検索フィルタを含む条件によって保護されているリソースへのアクセスを試行すると、Access Managerによって、フィルタの一部として指定されたアイデンティティ・ドメイン(アイデンティティ・ストア)に対するディレクトリ検索(LDAP検索)が実行されます。検索結果はキャッシュされるため、ディレクトリ・サーバー検索が繰り返し実行されることはありません。
「検索フィルタの追加」を選択すると、図20-28のようなコントロールが表示されます。複数のLDAP検索フィルタを認可ルールに追加し、実行時の評価に使用できます。LDAP検索フィルタを入力したフィールドは、許可または拒否されるユーザーの識別に使用されます。
表20-21は、検索フィルタの追加に関連付けられている要素を示しています。
表20-21 「検索フィルタの追加」の要素
| 要素 | 説明 |
|---|---|
|
ドメイン |
実行時に検索する必要があるアイデンティティ・ドメイン(登録されたユーザー・アイデンティティ・ストア)。各フィルタは特定のユーザー・アイデンティティ・ストアに関連付けられている必要があります。Access Manager 11gでは、指定されたアイデンティティ・ドメイン(アイデンティティ・ストア)に対してのみディレクトリ検索(LDAP検索)が実行されます。 |
|
検索フィルタ |
LDAP検索フィルタを入力するフィールド。例: ((|dept=sales)(dept=support)) 関連項目: 「LDAP検索フィルタの構文について」 |
|
テスト・フィルタ |
このボタンを使用すると、LDAP検索フィルタをテストして、予想した結果が返されるかどうかを確認できます。 |
|
テスト結果 |
フィルタ・テストの結果は、独自に指定した次の内容とともに表示されます。
|
|
フィルタの追加 |
このアイデンティティ条件にフィルタを追加するときにクリックします。 |
|
取消 |
フィルタを追加せずに「検索フィルタの追加」ダイアログを閉じるときにクリックします。 |
図20-29は、LDAP検索フィルタの追加後に表示される、アイデンティティ条件の詳細ページを示しています。
LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。正確な構文はアイデンティティ・ストアによって異なるため、ベンダーのドキュメントを参照してください。表20-22は、Access ManagerのLDAP検索フィルタの例を示しています。
表20-22 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)) |
(10gから)Access Manager 11gへの移行中、各LDAPルールは、Oracle Access Manager 10gディレクトリ・プロファイルに基づいて、対応する11gアイデンティティ・ドメイン(ユーザー・アイデンティティ・ストア)にマップされます。Access Manager 11gアイデンティティ・ドメイン(ユーザー・アイデンティティ・ストア)は、各LDAP検索フィルタに関連付ける必要があります。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』 |
有効な管理者の資格証明を持つユーザーは、次の手順を使用して、アイデンティティ・タイプ条件をアプリケーション・ドメインに追加できます。
|
注意: 別の条件を追加または選択する前に、個々に各条件定義を保存する必要があります。 |
前提条件
アプリケーション・ドメインが存在している必要があります。
アイデンティティ条件を認可ポリシーに追加するには
「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。
「条件」タブをクリックし、「追加」(+)ボタンをクリックします。
「名前」を入力し、「タイプ」リスト(または「トークン・リクエスタ・アイデンティティ」)から「アイデンティティ」を選択して、「選択済の追加」をクリックします。
ユーザー/グループの追加:
「条件詳細」セクションで、「追加」(+)ボタンをクリックします。
リストから「ユーザーとグループの追加」を選択します。
ストア名: 登録されたLDAPストアのリストから目的の名前を選択します。
検索する移入の基準(アイデンティティ・タイプおよびアイデンティティ名)を入力し、「検索」ボタンをクリックします。
目的の結果を選択します。
「選択済の追加」をクリックします。
別のユーザーまたはグループの条件を追加するには、この手順を繰り返します。
検索フィルタの追加:
「条件詳細」セクションで、「追加」(+)ボタンをクリックします。
ドメイン名: このフィルタのユーザー・アイデンティティ・ストアを選択します。
検索フィルタ: 検索フィルタの構文を入力します(表20-21)。
テスト: 「テスト・フィルタ」ボタンをクリックし、結果表を確認します。
「選択済の追加」ボタンをクリックします。
別のLDAP検索フィルタの条件を追加するには、この手順を繰り返します。
「適用」をクリックして、確認ウィンドウを閉じます。
終了する際はページを閉じます。
異なるユーザーとしてログインすることによって条件を検証し、リソースへのアクセスをテストします。
この項では次の情報を提供します:
IP4範囲条件タイプを使用すると、管理者はアクセスを許可または拒否されるIPアドレス範囲のリストを指定できます。他の認可条件と同様、IP4範囲条件タイプはアイデンティティ条件および一時的条件と組み合せて使用できます。
明示的なアドレス: 指定する各IPアドレスは、明示的で有効なアドレス(形式nnn.nnn.nnn.nnn)である必要があります。たとえば、192.2.2.2のように指定します。
|
注意: Oracle Access Manager 10gでは、ワイルドカードが最後の入力として受け入れられます(192.2.2.*や192.2.*など)。ワイルドカードを含まないIP4範囲は、複数のIP4範囲の値を含む条件を作成することによって、簡単に11gに移植できます。ただし、ワイルドカードを含む10gのIP4範囲は、アップグレード・ツールの使用によって、そのワイルドカードに関連する複数の範囲に拡張されます。 |
IP4範囲: 「開始」(開始)および「終了」(範囲の終了)にアドレスを入力することによって、範囲を定義します。指定する各IPアドレスは、明示的で有効なアドレス(形式nnn.nnn.nnn.nnn)である必要があります。たとえば、192.2.2.2のように指定します。「終了」フィールドには、「開始」フィールドよりも値の大きいアドレスを指定する必要があります。認可中、Access Managerによって、クライアントのIPアドレスが「開始」(開始)および「終了」(範囲の終了)に指定したアドレスの範囲に含まれているかどうかが確認されます。複数の重複する範囲が指定され、クライアントのIPアドレスがその範囲の1つにでも含まれている場合、条件によってtrueと評価され、その条件に設定された条件に基づいてアクセスが許可(または拒否)されます。
複数の重複する範囲が指定され、クライアントのIPアドレスがそのいずれかの範囲に含まれている場合は、条件によってtrueと評価され、その条件に基づいてアクセスが許可(または拒否)されます。
|
注意: 「開始」のIPアドレスが「終了」のアドレスよりも大きい場合、条件はどのクライアントのIPアドレスにも一致しません。 |
図20-30は、開始および終了が指定されたサンプルIP4範囲を含むIP4範囲条件の表を示しています。無効な値を指定すると、そのことが通知され、値は保存できません。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して、IP4範囲タイプ条件をアプリケーション・ドメインに追加できます。別の条件を追加または選択する前に、個々に各条件定義を保存する必要があります。
|
注意: ユーザーのIPアドレスが拒否されるアドレスの範囲外の場合、認可は成功しません。認可を成功させるには、許可ルールに基づいてユーザーに具体的にアクセス権を付与する必要があります。 |
前提条件
アプリケーション・ドメインが存在している必要があります。
IP4範囲タイプ条件を認可ポリシーに追加するには
「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。
「条件」タブをクリックし、「追加」(+)ボタンをクリックします。
「名前」を入力し、「タイプ」リストから「IP4範囲」を選択します。次にオプションの説明を入力し、「選択済の追加」をクリックします。
目的のIPアドレス範囲を追加します(表20-22を参照してください)。
「詳細」パネルで、「追加」(+)ボタンをクリックして「IP範囲の追加」ダイアログを表示します。
開始: 範囲の開始を入力します。
終了: 範囲の終了を入力します。
「追加」ボタンをクリックして、この範囲を「条件詳細」セクションに含めます。
別の範囲を追加する場合は、これらの手順を繰り返します。
「適用」をクリックして、確認ウィンドウを閉じます。
異なるIPアドレスを持つ異なるクライアントからログインして、保護されたリソースへのアクセスをテストすることによって、IP4範囲条件を検証します。
この項では次のトピックを記載しています:
一時的条件タイプを使用する場合、管理者は、開始時間、終了時間および曜日を追加する必要があります。他の条件のように、アイデンティティ条件およびIP4範囲条件と組み合せてこれを使用できます。
図20-31では何も選択されていませんが、デフォルトですべての曜日が有効です。
グリニッジ標準時(GMT)の24時間制に基づくHH:MM:SS(時間、分、秒)形式で期間を指定する必要があります。深夜は00:00:00(開始)に指定します。24:59:59で1日が終了します。
表20-23 一時的条件の詳細
| 要素 | 説明 |
|---|---|
|
開始時間 注意: 完全な24時間の範囲で時間を指定します。たとえば、深夜を00:00:00に指定して、午後11時を23:00:00に指定します。 |
この条件が開始する時間、分および秒を指定します。 注意: 時間はグリニッジ標準時(GMT)に基づいています。GMTは、夏時間またはサマー・タイムの調整がなく1年中同じです。 |
|
終了時間 |
この条件が終了する時間、分および秒を指定します。 |
|
日 |
このポリシーがアクティブな日を指定します。 デフォルト: すべての日(すべての曜日が未選択の場合を含む) |
このページを閉じる前に、詳細を保存します。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して、一時的タイプ条件をアプリケーション・ドメインに追加できます。
|
注意: 別の条件を追加または選択する前に、個々に各条件定義を保存する必要があります。 |
前提条件
アプリケーション・ドメインが存在している必要があります。
一時的条件を認可ポリシーに追加するには
「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。
「条件」タブをクリックし、「追加」(+)ボタンをクリックします。
「名前」を入力し、「タイプ」リストから「一時的」を選択します。次にオプションの説明を入力し、「選択済の追加」をクリックします。
「詳細」パネル(表20-23)で、次の操作を実行します。「詳細」パネルを開くには、表内の条件名をクリックします。
開始時間を入力します。
終了時間を入力します。
この条件を適用する曜日をクリックします(またはすべてを空白にして毎日を指定します)。
「保存」をクリックします。
「適用」をクリックして、確認ウィンドウを閉じます。
異なる回数ログインして、保護されたリソースへのアクセスを検証することによって、一時的条件を検証します。
この項では次のトピックを記載しています:
属性タイプ条件では、アプリケーション・ドメイン内のすべてのリソース・タイプおよび認可ポリシーに関連する許可または拒否アクセスのリクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性が評価されます。属性タイプ条件を定義すると、アクセスは次の項目によってスコープ指定される、名前と値のペアのリストに基づきます。
リクエスト・コンテキスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報。
セッション: ユーザーがセッションを確立したときのユーザー・セッションの詳細(事前定義済のセッション属性または任意のセッション属性の参照)。
ユーザー: ユーザー属性の情報(LDAP属性の参照)。この条件は、ユーザーの任意のLDAP属性の参照に対する条件を定義する場合のみ使用されます。ただし、userIDまたはgroupIDに基づく条件は、アイデンティティ条件を使用して定義されます。
アクセスが表20-24で説明されているいずれかの状況に基づく場合は、属性タイプ条件が必要です。
表20-24 属性タイプ条件を必要とするアクセス条件
| アクセスが基づく内容 | 説明 |
|---|---|
|
セッション属性 |
ユーザーにリソースへのアクセスが認可されるのは、セッション属性「認証レベル」がxx、セッション属性s1がv1およびセッションの開始時間がxxxxである場合です。 |
|
リクエストされたリソース |
ホスト名およびポート番号 |
|
ユーザーの詳細 |
ユーザーにリソースへのアクセスが認可されるのは、そのリソースのEmpnoがxxxxである(department=salesなど)場合です。 |
|
セッション属性に基づくトークン発行 |
リクエスタ・パートナでは、要求に含まれる属性SessionActiveTimeが15000である場合、リライイング・パーティにトークンを発行できます。 トークン発行ポリシーの要求ベースの条件は、セッション・データを使用して作成されたアサーションに基づいて定義します。 |
属性タイプ条件を定義する管理者は、組込み属性および既知の属性のフィールドにデータを入力します。属性名は、テキスト・フィールドに入力するか、値のリストから選択できます。実行する条件は、その条件にANDまたはOR接続詞を使用して構築されます。図20-32は、属性条件のページを示しています。
図20-33は、「属性の追加」ダイアログ・ボックスを示しています。各属性条件は、表20-25で説明されているフィールドによって定義されます。
表20-25 属性条件の要素
| 条件 | 説明 |
|---|---|
|
ネームスペース |
サポートされるネームスペース:
|
|
名前 |
属性名。次の内容に従って追加できます。 |
|
演算子 |
許可される演算子:
|
|
値 |
特殊なワイルドカード文字を含まないリテラル値。 |
組込みリクエスト
表20-26は、組込みリクエストの組込み属性名のリストを示しています。
表20-26 組込みリクエストの属性名
| 属性名 | 説明 |
|---|---|
|
agent_id |
リクエストしているエージェントの名前。 |
|
client_ip |
ユーザー・ブラウザのIPアドレス。 |
|
Policy_appdomain |
リクエストに一致するポリシーを保持するアプリケーション・ドメインの名前。 |
|
Policy_res |
リクエストに一致するリソース・ホストIDおよびURLパターン。 |
|
policy_name |
リクエストに一致する特定のポリシーの名前。 |
|
res_host |
リクエストしたリソースのホスト名。 |
|
res_port |
リクエストしたリソースのポート番号。 |
|
res_type |
リクエストしたリソースのタイプ。 |
|
res_url |
リクエストしたリソースURL。 |
組込みセッション
表20-27は、セッション・ベースの属性タイプ条件の属性名のリストを示しています。
表20-27 組込みセッションの属性名
| 属性名 | 説明 |
|---|---|
|
認証レベル |
セッションの現在の認証レベル。 |
|
認証スキーム |
現在の認証レベルを実現するために実行される認証スキームの名前。 |
|
セッション・カウント |
セッションにバインドされたユーザーのセッション数。 |
|
セッション作成時間 |
セッションの作成時間。 |
|
セッション有効期限時間 |
セッションの有効期間。 |
例: 属性条件のデータ(条件の集約)
表20-28は、許容できる各ネームスペースのサンプル条件データを示しています。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して、属性タイプ条件をアプリケーション・ドメインに追加できます。
|
注意: 別の条件を追加または選択する前に、個々に各条件定義を保存する必要があります。 |
前提条件
アプリケーション・ドメインが存在している必要があります。
属性タイプ条件を認可ポリシーに追加するには
「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。
「条件」タブをクリックし、「追加」(+)ボタンをクリックします。
「名前」を入力し、「タイプ」リストから「属性」を選択します。次にオプションの説明を入力し、「選択済の追加」をクリックします。
属性条件の詳細の追加: 条件の名前をクリックして詳細パネルを開き、次の操作を実行します。
「適用」をクリックして、確認ウィンドウを閉じます。
異なるシナリオでログインすることによって、属性条件を検証します。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して、アイデンティティ・タイプ条件をアプリケーション・ドメインに追加できます。
前提条件
アプリケーション・ドメインおよび認可ポリシーが存在していること。
認可ポリシー条件を表示、編集または削除するには
「認可ポリシーの検索」の説明に従って、目的のポリシーを検索します。
「条件」タブをクリックします。
「条件詳細」の編集: 目的の条件をクリックして、「編集」ボタンをクリックすると「詳細」パネルが表示されます。条件タイプによっては、「説明」のみが編集可能になります。
True: 名前をクリックし、「編集」ボタンをクリックします。編集できるのは「説明」のみです。
条件の削除: 削除する条件をクリックし、「条件」タブの「削除」ボタンをクリックします。
「適用」をクリックして、確認ウィンドウを閉じます。
終了する際はページを閉じます。
リソースにアクセスして結果を評価することによって、条件を検証します。
アクセスの許可ルール、アクセスの拒否ルールまたはこの両方が指定されていて、ユーザーがこれらの条件に該当しない場合、ユーザーはルールの対象外とされ、リクエストしたリソースへのアクセスをデフォルトで拒否されます。
ルールでは、リソースへのアクセスをユーザーに許可するか否かを指定するために次のことができます。
ユーザー名、ロールまたは、ユーザーが満たす必要のある基準を含むLDAPフィルタによって、ユーザーを識別します。
ユーザーがリソースへのアクセスに使用できるコンピュータを指定します。
ルールが適用される時間帯を設定します。
この項では次のトピックを記載しています:
ルールはAccess Manager 11gポリシー・モデルの新しい構造です。ルールによって、条件の評価結果を組み合せる方法が指定されます。また、各ルールには、全体的なポリシーの結果を決定するルール効果(ALLOWまたはDENY)が含まれます。
認可ルールでは、ポリシー、条件およびルールの評価中に実行するアクションと、その結果に基づく必要な操作が定義されます。結果は次の3つのいずれかになります。
True (アクセスの許可): アクセスの許可条件を満たす場合、ユーザーはルールのアクセスの許可部分の対象になります。
False (アクセスの拒否): アクセスの拒否条件を満たす場合、ユーザーはルールのアクセスの拒否部分の対象になります。
未確定: アクセスの許可条件もアクセスの拒否条件も満たさない場合、ルールはそのユーザーにとって対象外と呼ばれます。これは、ユーザーがルールの対象外であることと同じ意味です。ルールを評価した結果、ユーザーが対象外となった場合、ユーザーはそのルールに基づいてリソースへのアクセスを拒否されます。
場合によっては、単一の認可ルールが、アプリケーション・ドメインまたはポリシーのリソースを保護するための唯一の要件となります。ルールを構成して、そのルールによって保護されるリソースへのアクセスが許可されるユーザー、アクセスが拒否されるユーザー、およびこれらの制御が適用される条件(いつどのコンピュータから適用されるかなど)を識別できます。認可ルールに含まれるアクセスの許可条件およびアクセスの拒否条件で、すべてのユーザーを対象にする必要はありません。ルールによって保護されるリソースへのアクセスをリクエストしたが、いずれの条件も満たしていないユーザーは、そのリソースへのアクセスを拒否されます。
または、複数の認可条件からルールを構成してリソースを保護することが必要な場合もあります。異なるユーザーに対して複雑な条件を設けることもできます。たとえば、様々な認可条件を含むルールを定義し、それらの条件の1つ以上をユーザーが満たしているときにのみ、保護されているリソースへのアクセスを許可(または拒否)できます。たとえば、ユーザーがリソースへのアクセス権を付与されるには、2つの条件(あるグループに属し、かつ特定のIPアドレスが割り当てられているコンピュータを使用している、など)を満たす必要があると指定することもできます。
Oracle Access Managementコンソールを使用すると、認可ルールの式を簡単に作成できます。条件はルールの外部で宣言され、ルールの内部で参照されます。評価結果は、簡易モードと式モードのいずれかで結合されます。図20-34は、認可ポリシーの「ルール」タブを示しています。
表20-29は、簡易モードの評価の「ルール」タブに表示される要素およびコントロールを示しています。
表20-29 認可ポリシーの「ルール」の要素
| 要素 | 説明 |
|---|---|
|
ルール・モード |
条件およびルールの評価に使用される次の方法。
|
|
ルールの許可 |
ルールの評価および「選択した条件」リストの評価に基づいてアクセスを許可するルール。 |
|
ルールの拒否 |
ルールの評価および「選択した条件」リストの評価に基づいてアクセスを拒否するルール。 |
|
一致 |
「選択した条件」リストのすべての条件に一致させるか、「選択した条件」リストのいずれかの条件に一致させるかを選択する基準。 |
|
使用可能な条件 |
この認可ポリシー用に定義されたすべての条件のリスト。 |
|
選択した条件 |
ポリシーの評価プロセス用に構築する特定の条件のリスト。「使用可能な条件」リストからこのリストに項目を移動することによって構築します。 |
|
|
矢印型のコントロールを使用すると、条件を「選択した条件」リストに追加できます(またはその逆に、選択されている条件を削除できます)。 |
ユーザーがリソースへのアクセスをリクエストし、そのリソースが認可条件およびルールで保護されている場合、そのユーザーに関する情報がルールのとおりであるかどうかを確認します。条件にその他の情報(条件が適用される時間帯や日時など)が指定されている場合は、その情報も確認されます。このプロセスは、ルールの評価と呼ばれます。
認可条件式は、単一のルール、またはより複雑な条件を表現するために組み合せた複数ルールのグループから構成されます。たとえば、ユーザーがリソースへのアクセス権を付与されるために2つのルールのアクセスの許可条件を満たすことを要求する式を作成できます。これらの式を作成するには、Oracle Access Managementコンソールを使用します。式には次の要素が含まれます。
認可条件。認可ポリシー内で定義されている、使用可能な条件から選択します。
ルールを組み合せるための演算子。ルールの組合せにより、必要な認可保護を提供します(表20-31)。
複数の条件を含む式に対しては、ユーザーは式のどの条件の対象にもならない場合や、1つの条件の対象になる場合、または複数のルールの条件の対象になる場合があります。ユーザーにリソースへのアクセスが許可されるか拒否されるかは、常に式の評価結果(1つの条件ではなく、すべての条件とその組合せ)によって決まります。
認可条件式の最終結果の概要: Access Managerでは、最終的な結果を得られるまで、式に含まれる各ルールを評価します。認可条件式の評価では、最終結果として、アクセスの許可、アクセスの拒否または未確定のいずれかが戻されます。
図20-35は、式をルール・モードとして使用したときの「ルール」タブを示しています。
表20-30は、式モードの「ルール」タブに表示される要素を示しています。
表20-30 式モードの「ルール」タブ
| 要素 | 説明 |
|---|---|
|
ルール・モード |
条件およびルールの評価に使用される次の方法。
関連項目: 表20-31 認可ルールの式の演算子 |
|
ルールの許可 |
ルールの評価および「選択した条件」リストの評価に基づいてアクセスを許可するルール。 |
|
ルールの拒否 |
ルールの評価および「選択した条件」リストの評価に基づいてアクセスを拒否するルール。 |
|
条件 |
この認可ポリシー用に定義されたすべての条件のリストが提供されます。 |
|
挿入条件 |
選択した条件が式ウィンドウに追加されます。 |
|
検証 |
自動的に式の妥当性がテストされ、結果がレポートされます。 |
表20-31は、認可条件式の作成時に使用できる演算子を示しています。
表20-31 認可ルールの式の演算子
| 演算子 | 説明 |
|---|---|
|
( ) |
デフォルトでは、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つのルールを接続することもできます。 |
認可ルールの評価結果(式に複数の認可ルールが含まれている場合は、それらの認可ルールとも組み合せた評価結果)により、リクエストしたリソースへのアクセス権がユーザーに付与されるかどうかが判定されます。ルールの評価は、次のように実行されます。
式に指定された各認可ルールは、左から右に評価されます。結果は以前に評価されたルールと順次組み合されます。
評価結果が、それ以上他のルールを評価することなく、全体的なポリシーの結果を判断できるほど良好である場合、評価は終了し、全体的な結果が返されます。
各評価結果は、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))
スペース、タブまたは特殊文字を含む条件名(式を定義するときに正しくエスケープされている場合)は、正しく処理されます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して、ルールを認可ポリシーに追加できます。
前提条件
認可ポリシー・ルールを定義するには
「認可ポリシーの検索」の説明に従って、目的のドメインを検索します。
「ルール」タブをクリックします。
式:
簡易ルール・モード:
「ルール・モード」で「簡易」をクリックします。
ルールの許可:
一致させる次のいずれかの内容をクリックします。
「ルールの許可」または「ルールの拒否」の矢印を使用して、「使用可能な条件」列から「選択した条件」列に目的の条件を移動します。
「適用」をクリックします。
「ルールの拒否」で手順bを繰り返します。
「適用」をクリックして、確認ウィンドウを閉じます。
リソースにアクセスして結果を評価することによって、ルールを検証します。
ここでの手順は、エージェント登録と認証および認可ポリシーを操作できることを確認するいくつかの方法を示しています。手順は、OAMエージェントおよびOSSOエージェント(mod_osso)でほとんど同じです。ただし、OSSOエージェントは認証ポリシーのみ使用し、認可ポリシーは使用しません。
前提条件
アクセス権を付与されるユーザーおよびグループは、Oracle Access Managementに登録されるプライマリLDAPユーザー・アイデンティティ・ストアに存在する必要があります。
Access Managerで操作するためにエージェントを登録する必要があります。登録後、管理サーバーまたは管理対象サーバーを再起動することなく適切な認証とともに保護されたリソースにアクセスできる必要があります。
アプリケーション・ドメイン、認証ポリシーおよび認可ポリシーを構成する必要があります。
ログアウトは、第22章「11g Webゲートが関与するセッションの集中ログアウトの構成」の説明に従って構成されている必要があります。
認証およびアクセスを確認するには、次の手順を実行します。
Webブラウザを使用すると、登録されたエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します(認証リダイレクトURLが適切に指定されたことが証明されます)。例:
http://exampleWebserverHost.example.com:8100/resource1.html
ログイン・ページにリダイレクトしていることを確認します。
サインイン・ページで、求められた場合に有効なユーザー名およびパスワードを入力し、「サインイン」をクリックします。
リソースにリダイレクトしていることを確認し、先に進みます。
成功: 正しく認証され、リソースへのアクセスが付与された場合、構成が正常に動作します。
失敗: ログイン中にエラーを受け取った場合またはリソースへのアクセスが拒否された場合、次の項目を確認します。
失敗した認証: 有効な資格証明を使用して再度サインインします。
URL...のアクセスの拒否: このリソースのアクセスにこのユーザーIDが認可されていません。
使用不能なリソース: リソースが使用できることを確認します。
不正なリダイレクトURL: Oracle Access ManagementコンソールのリダイレクトURLを確認します。
いくつかのリモート管理モードで、管理者は既存のエージェント登録を更新、検証または削除できます。この項では次のトピックを記載しています:
Access Managerには、付属のエージェントを登録または変更せずにアプリケーション・ドメインとそのポリシーを管理する2つのモードがあります。リモート・ポリシーおよびアプリケーション・ドメイン管理でサポートされるのは、作成および更新の機能のみです。リモート管理では、アプリケーション・ドメインやポリシーの削除はサポートされていません。
|
注意: アプリケーション・ドメインの削除は手動のタスクであり、Oracle Access Managementコンソールを使用して実行する必要があります。 |
表20-32に、リモート・アプリケーション・ドメイン管理のモードを示します。ここでもコマンドのパラメータには、モード、$OAM_REG_HOMEに対する相対パスを使用する入力*Request.xmlファイル、入力ファイルの優先ロケーションが含まれます。
./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value
表20-32 リモート・ポリシー管理のモード、テンプレートおよびフラグ
| モードおよびテンプレート | 説明 |
|---|---|
|
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 |
CreatePolicyRequest.xmlファイルをリモートpolicyCreateモードで使用すると、管理者はエージェント登録を作成または更新することなく、ホスト識別子とアプリケーション・ドメインを作成できます。
複数のhostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を作成します。
アプリケーション・ドメインを作成します。
複数の保護リソース、パブリック・リソース、除外リソースを追加します。リソースは、問合せ文字列の有無にかかわらずどちらもサポートされます。
カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを作成します。
前述のとおり、CreatePolicyRequest.xmlファイルと、拡張された(完全な)エージェント登録テンプレートには、同じパラメータが多数存在します。CreatePolicyRequest.xmlファイルには、認証および認可のポリシーおよびリソースの要素があります(<agentName>要素はない)。
CreatePolicyRequest.xmlファイルのパラメータの一部は新規であり、エージェント登録XMLファイル全体には含まれず、元のエージェント登録ファイルの特定の要素を使用して作成または更新されます。ただし、同じ要素もあります。CreatePolicyRequest.xml固有の主な違いは、次のとおりです。
認証および認可のポリシーおよびリソースの要素があります。
<agentName>要素または関連する要素はありません。
UpdatePolicyRequest.xmlとCreatePolicyRequest.xmlの内容は、ほぼ同じです。どちらも同じ要素を提供しますが、例外は<protectedAuthnScheme>要素です。
UpdatePolicyRequest.xmlを使用して、管理者は次の操作が可能です。
複数のhostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を更新します。
アプリケーション・ドメインを更新します。
問合せ文字列の有無にかかわらず、複数の保護リソース、パブリック・リソース、除外リソースを追加します。
カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを更新します。
次を含む、カスタマイズしたポリシーを作成します。
ポリシーの表示名
ポリシーの説明
認証スキーム(認証ポリシーのみ)およびポリシーに関連付けられるリソースのサブセット
この項では、CreatePolicyRequest.xmlおよびUpdatePolicyRequest.xmlファイルにある、アプリケーション・ドメイン管理に対する一意のリモート管理要素について説明します。これらの要素の詳細は、表20-33を参照してください。
表20-33 リモート管理テンプレートの要素
| 要素 | 説明 | 例 |
|---|---|---|
<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>
|
次の手順は、管理者が、エージェントの登録を修正せずに、リモートでポリシーを作成するか、または既存のポリシーを更新する方法について説明します。
前提条件
「ポリシーのリモート管理について」を確認してください。
エージェントを使用せずにリモートでポリシーまたはアプリケーション・ドメインを管理するには
「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。
適切なリクエスト・テンプレートをコピーし、独自のポリシー管理リクエスト(必要に応じてアプリケーション・ドメインを修正)を開発します。
ポリシー作成リクエスト・ファイル
ポリシー更新リクエスト・ファイル
エージェント・ホストで、適切なモードで独自の*Request*.xml入力ファイルを指定して、次のコマンドを実行します。例:
policyCreateモード:
./bin/oamreg.sh policyCreate input/myCreatePolicyRequest.xml
policyUpdateモード:
./bin/oamreg.sh policyUpdate input/myUpdatePolicyRequest.xml
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面に表示されるメッセージを読んで成功したことを確認し、Oracle Access Managementコンソールを使用してドメインおよびポリシーを管理します。
agentUpdateプロセスは正常に完了しました。
固有の構成ファイルの場所: ...が出力フォルダ...に作成されました。
出力フォルダは、RREG.tar.gzが解凍されている場所(.../rreg/output/AgentName/)にあります。
アプリケーションは、PS2で導入された新しい概念です。アプリケーションには次の要素が含まれています。
launch-url (アプリケーションのエンド・ユーザーが使用)
アイコン、その説明、および(ユーザー向け)アプリケーション・ポータルでこのアイコンが表示される際に使用されるその他のメタデータ
次のアプリケーション・タイプがサポートされています。
SSOエージェント・アプリケーション(Webゲートにより保護)
フェデレーション・サービス・プロバイダ・パートナ・アプリケーション(Federationを使用してサードパーティのパートナ・アプリケーションを起動)
フォーム入力アプリケーション(アクセス・ポータル・アプリケーションのテンプレートに基づいたアプリケーション)
アプリケーションには、SSOによってそのアプリケーションを有効にするために必要な構成が含まれている必要があります。ただし、PS2の場合、フォーム入力アプリケーションとFederation SPアプリケーションにのみ、アプリケーション内にその構成が含まれます。SSOアプリケーションには、起動URLのみが含まれます。以降のリリースでは、新しい機能が追加されています。
|
注意: アプリケーション登録は、ESSOが構成されて有効になっている場合のみ機能します。アプリケーションを登録するには、アプリケーションのポリシー情報はESSOディレクトリ・ストアに格納されているため、ESSO IDSプロファイルが作成されている必要があります。 |
