| Oracle® Fusion Middleware Oracle Entitlements Server管理者ガイド 11gリリース2 (11.1.2.2) B71695-05 |
|
 前 |
 次 |
ポリシーは、Oracle Entitlements Serverによって評価され、特定の保護されたリソースへのアクセスまたは特定のロールへの割当てをユーザーに付与するかどうかを指定する条件のセットです。この章では、ポリシーを構成する要素であるOracle Entitlements Serverのポリシー・モデルの概要と、その要素のポリシー・ストアでの構成について説明します。この章には次の項目があります。
Oracle Entitlements Serverでは次のタイプのポリシーの作成がサポートされます。参照先の項には、ポリシー・タイプに関する詳細がその使用法とともに含まれています。
認可ポリシーは、組織の保護されたリソースへのアクセスを制御する条件を定義します。2.1.1項「認可ポリシーの理解」を参照してください。
ロール・マッピング・ポリシーは、Oracle Entitlements Serverで作成したロールへのメンバーシップを外部のユーザー、グループまたはロールに付与または拒否する方法を制御する条件を定義します。2.1.2項「ロールの割当てとロール・マッピング・ポリシーの理解」
認可ポリシーは、リクエストしているユーザーのプロファイルに基づき特定のリソースへのアクセス権を付与または拒否するために作成されます。高いレベルから、認可ポリシーは、結果(付与または拒否)、プリンシパル(リクエストしているユーザー)、ターゲット・リソース、リソースに許可されたアクション、およびオプションの条件間の関係を定義します。認可ポリシーは、リクエストのパラメータがポリシーに指定したものと一致した場合に、アクセスのリクエストに適用できます。次の認可ポリシーの定義を考えてみます。
GRANT the SupportManagerEast role MODIFY access to the Incidents servlet if the request is made from an IP address of 229.188.21.21
この認可ポリシーでは、SupportManagerEastロールのメンバーであるユーザーに、インシデント・サーブレットへの変更目的のアクセス権を付与します。このポリシーには、IPアドレス229.188.21.21からのリクエストに限られるというオプションの条件による制約もあります。したがって、リクエストのパラメータがポリシーのパラメータと一致し(SupportManagerEastロールのメンバーがインシデント・サーブレットを変更する)、リクエストがIPアドレス229.188.21.21から出された場合、リクエストは許可されます。リクエストのパラメータがポリシーのパラメータと一致した(SupportManagerEastロールのメンバーがインシデント・サーブレットを変更する)が、リクエストがIPアドレス229.188.21.21から出されていない場合、リクエストは無視されます。次の用語と値のリストは、ポリシー定義から抽出されたもので、認可ポリシーのコンポーネントを構成します。
結果: 付与
アクション: 変更
リソース: インシデント・サーブレット
プリンシパル: SupportManagerEastロールのメンバー
条件/制約: IPアドレス229.188.21.21
図2-1に、このポリシーのコンポーネントの、Oracle Entitlements Server認可ポリシー・オブジェクトへのマップ方法を示します。
認可ポリシーの作成、更新および削除方法の詳細は、4.5.5項「認可ポリシーの管理」を参照してください。
アプリケーション・ロールは、ユーザー、グループまたは他のアプリケーション・ロールのコレクションであり、Oracle Entitlements Serverで定義され、ポリシー・ストアに格納されます。アイデンティティ・ストア内のユーザー、グループまたは外部ロール、またはOracle Entitlements Serverポリシー・ストア内の別のアプリケーション・ロールに割り当てることができます。
|
注意: アプリケーション・ロールを別のアプリケーション・ロールに割り当てることで、アプリケーション・ロールの階層を構築できます。 |
アプリケーション・ロールは次のいずれかの方法でユーザーに割り当てることができます。
ロールの特定のユーザー・メンバーシップに静的に付与。
実行時にロール・メンバーシップを動的に割り当てるのに使用されるロール・マッピング・ポリシーのアプリケーション・ロールを参照。
ロール・マッピング・ポリシーにより、ロール・メンバーシップをユーザーに動的に割り当てる(GRANT)か、またはロール・メンバーシップをユーザーから動的に失効する(DENY)ことができます。次のロール・マッピング・ポリシーの定義を考えてみます。
GRANT the Employee group application role SupportManageEast if the request is made from an IP address of 229.188.21.21
このポリシーでは、SupportManagerEastアプリケーション・ロールをグループEmployeeのメンバーであるユーザーに付与します。このポリシーには、IPアドレス229.188.21.21からのリクエストに限られるというオプションの条件による制約もあります。したがって、リクエストのパラメータがロール・マッピング・ポリシーのパラメータと一致し(リクエストしているユーザーはEmployeeグループのメンバーである)、リクエストがIPアドレス229.188.21.21から出された場合、アプリケーション・ロールは付与されます。リクエストが定義されたIPアドレスからではない場合、ロール・マッピング・ポリシーは無視されます。ロール・マッピング・ポリシーには、オプションでターゲットも追加できます。次の用語と値が、このロール・マッピング・ポリシー定義に適用されます。
結果: 付与
アプリケーション・ロール: SupportManagerEast
プリンシパル: Employeeグループのメンバー
条件/制約: IPアドレス229.188.21.21
リソースまたはリソース名式がロール・マッピング・ポリシーのターゲットとして定義されている場合、それがリクエストに定義されているリソースと一致した場合のみ、ロール・マッピング・ポリシーが適用されます。図2-2に、このサンプル・ポリシーのコンポーネントの、Oracle Entitlements Serverロール・マッピング・ポリシー・オブジェクトへのマップ方法を示します。
ロール・マッピング・ポリシーを使用して、特定のユーザーがアプリケーション・ロールに割り当てられるのを防ぐこともできます。次のロール・マッピング・ポリシーの定義を考えてみます。
DENY the Customers group the application role GoldCircle if the account balance is less then $10,000
このポリシーでは、GoldCircleアプリケーション・ロールのCustomersグループのメンバーへの付与は、その口座残高が$10,000に満たない場合は拒否されます。ロール・マッピング・ポリシーの作成、更新および削除方法の詳細は、4.5.7項「ロール・マッピング・ポリシーの管理」を参照してください。
Oracle Entitlements Serverランタイム評価中に、次のことが行われます。
サブジェクトに基づき、次を実行することでアプリケーション・ロールのリストが決定されます。
ユーザーの静的ロール・メンバーシップを取得します。
すべての適用できるロール・マッピング・ポリシーをGRANTの結果で評価し、それを事前に決定されたロールのリストに追加します。
すべての適用できるロール・マッピング・ポリシーをDENYの結果で評価し、それを事前に決定されたロールのリストから削除します。
サブジェクトと取得したアプリケーション・ロールのリストに基づき、認可ポリシーのリストが評価されて、権限受領者、ターゲットの一致と条件に基づいて適用できるポリシーを見つけます。(リソースで許可されるアクションは認可ポリシーで定義されます。)
最終的な認可決定は、アルゴリズムを組み合せた拒否のオーバーライドに基づいており、コール元アプリケーションに返されます。
1.4項「Oracle Entitlements Serverの認可ポリシーの処理方法」にはこの処理についての詳細が含まれています。
この項で定義されているポリシー・オブジェクトは、Authorization Policy Manager管理コンソールを使用して作成、プロビジョニングまたは管理できます。
アプリケーションはロール、ポリシー、リソース定義およびその他のポリシー・オブジェクト(実際には、特定のリソースへのセキュア・アクセスを定義するために必要なすべての項目)を管理するための高レベルのコンテナです。アプリケーションは、配置済の1つのソフトウェア・アプリケーション、配置済のソフトウェア・アプリケーションのセット、またはソフトウェア・アプリケーションのコンポーネント(Enterprise Java Beanなど)に対応します。Oracle Entitlements Serverで、複数のアプリケーションを管理できます。詳細は、4.5.1項「アプリケーションの管理」を参照してください。
アプリケーション・ロールは、ユーザー、グループ、外部ロールまたはその他のアプリケーション・ロールを特定のOracle Entitlements Serverアプリケーション・オブジェクトにマッピングするための条件を定義します。アプリケーション・ロールは、アイデンティティ・ストアの外部ユーザー、グループ、ロールまたはポリシー・ストアの別のアプリケーション・ロールに付与することができます。(ロール・カタログ内で)アプリケーション・ロールを作成する場合は、あるターゲット・リソースへアクセスするために必要なすべての権限をそのロールに付与することができます。次に、メンバーシップを明示的に付与することで、アプリケーション・ロールを静的に割り当てることができます。あるいは、ロール・マッピング・ポリシーでサブジェクトとして参照することで、アプリケーション・ロールを動的に割り当てることができます。1つのターゲット・アプリケーションが複数の異なるアプリケーション・ロールを持ち、より詳細なアクセスを提供する異なる権限のセットをそれぞれのロールに割り当てることが可能です。
1つの外部ロールを複数のアプリケーション・ロールにマップできます。たとえば、(LDAPベースのアイデンティティ・ストア内に格納されている)外部ロールemployeeは、(あるアプリケーションで定義されている)アプリケーション・ロールcustomersupport memberと(別のアプリケーションで定義されている)アプリケーション・ロールIT memberにマップできます。ロール・カタログはアプリケーション・ロールが格納されるコンテナです。詳細は、4.5.6項「ロール・カタログのアプリケーション・ロールの管理」を参照してください。
|
注意: アプリケーションのロール・カタログを使用して、アプリケーション・ロールを編成できます。Oracle Entitlements Server管理コンソールのロール・カタログ・ノードのアプリケーション・ロールを検索します。詳細は、第5章「セキュリティ・オブジェクトの問合せ」を参照してください。 |
属性は、ポリシーの条件で使用できるデータ、またはポリシー決定により責任として返すことができるデータを表します。属性には、組込み属性(現在時刻または現在のユーザーなど、その値が常に定義されている)、リソース属性(構成済Oracle Entitlements Serverリソースに関連付けられ、管理されている)または動的属性があります。属性は、名前、値として使用するデータの型、および値が1つのみかそれとも複数かによって定義されます。属性値は保護されたアプリケーションによって認可リクエストの一部として渡されるか、またはOracle Entitlements Serverによって属性リトリーバを使用して取得されます。詳細は、4.5.9項「属性および関数を拡張として管理」を参照してください。
認可ポリシーでは、保護されたリソース上でエンティティ(権限受領者、プリンシパルまたはコード・ソース)に許可される権限のセットを指定します。たとえば、Webページの表示やレポートの変更などです。つまり、Oracle Entitlements Serverによって保護されたリソースに対して誰が何を実行できるかを指定します。詳細は、4.5.5項「認可ポリシーの管理」を参照してください。
|
注意: 構成されたアプリケーションのデフォルトのポリシー・ドメイン・ノード(または該当する場合はカスタム・ポリシー・ドメイン・ノード)で認可ポリシーを検索します。詳細は、第5章「セキュリティ・オブジェクトの問合せ」を参照してください。 |
条件とは、ポリシーが認可決定に含まれるためにtrueと評価される必要がある1つ以上のブール式のことです。条件をポリシーに追加することはオプションで、使用すると保護リソースへのアクセスがさらに制限されます。一般的に、条件のブール式では、なんらかのユーザー、リソースまたはシステム属性の値をテストします。個々の条件はAND、OR、NOTといった論理演算子を使用して結合できます。条件は、日付、時間、時間範囲、曜日などに基づく制約を定義できます。詳細は、4.6項「条件ビルダーの使用」を参照してください。
資格(権限セットとも呼ばれます)は、リソースの小さなセット、およびタスクを実行するために必要な関連アクションを表します。ビジネス機能を実行するために必要な、タイプが異なる可能性がある関連リソースをグループ化します。資格は、複数のプリンシパルに付与できるアクセス権の再利用可能なコレクションです。詳細は、4.5.4項「資格の管理」を参照してください。
外部ロールは、LDAPサーバーまたはデータベースなどの外部アイデンティティ・ストアで定義されます。外部ロールという用語は、エンタープライズ・ロールまたはエンタープライズ・グループと同義で使用されることもあり、通常はアイデンティティ・ストア内のLDAPグループとして実装されます。外部ロールのポリシーへの追加の詳細は、4.5.5.1項「認可ポリシーの作成」または4.5.7.1項「ロール・マッピング・ポリシーの作成」を参照してください。
|
注意: Oracle Entitlements Server内では、外部ロールおよびユーザーは読取り専用です。これらはOracle Identity Managerなどの別のツールで管理されます。詳細は、『Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイド』を参照してください。 |
関数は、ポリシーの条件評価の一部として起動できるコードを表し、戻り値は条件の評価に影響します。カスタム関数を追加作成することによって、Oracle Entitlements Serverで提供されている関数を拡張できます。詳細は、4.5.9項「属性および関数を拡張として管理」を参照してください。
責任には認可決定のGRANTまたはDENYと一緒に返される追加の情報を指定します。ポリシーで使用すると、責任にはポリシー実行コンポーネントへの追加の要件を設定できるほか、単に有用な情報をリクエストできます。たとえば、アクセスのリクエストが拒否された理由を責任として返すことができます。責任のポリシーへの追加の詳細は、4.5.5.1項「認可ポリシーの作成」を参照してください。
ポリシー・ドメインは、リソース、資格および認可ポリシーの管理を促進するパーティションとして機能できるアプリケーション・オブジェクトの下のコンテナです。ポリシー・ドメインは管理者の権限を特定のリソース、資格、認可ポリシーのサブセットに限定できるオプションの管理構造体です。ポリシー・ドメインはランタイム・ポリシー評価時には無効です。複数のポリシー・ドメインを作成し、階層化できます。デフォルト・ポリシー・ドメインをその作成時に各アプリケーションに追加できます。詳細は、11.4「委任するポリシー・ドメインの使用」を参照してください。
ポリシー・ストアは、すべてのOracle Entitlements Serverポリシー・オブジェクト(アプリケーション、リソースおよび様々なロール・タイプが含まれますがこれに限定されません)が保存される場所です。ポリシー・ストアはリレーショナル・データベース(推奨)またはLDAPベース・ディレクトリのどちらでもかまいません。詳細は、3.2.3項「ポリシー・ストアへのアクセス」を参照してください。
プリンシパルとは、ポリシー内で定義されたアクセス権が付与されるアイデンティティです。プリンシパルには、ユーザー、グループ、外部ロールまたはアプリケーション・ロールを指定できます。ほとんどの場合、アプリケーション・ロールを指定します。プリンシパルのOracle Entitlements Serverポリシーへの追加の詳細は、4.5.5.1項「認可ポリシーの作成」または4.5.7.1項「ロール・マッピング・ポリシーの作成」を参照してください。
リソースは保護されたコンポーネントまたはオブジェクトであり、これに対してアクセス権が付与または拒否されます。リソースは、認可ポリシーで保護されるアプリケーション・コンポーネントまたはビジネス・オブジェクトを表します。アプリケーションは実行時にリソース名を渡して、プリンシパルにアクセスが認可されているかどうかを決定するアクセス定義を確認します。リソースには関連付けられたリソース・タイプが必要です。詳細は、4.5.3項「リソースの管理」を参照してください。
リソース・タイプは、保護されたオブジェクトのタイプを表します。共通の特徴を共有する保護されたソフトウェア・アプリケーション・コンポーネントは、特定のリソース・タイプで表すことができます。たとえば、ページのセットを1つのリソース・タイプで表し、銀行口座を別のリソース・タイプで表すことができます。リソース・タイプでは、適格なリソース属性と、保護されたコンポーネントに適用できる有効なアクションを定義します。詳細は、4.5.2項「リソース・タイプの管理」を参照してください。
ロール・カテゴリはアプリケーション・ロールに関連付けることのできるオプションのタグで、検索に使用できます。ロール・カテゴリを使用すると、管理者はロールを任意のフラット・コレクションに編成できます。これはランタイム・ポリシー評価時には無効です。詳細は、4.5.8項「ロール・カテゴリの管理」を参照してください。
ロール・マッピング・ポリシーは、適用可能なアプリケーション・ロールに割り当てる外部サブジェクト(ユーザー、グループまたは外部ロール)を決定するために使用します。認可ポリシーで参照されているアプリケーション・ポリシーは、認可ポリシーの影響を受けるプリンシパルを定義します。ロール・マッピング・ポリシーでは条件も使用できます。詳細は、4.5.7項「ロール・マッピング・ポリシーの管理」を参照してください。
|
注意: Oracle Entitlements Server管理コンソールのロール・カタログ・ノードでロール・マッピング・ポリシーを検索します。詳細は、第5章「セキュリティ・オブジェクトの問合せ」を参照してください。 |
Oracle Entitlements Serverはポリシー管理とポリシー決定ロジックを組織のリソースから外部化する機能を提供します。組織のリソースへのアクセスを、それらにアクセスできるユーザー、グループおよびロールを指定するポリシーを実装することで保護します。リソースには、アプリケーション・ソフトウェア・コンポーネント(URL、Enterprise JavaBeans、JavaServer Pages)またはエンタープライズ・ビジネス・オブジェクト(顧客の口座、患者のレコード)があります。このユースケースでは、ポリシー・モデルを使用してAcme Investment Bankにより提供される金融サービスを保護する方法について考えてみます。これは階層型リソースの概念に基づきます。つまり、リソースはツリーに編成され、親要素から継承します。
このユースケースでは、次の条件が適用されます。
顧客は家族口座を開くことができ、その口座の所有者とみなされます。
顧客は家族メンバー用の子口座を開き、各メンバーに対し振替限度額を設定できます。振替限度額は顧客自身の振替限度額よりも低い必要があります。
各口座には、口座担当者としての役目を果たし、口座に振替限度額を設定する銀行員がいます。
サマリー・レポートと口座担当者レポートの両方が各家族口座に関連付けられます。
図2-3に、保護リソースをビジネス・オブジェクトとソフトウェア・コンポーネントに編成することによる金融サービスのシナリオを示します。Paulは口座担当者で、管理する口座の振替限度額を$100,000を設定できる銀行員です。Paulは口座の所有者であるBobの家族口座を管理します。この口座の振替限度額は$10,000です。Bobは自分の家族口座と、振替を行わないMary用に作成した子口座を管理します。これらの口座はビジネス・オブジェクトとみなされ、そのように保護されます。
口座所有者のBobには家族口座用に生成されたサマリー・レポートへのアクセス権があります。口座担当者のPaulにはBobのサマリー・レポートと自分の口座管理レポートへのアクセス権があります。子口座の名義人のMaryにはレポートへのアクセス権はありません。これらのレポートはJavaServerページとして生成され、ソフトウェア・コンポーネントとみなされて、そのように保護されます。
指定したユーザーに対し、金融サービスの口座(ビジネス・オブジェクト)または口座レポート(ソフトウェア・コンポーネント)へのアクセスのリクエストでは、次の質問に基づき、決定が生成されます。
このユーザーは口座の名義人、口座の所有者または口座担当者ですか。
このユーザーはこの口座から資金の振替ができますか(ロール、振替限度額、取引時間による)。
このユーザーはどのレポートにアクセスできますか。
最初の2つの質問はビジネス・オブジェクトを保護するために作成されたポリシーを使用して決定できますが、最後の質問はソフトウェア・コンポーネントを保護するために作成されたポリシーを使用して決定できます。次の各項では、ポリシーを概念化する方法について説明します。
図2-3「ソフトウェア・コンポーネントとビジネス・オブジェクトのユースケース」のAccount Reportsノードは、レポーティング・アプリケーションを表しています。Summary.jspおよびDetailed.jspはソフトウェア・コンポーネントです。これらのソフトウェア・コンポーネントを保護するためにポリシーをモデル化する方法を決定するときに、選択するオプションがいくつかあります。1つのオプションは、グループ・メンバーシップを使用することで上位ノードのレポーティング・アプリケーションに認可ポリシーを設定します。次の例で、リソースとそれにアクセスできるユーザーのグループに名前を付けることで、アクセス権を明示的に付与する方法を示します。
GRANT the BankManagers group access to the AccountReports node
このトップダウンの認可ポリシーでは、Account Reportsノードへのアクセス権をBankManagersグループのユーザーに付与します。これらのリソースは階層化されているので、許可されたグループの全員がサマリーおよび詳細レポートにアクセスできます。しかしこのアクセスはシステム・ベースまたは属性ベースの条件を使用して制約されることがあります。たとえば、時間に基づく、または特定のユーザー、グループまたはリソース属性に基づく条件を追加することで、さらにアクセスが制限されます。次の例で、時間ベースの条件によりレポートへのアクセスが通常の営業時間に制限される方法を示します。
GRANT the BankManagers group access to the AccountReports node IF the request is made between 09:00 and 17:00
もう1つのオプションでは、グループではなくロールとしてプリンシパルを定義することでトップダウンの認可ポリシーを設定できます。1つのロールはユーザーまたはグループから構成されます。(アプリケーション・ロールはそれが構成されたアプリケーションに特有であるのに対し、LDAPロールはエンタープライズ全体で付与されます。)
|
注意: 2.1項「Oracle Entitlements Serverポリシーの理解」で説明したように、ユーザーはメンバーシップまたはロール・マッピング・ポリシーを使用してロールに割り当てることができます。 |
次の例では、リソースに明示的に名前が付けられ、アクセス権は定義済のロールに割り当てられているユーザーに暗黙的に付与されます。
GRANT access to AccountReports node if user has BankManagers role
BankManagersロールをレポーティング・アプリケーションにアクセスしているユーザーに(BankManagersグループのメンバーであれば)動的に割り当てることもできます(次に例示)。
GRANT BankManagers role to members of BankManagers group FOR access to AccountReports node
以前の認可ポリシーを定義するもう1つの方法は、グループ・メンバーシップではなくユーザー属性値に基づきロールを割り当てることです。(規模の大きい企業では、グループ・メンバーシップではなく属性に基づきユーザーを割り当てることが通常はより効率的です。)次の例では、ユーザーのプロファイルのUserType属性の値がBankManagerである場合に、BankManagersロールを、リクエストしているユーザーに割り当てます。
GRANT BankManagers role to anyone defined by UserType 'BankManager' FOR access to the AccountReports node
前の例では、上位ノードのレポーティング・アプリケーションからレポートまで範囲とする認可ポリシーを示していますが、認可ポリシーは特定のレポート・ノードに対して定義することもできます。次の例では、Summary.jspレポートへのアクセス権をBankManagersおよびAccountOwnersロールのすべての割当先に付与します。追加の条件は、アクセスをリクエストしているプリンシパルが、レポートの関連アカウントにリストされている必要があることです。
GRANT Summary.jsp access to all members of BankManagers and AccountOwners role IF the requesting assignee is listed as OWNER or MANAGER on specified account
もう1つの例は、Detailed.jspレポートへのアクセスが、BankManagerロールに割り当てられたユーザーに付与できる方法を示しています。
GRANT Detailed.jsp access to all assignees of BankManagers role
前の例は、認可ポリシーが特定のアプリケーション・ソフトウェア・コンポーネントにモデル化できる方法を示しています。実際の企業でのシナリオでは、各アプリケーションに数十または数百のリソースが含まれる場合があるので、それぞれに対して認可ポリシーを作成するのは現実的ではない可能性があります。リソース属性の概念は、このアプリケーション・ソフトウェア・コンポーネント・リソースと関連する認可ポリシーの急増に対処するために、Oracle Entitlements Serverにより実装されました。
リソースと属性を関連付けることで、属性の値に基づきアクセス権を付与することができます。たとえば、filetypeはHTMLページ、イメージまたはPDFを定義するのに使用するリソース属性です。if filetype=pdfとして条件を定義することで、リソースに関連付けられたすべてのPDFファイルへのアクセス権を付与することができます。次の例ではリソース属性を使用します。これにより、リクエストされているレポート・タイプが特定のユーザー・プロファイルのUserReportType属性の値と一致している場合にのみアクセス権が付与されるにもかかわらず、BankManagersおよびAccountOwnersロールに割り当てられたユーザーはすべてのレポートにアクセスできます。
GRANT users assigned BankManagers or AccountOwners roles
access to AccountReports
IF requested ReportType matches UserReportType attribute value
in user profile
このポリシーでは、アクセスがリソース属性値とユーザー属性値の一致に基づいて制約されるにもかかわらず、BankManagersおよびAccountOwnersにすべてのレポートへのアクセス権が付与されます。この方法の利点は、リソースがアプリケーションに追加されたり削除されたりしても、アクセスを管理するポリシーを変更する必要がないことにあります。リソースが変更されても、アプリケーションに付属するReportTypeリソース属性によるアクセスの管理は継続します。
ビジネス・オブジェクトを保護するために認可ポリシーをモデル化する方法を決定するときに、選択するオプションがいくつかあります。この銀行シナリオでは、ビジネス・オブジェクトは銀行口座です。図2-3「ソフトウェア・コンポーネントとビジネス・オブジェクトのユースケース」は、銀行口座の構造を表しています。
各銀行口座に、担当者、所有者、および名義人を、特定の権限のセット(または 資格)に割り当てられた各スコープとともに持たせることができます。そのため、ユーザーが銀行口座で実行できることを評価しているポリシーが基づくのは、リソースではなくユーザーの属性です。次の例では誰でも振替は可能ですが、リクエストされた口座の所有者としてそのユーザーが定義され、振替金額がユーザーに定義された制限額よりも少ないか同じである場合にのみ、その権限が付与されます。
GRANT anyone transfer privileges only IF the user is listed as OWNER on specified account AND transfer amount is equal to or less than the transfer limit
ユーザーの資格を取得する別のオプションがあります。振替のリクエストと振替限度額を比較するのでなく、Oracle Entitlements Serverでは評価の出力として振替限度額を返すことができます。このシナリオでは、ユーザーが口座にアクセスできるかどうかは検証されますが、振替金額が責任としてコール元に返されます(Javaオブジェクト内で)。ここでは、振替金額が振替限度額内であるかどうかの検証はアプリケーションに任されています。次の例で、このモデルを説明します。
GRANT anyone transfer privileges only IF the user is listed as OWNER on specified account THEN RETURN transfer limit to calling application
銀行口座が個別のリソース・インスタンスに対応するモデルを使用することもできますが、ポリシーの急増(口座ごとに1つ)が生じ、管理が難しくなります。たとえば、Acme Investment Bankに100,000口座がある場合、振替を管理するだけで少なくとも100,000ポリシーが必要になります。責任の追加の詳細は、4.5.5項「認可ポリシーの管理」を参照してください。
