| Oracle® Fusion Middleware Oracle Entitlements Server開発者ガイド 11gリリース2 (11.1.2.2) B71698-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Entitlements Server開発者ガイド 11gリリース2 (11.1.2.2) B71698-05 |
|
前 |
次 |
Oracle Entitlements Serverでは、モデルを使用してポリシーを構成する要素とその使用方法を定義し、ポリシーを作成します。ポリシー・モデルの詳細は、『Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド』を参照してください。さらに、モデルのコンポーネントの用語集や、ポリシーの実装の使用例が含まれています。この章では、管理APIを使用したOracle Entitlements Serverポリシー・モデルの実装方法について説明します。この章には次の項目があります。
ポリシーは、リクエスト時に、リクエストしているプリンシパルのプロファイルに基づいき、保護対象のターゲット・リソースに対して、結果(GRANTまたはDENY)を返すために作成します。高いレベルから、ポリシーは、結果、プリンシパル、ターゲット・リソース、リソースに許可されたアクション、およびオプションの条件間の関係を定義します。ポリシーが、アクセスのリクエストに対して適用可能となるのは、リクエストのパラメータがポリシーに指定されたものと一致した場合です。このポリシーの構文は次のとおりです。
GRANT the SupportManagerEast role MODIFY access to the Incidents servlet
if the request is made from an IP address of 229.188.21.21; return Obligation
("send log message if access is granted")
図1-1は、これらの要素が、(ポリシー・モデルにおいて)ポリシーに関係するオブジェクトに、どのようにマップされるかを示しています。これらのオブジェクトは、ポリシーをプラグラムによって作成するために使用できます。
結果(PolicyRuleEntry.EffectType)およびオプションの条件(RuleExpressionEntry)は、ポリシー・ルール(PolicyRuleEntry)で定義されています。ターゲット・リソース(ResourceEntry)とそこで実行可能なアクションはResourceActionsEntryで定義されています。リクエストするユーザー、グループまたはロールはプリンシパル(PrincipalEntry)として定義されています。さらに、プリンシパルには、AppRoleEntryで定義されたロールが割当済です。オプションの義務(ObligationEntry)は、コール元に決定とともに返される情報を指定します。これは、決定の実行時に評価されます(決定の評価時ではありません)。この情報は、コール元で使用される場合と使用されない場合があり、さらに決定自体に影響する場合があります。これらのプログラム・オブジェクトは、ポリシー・ストア(PolicyStore)のインスタンスに格納されています。詳細は、1.2項「単純なポリシーの構成」および2.3.1項「ポリシー・ストアへのアクセス」を参照してください。
認可ポリシーは、アプリケーション・ソフトウェア・コンポーネントと、アプリケーション・ビジネス・オブジェクトの両方へのアクセスを制御します。詳細は、第2章「プログラムによるポリシーの作成」を参照してください。
ロール・マッピング・ポリシーは、プリンシパルにどのようにロールを付与するか、または拒否するかを制御するルールを定義します。詳細は、1.3.2項「ロール・マッピング・ポリシーの定義」を参照してください。
第2章「プログラムによるポリシーの作成」の関連情報も参照してください。
単純な認可ポリシーを構成するには要素(またはポリシー・オブジェクト)を特定の順序で作成する必要があります。たとえば、ResourceEntryオブジェクトは、ResourceTypeEntryオブジェクトを定義した後にのみ作成できます。単純なポリシーは次に説明する順番で構成できます。
PolicyStoreオブジェクトは、ポリシー・ストア全体を表します。ポリシー管理アクティビティはすべて、管理権限を持つ管理ユーザーがポリシー・ストアへのハンドルを取得してポリシーを管理する場合にのみ開始できます。ユーザーには、少なくとも管理ロールを1つ割り当てる必要があります。コールが認可されていないロールのメソッドには、エラーが返されます。詳細は、2.3.1項「ポリシー・ストアへのアクセス」を参照してください。
|
注意: ポリシー・ストアは、Oracle Fusion Middlewareのインストール時に作成および構成されます。デフォルトのポリシー・ストア・ファイルは、$DOMAIN_HOME/config/fmwconfig/ディレクトリにあるsystem-jazn-data.xmlです。詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。 |
ApplicationPolicyオブジェクトはPolicyStoreオブジェクトの子であり、特定のアプリケーションのコンポーネントを保護するポリシーおよび関連情報の全体的なコンテナとして作成する必要があります。必要に応じて任意の数のApplicationPolicyオブジェクトを作成できますが、保護するアプリケーションごとに1つ作成することをお薦めします。createApplicationPolicyメソッドを使用すると、ApplicationPolicyオブジェクトのハンドルが返されます。詳細は、2.3.2項「アプリケーション・ポリシーの作成」を参照してください。
ResourceTypeEntryオブジェクトには、1つまたは複数のリソース属性と、特定の種類のリソースで実行できるすべての有効なアクションの定義を指定します。このアクションは標準のアクション(URLへのGETおよびPOST)の場合もビジネス・オブジェクトでのカスタム・アクション(銀行口座間の振替)の場合もあります。次のResourceTypeEntryオブジェクトとその有効なアクションについて考えてみます。
テキスト・ファイルは「読取り」、「書込み」、「コピー」、「編集」、「削除」をサポートできます。
銀行の当座預金口座アプリケーションでは、預入れ、引出し、残高確認、履歴の確認、普通口座への振替、または普通口座からの振替がサポートされます。
アクションは、ResourceTypeEntryから作成された保護されたResourceEntryインスタンスにアクセスしたときに付与または拒否されます。ResourceTypeEntryを作成するには、オブジェクトの作成、読取り、更新および変更を提供するResourceTypeManagerをコールします。詳細は、2.3.3項「リソース・タイプの定義」を参照してください。
ResourceTypeEntryからResourceEntryを開始します。
特定の保護ターゲット(ResourceEntry)はResourceTypeEntryオブジェクトからインスタンス化されます。ResourceManagerは、ResourceEntryを作成、読取り、更新および削除するメソッドを提供します。ResourceEntryオブジェクトは、保護されたターゲットを表します(たとえば、アプリケーション)。さらにResourceTypeEntryを参照し、PolicyDomainEntryに従って作成されます。PolicyDomainEntryオブジェクトが指定されていない場合は、デフォルトのPolicyDomainEntryオブジェクトに従って作成されます。詳細は、2.3.4項「リソースのインスタンス化」を参照してください。
|
注意: PolicyDomainEntryは編成構造です。デフォルトのPolicyDomainEntryのインスタンスは取得できません。デフォルトのPolicyDomainEntryでオブジェクトを取得するには、ApplicationPolicyを取得してオブジェクトのManagerインタフェースを使用します。 |
ResourceActionsEntryインタフェースを使用して、適用可能なアクションをResourceEntryに関連付けます。
ResourceActionsEntryオブジェクトを作成して、ResourceEntryオブジェクトで実行可能なアクションを定義します。ResourceActionsEntryオブジェクトで定義されたアクションのセットは、そのオブジェクトが参照するResourceTypeEntryで定義済の有効なアクションのセットのサブセットです。ResourceActionsEntryオブジェクトは直接ポリシーに追加するか、1つ以上をPermissionSetEntryに追加できます。概要は、1.3.4項「権限セットの移入」を参照してください。ResourceActionsEntryオブジェクトをPermissionSetEntryオブジェクトに追加するプログラミングの詳細は、2.4.4項「権限セットの定義」を参照してください。
この手順の内容は次のとおりです。
PolicyRuleEntryオブジェクトで結果(GRANTまたはDENY)を指定します。
詳細は、2.3.6項「ポリシー・ルールの指定」を参照してください。
PrincipalEntryオブジェクトでポリシー・プリンシパルとしてユーザーまたはグループを指定します。
詳細は、2.3.7項「プリンシパルの指定」を参照してください。ポリシー・プリンシパルとしてアプリケーション・ロールを指定することもできます。詳細は、1.3.1項「アプリケーション・ロールの作成」を参照してください。
ターゲット・リソース・インスタンスと適用可能なアクションを含んだResourceActionsEntryオブジェクトを使用します。
詳細は、2.3.5項「リソースへのアクションのポリシー・ルールの関連付け」を参照してください。
PolicyManagerをコールし、PolicyEntryを作成します。
詳細は、2.3.8項「ポリシーの定義」を参照してください。
このシーケンスと、ポリシー・オブジェクトの作成に関する情報は、第2章「ポリシーのプログラムによる作成」で追加情報とともに再度説明します。ポリシー・オブジェクトの管理(取得、変更および削除など)に関する詳細は、第3章「ポリシー・オブジェクトのプログラムによる管理」を参照してください。
1.2項「単純なポリシーの構成」では、ポリシーを作成するために必要な最小限のコンポーネントについて説明しました。ここでは、単純なポリシーに追加して詳細な調整を可能にするオブジェクトの情報について説明します。
これらのオブジェクトの作成に関する追加のプログラムの情報は、第2章「ポリシーをプログラムによる作成」を参照してください。これらのオブジェクトの取得、変更および削除に関する追加のプログラムの情報は第3章「ポリシー・オブジェクトのプログラムによる管理」を参照してください。
アプリケーション・ロールはユーザー、グループおよび他のアプリケーション・ロールの集合です。たとえば、特定のターゲット・アプリケーションに必要なすべての権限をアプリケーション・ロールに付与できます。アプリケーション・ロールを作成したら、そのロールのメンバーシップをユーザーに付与することで、ユーザーに静的に割り当てることができます。あるいは、ロール・マッピング・ポリシーでロールを参照することで、ポリシー自体で定義された権限がポリシーのプリンシパルに付与されるため、動的に割り当てることもできます。アプリケーション・ロールはエンタープライズ・ユーザー、グループまたはアイデンティティ・ストアのロール、またはポリシー・ストアの別のアプリケーション・ロールに割り当てることができます。1つのターゲット・アプリケーションが複数の異なるロールを持ち、よりきめの細かいアクセスのために、それぞれのロールに異なる権限のセットを割り当てることが可能です。
アプリケーション・ロールはApplicationPolicyレベル(したがってその名前)で定義されます。AppRoleEntryオブジェクトは、アプリケーション・ロールを表します。AppRoleManagerは、アプリケーション・ロールの作成、削除、変更および検索するためのメソッドを提供し、さらにロールのメンバーシップを付与および取り消すメソッドを提供します。メンバーシップは、grantAppRole()メソッドの使用により静的に付与するか、ロール・マッピング・ポリシーにより動的に付与できます。ロール・マッピング・ポリシーでは、ロールをユーザーに割り当て、認可ポリシーではロールのアクセス権限を定義します。
アプリケーション・ロールはロールの継承および階層を使用します。継承パターンは、エンタープライズ・ユーザーまたはグループあるいはアイデンティティ・ロールがアプリケーション・ロールに割り当てられる(ロール・マッピング・ポリシーを使用)ようなもので、ロール・マッピング・ポリシーにより禁止されなければ、子ロールも継承します。たとえば、アプリケーション・ロール1がアプリケーション・ロール2に付与された場合、アプリケーション・ロール2はアプリケーション・ロール1のメンバーです。アプリケーション・ロール2として定義されたすべてのサブジェクトは、継承を通じてアプリケーション・ロール1にも定義されます(他のロール・マッピング・ポリシーによって禁止されていない場合)。AppRoleEntryがポリシー・プリンシパルとして参照されるとき、ロールに割り当てられたすべてのユーザーのリソースへのアクセスは、ポリシーにより管理されます。
|
注意: アプリケーション・ロールは、ロール・マッピング・ポリシーによって他のアプリケーション・ロールに割り当てることはできません。アプリケーション・ロール間のメンバーシップは、静的でのみ定義できます。 |
詳細は、2.4.1項「アプリケーション・ロールの作成」を参照してください。
保護されたリソースへのアクセスは、認可ポリシーにリソースと、そのリソースにアクセス可能な特定のユーザーまたはグループを定義することで付与できます。ただし、実行時に認可の前に動的にユーザーを決定する場合は、アプリケーション・ロールを定義し、保護されたリソースとアプリケーション・ロールを認可ポリシーで設定し、ロール・マッピング・ポリシーを作成することでもアクセスを付与できます。
1.3.1項「アプリケーション・ロールの作成」の説明のとおり、アプリケーション・ロールへのメンバーシップは、grantAppRole()メソッドの使用により静的に付与するか、ロール・マッピング・ポリシー(RolePolicyEntry)により動的に付与できます。アプリケーション・ロールはロール・マッピング・ポリシーのプリンシパルとして参照され、ユーザーに定義済のリソースへのアクセス権を付与できますが、ロール・マッピング・ポリシーは認可が決定される前に解決される必要があります。この解決では、アクセスのリクエスト・ユーザーをこのアプリケーション・ロールに割り当てることができるかどうかという質問に対応します。リソースへのアクセスのリクエストが受信されると、適用された認可ポリシーが取得され、評価されます。ポリシーがアプリケーション・ロールをプリンシパルとして参照している場合、アクセスの決定の前にそれらのロールが評価される必要があります。
また、ロール・マッピング・ポリシー、認可ポリシーあるいはこれら両方に日中の時刻や週の曜日などの条件を定義することで、リソースへのアクセスを限定する制限を適用できます。詳細は、1.3.3項「条件の追加」を参照してください。ロール・マッピング・ポリシーの詳細は、1.4項「ロールを使用したポリシーの実装」および2.4.2項「ロール・マッピング・ポリシーの作成」を参照してください。
認可ポリシーまたはロール・マッピング・ポリシーには、追加の制約を設定する方法で条件を追加できます。条件は式の形で作成され、trueかfalse(ブール値)かが決定されて、次のいずれかの結果になります。
式の結果がtrueの場合、ポリシーの条件は満たされ、PolicyRuleEntryが適用されます。
式の結果がtrueでない場合、ポリシーは適用されません。
条件はなんらかのユーザー、リソースまたはシステム属性の値をテストするブールの複雑な組合せであるか、複雑なビジネス・ロジックを評価するカスタムのJava評価関数である可能性があります。条件を作成して属性や関数を定義するには、ExtensionManagerをコールし、利用可能なメソッドを使用して、ポリシーを参照するための次のいずれかのオブジェクトを作成します。
AttributeEntry(ポリシー・ルールに動的に追加可能な名前/値のペア)
FunctionEntry(外部で実装されたロジック)
ポリシー評価時に、条件を設定する手段としてこれらのいずれかをPolicyRuleEntryに追加できます。詳細は、2.4.5項「条件の定義」を参照してください。
ResourceActionsEntryオブジェクトは、特定の保護されたターゲット(リソース)に実行可能なアクションを関連付けます。ResourceActionsEntryオブジェクトは、単純な認可ポリシーを作成するときに指定します。また、1つ以上のResourceActionEntryオブジェクトにPermissionSetEntry(資格とも呼ばれます)を移入することでより複雑なポリシーを作成することもできます。
移入するには、PermissionSetManagerをコールし、PermissionSetEntryを初期化して、1つ以上のResourceActionsEntryオブジェクトを追加します。これによりPermissionSetEntryが、PolicyEntryオブジェクトで参照されます。詳細は、2.4.4項「プロパティ・セットの定義」を参照してください。
義務にはアクセスの決定と一緒にコール側アプリケーションに返される追加の情報を指定します。この情報がポリシー実行中に考慮されるかどうかは、アプリケーションにより定義された設定に基づきます。義務の情報は、有効なポリシーの結果(GRANTまたはDENY)とともに返されます。たとえば、アクセスのリクエストが拒否された理由を義務として返すことができます。異なるタイプの義務にはメッセージの送信を含めることができます。たとえば、特定の金額が当座預金口座から引き出される場合に、口座の名義人の登録携帯電話にテキスト・メッセージを送信します。
|
注意: 条件がfalseと評価された場合、義務はコール側に送信されません。 |
義務を指定するには、ObligationEntryオブジェクトを作成します。このオブジェクトは、義務の引数を形成する一連の属性を含みます。これによりObligationEntryが、PolicyEntryオブジェクトで参照されます。詳細は、2.4.6項「義務の追加」を参照してください。
1.3.2項「ロール・マッピング・ポリシーの定義」の説明のとおり、ユーザーおよびグループをアプリケーション・ロールへマッピングするときには、(直接ロール・メンバーシップを使用した)静的なマッピングと、(ロール・マッピング・ポリシーを使用した)動的なマッピングが可能です。ロール・マッピング・ポリシーは、プリンシパル(ユーザー、グループ)、オプションのターゲット(リソース、リソース名の式)および(オプションの)条件を含みます。ロールは、認可ポリシーを使用してアクセス権限にもマップできます。認可ポリシーには、プリンシパル(ユーザー、グループ、アプリケーション・ロール)、ターゲット(リソース、資格セット、リソース名の式)、ターゲットで実行可能なアクションおよび(オプションの)条件と義務を含めることができます。認可の評価では次の処理が実行されます。
プリンシパルに基づき、アプリケーション・ロールのリストは、静的ロール・メンバーシップと、適用可能なロール・マッピング・ポリシーのチェックにより決定されます。
プリンシパルとアプリケーション・ロールの結果リストに基づき、適用できるポリシーを検出するために、認可ポリシーのリストが評価されます。適用できるポリシーは、プリンシパル、一致するターゲットおよび条件の評価に基づきます。
評価結果は、アルゴリズムを組み合せた拒否のオーバーライドに基づきます。
詳細は、2.4.1項「アプリケーション・ロールの作成」と2.4.2項「ロール・マッピング・ポリシーの作成」を参照してください。
