Oracle® Fusion Middleware Oracle Entitlements Server開発者ガイド 11gリリース2 (11.1.2.3) E67355-01 |
|
前 |
次 |
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
を作成します。
ApplicationPolicy
オブジェクトはPolicyStore
オブジェクトの子であり、特定のアプリケーションのコンポーネントを保護するポリシーおよび関連情報の全体的なコンテナとして作成する必要があります。必要に応じて任意の数のApplicationPolicy
オブジェクトを作成できますが、保護するアプリケーションごとに1つ作成することをお薦めします。createApplicationPolicy
メソッドを使用すると、ApplicationPolicy
オブジェクトのハンドルが返されます。詳細は、2.3.2項「アプリケーション・ポリシーの作成」を参照してください。
ResourceTypeEntry
を作成します。
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項「権限セットの定義」を参照してください。
PolicyEntry
を作成します。
この手順の内容は次のとおりです。
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項「ロール・マッピング・ポリシーの作成」を参照してください。
WebLogicオーセンティケータは、ユーザーがシステムにログインできるかどうかをチェックするモジュールです。WebLogicオーセンティケータをJavaセキュリティ・モジュールとともに使用している場合、LoginContextからのサブジェクト内のプリンシパルにシグネチャ情報が含まれているが、ポリシー・ストア内のプリンシパルにはシグネチャ情報が含まれていないため、セキュリティ・モジュールでポリシーが見つからないことがあります。これが発生する場合、セキュリティ・モジュールで適切な決定を行うことができません。このシナリオは、Javaセキュリティ・モジュールのみで発生し、その他のセキュリティ・モジュールでは発生しません。
ポリシー評価中にこの問題を回避するには、イテレータを使用して、現在のサブジェクトを表示し、プリンシパルからシグネチャを手動で削除するか、シグネチャなしのサブジェクト・ユーザー/グループ・プリンシパルを再作成できます。サブジェクト変数は、LoginContextから取得されるサブジェクトです。
手順は次のとおりです。
イテレータを使用して現在のサブジェクトを表示します。
Set<Principal> principles = subject.getPrincipals(); Iterator<Principal> it = principals.iterator(); while(it.hasNext()){ Principal principal = it.next(); if(principal instanceof WLSPrincipal){ ((WLSPrincipal)principal).setSignature(null); } }
hasNext()
- 反復処理でさらに要素がある場合にtrueを返します。
next()
- 反復処理で次の要素を返します。
((WLSPrincipal)principal).setSignature(null)
がコールされ、シグネチャが削除されます。
setSignature
は、導出されたプリンシパルのトラスト・シグネチャを設定します。
プリンシパルからシグネチャを削除します。
シグネチャをNULLに設定する方法は、WebLogic Server 10.3 APIリファレンスのクラスWLSPrincipalのAPIに関する項を参照してください。
シグネチャなしのサブジェクト・ユーザー・グループ・プリンシパルを再作成します。
Subject newSubject = new Subject(); Set<Principal> principals = subject.getPrincipals(); Iterator<Principal> it = principals.iterator(); while(it.hasNext()){ Principal principal = it.next(); if(principal instanceof WLSGroupImpl){ Principal groupPrincipal = new WLSGroupImpl(principal.getName()); newSubject.getPrincipals().add(groupPrincipal); } else if(principal instanceof WLSUserImpl){ Principal userPrincipal = new WLSUserImpl(principal.getName()); newSubject.getPrincipals().add(userPrincipal); } }
Principal userPrincipal = new WLSUserImpl(principal.getName())
は、プリンシパルを作成します。
getName
- プリンシパルの名前を返します。
"subject.setReadOnly()"/"newSubjectsubject.setReadOnly()"を追加します。