| Oracle® Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド 12c (12.2.1.3.0) E80600-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド 12c (12.2.1.3.0) E80600-02 |
|
|
前 |
次 |
次のトピックが含まれています:
Oracle Fusion Middlewareセキュリティ・モデルは、Javaセキュリティ・モデルを組み込んだ、Oracle Fusion Middlewareプラットフォームに基づいています。
Javaモデルは、ロールベースの宣言モデルで、コンテナ管理のセキュリティを採用しているため、リソースは、ユーザーに割り当てられているロールによって保護されます。しかし、Oracle Fusion Middlewareセキュリティ・モデルを使用するときは、Javaベースのアーキテクチャに関する高度な知識は不要です。セキュリティ・モデルを使用するときには、BI Publisherによって、企業全体にわたる共通のセキュリティおよびID管理機能が提供されます。
インストール後、BI Publisherは自動的にOracle WebLogic Serverドメインにインストールされます。このドメインは、論理的に関連付けられ、一体となって管理される、WebLogic Serverリソースのグループです。簡易インストールでは、インストール後、作成されたWebLogic Serverドメインはbifoundation_domainという名前になります。この名前は、実行するインストール・タイプによって変わる可能性があります。各ドメインでは、1つのWebLogic Serverインスタンスが管理サーバーとして構成されます。管理サーバーではWebLogic Serverドメインを一元的に管理できます。管理サーバーでは管理コンソールがホストされます。管理コンソールは、管理サーバーへのネットワーク・アクセスを持ち、サポートされたWebブラウザであればどのブラウザからでもアクセス可能なWebアプリケーションです。BI Publisherは、インストール先のOracle WebLogic Serverドメインに構成されているアクティブなセキュリティ・レルムの一部となります。
『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。Oracle WebLogic Serverドメインとセキュリティ・レルムの管理の詳細は、『Oracle WebLogic Serverセキュリティの理解』および『Oracle WebLogic Serverセキュリティの管理』を参照してください。
Oracle Fusion Middlewareセキュリティ・モデルは、主な要素に基づいて会社全体でセキュリティとIDの統一的な管理を提供します
次の主な要素があります。
アプリケーション・ポリシー
BI Publisherの権限は、そのアプリケーション・ロールのメンバーに付与されます。デフォルトのセキュリティ構成では、事前定義済の権限のセットが各アプリケーション・ロールによって伝達されます。権限の付与は、アプリケーション・ポリシーで定義および管理されます。アプリケーション・ロールがアプリケーション・ポリシーと関連付けられると、そのロールはポリシーの権限受領者となります。アプリケーション・ポリシーは、特定のアプリケーションに固有のものです。
アプリケーション・ロール
権限の付与についてアプリケーション・ポリシーで定義されると、アプリケーション・ロールをそのポリシーにマップできるようになり、そのアプリケーション・ロールが権限を伝達するためのメカニズムとして機能するようになります。この方式では、アプリケーション・ロールが、そのメンバーに権限を付与するコンテナとなります。権限は、ポリシーとロール間の関係を通じてアプリケーション・ロールと関連付けられます。グループがアプリケーション・ロールにマップされると、対応する権限がすべてのメンバーに同じように付与されます。メンバーシップは、アプリケーション・ロールの定義において定義されます。アプリケーション・ロールは、特定の条件に従って割り当てられ、認証時の条件に基づいて動的に付与されます。複数のユーザーやグループが同じアプリケーション・ロールのメンバーになることがあります。
認証プロバイダ
認証プロバイダは、ユーザーやグループの情報にアクセスするために使用され、ユーザーを認証する役割を持っています。BI Publisherが簡易インストールまたはエンタープライズ・インストールで使用するデフォルトの認証プロバイダは、DefaultAuthenticatorという名前のものです。これは、Oracle WebLogic Serverの基本インストールで使用されるのと同じものです。Oracle WebLogic Server認証プロバイダにより、ユーザーとグループを1つの場所で管理できるようになります。
アイデンティティ・ストアには、ユーザー名、パスワードおよびグループ・メンバーシップの情報が含まれています。認証プロバイダは、アイデンティティ・ストアのデータにアクセスし、そのデータと照合しながら認証を行います。たとえば、ログイン時にユーザー名とパスワードの組合せを入力すると、認証プロバイダは、提供された資格証明を検証するためにアイデンティティ・ストアを検索します。BI Publisherのデフォルトの認証プロバイダは、Oracle WebLogic Serverの埋込みディレクトリ・サーバーと照合しながら認証を行います。
ユーザーとグループ
ユーザーとは、認証可能なエンティティです。ユーザーには、アプリケーション・ユーザーなどの人、クライアント・アプリケーションなどのソフトウェア・エンティティがあります。各ユーザーには一意の識別子が割り当てられます。
グループは、何かしら共通するものを持つユーザーを集合にまとめたものです。セキュリティ管理をより効率化するには、同じようなアクセス権を必要とするグループごとにユーザーをまとめる必要があります。
セキュリティ・レルム
インストール時に、Oracle WebLogic Serverドメインが作成され、BI Publisherがそのドメインにインストールされます。BI Publisherのセキュリティは、そのOracle WebLogic Serverドメインのセキュリティ・レルム内で管理されます。セキュリティ・レルムは範囲指定メカニズムとして機能します。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます。ドメインでは1つのセキュリティ・レルムだけがアクティブになります。BI Publisherの認証は、パブリッシャがインストールされたWebLogic Serverドメインのデフォルトのセキュリティ・レルムに対して構成された認証プロバイダにより実行されます。Oracle WebLogic Server管理コンソールは、Oracle WebLogic Serverドメインの管理に使用される管理ツールです。
BI Publisherには、様々な機能にアクセスするためのアプリケーション固有の権限が用意されています。
BI Publisherの権限は通常、アプリケーション・ロールのメンバーになることにより付与されます。権限は、2つの方法で付与されます。アプリケーション・ロールでメンバーシップを通じて付与する方法(直接的な付与)と、グループやロールの継承を通じて付与する方法(間接的な付与)です。アプリケーション・ロールのメンバーシップは、アプリケーション・ロール階層の特性によって継承されることができます。デフォルトのセキュリティ構成では、各アプリケーション・ロールは、事前定義済の一連の権限を付与するようにあらかじめ構成されています。グループは、アプリケーション・ロールにマップされます。グループとロールのマッピングにより、ロールの権限がグループのすべてのメンバーに伝達されます。つまり、権限はBI Publisherで次の関係を確立することにより付与されます。
グループによって、同様のシステム・アクセス要件を持つユーザーの組が定義されます。ユーザーは、必要なアクセスのレベルに応じ、1つ以上のグループのメンバーとして追加されます。
アプリケーション・ロールは、ユーザーがBI Publisherを使用するときに一般的に実行するロールを示すように定義されます。デフォルトのセキュリティ構成では、事前構成済のアプリケーション・ロールとして、BIServiceAdministrator (管理者)、BIContentAuthor (コンテンツの作成者)およびBIConsumer (コンテンツのコンシューマ)が用意されています。
ユーザーのグループは、それらのユーザーが必要とするアクセスの種類に応じて1つ以上のアプリケーション・ロールにマップされます。
アプリケーション・ポリシーが作成されると、ロール・タイプに対応する一連のアクセス権を付与するBI Publisherの権限がマップされます。
アプリケーション・ロールは、ロール・タイプ(管理者、作成者、コンシューマ)で必要とされる権限のセットを付与するアプリケーション・ポリシーにマップされます。
グループ・メンバーシップは、グループ階層の性質によって継承できます。継承されるグループにマップされるアプリケーション・ロールも継承され、それらの権限は同様にメンバーに伝達されます。
ユーザーの権限は、システムによって次のように決定されます。
ユーザーは、ログイン時にWebブラウザに資格証明を入力します。ユーザー資格証明は、認証プロバイダにより、アイデンティティ・ストア内のデータと照合して認証されます。
認証に成功したら、Javaサブジェクトとプリンシパルの組合せが発行され、ユーザー名とユーザーのグループが入力されます。
ユーザー・グループのリストが作成され、アプリケーション・ロールと照合してチェックされます。各ユーザー・グループにマップされたアプリケーション・ロールのリストが作成されます。
付与されるユーザー権限は、ユーザーがどのアプリケーション・ロールのメンバーであるかを把握することによって決定されます。グループのリストは、ユーザーがどのロールを持っているかを判断するためだけに生成され、他の目的には使用されません。
ユーザーは、他のアプリケーション・ロールを継承する場合にも、権限を付与されます。アプリケーション・ロールのメンバーには、他のグループやアプリケーション・ロールも含まれます。そして、結果的には、権限が明示的に付与されるほかに継承もされる、階層ロール構造となります。この階層では、そのアプリケーション・ロールがメンバーとして属しているロールの権限、およびそのアプリケーション・ロールの子孫であるすべてのロールにより付与される権限がグループに付与されることになります。
たとえば、デフォルトのセキュリティ構成には、いくつかのグループとアプリケーション・ロールが事前定義されています。デフォルトのBIServiceAdministratorアプリケーション・ロールにはBIAdministratorsグループ、BIContentAuthorアプリケーション・ロールにはBIAuthorsグループ、およびBIConsumerアプリケーション・ロールにはBIConsumersグループが含まれています。デフォルトのBIServiceAdministratorアプリケーション・ロールはBIContentAuthorアプリケーション・ロールのメンバーであり、BIContentAuthorアプリケーション・ロールはBIConsumerアプリケーション・ロールのメンバーです。これらのアプリケーション・ロールのメンバーは、次のように権限を継承します。BIAdministratorsグループのメンバーには、BIServiceAdministratorロール、BIContentAuthorロールおよびBIConsumerロールのすべての権限が付与されます。このロール階層の特性に基づき、特定のグループのメンバーであるユーザーには、権限が明示的に付与されるほか、継承を通じて付与されます。デフォルトのアプリケーション・ロールとグループの詳細は、「デフォルトのアプリケーション・ロールと権限」を参照してください
注意:
アプリケーションによって管理されるリソースにアクセスするための権限は、グループやグループ階層自体により有効化されるわけではありません。権限は権限の付与により伝達され、アプリケーション・ポリシーで定義されます。ユーザー、グループまたはアプリケーション・ロールは、アプリケーション・ポリシーの権限受領者となります。アプリケーション・ポリシーの権限受領者により権限が伝達されますが、これは、直接のアソシエーション(ユーザー)によって、または権限受領者(グループまたはアプリケーション・ロール)のメンバーになることによって実行されます。
次の図は、デフォルトのグループとアプリケーション・ロールの関係を示しています。
次の表は、前の例や図で示した権限がどのようにして明示的に付与され、継承されるかをまとめたものです。
| ユーザー名 | グループ・メンバーシップ: 明示的/継承 | アプリケーション・ロールのメンバーシップ: 明示的/継承 | 権限付与: 明示的/継承 |
|---|---|---|---|
User1、User2、User3 |
BIConsumers: 明示 |
BIConsumer: 明示 |
権限A: 明示 |
User4、User5 |
BIAuthors: 明示BIConsumers: 継承 |
BIContentAuthor: 明示、BIConsumer: 継承 |
権限B: 明示権限A: 継承 |
User6、User7 |
BIAdministrators: 明示BIAuthors: 継承BIConsumers: 継承 |
BIServiceAdministrator: 明示、BIContentAuthor: 継承、BIConsumer: 継承 |
権限C: 明示権限B: 継承権限A: 継承 |
システム・リソースのアクセス制御は、ログイン時の認証をユーザーに要求し、認証されたリソースにのみユーザーがアクセスできるよう制限することによって実現されます。
デフォルトのセキュリティ構成は、BI Publisherのインストール後すぐに使用可能であり、Oracle Fusion Middlewareセキュリティ・モデルを使用するように構成されています。BI Publisherは、Oracle WebLogic Serverドメインにインストールされ、そのドメインのセキュリティ・レルムを使用します。デフォルトの構成には、ユーザー・アイデンティティ、資格証明およびBI Publisher固有の権限付与が可能な3つの事前定義済セキュリティ・ストアが含まれています。ユーザーは、事前構成済のアプリケーション・ロールにマップされた事前定義済グループに追加できます。各アプリケーション・ロールは、特定のBI Publisher権限を付与するように事前構成されています。
BI Publisherのデフォルトのセキュリティ・ストアは、インストール時に次の表のように構成されます。
| ストア名 | 用途 | デフォルト・プロバイダ | オプション |
|---|---|---|---|
アイデンティティ・ストア |
|
|
BI Publisherが代替の認証プロバイダを使用するように構成できます。詳細なリストは、「システム要件と動作要件」を参照してください。 |
ポリシー・ストア |
|
|
BI PublisherがOracle Internet Directoryをポリシー・ストア・プロバイダとして使用するように構成できます。 |
資格証明ストア |
提供された、またはシステムにより生成された、パスワードおよびその他のセキュリティ関連の資格証明を格納 |
|
BI PublisherがOracle Internet Directoryを資格証明ストア・プロバイダとして使用するように構成できます。 |
管理ユーザーはOracle WebLogic Server管理コンソールを使用して、ユーザーとグループのデフォルト名を別の値に変更したり、新しい名前を追加することができます。
次の表には、BI Publisherのアイデンティティ・ストア・プロバイダのインストール後にそのプロバイダに追加されるデフォルトのユーザー名とパスワードがリストされています。
| デフォルトのユーザー名とパスワード | 用途 | 説明 |
|---|---|---|
名前: 管理者ユーザー パスワード: ユーザーが指定 |
管理ユーザー |
このユーザー名はインストールを実行する人が入力し、任意の名前でもよく、管理者という名前である必要はありません。 インストール時に入力されたパスワードは、アイデンティティ・ストア・プロバイダの管理インタフェースを使用して後で変更できます。 この単一の管理ユーザーは、BI PublisherとOracle WebLogic Serverで共有されます。このユーザーは、インストール後にOracle WebLogic Serverのデフォルトの管理者グループのメンバーに自動的になります。これにより、このユーザーは、Oracle WebLogic Serverの埋込みディレクトリ・サーバーの管理など、Oracle WebLogic Serverのすべての管理タスクを実行できるようになります。 |
BI Publisherのインストール中にデフォルトのグループは作成されません。
BI Publisherの権限は特定のロール別に付与されます。権限は、グループやアプリケーション・ロールの階層から継承される場合もあります。
次の表は、これらの権限を付与するBI Publisherの権限とアプリケーション・ロールを示しています。このマッピングは、デフォルトのポリシー・ストアに存在します。
この表は、対応するデフォルトのアプリケーション・ロールのメンバーとなることで明示的に付与される権限を示しています。権限は、グループやアプリケーション・ロールの階層から継承される場合もあります。権限の継承の詳細は、「権限の付与と継承」を参照してください。
| BI Publisherの権限 | 説明 | 権限を明示的に付与するデフォルトのアプリケーション・ロール |
|---|---|---|
oracle.bi.publisher.administerServer |
「管理」ページにアクセスする管理リンクを有効にして、システム設定を行う権限を与えます。 重要: 共有フォルダのBIServiceAdministrator権限の付与に必要な追加手順の詳細は、「BIServiceAdministratorロール・カタログ権限の付与」を参照してください。 |
BIServiceAdministrator |
oracle.bi.publisher.developDataModel |
データ・モデルを作成または編集する権限を付与します。 |
BIContentAuthor |
oracle.bi.publisher.developReport |
レポート、スタイル・テンプレート、およびサブ・テンプレートを作成または編集する権限を付与します。また、この権限によってBI PublisherサーバーにTemplate Builderから接続できるようになります。 |
BIContentAuthor |
oracle.bi.publisher.runReportOnline |
レポートを開き(実行し)、生成したドキュメントをレポート・ビューアに表示する権限を付与します。 |
BIConsumer |
oracle.bi.publisher.scheduleReport |
ジョブを作成または編集したり、ジョブを管理および参照する権限を付与したりします。 |
BIConsumer |
oracle.bi.publisher.accessReportOutput |
ジョブ履歴と出力を参照し管理する権限を付与します。 |
BIConsumer |
暗黙的に付与されるBIConsumer権限 |
認証ロールは、デフォルトではBIConsumerロールのメンバーであり、すべての認証ロール・メンバーには、BIConsumerロールの権限が暗黙的に付与されます。 |
認証済ロール |
認証ロールは、Oracle Fusion Middlewareセキュリティ・モデルで提供される特別なアプリケーション・ロールであり、このセキュリティ・モデルをデプロイするすべてのアプリケーションで使用できる必要があります。BI Publisherは、認証アプリケーション・ロールを使用して、その認証ロールがメンバーとして属しているロールおよびグループ階層により暗黙的に取得される権限を付与する必要があります。認証ロールは、デフォルトではBIConsumerロールのメンバーであり、すべての認証ロール・メンバーには、BIConsumerロールの権限が暗黙的に付与されます。デフォルトでは、すべての認証ユーザーは自動的にBIConsumersグループに追加されます。認証ロールはobiアプリケーション・ストライプに格納され、BI Publisherのポリシー・ストアでは検索できません。ただし、認証ロールはポリシー・ストアの管理インタフェースには表示されます。これをアプリケーション・ロールのリストで使用し、別のアプリケーション・ロールのメンバーとして追加することができます。認証ロールは、別のユーザー、グループまたはアプリケーション・ロールにマップできますが、認証ロール自体を削除することはできません。認証済ロールを削除すると、システムにログインできなくなり、この権利の明示的な付与が必要になります。
Oracle Fusion Middlewareのセキュリティ・モデルおよび認証済ロールの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。
BIServiceAdministratorロールには、カタログの読取り権限のみがデフォルトで付与されます。
つまり、BIServiceAdministratorが共有フォルダを管理するには、BIServiceAdministratorロールに共有フォルダ・ノードの書込みおよび削除権限が付与されている必要があります。カタログにおける権限の付与の詳細は、「カタログ権限の付与」を参照してください。
認証とは、ユーザーが身元を偽っていないことを確認してアイデンティティを検証するプロセスのことです。Oracle WebLogic Serverの埋込みディレクトリ・サーバーは、デフォルトのセキュリティ構成の認証プロバイダです。
ユーザー、グループおよびパスワードは、Oracle WebLogic Server管理コンソールを使用して管理されます。環境の開発やテストにはデフォルトの認証プロバイダを使用するとよいでしょう。本番環境でのベスト・プラクティスは、フル機能の認証プロバイダを使用することです。
注意:
ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、システム要件と動作要件のドキュメントを参照してください。いずれのドキュメントもOracle Technology Network (OTN)から入手できます。
インストール中にOracle WebLogic Serverドメインが作成されます。BI Publisherがそのドメインにインストールされ、Oracle WebLogic Serverのセキュリティ・レルムを使用します。セキュリティ・レルムには、複数の認証プロバイダを構成しておくことができますが、一度に1つのプロバイダのみがアクティブになることができます。その優先度は、リスト内のプロバイダの順序によって決まります。セキュリティ・レルムに認証プロバイダを多数定義しておくことで累積的な効果がもたらされるというわけではなく、リスト内の最初のプロバイダが、認証で必要とされるユーザーやパスワードの全データの情報源となります。この方法により、必要に応じて認証プロバイダを切り替えられるようになります。たとえば、開発環境と本番環境で異なるLDAPサーバーを必要とする場合は、認証に使用されるディレクトリ・サーバーを、管理コンソールで順番を並べ替えることによって変更できます。異なる認証プロバイダの構成方法の詳細は、「新しい認証プロバイダの構成」を参照してください。
Oracle WebLogic Serverでの認証プロバイダの管理の詳細は、オンライン・ヘルプを参照してください。詳細は、Oracle WebLogic Server管理コンソールにログインして、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを起動します。
Oracle WebLogic Serverは自動的にインストールされ、デフォルト管理サーバーとして機能します。
管理コンソールはブラウザベースで、デフォルト認証プロバイダとして構成されている埋込みディレクトリ・サーバーの管理に使用されます。これは、URLをWebブラウザに入力することにより起動されます。デフォルトURLの形式は、http://hostname:port_number/consoleのようになります。ポート番号は、管理サーバーの番号です。デフォルトのポート番号は7001です。
Oracle WebLogic Server管理コンソールを起動するには:
たとえば、http://hostname:7001/consoleです。次の図に示すように、管理コンソールのログイン・ページが表示されます。
このパスワードは、BI Publisherのインストール時に指定したものです。これらの値が変更されている場合は、現在の管理ユーザーの名前とパスワードを入力します。
次の図に示すように、管理コンソールが表示されます。
グループを管理することは、多数のユーザーを個々に管理するより効率的です。ベスト・プラクティスとしては、最初にBI Publisherのすべてのユーザーを、同様のシステム・アクセス要件を持つグループにまとめます。
その後、それらのグループを、適切なレベルのアクセスが提供されるアプリケーション・ロールにマップできます。システム・アクセス要件が変更される場合には、アプリケーション・ロールで付与される権限を変更するか、適切な権限を持つ新たなアプリケーション・ロールを作成するだけで済みます。グループが作成された後も、通常どおりに管理インタフェースを使用してアイデンティティ・ストアのユーザー・ディレクトリを追加または削除できます。
デフォルトのディレクトリ・サーバーでユーザーを作成するには:
Oracle WebLogic Server管理コンソールを起動します(その必要がある場合)
「Oracle WebLogic管理コンソールへのアクセス」を参照してください。
管理ユーザーとしてログインします。
管理コンソールの左のパネルで「セキュリティ・レルム」を選択して、構成しているセキュリティ・レルムをクリックします。たとえば、myrealmです。
「ユーザーとグループ」タブ→「ユーザー」を選択します。「新規」をクリックします。
「新しいユーザーの作成」ページ(後に示す)で、次の情報を指定します。
名前: ユーザーの名前を入力します。無効な文字のリストは、オンライン・ヘルプを参照してください。
(オプション)説明: 説明を入力します。
プロバイダ: ユーザー情報の場所に対応する認証プロバイダをリストから選択します。DefaultAuthenticatorは、デフォルト認証プロバイダの名前です。
パスワード: 8文字以上の長さで、ユーザーのパスワードを入力します。
パスワードの確認: ユーザー・パスワードを再入力します。
「OK」をクリックします。
ユーザー名は、User表に追加されます。
デフォルト・ディレクトリ・サーバーでグループを作成するには:
Oracle WebLogic Server管理コンソールを起動します(その必要がある場合)
「Oracle WebLogic管理コンソールへのアクセス」を参照してください。
管理ユーザーとしてログインします。
管理コンソールの左のパネルで「セキュリティ・レルム」を選択して、構成しているセキュリティ・レルムをクリックします。たとえば、myrealmです。
「ユーザーとグループ」タブ→「グループ」を選択します。「新規」をクリックします。
「新しいグループの作成」ペインで、次の情報を指定します。
名前: グループの名前を入力します。グループ名は、大文字と小文字が区別され、一意である必要があります。無効な文字のリストは、オンライン・ヘルプを参照してください。
(オプション)説明: 説明を入力します。
プロバイダ: グループ情報の場所に対応する認証プロバイダをリストから選択します。DefaultAuthenticatorは、デフォルト認証プロバイダの名前です。
「OK」をクリックします。
グループ名は、Group表に追加されます。
ユーザーをデフォルト・ディレクトリ・サーバーのグループに追加するには:
Oracle WebLogic Server管理コンソールを起動します(その必要がある場合)
「Oracle WebLogic管理コンソールへのアクセス」を参照してください。
管理ユーザーとしてログインします。
管理コンソールの左のパネルで「セキュリティ・レルム」を選択して、構成しているセキュリティ・レルムをクリックします。たとえば、myrealmです。
次の図に示すように、「ユーザーとグループ」タブ、「ユーザー」の順に選択します。「名前」からユーザーを選択します。
「設定」ページから、「グループ」タブを選択して使用可能なグループのリストを表示します。
次に示すように、1つ以上のグループを「使用可能」リストから選択し、シャトル・コントロールを使用してそれらのグループを「選択済み」リストに移動します。
「保存」をクリックします。
ユーザーがグループに追加されます。
デフォルトのディレクトリ・サーバーでユーザー・パスワードを変更するには:
次に示すように、ユーザーの設定ページが表示されます。
ユーザーが認証された後のBI Publisherリソースへのアクセスは権限(認可)により制御されます。
ポリシー・ストアには、BI Publisherに必要な、システムやアプリケーションに固有のポリシーとロールが含まれます。ポリシー・ストアは、ファイルベースであってもLDAPベースであっても問題はなく、BI Publisherのデフォルトのアプリケーション・ロール、権限、ユーザーおよびグループ間のマッピング定義を保持します。BI Publisherの権限は、アイデンティティ・ストアのユーザーとグループをポリシー・ストア内のアプリケーション・ロールや権限付与とマッピングすることにより付与されます。ユーザーやグループ(アイデンティティ・ストア)とアプリケーション・ロール(ポリシー・ストア)との間のこれらマッピング定義は、ポリシー・ストアにも保存されます。
注意:
ベスト・プラクティスは、個々のユーザーではなくグループをアプリケーション・ロールにマップすることです。グループのメンバーシップを制御することで、複数のユーザーのアクセス権を個々に追跡する場合の複雑さを軽減できます。グループ・メンバーシップは、アイデンティティ・ストアで制御されます。
system-jazn-data.xmlファイルは、デフォルトのポリシー・ストアとしてインストールおよび構成されます。デフォルトのストアを使用し続け、環境に応じて必要な変更を加えることも、データをLDAPベースのプロバイダに移行することもできます。このリリースでは、Oracle Internet DirectoryがLDAPサーバーとしてサポートされています。
環境内のポリシー・ストアと資格証明ストアは、同じタイプのものである必要があります。つまり、どちらもファイルベースであるか、LDAPベースである必要があります。
権限は、BI Publisherが認識可能な方法で定義される必要があります。有効なBI Publisherの権限はすべて、アプリケーション・ポリシーに事前マップされており、そこからさらにデフォルトのアプリケーション・ロールに事前マップされています。ポリシー・ストアに新しい権限を作成することはできません。ただし、デフォルトのアプリケーション・ポリシーの権限付与やアプリケーション・ロールのマッピングをカスタマイズしたり、独自のものを作成することはできます。
デフォルトのBI Publisherの権限付与の詳細は、「デフォルトのアプリケーション・ロールと権限」を参照してください。アプリケーション・ロールと権限付与のカスタマイズの詳細は、「ポリシー・ストアのカスタマイズ」を参照してください。
Fusion Middleware Controlは、ファームの監視および管理に使用できるWebブラウザベースのグラフィカル・ユーザー・インタフェースです。
ファームとは、Fusion Middleware Controlで管理されるコンポーネントの集まりです。複数のOracle WebLogic Serverドメイン、1つの管理サーバー、1つ以上の管理対象サーバー、クラスタのほか、ドメインにインストールおよび構成されていて、実行されているOracle Fusion Middlewareのコンポーネントが含まれます。インストール中に、Oracle WebLogicドメインが作成され、BI Publisherがドメインにインストールされます。簡易インストールおよびエンタープライズ・インストールを実行した場合、このドメインはbifoundation_domainという名前で、Fusion Middleware Controlのターゲット・ナビゲーション・ペインのWebLogicドメイン内に配置されます。
WebブラウザにURLを入力してFusion Middleware Controlを起動します。URLには、ホストの名前とインストール時に割り当てられた管理ポート番号が含まれます。このURLの形式はhttp://hostname:port_number/emのようになります。デフォルトのポートは7001です。Fusion Middleware Controlの使用の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
Fusion Middleware Controlの「セキュリティ」メニューを表示するには:
ファイルベースまたはLDAPベースのポリシー・ストアに保持されているBI Publisherのアプリケーション・ポリシーやアプリケーション・ロールを管理するには、Fusion Middleware Controlを使用します。
LDAPベース・ポリシー・ストアの構成の詳細は、「新しいポリシー・ストアと資格証明ストアの構成」を参照してください。
注意:
オリジナルのsystem-jazn-data.xmlポリシー・ファイルのコピーを作成して安全な場所に置いておくことをお薦めします。必要に応じて、元のファイルのコピーを使用してデフォルトのポリシー・ストア構成をリストアします。デフォルトのセキュリティ構成に対する変更は、望ましくない状態を引き起こす可能性があります。デフォルトのインストール場所はMW_HOME/user_projects/domain/your_domain/config/fmwconfigです。
一般的なポリシー・ストア管理タスクを次に示します。
アプリケーション・ロールのメンバーシップを変更します。「アプリケーション・ロールのメンバーシップの変更」を参照してください。
アプリケーション・ロールの権限付与を変更します。「アプリケーション・ポリシーの権限付与の変更」を参照してください。
新しいアプリケーション・ロールを最初から作成します。「Fusion Middleware Controlを使用したアプリケーション・ロールの作成」を参照してください。
既存のアプリケーション・ロールに基づいて新しいアプリケーション・ロールを作成します。「Fusion Middleware Controlを使用したアプリケーション・ロールの作成」を参照してください。
Fusion Middleware Controlを使用してアプリケーション・ロールのメンバーを追加または削除できます。
これらのタスクは、BI PublisherがインストールされているWebLogicドメインで実行する必要があります。たとえばbifoundation_domainなどです。
注意:
デフォルト・アプリケーション・ロールの権限付与およびメンバーシップを変更する場合は、十分注意してください。変更によりシステムが使用不可能になる可能性があります。
システムにより使用される資格証明は、単一のセキュアな資格証明ストアに格納されます。Oracle Walletがデフォルトの資格証明ストア・ファイルです(cwallet.sso)。
資格証明ストアは、LDAPベースであっても構いません。Oracle Internet DirectoryがこのリリースでサポートされているLDAPサーバーです。Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTのコマンドを使用して、LDAPベースの資格証明ストアを構成および管理できます。
各資格証明は、マップ名とキー名により一意に識別されます。各マップには一連のキーが含まれており、各キーが資格証明となります。マップ名とキー名の組合せは、資格証明ストアのすべてのエントリに対して一意である必要があります。
BI Publisherでは、次の資格証明マップがサポートされます。
oracle.bi.system: BI Publisherプラットフォーム全体にわたる資格証明が含まれます。
oracle.bi.publisher: BI Publisherのみによって使用される資格証明が含まれます。
BI Publisherでは、次の資格証明タイプがサポートされます。
パスワード: ユーザー名とパスワードをカプセル化します。
汎用: 公開鍵証明書などの、カスタマイズされたデータや任意のトークンがすべてカプセル化されます。
開発環境をすぐに使用できるようにするため、インストール時にデフォルトの資格証明がファイルベースの資格証明ストアに追加されます。ユーザー・パスワードなどのBI Publisherの資格証明は、アイデンティティ・ストアに格納され、対応する管理インタフェースで管理されます。
Oracle Business Intelligenceをデータ・ストアとして使用している場合、BI PublisherはBIシステム・ユーザーとしてOracle Business Intelligenceとのシステム通信を確立します。
Oracle Business Intelligenceは信頼性のあるシステム通信にBIシステム・ユーザーを使用します。資格証明ストア(oracle.bi.system credential map)でBIシステム・ユーザーのパスワードを変更するには、『Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
デフォルトのセキュリティ構成を様々な方法でカスタマイズできます。
新しい認証プロバイダを構成します。「新しい認証プロバイダの構成」を参照してください。
新しいポリシー・ストアと資格証明ストア・プロバイダを構成します。「新しいポリシー・ストアと資格証明ストア・プロバイダの構成」を参照してください。
ポリシーと資格証明を、1つのストアから別のストアに移行します。「ポリシー・ストアおよび資格証明ストアの再関連付け」を参照してください。
新しいアプリケーション・ロールを作成します。「Fusion Middleware Controlを使用したアプリケーション・ロールの作成」を参照してください。
新しいアプリケーション・ポリシーを作成します。「Fusion Middleware Controlを使用したアプリケーション・ポリシーの作成」を参照してください。
アプリケーション・ポリシーに対する権限付与を変更します。「アプリケーション・ポリシーの権限付与の変更」を参照してください。
サポートされている別のLDAPサーバーを認証プロバイダとして構成することもできます。
Oracle WebLogic Server管理コンソールを使用して、BI Publisherでかわりの外部アイデンティティ・ストアが実行されるように構成します。BI Publisherは認証とユーザー移入管理を、BI Publisherが属するドメインに対して構成されている認証プロバイダとアイデンティティ・ストアに委任します。たとえば、Oracle WebLogic Serverのデフォルトの認証プロバイダを使用するように構成されている場合は、Oracle WebLogic Server管理コンソールで管理が実行されます。Oracle Internet Directory(OID)を使用するように構成されている場合は、OID管理ユーザー・インタフェースが使用されます。
デフォルトのセキュリティ構成の一部としてインストールされている認証プロバイダ以外を使用している場合は、「デフォルトのユーザーとグループ」で説明しているデフォルトのユーザーとグループは自動的には提供されません。独自に選択した名前でユーザーやグループを作成することも、デフォルトのユーザー名とグループ名を作成しなおすこともできます(認証プロバイダでサポートされている場合)。この作業が完了した後、BI Publisherのデフォルトのアプリケーション・ロールを別のグループに再度マップする必要があります。たとえば、企業でLDAPサーバーがアイデンティティ・ストアとして使用されており、BI Publisherのデフォルトのユーザーやグループをそのストア内に作成できない場合は、デフォルトのアプリケーション・ロールを企業のLDAPサーバーに固有の別のグループにマップする必要があります。Fusion Middleware Controlを使用して、グループをアプリケーション・ロールにマップします。
異なる認証プロバイダの構成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプおよび『Oracle WebLogic Serverセキュリティの管理』を参照してください。
ポリシー・ストアと資格証明ストアは、ファイルベースまたはLDAPベースで構成できます。
このリリースでその両方のストアに対してサポートされているLDAPサーバーは、Oracle Internet Directoryです。LDAPベースのストアを使用するための前提条件は、ポリシー・ストアと資格証明ストアのいずれであっても同じです。『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。
Fusion Middlewareのセキュリティ・モデルは、独自のアプリケーション・ポリシーとアプリケーション・ロールを作成することにより、環境に合せてカスタマイズできます。
既存のアプリケーション・ロールは、必要に応じてメンバーを追加または削除することにより変更できます。既存のアプリケーション・ポリシーは、権限付与を追加または削除することにより変更できます。アプリケーション・ポリシーおよびアプリケーション・ロールの管理の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。
注意:
新しいアプリケーション・ポリシーやアプリケーション・ロールを作成してBI Publisherのデフォルトのセキュリティ構成に追加する前に、権限やグループの継承の仕組みについて理解しておく必要があります。ロールの階層を構築するときは、循環依存が生じないことが重要です。ベスト・プラクティスは、デフォルトのセキュリティ構成はそのままにしておいて、カスタマイズされたアプリケーション・ポリシーやアプリケーション・ロールをまずはテスト環境に取り込んでみることです。詳細は、「権限の付与と継承」を参照してください。
Fusion Middleware Controlを使用して新規アプリケーション・ロールを作成するか、既存のロールからコピーできます。
アプリケーション・ロールの作成
新しいアプリケーション・ロールを作成するには、2つの方法があります。
「新規作成」 — 新しいアプリケーション・ロールを作成します。新規ロールを作成するときにメンバーを追加するか、新しいロールに名前を付けて保存しておき、後でメンバーを追加することもできます。
既存のコピー — 既存のアプリケーション・ロールをコピーすることで、新規アプリケーション・ロールを作成します。コピーにはオリジナルと同じメンバーが含まれ、新規ロールは同じアプリケーション・ポリシーの権限受領者となります。新しいロールを作成するときに、必要に応じてコピーを変更できます。
新しいアプリケーション・ロールの作成
Fusion Middleware Controlにログインして、「セキュリティ」に移動し、「アプリケーション・ロール」を選択して「アプリケーション・ロール」ページを表示します。
詳細は、「Oracle Enterprise Manager Fusion Middleware Controlへのアクセス」を参照してください。
「アプリケーション・ストライプ」リストからobiを選択します。「ロール名」の横にある検索アイコンをクリックします。
BI Publisherのアプリケーション・ロールを表示できます。
「作成」をクリックして「アプリケーション・ロールの作成」ページを表示します。すべての情報を一度に入力することも、「ロール名」を入力し、保存しておいて、それ以外のフィールドを後で入力することもできます。各フィールドに次の情報を入力します。
「一般」では:
ロール名: アプリケーション・ロールの名前を入力します。
(オプション)表示名: アプリケーション・ロールの表示名を入力します。
(オプション)説明: アプリケーション・ロールの説明を入力します。
「メンバー」セクションで、「追加」をクリックして、アプリケーション・ロールにマップするユーザー、グループまたはアプリケーション・ロールを選択します。
「タイプ」リストからアプリケーション・ロールにマップする「アプリケーション・ロール」、「ユーザー」または「ロール」を選択します。
「プリンシパル名」および「表示名」の基準を任意で指定できます。
「表示名」の横にある検索アイコンをクリックします。
「検索済プリンシパル」表からプリンシパルを選択します。
「OK」をクリックします。
「OK」をクリックして、「アプリケーション・ロール」ページに戻ります。
このページの下部にある表には、新しいアプリケーション・ロールが表示されます。
既存のロールに基づくアプリケーション・ロールの作成
たとえば、次の図はBIContentAuthorロールに基づくMyNewRoleアプリケーション・ロールを示しています。
このページの下部にある表には、新たに作成されたアプリケーション・ロールが表示されます。たとえば、次の図はデフォルトのBIContentAuthorアプリケーション・ロールに基づくMyNewRoleを示しています。
BI Publisherの権限はすべて提供されており、ユーザーが新しい権限を作成することはできません。権限付与は、Fusion Middleware Controlの「アプリケーション・ポリシー」ページでコントロールされます。
アプリケーション・ポリシーの作成
権限付与は、アプリケーション・ポリシーで定義されます。アプリケーション・ロール、ユーザー、またはグループが、その後アプリケーション・ポリシーにマップされます。このプロセスによって、アプリケーション・ロール、ユーザーまたはグループがアプリケーション・ポリシーの「権限受領者」となります。
新しいアプリケーション・ポリシーを作成するには、2つの方法があります。
「新規作成」 — 新規アプリケーション・ポリシーを作成し、それに権限を追加します。
既存のコピー — 既存のアプリケーション・ポリシーをコピーすることで、新規アプリケーション・ポリシーを作成します。必要に応じて、コピーに名前を付けたり、既存の権限を削除したり、新規の権限を追加することができます。
新しいアプリケーション・ポリシーの作成
Fusion Middleware Controlにログインして「セキュリティ」に移動し、「アプリケーション・ポリシー」を選択して「アプリケーション・ポリシー」ページを表示します。
詳細は、「Oracle Enterprise Manager Fusion Middleware Controlへのアクセス」を参照してください。
「アプリケーション・ストライプ」リストからobiを選択します。「プリンシパル名」の横にある検索アイコンをクリックします。
BI Publisherのアプリケーション・ポリシーを表示できます。「プリンシパル」列に、ポリシー名「権限受領者」が表示されます。
「作成」をクリックして、「アプリケーション権限の作成」ページを表示します。
作成するポリシーに権限を追加するには、「権限」領域で「追加」をクリックして「権限の追加」ダイアログを表示します。
「検索」セクションへの入力後に、「リソース名」フィールドの横にある検索アイコンをクリックします。
obiアプリケーション・ストライプで検出されたすべての権限が表示されます。BI Publisherの権限の詳細は、「デフォルトのアプリケーション・ロールと権限」を参照してください。
必要なBI Publisher権限を選択して、「続行」をクリックします。BI Publisher以外の権限を選択しても、ポリシーには何の効果も及ぼしません。
必要に応じて、権限をカスタマイズして、「選択」をクリックします。
「権限」セクションには選択した権限が表示されます。
作成するポリシーにアプリケーション・ロール、ユーザーまたはグループを追加するには、「権限受領者」セクションで「追加」をクリックします。
「プリンシパルの追加」ダイアログで、次のことを実行します。
「検索」セクションへの入力後に、「表示名」フィールドの横にある検索アイコンをクリックします。
必要なプリンシパルを「検索済プリンシパル」リストから選択します。
「OK」をクリックします。
「OK 」をクリックして、「アプリケーション・ポリシー」ページに戻ります。新しいポリシーの「プリンシパル」(権限受領者)および「権限」が表に表示されます。
既存のポリシーに基づくアプリケーション・ポリシーの作成
たとえば、次の図では、BIServiceAdministratorプリンシパル(権限受領者)が選択され、「類似作成」ボタンがアクティブになっています。
「アプリケーション・ポリシー」ページにポリシーの「プリンシパル」と「権限」が表示されます。
