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