| Oracle® Fusion Middleware Oracle Real-Time Decisions管理者ガイド 11gリリース1(11.1.1) B72431-01 |
|
 前 |
 次 |
Oracle Real-Time DecisionsはOracle Fusion Middlewareプラットフォームとシームレスに統合され、共通セキュリティ・フレームワークおよび機能をOracle Fusion Middlewareプラットフォームと共有します。この章では、全体的なセキュリティ・モデルを理解するための背景情報を提供するために、セキュリティ・フレームワークの概要を示します。
Oracle Fusion Middlewareプラットフォームおよび一般的なセキュリティ・フレームワークの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
この章には次の項が含まれます:
Oracle Fusion MiddlewareとOracle Real-Time Decisionsは共通セキュリティ・フレームワークを共有します。共通セキュリティ・フレームワークを使用することによって、Oracle Fusion Middlewareデプロイメント内でのOracle Real-Time Decisionsの安全な相互運用が可能になります。このセキュリティ・フレームワークは、Javaセキュリティ・モデル上に構築されています。Javaセキュリティ・モデルは、ユーザーに割り当てられたロールに基づいてリソースを保護するコンテナ管理セキュリティを使用した、ロールベースの宣言モデルです。
このトピックで取り上げている概念の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
Oracle Platform Security Services
Oracle Platform Security Services(OPSS)は、セキュリティ・フレームワークの構築の基盤のプラットフォームです。OPSSは標準ベースであり、ロールベースのアクセス制御(RBAC)、Java Enterprise Edition(JavaEE)およびJava Authorization and Authentication Servers(JAAS)に準拠しています。
Oracle WebLogic Server
Oracle Real-Time Decisionsの認証は、Oracle WebLogic Server認証プロバイダにより、OPSSモデルに準拠して処理されます。認証プロバイダは、次の機能を実行します。
ユーザーとシステム・プロセスのアイデンティティを確立します。
アイデンティティ情報を送信します。
アイデンティティ情報のリポジトリとして機能します。コンポーネントはこのリポジトリから情報を取得できます。
デフォルトの認証プロバイダは、Oracle WebLogic Serverに組み込まれたディレクトリ・サーバーです。必要に応じて、代替の認証プロバイダを使用し、Oracle WebLogic管理コンソールで管理できます。
Oracle WebLogic Server認証プロバイダの詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。
Oracle WebLogic Serverのセキュリティ・レルム
Oracle WebLogic Serverのセキュリティ・レルムは、個々のドメイン固有のものです。セキュリティ・レルムには、認証プロバイダ、ユーザー、グループ、セキュリティ・ロールおよびセキュリティ・ポリシーの一括構成が格納されます。1つのドメインに対して複数のセキュリティ・レルムを定義できますが、アクティブ化(つまり、デフォルトのレルムとして指定)可能なセキュリティ・レルムは一度に1つのみです。
セキュリティ管理ツール
アプリケーション・オブジェクトを保護するために必要な管理タスクの実行には、Oracle Fusion MiddlewareおよびOracle WebLogic Serverのコンソールと、コマンドラインのOracle WebLogic Scripting Tool(WLST)が使用されます。詳細は、第4.4項「共通セキュリティ関連タスクに使用される管理ツール」を参照してください。
セキュリティ・プラットフォームは、すべてのOracle Fusion Middleware製品に対して均一のセキュリティおよびアイデンティティ管理を提供するために、特定の重要な要素とプロセスに依存します。Oracle RTDユーザーを対象とするこのセキュリティの概要では、Oracle RTDの簡易インストール時に作成されるデフォルトの要素に基づいて説明を行います。
これらの要素、プロセスおよびセキュリティ・プラットフォームの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
このトピックでは、Oracle RTDに関連するセキュリティ制御と、デフォルト・インストール時に作成されるセキュリティ構成について説明します。
アプリケーションに必要な主な保護と、それぞれの保護で処理される基本的な質問は次のとおりです。
認証
アプリケーションへのアクセスを許可されているユーザーは誰か。
ユーザーおよびグル―プがアイデンティティ・ストアに格納されます。
認可
認証済ユーザーが実行を許可されているアプリケーション内の操作およびアプリケーションを使用した操作は何か。
認証済ユーザーに割り当てられたロールと権限がポリシー・ストアに格納されます。
表4-1に、Oracle RTDの標準のセキュリティ制御についてまとめます。
表4-1 Oracle RTDの標準のセキュリティ制御
| セキュリティ制御 | 主要目的 | 説明 |
|---|---|---|
|
アイデンティティ・ストア |
認証 |
ユーザーおよびグループのアイデンティティを保持するトラスト・ストア。 |
|
ポリシー・ストア |
認可 |
アプリケーション・オブジェクトへのアクセスを可能にするアプリケーション・ロールとアプリケーション権限の保持に使用されるトラスト・ストア。 |
セキュリティの概念を明らかにするため、図4-1に、Oracle Fusion Middlewareアプリケーションで定義および使用される、ユーザー、グループ、アプリケーション・ロールおよび権限の関係の例を示します。この例は、個々のセキュリティ要素に関する後続の説明の参照ポイントとして使用されます。
グループBIConsumers、BIAuthorsおよびBIAdministratorsとアプリケーション・ロールBIConsumer、BIAuthorおよびBIAdministratorは、Oracle Real-Time Decisionsまたは他のOracle Business Intelligenceコンポーネントの構成を行うインストール時に設定されます。C1、C2、C3、Au1、Au2、Ad1は、インストール後にグループのメンバーとして定義されるユーザーの例です。
ロールに割り当てられたグループのメンバーとなったユーザーは、上位レベルのグループおよびロール階層から権限を継承できます。
たとえば、作成者Au1およびAu2は次の2つの権限セットを保有します。
BIAuthorsグループがBIAuthorロールのメンバーであることに基づく、BIAuthorロールの明示的な権限
BIAuthorロールとBIConsumersグループの両方から継承される、BIConsumersロールの暗黙的な権限
インストールされたアプリケーション・ロールでは、インストールされたOracle BIおよびOracle RTDソフトウェア・コンポーネントを操作できるように、適切な権限が事前構成されます。たとえば、BIAuthorという名前のアプリケーション・ロールでは、インライン・サービスをデプロイする権限が事前構成され、BIConsumerというアプリケーション・ロールでは、デシジョン・センター・レポートへのアクセスが許可されます。Oracle RTDのデフォルトの権限の詳細は、第4.3.1項「Oracle Real-Time Decisionsのデフォルトのアプリケーション権限」を参照してください。
図4-2に、インストール時に事前構成されるアプリケーション・ロール、グループおよびユーザーを示します。
たとえば、インストール時に指定したユーザー(WebLogicなど)が、BIAdministratorsという名前のWebLogic Administratorsグループと、BIAdministratorという名前の関連アプリケーション・ロールに自動的に割り当てられます。このユーザーは他のユーザーを作成および管理する権限を保有します。
この項の残りの部分では、アプリケーションへのアクセス権限がユーザーにどのように取得されるかと、アプリケーション内でユーザーが実行できる操作の制御方法について説明します。
この項では、認証に使用されるセキュリティ要素について説明します。
通常、ユーザーおよびグループはアイデンティティ・ストアに定義されます。ユーザーおよびグループのアイデンティティはディレクトリ・サーバーに格納されます。ユーザーおよびグループの認証は、Oracle WebLogic Serverセキュリティ設定の一部として指定された認証プロバイダによって実行されます。
アイデンティティ・ストアには、ユーザー、グループおよびグループ階層の定義が格納されます。Oracle WebLogic Serverの組込みLDAPサーバーはデフォルトのアイデンティティ・ストアです。デフォルトでは、認証プロバイダDefaultAuthenticatorがこのLDAPサーバー内のユーザーとグループに対する認証を実行します。
他のLDAPサーバーなどの代替ディレクトリ・サーバーを使用するように、Oracle RTDを構成できます。詳細なリストは、Oracle Fusion Middleware 11gR1のシステム要件およびサポートされているプラットフォームを参照してください。
ユーザーは、認証可能な実体です。ユーザーは、アプリケーション・エンド・ユーザーなどの人を指す場合と、クライアント・アプリケーションなどのソフトウェアを指す場合があります。各ユーザーには、Oracle Real-Time DecisionsがデプロイされているWebLogicドメイン内で一意の識別子が与えられます。各ユーザーはアイデンティティ・ストア内で一意の識別子を保有するため、Oracle Fusion Middleware、Oracle WebLogic ServerおよびOracle Real-Time Decisionsの全体で認識されます。
グループは、なんらかの共通項を持つユーザーの集合(他のグループを含めることも可能)を編成することによって作成されます。ユーザーは複数のグループで定義できます。グループは、システム管理者によって割り当てられた静的な識別子です。
|
注意: グループおよびグループ階層自体では、アプリケーション内でのどのようなアクションの実行権限も有効化されません。このような権限はアプリケーション・ロールおよび権限を通じて伝達されます。これについては、第4.2.3項「認可の主要素」で説明します。 |
デフォルト・アイデンティティ・ストアは、Oracle WebLogic Serverが提供する、LDAPベースの組込みディレクトリ・サーバーです。このサーバーは、Oracle WebLogic Server管理コンソールを使用して管理されます。これには、インストール時に作成されたデフォルトのユーザーおよびグループが格納されます。
デフォルトの認証プロバイダはDefaultAuthenticatorです。
管理権限を保有するユーザーとして、Oracle Fusion Middlewareの内部プロセス管理に必要な2つのシステム・ユーザーの他にもう1人ユーザーが存在します。このユーザーの名前はインストール時に入力されます。
|
注意: この項では、便宜上、インストール時に入力された名前を |
デフォルトのシステム構成では、<orig_admin_user>はBIAdministratorsグループのメンバーです。
デフォルトの管理者ユーザー名<orig_admin_user>は、別の値に変更できます。また、管理ユーザーがOracle WebLogic Server管理コンソールを使用してユーザー名を追加することも可能です。
表4-2に、デフォルト・アイデンティティ・ストア内のデフォルト・グループおよびグループ・メンバーを示します。これらのデフォルトは異なる値に変更することが可能であり、また、管理ユーザーはOracle WebLogic Server管理コンソールを使用して新しいグループ名を追加できます。
表4-2 デフォルト・グループおよびメンバー
| グループ名 | グループ・メンバー |
|---|---|
|
BIAdministrators |
administrative_user |
|
BIAuthors |
BIAdministratorsグループ |
|
BIConsumers |
BIAuthorsグループ Oracle WebLogic Server LDAPサーバー・ユーザー・グループ |
開始点として機能するこれらのデフォルト・グループ名では、標準的なソフトウェア・ユーザー・カテゴリである管理者、アプリケーション開発者およびエンド・ユーザーに対応する、機能用途の広義のカテゴリ - 管理者、作成者およびコンシューマ - が定義されています。 表4-2と図4-1のグループ階層に示すように、作成者はコンシューマともみなされ、また管理者は作成者ともみなされます。
この項では、認証で使用されるセキュリティ要素について説明します。
アプリケーション・ポリシーは、特定のアプリケーションに適用されるJava 2およびJAASポリシーの集合です。アプリケーション・ポリシーでは、誰が、どのアプリケーション・リソースで、何を実行できるかが定義されます。このポリシーは1つ以上のアプリケーション権限で構成されます。
図4-3に、アプリケーション・ポリシーの各要素の概念の概要を示します。個々のコンポーネントの詳細は、この項で後述します。
|
注意: アプリケーション・ストライプは、ポリシー・ストアにポリシーのサブセットを定義します。Oracle Real-Time Decisionsを含む、すべてのOracle Business Intelligenceコンポーネントによって使用される一般アプリケーション・ストライプはobiという名前です。 |
アプリケーション・ロールは、共通のアプリケーション機能またはプロセス・セットを実行する必要があるユーザーおよびグループの集合を定義する、ポリシー・ストア内のグループ構成です。通常、アプリケーション・ロールは、ユーザー、グループおよび他のアプリケーション・ロールで構成されます。
アプリケーション・ロールは、アプリケーション・ユーザーに権限を付与するための主要手段として機能します。アプリケーション・ロール自体では、アプリケーション・オブジェクトへのアクセスは有効化されません。アクセスの有効化は、アプリケーション・ポリシーでアプリケーション・ロールをアプリケーション権限内の権限にマップすることによって達成されます。
アプリケーション権限は、単一または複数の権限受領者(アプリケーション・ロール、グループまたはユーザー)と1つ以上の権限の組合せです。ユーザーおよびグループの詳細は、第4.2.2項「認証の主要素」を参照してください。
権限は、Javaの権限概念の拡張であり、Javaクラス、リソースおよびリソースのタイプによって許可される1つ以上のアクションで構成されます。
Oracle RTDで使用できるリソースおよびアクションの詳細と例は、第4.3項「Oracle RTDのリソース・タイプとアクション」を参照してください。
アプリケーション・ロールに割り当てられているユーザーまたはグループには、そのロールに関連付けられている権限が付与されます。同じアプリケーション・ロールに複数のユーザーまたはグループを割り当てることができます。
アプリケーション・ロール・マッピングは、実行時にユーザー、グループおよび他のアプリケーション・ロールをアプリケーションに動的にマップするプロセスです。ユーザーおよびグループがメンバーとなっている(つまり、マップされている)アプリケーション・ロールに従って、ユーザーおよびグループに権限が付与されます。
また、グループおよびロール階層は、継承の原則を示します。ロール階層を通じてロールが他のロールに継承され、グループおよびロール階層を通じて権限が継承されます。ユーザー、グループ、アプリケーション・ロールおよび権限の関係の例は、図4-1を参照してください。
図4-1の例では、ユーザーAu1はロールBIAuthorとBIConsumerのすべての権限を保有し、ユーザーAd1はロールBIAdministrator、BIAuthorおよびBIConsumerのすべての権限を保有します。
ポリシー・ストアは、システム・ポリシーとアプリケーション固有のポリシーのリポジトリです。ポリシー・ストアには、ファイルベースまたはLDAPベースのものがあります。
デフォルトのポリシー・ストアはsystem.jazn-data.xmlファイルです。
デフォルト・ポリシー・ストアsystem.jazn-data.xmlには、インストール時に構成されたOracle RTDポリシー、アプリケーション・ロール、アプリケーション権限およびデフォルトのメンバーシップ定義が格納されます。
表4-3に、インストール後のデフォルトのアプリケーション・ロールおよびロール・メンバーを示します。これらのデフォルトは別の値に変更できます。また、管理ユーザーはOracle Fusion Middleware Controlを使用してロール名を追加できます。
図4-1「Oracle Fusion Middlewareセキュリティ要素の例」は、これらのデフォルトのユーザー・ロールとデフォルトのグループおよびロール階層を図解したものです。
表4-3 デフォルトのアプリケーション・ロールおよびロール・メンバー
| アプリケーション・ロール名 | ロール・メンバー |
|---|---|
|
BIAdministrator |
BIAdministratorsグループ |
|
BIAuthor |
BIAuthorsグループ BIAdministratorアプリケーション・ロール |
|
BIConsumer |
BIConsumersグループ BIAuthorアプリケーション・ロール |
BIAdministratorは、Oracle RTDインストールの構成と管理に必要な管理権限に対応するロールです。BIAdministratorsグループのメンバーには、このロールが明示的に付与され、BIAuthorとBIConsumerのロールが暗黙的に付与されます。このロールのデフォルトのOracle RTDアプリケーション権限のリストは、表4-5を参照してください。
BIAuthorは、他のユーザーが使用するコンテンツの作成および編集に必要な権限に対応するロールです。BIAuthorsグループのメンバーには、このロールが明示的に付与され、BIConsumerのロールが暗黙的に付与されます。このロールのデフォルトのOracle RTDアプリケーション権限のリストは、表4-5を参照してください。
BIConsumerは、他のユーザーが作成したコンテンツを使用するために必要な権限に対応するロールです。このロールのデフォルトのOracle RTDアプリケーション権限のリストは、表4-5を参照してください。
|
注意: 特殊ロールauthenticated_roleは、あらゆる認証済ユーザーにデフォルトで付与されます。デフォルトで、これはBIConsumerロールのメンバーです。authenticated_roleを削除すると、システムにログインできなくなります。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の認証ロールに関する項を参照してください。 |
インストール後のOracle RTDユーザーのデフォルトのアプリケーション権限の詳細は、第4.3.1項「Oracle Real-Time Decisionsのデフォルトのアプリケーション権限」で説明します。
OPSSには、アプリケーションまたはシステムのリソースを保護するために、どの権限でも権限クラスとして使用できるJavaクラスoracle.security.jps.ResourcePermissionが含まれています。Oracle RTDは、このクラスを使用して、次の3種類のリソースへのアクセスを制御します。
インライン・サービス
デシジョン・センター・パースペクティブ
バッチ・ジョブ
表4-4に、Oracle RTDでサポートされているリソース・タイプと各タイプの関連アクションを示します。
表4-4 Oracle RTDのリソース・タイプとアクション
| リソース・タイプ | アプリケーション権限に格納されるリソース・タイプ名 | アクション[:修飾子] | コメント |
|---|---|---|---|
|
インライン・サービス |
rtd_ils |
choice_editor |
名前付きインライン・サービスのためにExternalChoice Webサービスの任意のメソッドを実行できます。 |
|
decision_service:normal |
名前付きインライン・サービスのために任意の統合点(アドバイザとインフォーマント)を実行できます。 アクション修飾子normalは、統合点リクエストをサーバーで実行できるようにします。 |
||
|
decision_service:stress |
名前付きインライン・サービスのために任意の統合点(アドバイザとインフォーマント)を実行できます。 アクション修飾子のstressにより、LoadGenが統合点コールを発行できます。サーバーによって受け入れられるには、ユーザーはnormalアクションも必要です。 |
||
|
open_service:read |
表示用に名前付きインライン・サービスを開くためにデシジョン・センターの使用を認可します。 また、外部ルール・エディタはインライン・サービスのコンテンツを更新する必要がないため、外部ルール・エディタが名前付きインライン・サービスにアクセスすることを認可します。 |
||
|
open_service:write |
編集用に名前付きインライン・サービスを開くためにデシジョン・センターの使用を認可します。 |
||
|
deploy_service |
デシジョン・スタジオからの名前付きインライン・サービスのデプロイメントを認可します。 |
||
|
download_service |
サーバーから名前付きインライン・サービスをダウンロードするためにデシジョン・スタジオの使用を認可します。 |
||
|
clear_choice_history |
Administration Webサービスを介した、名前付きインライン・サービスの選択肢履歴のクリアを認可します。 |
||
|
clear_study |
Administration Webサービスを介した、名前付きインライン・サービスのスタディのクリアを認可します。 スタディは複数のインライン・サービスで共有されないため、所有インライン・サービスを指定することは、スタディを指定することと同じです |
||
|
clear_statistics |
Administration webサービスを介した、インライン・サービスの統計のクリアを認可します。 |
||
|
clear_model |
Administration Webサービスを介した、名前付きインライン・サービスのモデルのクリアを認可します。 |
||
|
clear_all_operational_data |
Administration Webサービスを介した、名前付きインライン・サービスの操作データのクリアを認可します。 |
||
|
delete_service |
Administration Webサービスを介した、名前付きインライン・サービスの削除を認可します。 |
||
|
unlock_service |
Administration Webサービスを介した、名前付きインライン・サービスのロック解除を認可します。 |
||
|
デシジョン・センター・パースペクティブ |
rtd_dc_persp |
dc_perspective |
デシジョン・センターに専門のUI要素または機能をレンダリングさせるために、名前付きデシジョン・センター・パースペクティブを開きます。 |
|
登録されているバッチ・ジョブ・タイプ |
rtd_batch |
batch_admin |
登録されているバッチ・ジョブ・タイプ名の開始、停止、またはステータスの問合せを行うために、BatchManager Webサービスの任意のメソッドを実行できます。 |
デフォルトのファイルベースのポリシー・ストアには、事前構成されたアプリケーション権限が含まれています。Oracle RTDでは、権限クラスoracle.security.jps.ResourcePermissionが使用されます。このクラスは、表4-4で示しているリソース・タイプの属性を参照します。
表4-5に、インストール後のデフォルトのアプリケーション権限に含まれるデフォルトのアプリケーション・ロール、Oracle RTDリソース・タイプ、リソース名およびアクションを示します。
|
注意: リソース名_all _は、関連付けられているリソース・タイプの任意のOracle RTDリソース名に一致する特殊な名前です。 |
表4-5 RTDユーザーのデフォルトのアプリケーション権限
| アプリケーション・ロール | リソース・タイプ | リソース名 | アクション[:修飾子] |
|---|---|---|---|
|
BIAdministrator |
rtd_ils |
_all_ |
open_service:read |
|
_all_ |
open_service:write |
||
|
_all_ |
deploy_service |
||
|
_all_ |
download_service |
||
|
_all_ |
choice_editor |
||
|
_all_ |
decision_service:normal |
||
|
_all_ |
decision_service:stress |
||
|
_all_ |
clear_choice_history |
||
|
_all_ |
clear_study |
||
|
_all_ |
clear_statistics |
||
|
_all_ |
clear_model |
||
|
_all_ |
clear_all_operational_data |
||
|
_all_ |
delete_service |
||
|
_all_ |
unlock_service |
||
|
rtd_dc_persp |
_all_ |
dc_perspective |
|
|
rtd_batch |
_all_ |
batch_admin |
|
|
BI Author |
rtd_ils |
_all_ |
open_service:read |
|
_all_ |
open_service:write |
||
|
_all_ |
deploy_service |
||
|
_all_ |
download_service |
||
|
_all_ |
decision_service:normal |
||
|
_all_ |
decision_service:stress |
||
|
rtd_dc_persp |
_all_ |
dc_perspective |
|
|
BI Consumer |
rtd_ils |
_all_ |
open_service:read |
|
_all_ |
choice_editor |
||
|
_all_ |
decision_service:normal |
||
|
rtd_dc_persp |
Explore |
dc_perspective |
|
|
At a Glance |
dc_perspective |
||
|
rtd_batch |
_all_ |
batch_admin |
Fusion Middleware Controlの「アプリケーション・ポリシー」画面に、アプリケーション・ロールBIAuthorの、Oracle RTDに関連するデフォルトの権限が図4-4のように表示されます。
アプリケーション・ロールとアプリケーション・ポリシーの作成および編集方法の詳細は、第4.7.4項「Fusion Middleware Controlを使用したポリシー・ストアの管理」を参照してください。
Oracle Real-Time DecisionsはOracle Fusion Middlewareプラットフォームと共通セキュリティ・フレームワークを共有します。この共通セキュリティ構成では、事実上の管理サーバーとしてOracle WebLogic Serverが使用されます。日常の管理タスクの実行中、実装詳細の大部分は隠され、Oracle Real-Time Decisionsのセキュリティ構成の管理に使用されるツールによってのみ公開されます。2つの主要管理ツールとして、次のものがあります。
Oracle WebLogic Server管理コンソールは、デフォルトの管理インストール後にデフォルト・アイデンティティ・ストアとして機能する組込みLDAPサーバーのユーザーとグループを管理するために使用されます。
Oracle Enterprise Manager Fusion Middleware Controlは、ユーザー、グループまたは他のアプリケーション・ロールに権限を付与するアプリケーション・ロールおよびアプリケーション・ポリシーを定義するために使用されます。
また、Oracle WebLogic Serverドメインの作成、管理および監視と、Oracle Fusion Middlewareセキュリティ機能の管理に使用できるコマンドライン・スクリプト・ツールとして、Oracle WebLogic Scripting Tool(WLST)があります。WLSTの使用の詳細は、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』および『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
表4-6に、実行する共通セキュリティ関連タスクと、使用管理ツールを示します。
表4-7に、Oracle RTDを保護するための標準のシステム管理タスクと、各タスクの関連情報の場所を示します。
この項には次のトピックが含まれます:
|
注意: シングル・サインオン・ソリューションを使用した認証の構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Fusion Middlewareのシングル・サインオンの概要に関する項を参照してください。 |
次のタスク・マップに、認証構成の共通タスクをリストし、各タスクの詳細へのリンクを示します。
| タスク | 説明 | 参照先 |
|---|---|---|
|
認証方式の決定 |
デフォルトの組込みディレクトリ・サーバー(LDAPベース)を使用するか、別の外部認証方式を使用するかを決定します。 |
第4.6.2項「Oracle Real-Time Decisionsの認証の概要」 |
|
デフォルトの認証プロバイダの構成 |
デフォルトのセキュリティ・レルムのデフォルトの認証プロバイダを構成します。 |
|
|
ユーザーおよびグループの追加 |
アイデンティティ・ストアにユーザーおよびグループを追加します。 |
|
|
ユーザーを認証する代替認証プロバイダの構成 |
代替認証プロバイダを構成します。 |
|
インストール時にOracle WebLogic Serverドメインが作成され、そのドメインにOracle Real-Time Decisionsがインストールされます。Oracle WebLogic Serverドメインのセキュリティは、そのドメインのセキュリティ・レルムのコンテキストで管理されます。セキュリティ・レルムは、範囲指定メカニズムとして機能します。各セキュリティ・レルムには、一連の構成済セキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーが含まれています。ドメインでは1つのセキュリティ・レルムだけがアクティブになります。
Oracle Real-Time Decisionsの認証は、Oracle Real-Time Decisionsのインストール先WebLogic Serverドメインのデフォルトのセキュリティ・レルムに対して構成されている認証プロバイダによって実行されます。Oracle WebLogic Serverドメインの管理に使用される管理ツールは、Oracle WebLogic Server管理コンソールです。
次の各項では、Oracle WebLogic Serverの主なセキュリティ概念の概要を示します。Oracle WebLogic Serverのセキュリティの詳細と管理方法は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』およびOracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。
アイデンティティ・ストアには、ユーザー名、パスワードおよびグループ・メンバーシップの情報が含まれています。これはユーザー資格証明のデータ・ストアとして機能します。認証プロバイダは、格納されているユーザー情報にアクセスし、ユーザーの認証処理を担当します。たとえば、ログイン時にユーザー名とパスワードの組合せを入力すると、認証プロバイダは、提供された資格証明を検証するためにアイデンティティ・ストアを検索します。Oracle RTDに対してSSO認証が構成されている場合は、SSOプロバイダもこのアイデンティティ・ストアに格納されているデータを使用します。
Oracle WebLogic Server付属の組込みディレクトリ・サーバー以外のアイデンティティ・ストアを使用した場合、第4.2.2項「認証の主要素」で示しているデフォルト・ユーザーおよびグループの自動構成は行われません。独自に選択した名前でユーザーやグループを作成することも、デフォルトのユーザー名とグループ名を作成しなおすこともできます(認証プロバイダでサポートされている場合)。この作業が完了したら、デフォルトのOracle RTDアプリケーション・ロールを対応するグループにマップする必要があります。たとえば、企業のLDAPサーバーをアイデンティティ・ストアとして使用しており、Oracle RTDのデフォルトのユーザーとグループをそのサーバーに再作成できない場合は、デフォルトのアプリケーション・ロールを、企業のLDAPサーバー固有の別のグループにマップする必要があります。デフォルトのアプリケーション・ロールとグループのマッピングの詳細は、第4.2.2項「認証の主要素」および第4.2.3項「認可の主要素」を参照してください。
Oracle Real-Time Decisionsは、インストール後、Oracle WebLogic Serverのデフォルトの認証プロバイダ(DefaultAuthenticator)を使用するように構成されます。DefaultAuthenticatorは、ユーザー名およびパスワード認証をサポートしています。Oracle WebLogic Serverの組込みディレクトリ・サーバーが、デフォルトのユーザー・データ・ソース(アイデンティティ・ストア)として構成されます。認証プロバイダは、認証リクエストの検証中、アイデンティティ・データ・ストアに接続して資格証明を検証します。認証プロバイダは、Oracle WebLogic Server管理コンソールで構成されたユーザー・データ・ストアを使用します。
アクティブな・セキュリティ・レルムには、複数の認証プロバイダを構成できますが、アクティブ化できるプロバイダは一度に1つのみです。その優先度は、リスト内のプロバイダの順序によって決まります。セキュリティ・レルムに認証プロバイダを多数定義しておくことで累積的な効果がもたらされるというわけではなく、リスト内の最初のプロバイダが、認証で必要とされるユーザーやパスワードの全データの情報源となります。複数の認証プロバイダを定義できるため、リスト内の順序を変更することによって、認証プロバイダを切り替えることが可能です。たとえば、開発環境と本番環境で異なるディレクトリ・サーバーを個別に使用している場合、リスト内のサーバーを並べ替えることによって、認証時に使用するサーバーを変更できます。
Oracle WebLogic Serverでの認証プロバイダの管理と構成の詳細は、Oracle WebLogic Serverのオンライン・ヘルプで説明しています。詳細は、Oracle WebLogic Server管理コンソールにログインし、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを起動してください。
グループとは、論理的に順序付けられたユーザーの集合のことです。グループを管理することは、多数のユーザーを個々に管理するより効率的です。ベスト・プラクティスとしては、まず、Oracle RTDのすべてのユーザーを、同様のシステム・アクセス要件を持つグループにまとめます。その後、これらのグループに、適切なアクセス・レベルを提供するアプリケーション・ロールをマップできます。システム・アクセス要件が変わった場合には、アプリケーション・ロールによって付与される権限を変更するか、適切な権限を持つアプリケーション・ロールを新たに作成するだけで済みます。グループの確立後も、ユーザー・データ・ソース(アイデンティティ・ストア)の管理インタフェースを通常どおり使用して、このデータ・ソースに対して直接、追加または削除操作を実行します。
デフォルトのアイデンティティ・ストアは、Oracle WebLogic Serverの組込みディレクトリ・サーバーです。ただし、使用可能なディレクトリ・サーバーとして多くのサーバーをサポートしており、またデータベースや表などの代替ソースも使用できます。デフォルト以外のディレクトリ・サーバーへのユーザーまたはグループの追加の詳細は、製品のドキュメントを参照してください。Oracle RTDでの使用がサポートされている認証プロバイダとディレクトリ・サーバーの最新のリストは、システム要件と動作保証情報のドキュメントを参照してください。詳細は、第1.4項「システム要件と動作保証情報」を参照してください。
デフォルトのディレクトリ・サーバーでのユーザーとグループの管理の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。
デフォルトのディレクトリ・サーバーでユーザーを作成するには:
Oracle WebLogic Server管理コンソールで左ペインから「セキュリティ・レルム」を選択し、構成するレルムをクリックします。例: myrealm。
「ユーザーとグループ」タブ→「ユーザー」を選択します。「新規」をクリックします。
「新しいユーザーの作成」ペインで、次の情報を指定します。
名前: ユーザーの名前を入力します。無効な文字のリストは、オンライン・ヘルプを参照してください。
(オプション)説明: 説明を入力します。
プロバイダ: ユーザー情報が含まれるデータ・ストアに対応するリストから、認証プロバイダを選択します。DefaultAuthenticatorは、デフォルト認証プロバイダの名前です。
パスワード: 8文字以上の長さで、ユーザーのパスワードを入力します。
パスワードの確認: ユーザー・パスワードを再入力します。
「OK」をクリックします。
ユーザー名は、User表に追加されます。
デフォルト・ディレクトリ・サーバーでグループを作成するには:
Oracle WebLogic Server管理コンソールで左ペインから「セキュリティ・レルム」を選択し、構成するレルムをクリックします。例: myrealm。
「ユーザーとグループ」タブ→「グループ」を選択します。「新規」をクリックします。
「新しいグループの作成」ペインで、次の情報を指定します。
名前: グループの名前を入力します。グループ名は、大文字と小文字が区別され、一意である必要があります。無効な文字のリストは、オンライン・ヘルプを参照してください。
(オプション)説明: 説明を入力します。
プロバイダ: グループ情報が含まれるデータ・ストアに対応するリストから、認証プロバイダを選択します。DefaultAuthenticatorは、デフォルト認証プロバイダの名前です。
「OK」をクリックします。
グループ名は、Group表に追加されます。
デフォルトのディレクトリ・サーバー内のグループにユーザーを追加するには:
Oracle WebLogic Server管理コンソールで左ペインから「セキュリティ・レルム」を選択し、構成するレルムをクリックします。例: myrealm。
「ユーザーとグループ」タブ→「ユーザー」を選択します。
「ユーザー」表で、グループに追加するユーザーを選択します。
「グループ」タブを選択します。
「使用可能」リスト・ボックスから1つまたは複数のグループを選択します。
「保存」をクリックします。
デフォルトのディレクトリ・サーバーでユーザー・パスワードを変更するには:
Oracle WebLogic Server管理コンソールで左ペインから「セキュリティ・レルム」を選択し、構成するレルムをクリックします。例: myrealm。
「ユーザーとグループ」タブ→「ユーザー」を選択します。
Users表で、パスワードを変更したいユーザーを選択します。
「パスワード」タブを選択し、「新規パスワード」フィールドおよび「パスワード確認」フィールドにパスワードを入力します。
「保存」をクリックします。
LDAPサーバーやデータベースなどの任意の環境で様々なタイプの認証プロバイダを使用できます。代替の外部アイデンティティ・ストアを使用するようにOracle RTDを構成するには、Oracle WebLogic Server管理コンソールを使用します。
Oracle RTDでの使用がサポートされている認証プロバイダとディレクトリ・サーバーの最新のリストは、システム要件と動作保証情報のドキュメントを参照してください。詳細は、第1.4項「システム要件と動作保証情報」を参照してください。
Oracle WebLogic Serverでサポートされている任意のアイデンティティ・ストア・プロバイダを、Oracle RTDで使用するように構成できます。Oracle RTDは認証とユーザー移入管理を、Oracle RTDのデプロイ先のドメインに対して構成されている認証プロバイダとアイデンティティ・ストアに委任します。たとえば、Oracle WebLogic Serverのデフォルトの認証プロバイダを使用するように構成されている場合、管理はOracle WebLogic Server管理コンソールで実行されます。Oracle Internet Directory(OID)を使用するように構成されている場合は、OID管理ユーザー・インタフェースが使用されます。
|
注意: 新しい認証プロバイダのユーザー・データ・ソースとしてデフォルト以外のディレクトリ・サーバーを使用している場合も、Oracle WebLogic Server管理コンソールでそのディレクトリ・サーバーのユーザーとグループを表示できます。しかし、ユーザーとグループの管理は、引き続きそのディレクトリ・サーバーのインタフェースで行います。 |
Oracle RTDは、WebLogic Serverドメイン内のアクティブなセキュリティ・レルムに対して構成されている最初の認証プロバイダを使用します。ドメインのアクティブなセキュリティ・レルムには、複数の認証プロバイダを構成できます。リスト内の順序によって、優先度が決まります。複数の認証プロバイダを構成することで累積的な効果がもたらされるわけではなく、先頭に配置されたプロバイダが認証に必要なすべてのユーザーおよびパスワード定義のソースになります。これにより、必要に応じて認証プロバイダを切り替えることが可能になります。たとえば、開発環境と本番環境で異なるLDAPサーバーを個別に使用している場合、サーバーの順序を変更することによって、認証に使用するサーバーを変更できます。
デフォルトのセキュリティ構成の一部としてインストールされるアイデンティティ・ストア・プロバイダ以外のプロバイダを使用した場合、第4.2.2項「認証の主要素」で説明しているデフォルトのユーザーおよびグループの自動構成は行われません。独自に選択した名前でユーザーやグループを作成することも、デフォルトのユーザー名とグループ名を作成しなおすこともできます(認証プロバイダでサポートされている場合)。この作業が完了したら、デフォルトのOracle RTDアプリケーション・ロールを別のグループにマップしなおす必要があります。たとえば、企業のLDAPサーバーをアイデンティティ・ストアとして使用しており、Oracle RTDのデフォルトのユーザーとグループをそのサーバーに再作成できない場合は、デフォルトのアプリケーション・ロールを、企業のLDAPサーバー固有の別のグループにマップする必要があります。
|
注意: デフォルトの組込みLDAPサーバー以外の認証プロバイダを使用するようにセキュリティ・レルムを構成した場合は、代替アイデンティティ・ストア内の適切なグループ(エンタープライズ・ロール)にアプリケーション・ロールをマップしなおす必要があります。 |
認証セキュリティ・プロバイダの構成方法を確認するには、Oracle WebLogic Server管理コンソールにログインし、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプで詳細手順を参照してください。Oracle Internet Directoryを認証プロバイダとして構成する方法の詳細は、第4.6.4.1項「認証プロバイダとしてのOracle Internet Directoryの構成」を参照してください。
別の認証プロバイダとアイデンティティ・ストアの組合せを構成するプロセスについて説明する次の手順では、Oracle Internet Directoryを使用しています。両方に同じディレクトリ・サーバーを使用すると便利ですが、Oracle RTDでサポートされている任意のサーバーの組合せを使用できます。
このプロセスでは、認証プロバイダとアイデンティティ・ストアの両方として機能するようにOracle Internet Directoryを構成する方法を示しています。別のディレクトリ・サーバーを使用する場合は相違点があります。Oracle WebLogic Serverドメインに対する認証プロバイダの構成の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。
Oracle Internet Directoryがユーザー・データ(アイデンティティ・ストア)を提供する場合、Oracle Internet Directory認証プロバイダの構成は管理コンソールで行います。
この項の残りの部分では、Oracle Internet Directory認証プロバイダの構成方法と、認証プロバイダ・リストの並替え方法について説明します。
Oracle Internet Directory認証プロバイダを構成するには:
次の説明では、Oracle Internet Directoryを表すものとして、MyOIDDirectoryという名前を使用しています。
Oracle WebLogic Server管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
図wls01.gifの説明
左側のペインで「セキュリティ・レルム」を選択し、構成対象のセキュリティ・レルムをクリックします。例: myrealm。
「プロバイダ」を選択し、「認証」を選択します。「新規」をクリックし、「新しい認証プロバイダの作成」ページを起動します。
図wls03.gifの説明
「新しい認証プロバイダの作成」ページで、次のように値を入力します。
名前: 認証プロバイダの名前を入力します。例: MyOIDDirectory。
タイプ: リストから、「OracleInternetDirectoryAuthenticator」を選択します。
「OK」をクリックします。
「プロバイダ」を選択し、「認証」を選択します。構成対象の認証プロバイダの名前をクリックします。例: MyOIDDirectory。
複数のタブで構成される、Oracle Internet Directory認証プロバイダの「構成」ページが表示されます。「構成」ページのフィールドの設定方法の詳細を確認するには、各フィールドにある「詳細...」リンクをクリックします。
次に、Oracle Internet Directory認証プロバイダの「制御フラグ」を設定します。複数の認証プロバイダの構成時には、「制御フラグ」によって、ログイン・シーケンスでの認証プロバイダの使用方法が制御されます。
「共通」タブの「制御フラグ」で、リストからSUFFICIENTを選択して、この値を設定します。「制御フラグ」の設定の詳細を確認するには、「詳細...」をクリックします。
図wls05.gifの説明
「プロバイダ固有」タブを選択して、各フィールドを次のように設定します。各セクションのその他のフィールドの設定を確認するには、「詳細...」をクリックします。
| セクション名 | フィールド名 | 説明 |
|---|---|---|
|
接続 |
ホスト |
Oracle Internet Directoryサーバーのホスト名。 |
|
ポート |
Oracle Internet Directoryサーバーがリスニングしているポート番号。 |
|
|
プリンシパル |
Oracle Internet Directoryサーバーへの接続に使用されるOracle Internet Directoryユーザーの識別名(DN)。例: cn=OIDUser,cn=users,dc=us,dc=mycompany,dc=com |
|
|
資格証明 |
プリンシパルとして入力されたOracle Internet Directoryユーザーのパスワード。 |
|
|
ユーザー |
ユーザー・ベースDN |
ユーザーを含むOracle Internet Directoryサーバー・ツリーのベース識別名(DN)。 |
|
グループ |
グループ・ベースDN |
グループを含むOracle Internet Directoryサーバー・ツリーのベース識別名(DN)。 |
「保存」をクリックします。
「チェンジ・センター」の「変更のアクティブ化」をクリックします。
管理サーバーと管理対象サーバーを再起動する必要があります。
Oracle WebLogic Serverを再起動します。
認証プロバイダを並べ替えるには:
Oracle WebLogic Server管理コンソールの「認証プロバイダ」ページには、デフォルトのセキュリティ・レルムに対して構成されているすべての認証プロバイダが表示されます。Oracle RTDは、先頭に配置されている認証プロバイダのみを使用します。複数のプロバイダが構成されている場合は、Oracle RTDに使用させる認証プロバイダを先頭に移動する必要があります。
Oracle WebLogic Server管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
左側のペインで「セキュリティ・レルム」を選択し、構成対象のセキュリティ・レルムをクリックします。例: myrealm。左側のペインの「ドメイン構造」セクションで、「セキュリティ・レルム」を選択します。
「プロバイダ」タブを選択し、「認証」を選択します。
「並替え」をクリックします。
Oracle Internet Directory認証プロバイダの名前を選択し、矢印ボタンを使用して先頭に移動します。次の図のような結果になります。ここでは、Oracle Internet DirectoryをMyOIDDirectoryとして示しています。
この項には次のトピックが含まれます:
次のタスク・マップに、認可構成の共通タスクをリストし、各タスクの詳細へのリンクを示します。
| タスク | 説明 | 参照先 |
|---|---|---|
|
認可方式の決定 |
ポリシー・ストアをデフォルトのファイルにするか、LDAPベースにするかを決定します。 |
|
|
ポリシー・ストアの構成 |
ポリシー・ストアの構成と再関連付けを行います。 |
|
|
アプリケーション・ロールとアプリケーション・ポリシーの作成、編集および削除 |
Fusion Middleware Controlを使用して、アプリケーション・ロールとアプリケーション・ポリシーを作成、編集および削除します。 |
第4.7.4項「Fusion Middleware Controlを使用したポリシー・ストアの管理」 |
ユーザーが認証されると、そのユーザーのOracle RTDへの後続のアクセスは、ポリシー・ストアに格納されたアプリケーション・ポリシー内のアプリケーション権限を通じて制御されます。この制御はFusion Middleware Controlによって管理されます。
ポリシー・ストアには、アプリケーションで使用される、システムおよびアプリケーション固有のポリシーとロールが格納されます。ドメインのポリシー・ストアとして、ファイルベースまたはLDAPベースのストアを使用できます。デフォルトのポリシー・ストアはXMLファイル(system-jazn-data.xml)としてインストールされます。このXMLファイルには、Oracle RTDのデフォルトのアプリケーション・ロール、権限、ユーザーおよびグループ間のマッピング定義が保持されます。これらの定義はすべてインストールの一部として構成されます。
Oracle RTDの権限は、アイデンティティ・ストア内のユーザーおよびグループを、ポリシー・ストアに配置されているアプリケーション・ロールおよびアプリケーション権限にマップすることによって付与されます。ユーザーやグループ(アイデンティティ・ストア)とアプリケーション・ロール(ポリシー・ストア)との間のこれらマッピング定義は、ポリシー・ストアにも保存されます。
ファイルベースとLDAPベースのどちらのタイプのポリシー・ストアも、Fusion Middleware Controlを使用して管理されます。
インストール時には、デフォルトのポリシー・ストアとしてsystem-jazn-data.xmlファイルが事前構成されます。デフォルトを継続して使用し、環境に応じて必要な変更を加えることができますが、LDAPベースのプロバイダにデフォルトのデータを移行することもできます。本番環境では、通常、LDAPベースのプロバイダが使用されます。この使用をお薦めします。
権限はOracle RTDが認識可能な方法で定義する必要があります。第4.3項「Oracle RTDのリソース・タイプとアクション」で説明しているように、Oracle RTDの有効なすべてのタイプおよびリソース名が用意され、デフォルトのアプリケーション・ロールに事前にマップされています。Oracle RTDのリソース・タイプの新規作成はできませんが、ダミー名_all_のかわりに特定の名前をリソース名として選択できます。
対応する管理インタフェースを使用して、ポリシー・ストアに格納されているアプリケーション・ポリシーおよびロール定義のアプリケーション権限を調整できます。
このリリースでサポートされているLDAPサーバーは、Oracle Internet Directoryのみです。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のLDAPベースのOPSSセキュリティ・ストアの使用に関する項を参照してください。
ポリシーや資格証明を1つのセキュリティ・ストアから別のセキュリティ・ストアに移行することを、再関連付けと呼びます。ファイルベースのストアからLDAPベースのストアへ、またはLDAPベースのストアから別のLDAPベースのストアへ、ポリシー・ストアのデータを再関連付けできます。一般に、再関連付けは、テスト環境などから本番環境などへ環境を移行するときに行われます。
再関連付けの詳細と、ポリシー・ストアのデータをOracle Internet Directoryに移行するために必要な手順の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlによる再関連付けに関する項を参照してください。
ポリシー・ストアは、Fusion Middleware Controlを使用して管理されます。Fusion Middleware Controlの使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
|
注意: 標準のバックアップ計画の一部として、元の |
認可を制御する2つの主要オブジェクトは、アプリケーション・ロールとアプリケーション・ポリシーです。これらのオブジェクト、およびこれらのオブジェクトとユーザーおよびグループとの相互関係に関する一般情報は、第4.2.3項「認可の主要素」および第4.2.1項「Oracle RTDのセキュリティ制御」を参照してください。
第4.3.1項「Oracle Real-Time Decisionsのデフォルトのアプリケーション権限」で説明しているように、デフォルトのセキュリティ構成の要素であるアプリケーション・ロール、アプリケーション権限およびグループは事前に相互にマップされています。
アプリケーション・ロールとアプリケーション・ポリシー
アプリケーション・ロールは、ユーザー、グループおよび他のアプリケーション・ロールで構成されます。ユーザーとグループは、認証プロバイダに関連付けられているアイデンティティ・ストア内に作成されます。これらは、Fusion Middleware Controlでアプリケーション・ロールに割り当てることができます。
アプリケーション権限は、誰が、どのリソースに対して、どの操作を実行できるかを制御します。この権限は、Fusion Middleware Controlでアプリケーション・ポリシー内に定義されます。アプリケーション権限は、通常、アプリケーション指向の権限セットと、これらの権限を付与された1つ以上のアプリケーション・ロールで構成されます。
インストール時に作成されるデフォルトのアプリケーション・ロールとアプリケーション・ポリシーを使用するほかに、独自のアプリケーション・ロールとアプリケーション・ポリシーを作成できます。この作成プロセスの簡略化した概要を次に示します。
アプリケーション・ロールを作成し、この新しいロールに単一または複数のユーザー、グループおよび既存のアプリケーション・ロールを追加します。
アプリケーション・ポリシーを作成し、アプリケーション指向の1つ以上の権限と、単一または複数の権限受領者を指定します。権限受領者は通常アプリケーション・ロールですが、一般に、アプリケーション・ロール、ユーザーまたはグループを権限受領者として指定できます。
アプリケーション・ポリシーにロールが追加された段階で初めて、そのロールによるアプリケーション・ポリシー内の権限の認可が有効になります。
一般に、Fusion Middleware Controlでは、新しいアプリケーション・ロールまたはアプリケーション・ポリシーの作成方法として次の2つの方法があります。
アプリケーション・ロールまたはアプリケーション・ポリシーの構成要素を明示的に定義することによって、これらを作成します。
既存のアプリケーション・ロールまたはアプリケーション・ポリシーに基づいてアプリケーション・ロールまたはアプリケーション・ポリシーを作成します。既存のオブジェクトの構成要素をコピーし、追加または変更を行います。
|
注意: セキュリティ構成に組み込むアプリケーション・ロールを新規作成する際には、事前に、権限とグループの継承がどのように行われるかを把握してください。アプリケーション・ロール階層の構成時には、循環依存が発生しないようにすることが重要です。 |
この項の残りの部分では、Fusion Middleware Controlでのアプリケーション・ロールとアプリケーション・ポリシーの管理方法について説明します。この項の内容は次のとおりです。
新しいアプリケーション・ロールの作成プロセスの概要は次のとおりです。
第2.1.1項「Fusion Middleware Controlへのログイン」の説明に従って、Fusion Middleware Controlにログインします。
「ターゲット・ナビゲーション・ペイン」で、「アプリケーション・デプロイメント」にあるサーバーレベルのOracle RTDエントリまたは「WebLogicドメイン」にあるbifoundation_domainエントリを右クリックして「セキュリティ」を選択し、「アプリケーション・ロール」を選択します。
アプリケーション・ストライプobiでアプリケーション・ロールを選択および検索します(「ロール名」ボックスの横のボタンをクリック)。
「作成...」をクリックします。
「アプリケーション・ロールの作成」ページで次の操作を行います。
「ロール名」に名前を入力します。
オプションで、「表示名」と「説明」に入力を行います。
単一または複数のアプリケーション・ロール、グループ、ユーザーを追加します。
どれについても、使用可能なアプリケーション・ロール、グループおよびユーザーから検索し、選択できます。
追加情報および詳細な手順は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したポリシーの管理に関する項を参照してください。
別のアプリケーション・ロールからのコピーによるアプリケーション・ロールの作成プロセスの概要は次のとおりです。
第2.1.1項「Fusion Middleware Controlへのログイン」の説明に従って、Fusion Middleware Controlにログインします。
「ターゲット・ナビゲーション・ペイン」で、「アプリケーション・デプロイメント」にあるサーバーレベルのOracle RTDエントリまたは「WebLogicドメイン」にあるbifoundation_domainエントリを右クリックして「セキュリティ」を選択し、「アプリケーション・ロール」を選択します。
アプリケーション・ストライプobiでアプリケーション・ロールを選択および検索します(「ロール名」ボックスの横のボタンをクリック)。
検索結果でアプリケーション・ロールを選択します。
「類似作成...」をクリックします。
「アプリケーション・ロールの類似作成」ページで:
「ロール名」の名前を変更します。
オプションで、「表示名」と「説明」の内容を編集します。
単一または複数のアプリケーション・ロール、グループ、ユーザーを追加または削除します。
各追加では、使用可能なアプリケーション・ロール、グループおよびユーザーから検索し、選択できます。
追加情報および詳細な手順は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したポリシーの管理に関する項を参照してください。
アプリケーション・ロールの編集プロセスの概要は次のとおりです。
第2.1.1項「Fusion Middleware Controlへのログイン」の説明に従って、Fusion Middleware Controlにログインします。
「ターゲット・ナビゲーション・ペイン」で、「アプリケーション・デプロイメント」にあるサーバーレベルのOracle RTDエントリまたは「WebLogicドメイン」にあるbifoundation_domainエントリを右クリックして「セキュリティ」を選択し、「アプリケーション・ロール」を選択します。
アプリケーション・ストライプobiでアプリケーション・ロールを選択および検索します(「ロール名」ボックスの横のボタンをクリック)。
検索結果でアプリケーション・ロールを選択します。
「編集...」をクリックします。
「アプリケーション・ロールの編集」ページで次の操作を行います。
オプションで、「表示名」と「説明」の内容を編集します。
単一または複数のアプリケーション・ロール、グループ、ユーザーを追加または削除します。
各追加では、使用可能なアプリケーション・ロール、グループおよびユーザーから検索し、選択できます。
追加情報および詳細な手順は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したポリシーの管理に関する項を参照してください。
アプリケーション・ロールの削除プロセスの概要は次のとおりです。
第2.1.1項「Fusion Middleware Controlへのログイン」の説明に従って、Fusion Middleware Controlにログインします。
「ターゲット・ナビゲーション・ペイン」で、「アプリケーション・デプロイメント」にあるサーバーレベルのOracle RTDエントリまたは「WebLogicドメイン」にあるbifoundation_domainエントリを右クリックして「セキュリティ」を選択し、「アプリケーション・ロール」を選択します。
アプリケーション・ストライプobiでアプリケーション・ロールを選択および検索します(「ロール名」ボックスの横のボタンをクリック)。
検索結果でアプリケーション・ロールを選択します。
「削除...」をクリックします。
アプリケーション・ロールの削除を確認します。
追加情報および詳細な手順は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したポリシーの管理に関する項を参照してください。
新しいアプリケーション・ポリシーの作成プロセスの概要は次のとおりです。
第2.1.1項「Fusion Middleware Controlへのログイン」の説明に従って、Fusion Middleware Controlにログインします。
「ターゲット・ナビゲーション・ペイン」で、「アプリケーション・デプロイメント」にあるサーバーレベルのOracle RTDエントリまたは「WebLogicドメイン」にあるbifoundation_domainエントリを右クリックして「セキュリティ」を選択し、「アプリケーション・ポリシー」を選択します。
アプリケーション・ストライプobiでセキュリティ権限を選択および検索します(「名前」ボックスの横の右矢印ボタンをクリック)。
検索結果でアプリケーション・ポリシーを選択します。
「作成...」をクリックします。
「アプリケーション権限の作成」ページで次の操作を行います。
1つ以上の権限を追加、編集または削除します。
単一または複数の権限受領者を追加、編集または削除します。
アプリケーション権限を作成する際には、権限と権限受領者のエントリを少なくとも1つずつ追加する必要があります。
1つ以上の権限の追加
Oracle RTDのデフォルトの権限(第4.3項「Oracle RTDのリソース・タイプとアクション」を参照)には、関連付けられたリソース・タイプのあらゆるOracle RTDリソース名と一致するダミー・リソース名_all_が含まれています。
次のいずれかのプロセスを使用して、権限を追加できます。
権限クラスoracle.security.jps.ResourcePermissionの既存の権限を検索し、必要に応じて変更します。
Oracle RTDリソース、つまり第4.3項「Oracle RTDのリソース・タイプとアクション」に指定されているいずれかのリソース・タイプのリソースの権限アクションを指定します。
たとえば、単一のインライン・サービスMarket_ILSを読み書き両用に開き、デプロイできるようにするには、次の手順を実行します:
「権限の追加」ウィンドウで、「リソース・タイプ」ラジオ・ボタンを選択し、「リソース・タイプ」でrtd_ilsを選択します。
「続行」をクリックします。
「カスタマイズ」領域で「リソース名」に「Market_ILS」と入力し、このリソースに対する適切な権限アクションを選択します。
「選択」をクリックします。
権限および権限アクションを編集することも可能です。ただし、表4-4で示している使用可能な権限アクションとアクション修飾子に従う必要があります。
単一または複数の権限受領者の追加
単一または複数のアプリケーション・ロール、グループ、ユーザーを追加できます。
各追加では、使用可能なアプリケーション・ロール、グループおよびユーザーから検索し、選択できます。
新しいアプリケーション・ポリシーの作成が完了すると、追加した権限受領者のリストによって、obiアプリケーション・ストライプのすべてのセキュリティ権限のリストのどこに新しいアプリケーション・ポリシーが表示されるかが決まります。次のようになります。
新しいアプリケーション・ポリシーの権限受領者が、「プリンシパル」列に示されている既存のセキュリティ権限の権限受領者と一致する場合、それらの権限受領者を示す既存のセキュリティ権限に、その権限受領者の組合せを対象として、新しいアプリケーション・ポリシーの権限が表示されます。
新しいアプリケーション・ポリシーの権限受領者が、「プリンシパル」列に示されている既存のセキュリティ権限の権限受領者と一致しない場合、新しい「プリンシパル」行に、新しいアプリケーション・ポリシーに含まれている新しい権限受領者と権限が表示されます。
追加情報および詳細な手順は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したポリシーの管理に関する項を参照してください。
別のアプリケーション・ポリシーからのコピーによるアプリケーション・ポリシーの作成プロセスの概要は次のとおりです。
第2.1.1項「Fusion Middleware Controlへのログイン」の説明に従って、Fusion Middleware Controlにログインします。
「ターゲット・ナビゲーション・ペイン」で、「アプリケーション・デプロイメント」にあるサーバーレベルのOracle RTDエントリまたは「WebLogicドメイン」にあるbifoundation_domainエントリを右クリックして「セキュリティ」を選択し、「アプリケーション・ポリシー」を選択します。
アプリケーション・ストライプobiでセキュリティ権限を選択および検索します(「権限」ボックスの横のボタンをクリック)。
検索結果でアプリケーション・ポリシーを選択します。
「類似作成...」をクリックします。
「アプリケーション権限の類似作成」ページに、コピー元のポリシーの権限と権限受領者が表示されます。「アプリケーション権限の類似作成」ページでは、次の編集操作を実行できます。
権限の追加、編集および削除
単一または複数のアプリケーション・ロール、グループ、ユーザーを追加および削除します。
第4.7.4.5項「新しいアプリケーション・ポリシーの作成」で説明している考慮事項と推奨事項が同様に適用されます。
新しいアプリケーション権限の作成が完了すると、アプリケーション権限内の権限受領者のリストによって、obiアプリケーション・ストライプのすべてのセキュリティ権限のリストのどこに新しいアプリケーション権限が表示されるかが決まります。次のようになります。
新しいアプリケーション権限の権限受領者が、「プリンシパル」列に示されている既存のセキュリティ権限の権限受領者と一致する場合、それらの権限受領者を示す既存のセキュリティ権限に、その権限受領者の組合せを対象として、新しいアプリケーション権限の権限が表示されます。
新しいアプリケーション・ポリシー権限の権限受領者が、「プリンシパル」列に示されている既存のセキュリティ権限の権限受領者と一致しない場合、新しい「プリンシパル」行に、新しいアプリケーション権限で選択された新しい権限受領者と権限が表示されます。
追加情報および詳細な手順は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したポリシーの管理に関する項を参照してください。
アプリケーション・ポリシーの編集プロセスの概要は次のとおりです。
第2.1.1項「Fusion Middleware Controlへのログイン」の説明に従って、Fusion Middleware Controlにログインします。
「ターゲット・ナビゲーション・ペイン」で、「アプリケーション・デプロイメント」にあるサーバーレベルのOracle RTDエントリまたは「WebLogicドメイン」にあるbifoundation_domainエントリを右クリックして「セキュリティ」を選択し、「アプリケーション・ポリシー」を選択します。
アプリケーション・ストライプobiでセキュリティ権限を選択および検索します(「権限」ボックスの横のボタンをクリック)。
検索結果でアプリケーション・ポリシーを選択します。
「編集...」をクリックします。
「アプリケーション権限の編集」ページで次の操作を行います。
1つ以上の権限の追加、編集または削除
単一または複数のアプリケーション・ロール、グループ、ユーザーを追加または削除します。
編集操作と、編集後のポリシーが表示される場所の両方に関して、第4.7.4.6項「別のアプリケーション・ポリシーに類似するアプリケーション・ポリシーの作成」で説明している考慮事項と推奨事項が同様に適用されます。
追加情報および詳細な手順は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したポリシーの管理に関する項を参照してください。
アプリケーション・ポリシーの削除プロセスの概要は次のとおりです。
第2.1.1項「Fusion Middleware Controlへのログイン」の説明に従って、Fusion Middleware Controlにログインします。
「ターゲット・ナビゲーション・ペイン」で、「アプリケーション・デプロイメント」にあるサーバーレベルのOracle RTDエントリまたは「WebLogicドメイン」にあるbifoundation_domainエントリを右クリックして「セキュリティ」を選択し、「アプリケーション・ポリシー」を選択します。
アプリケーション・ストライプobiでセキュリティ権限を選択および検索します(「権限」ボックスの横のボタンをクリック)。
検索結果でアプリケーション・ポリシーを選択します。
|
注意: 選択するアプリケーション・ポリシーは、「プリンシパル」列に示されているその権限受領者の組合せによって識別されます。削除操作の結果として、選択した行が削除されます。つまり、権限受領者の組合せが、その関連する権限とともにセキュリティ権限リストから削除されます。 |
「削除...」をクリックします。
アプリケーション・ポリシーの削除を確認します。
追加情報および詳細な手順は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したポリシーの管理に関する項を参照してください。
Oracle Fusion MiddlewareでのSSLに関する一般情報は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion MiddlewareでのSSLの構成」の章を参照してください。
Oracle RTDに対してSSLを有効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで「環境」を選択し、「サーバー」を選択して、Oracle RTDが含まれている管理対象サーバーに対してデフォルトのSSLポート(9804)とデモ信頼を有効化します。
クライアント・マシン上に<RTD_HOME>/etc/sslディレクトリを作成し、デモ・トラストストア・ファイルがインストールされているサーバー側の場所<mw_home>/wlserver_10.3/server/lib/DemoTrust.jksから、このファイルをクライアント・マシン上の<RTD_HOME>/etc/sslにコピーします。
デシジョン・スタジオがこのトラストストア・ファイルを使用できるようにするために、<MW_HOME>/Oracle_BI1/clients/rtd/eclipse/eclipse.iniファイルを次のように編集します。
トラストストア・ファイルを指すように、-Djavax.net.ssl.trustStore行を変更します。
例:
-Djavax.net.ssl.trustStore=C:/OracleBI/RTD/etc/ssl/DemoTrust.jks
CommandLineDeployでは、java -Djavax.net.ssl.trustStore=<DemoTrust.jks> -jar deploytool.jar -deploy -sslConnection true <ILS> <username> <password> <host> <port>を実行します。
例: java -Djavax.net.ssl.trustStore=C:/OracleBI/RTD/etc/ssl/DemoTrust.jks -jar deploytool.jar -deploy -sslConnection true "C:\OracleBI\RTD\examples\CrossSell" weblogic psw dadvmh0044 9804
ロード・ジェネレータでは、スクリプト<RTD_HOME>/scripts/sdexec.cmdで次の行のコメントを解除します。
rem set TRUST_STORE_OPTS=-Djavax.net.ssl.trustStore="%SD_ROOT%\etc\ssl\sdtrust.store"
そして、TRUST_STORE_OPTS値を次の値に置換します。
-Djavax.net.ssl.trustStore=<dir-name>\DemoTrustStore.jks
例:
-Djavax.net.ssl.trustStore=c:\rtd\etc\ssl\DemoTrust.jks
バッチ・コンソールでは、java -Djavax.net.ssl.trustStore="<DemoTrust.jks>" -jar batch-console.jar -url https://<machine_name>:<SSL_port>を実行します。
例: java -Djavax.net.ssl.trustStore="c:\rtd\etc\ssl\DemoTrust.jks" -jar batch-console.jar -url https://localhost:9804
この項では、Oracle RTDに対するシングル・サインオン(SSO)認証の構成の一般的なガイドラインを示します。
Oracle Fusion MiddlewareでのSSOに関する一般情報は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Fusion Middlewareでのシングル・サインオンの概要に関する項を参照してください。
Oracle Fusion Middleware 11gでのエンタープライズレベルのSSO認証プロバイダとして、Oracle Access Managerを使用することをお薦めします。Oracle Fusion MiddlewareによるOracle Access Managerの構成と管理の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 11gでのシングル・サインオンの構成に関する項およびOracle Access Manager 10gでのシングル・サインオンの構成に関する項を参照してください。
特にOracle RTDでは、認証ポリシーおよび認可ポリシーに対して定義するリソースURLは次のとおりです。
保護リソース
/ui/*
パブリック・リソース
/ui/images/*
/ui/do/logout
/ui/ping.jsp
/ui/logged_out.jsp
他のガイドで、システム管理者が関心を持つ可能性がある次のトピックを取り上げています。表4-8にこれらのトピックをリストし、参照先のガイド名を示します。
表4-8 他のガイドで取り上げられているトピック
| トピック | ガイド名 |
|---|---|
|
インストール |
Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド |
|
Fusion Middlewareセキュリティ・フレームワーク アプリケーション・ロールの管理 |
Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド |
|
Fusion Middleware Controlの使用 |
Oracle Fusion Middleware管理者ガイド |
|
Oracle WebLogic Server管理コンソールの起動 |
Oracle Fusion Middleware Oracle WebLogic Serverの紹介 |
|
Oracle Business Intelligenceのセキュリティ |
Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド |
