プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド
12c (12.2.1.2.0)
E82973-02
目次へ移動
目次

前
前へ
次
次へ

オブジェクト権限の設定

次の手順を使用すると、リポジトリで個々のアプリケーション・ロールのオブジェクト権限を設定して、プレゼンテーション・レイヤーおよびビジネス・モデルとマッピング・レイヤーのオブジェクトへのアクセスを制御できます。

最初にオンライン・モードでアプリケーション・ロールを変更した場合を除き、オフライン・モードを使用している場合は、アプリケーション・ロールは表示されません。「オフライン・モードでのデータ・アクセス・セキュリティの適用について」を参照してください。

  1. 管理ツールでリポジトリを開きます。
  2. 管理」→「アイデンティティ」を選択します。
  3. 「Identity Manager」ダイアログのツリー・ペインで、「BIリポジトリ」を選択します。
  4. 右のペインで「アプリケーション・ロール」タブを選択し、オブジェクト権限を設定するアプリケーション・ロールをダブルクリックします。
  5. 「アプリケーション・ロール」ダイアログで「権限」をクリックします。
  6. 「ユーザー/アプリケーション・ロール権限」ダイアログの「オブジェクト権限」タブで、次のいずれかの手順を実行してオブジェクトを選択します。
    • 「追加」ボタンをクリックし、オブジェクトを見つけて「選択」をクリックします。
    • 空の行の「名前」フィールドをクリックし、オブジェクトを見つけて「選択」をクリックします
  7. 各オブジェクトに対して適切な権限を割り当てます。次のいずれかのオプションを選択できます。
    • 読取り: このオブジェクトに対しては読取りアクセスのみを許可します。
    • 読取り/書込み: このオブジェクトに対しては読取りと書込みの両方のアクセスを提供します。
    • アクセス権なし: このオブジェクトに対してはすべてのアクセスを明示的に拒否します。
  8. OK」をクリックし、再度「OK」をクリックして、Identity Managerに戻ります。

ユーザーおよびアプリケーション・ロールにおける権限の継承について

ユーザーは明示的に付与される権限を持つことができます。また、ユーザーはアプリケーション・ロールのメンバーシップを通じて付与される権限を持つこともできます。さらに、アプリケーション・ロールは他のアプリケーション・ロールのメンバーシップを通じて付与される権限を持つことができます。

ユーザーに対して明示的に付与される権限は、アプリケーション・ロールを通じて付与される権限よりも高い優先度を持ちます。また、アプリケーション・ロールに対して明示的に付与される権限は、他のアプリケーション・ロールを通じて付与される権限よりも高い優先度を持ちます。

ユーザーまたはアプリケーション・ロールに対して、同じレベルで複数のアプリケーション・ロールが作用し、それらが競合するセキュリティ属性を持つ場合、このユーザーまたはアプリケーション・ロールには最も制限の少ないセキュリティ属性が付与されます。今では、あるオブジェクトへのアクセス権を持つアプリケーション・ロールは、オブジェクトのコンテナへのアクセス権も持つ必要があります。たとえば、ApplicationRole 1が表Bに属する列Aにアクセスする権限を持っている場合、ApplicationRole1は表Bにアクセスする権限も持つ必要があります。ある同一のオブジェクトに関して、ユーザーに対して明示的に作用する権限は、アプリケーション・ロールを通じてユーザーに付与される権限よりも高い優先度を持ちます。

以前のリリースでは、前述のとおり、オブジェクトのコンテナへのアクセス権がアプリケーション・ロールに要求されることはありませんでした。その動作に戻すには、Oracle BIサーバーマシンに移動し、環境変数OBIS_SECURITY_10g_COMPATIBLEを作成して、1に設定します。

一方で、フィルタ定義は常に継承されます。たとえば、User1がRole1およびRole2のメンバーであり、Role1にはフィルタ定義が含まれておりRole2には含まれていない場合、このユーザーはRole1に定義されているフィルタ定義を継承します。

オブジェクト権限は、個々のユーザーにではなく、常にアプリケーション・ロールに対して定義するようにしてください。

この結果、権限は次のようになります。

  • User1はRole1およびRole2の直接のメンバーであり、Role3、Role4およびRole5の間接的なメンバーです。

  • Role5の優先度レベルはRole2よりも低いため、Role5によって課されるTableAへのアクセス拒否は、Role2を通じて付与される読取り権限によって無効になります。この結果、Role2によってTableAに対する読取り権限が提供されます。

  • Role1から得られる権限は、TableAではアクセス権なし、TableBでは読取り、TableCでは読取りとなります。

  • Role1とRole2は同じレベルの優先度を持ち、それぞれの権限は相反する(Role1ではTableAへのアクセスが拒否され、Role2ではTableAへのアクセスが許可される)ため、User1はより制限の少ないレベルを継承することになります。つまり、User1はTableAの読取りアクセス権を持つことになります。

  • User1に対して総合的に付与される権限は、TableA、TableBおよびTableCの読取りアクセス権です。

権限の継承1

1人のユーザー(User1)がおり、このユーザーにはある表(TableA)の読取り権限が明示的に付与されているとします。また、このUser1はRole1のメンバーであり、Role1はTableAへのアクセスが明示的に拒否されているとします。結果として得られるUser1の権限は、TableAの読取り権限です。

ユーザーに直接付与される権限はアプリケーション・ロールを通じて付与される権限よりも高い優先度を持つため、User1はTableAの読取り権限を持ちます。