Oracle® Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド 12c (12.2.1) E70043-01 |
|
前 |
この付録では、ダッシュボードと分析に対して、ユーザーが次のアクセス権のみを持つようなセキュリティの管理方法について説明します。
Oracle BIプレゼンテーション・カタログ内で自分に該当するオブジェクトへのアクセス
自分に該当する機能とタスクへのアクセス
自分に該当する保存済カスタマイズへのアクセス
この付録には次の項が含まれます:
システム管理者は、認可されたユーザーのみがシステムにアクセスして適切な操作を実行できるようにするために、すべての機能(管理機能を含む)を確実に保護するようにビジネス・インテリジェンス・システムを構成する必要があります。また、管理者は、中間層の通信をすべて保護するようにシステムを構成できる必要があります。
この概要の項の内容は次のとおりです。
プレゼンテーション・サービスのユーザーに影響するセキュリティの設定は、次のOracle Business Intelligenceコンポーネントで実行します。
Oracle BI管理ツール — 次のタスクを実行できます。
ビジネス・モデル、表、列およびサブジェクト・エリアに対する権限の設定
ユーザーごとのデータベース・アクセスの指定
ユーザーがアクセス可能なデータを制限するためのフィルタの指定
認証オプションの設定
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
Oracle BIプレゼンテーション・サービス管理 — ビューの編集、エージェントやプロンプトの作成などの機能にアクセスするための権限をユーザーに設定できます。
Oracle BIプレゼンテーション・サービス — Oracle BIプレゼンテーション・カタログのオブジェクトに対する権限を割り当てることができます。
以前のリリースでは、プレゼンテーション・サービスの管理ページでオブジェクトに対する権限を割り当てることができました。このリリースでは、カタログ・マネージャ、またはプレゼンテーション・サービスの「カタログ」ページで権限を設定します。プレゼンテーション・サービスでの権限の割当て方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』を参照してください。
カタログ・マネージャ — Oracle BIプレゼンテーション・カタログのオブジェクトに対する権限を設定できます。カタログ・マネージャの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle BIプレゼンテーション・カタログの構成と管理に関する項を参照してください。
注意: セキュリティ管理者は、BI EE Answers内のサブジェクト・エリアのセキュリティ権限を編集しないようにレポート・ユーザーに通知する必要があります。データ・セキュリティは、セキュリティ管理者によって施行される必要があります。 |
プレゼンテーション・サービスでセキュリティを保持する場合は、次の点を保証する必要があります。
プレゼンテーション・サービスにサインインしてアクセスできるのは、適切なユーザーのみです。BIサーバーを通じて、ユーザーにサインイン権限を割り当てて認証する必要があります。
認証は、ユーザー名とパスワードを使用して、ログオンしている人物を識別するプロセスです。その後、認証されたユーザーには、システム(この場合はプレゼンテーション・サービス)にアクセスするための適切な認可が与えられます。プレゼンテーション・サービスには専用の認証システムはなく、BIサーバーから継承した認証システムに依存しています。
プレゼンテーション・サービスにサインインしているすべてのユーザーに、AuthenticatedUserロールと、Fusion Middleware Controlで割り当てられたロールが付与されます。
認証の詳細は、第1.3項「認証について」を参照してください。
ユーザーは、自分に該当するオブジェクトにのみアクセスできます。『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド.』で説明されているとおり、アクセス制御はパーミッションの形式で適用します。
ユーザーは、自分に該当する機能にアクセスできます。ユーザー権限は権限の形式で適用します。たとえば、権限には、「システム全体の列書式の編集」や「エージェントの作成」などがあります。
ユーザーは特定の権限を付与されるか、または拒否されます。これらの対応付けは、第D.2.3項「プレゼンテーション・サービスの権限の管理」で説明されているとおり、権限割当て表で作成されます。
Oracle Business Intelligenceは、Webサーバーでシングル・サインオン機能を使用するように構成できます。プレゼンテーション・サービスは、エンド・ユーザーに関する情報を取得するときにこの機能を使用できます。シングル・サインオンの詳細は、第4章「SSO認証の有効化」を参照してください。
プレゼンテーション・サービスで権限を割り当てる場合は、次のいずれかの方法で割り当てることができます。
アプリケーション・ロールに - これが、推奨される権限の割当て方法です。アプリケーション・ロールによって、ユーザーとその割当ての保守が簡単になります。アプリケーション・ロールでは、システムのアイデンティティ・ストアにそのロールを持つユーザーまたはグループに付与されるパーミッションのセットが定義されます。アプリケーション・ロールは、特定の条件に応じて割り当てられます。このため、アプリケーション・ロールは、認証が発生した時点の条件に基づいて動的に付与されます。
アプリケーション・ロールの詳細は、第1.4.1項「アプリケーション・ロールについて」を参照してください。
個々のユーザーに - パーミッションと権限を特定のユーザーに付与できますが、そのような割当ての保守は難しいため、この方法は推奨されません。
カタログ・グループに - このアプローチは非推奨であり、以前のリリースとの下位互換性を保つためにのみ用意されています。
カタログ・グループの詳細は、第D.2.2項「カタログ・グループの使用」を参照してください。
Oracle BIプレゼンテーション・サービスの管理ページを使用して、次の各項で説明されるタスクを実行できます。
メインの管理ページにはリンクが含まれていて、そこから、プレゼンテーション・サービスでユーザーに関連付けられた機能など、様々な機能を実行するための他の管理ページを表示できます。右上隅の「ヘルプ」ボタンをクリックすると、これらのすべてのページに関する情報を取得できます。
注意: 複数のユーザーが管理ページへのアクセス権を持っている場合は、他のユーザーの変更を上書きしてしまう可能性があるため注意してください。UserAとUserBの両方がプレゼンテーション・サービス管理の「権限の管理」ページにアクセスして変更しているとします。ユーザーBが権限を編集している間にユーザーAが同じ権限の更新を保存した場合、ユーザーBの変更内容は、ユーザーAが保存した変更内容によって上書きされてしまいます。 |
カタログ・グループは引き続き使用できますが、ユーザーを編成するには、カタログ・グループではなくアプリケーション・ロールの使用に移行することをお薦めします。詳細は、「アプリケーション・ロールへのカタログ・グループの移行」を参照してください。
以前のリリースでは、カタログ・グループが、ユーザーを編成するために使用されていました。カタログ・グループのメンバーシップは、明示的割当てと継承のいずれかによってユーザーに関連付けられた権限を判別するために使用されました。このリリースでは、カタログ・グループは、次の特性を備えています。
カタログ・グループと呼ばれる
ユーザー、アプリケーション・ロールまたはその他のカタログ・グループを含めることができる
以前のグループとの互換性を維持する目的で、プレゼンテーション・サービスにのみ存在する
専用のパスワードはなくなった
プレゼンテーション・サービス管理者は、カタログ・グループの名前として、Oracle BIプレゼンテーション・サービスにログインするために使用されたユーザーIDとは異なる名前を使用する必要があります。ユーザーIDとカタログ・グループが同じ名前の場合、Oracle BIプレゼンテーション・サービスにログインしようとすると、無効なアカウントであることを示すメッセージを受け取ります。
この項には次のトピックが含まれます:
カタログ・グループは以前のリリースのように引き続き機能しますが、今後のリリースではサポートされません。今すぐカタログ・グループをアプリケーション・ロールに移行することをお薦めします。カタログ・グループをアプリケーション・ロールに移行した後、カタログから手動で削除する必要があります。
この項では、カタログからアプリケーション・ロールにカタログ・グループを移行する方法およびカタログから削除する方法について説明します。
カタログ・グループを移行する前に、次に一致するレポートを実行します。
現在のカタログ・グループおよびそのメンバー。
カタログ・グループを参照する権限。
カタログ・グループを使用または参照するカタログ・パス。
カタログ・グループ・レポートを生成するには:
カタログ・グループおよびメンバーシップ情報を決定します。
次のコマンドを入力します。
runcat.cmd | runcat.sh -cmd report -offline <catalog path> -outputFile <output file> -type "Accounts" -accounts "group;;*" -fields "Account Name:Group Members" [-jaznFormat] [-excludeJaznHeader] [-expandGroups]
プレーン・テキストまたはJazn形式のカタログ・グループおよび各グループ内の関連付けられたメンバーのリストを生成します。
説明:
jaznFormat
Jazn形式の出力ファイルを生成します(既存のグループから変換される新しいロールをインポートするために使用されます)。
excludeJaznHeader
コンテンツを既存のJaznファイルに挿入できるように、ヘッダーなしでJaznファイルを生成します。
expandGroups
子カタログ・グループのメンバーを展開およびリストするか、アプリケーション・ロール名のみリストします。
プレゼンテーション・サービスの「権限の管理」ページに保存される権限に使用するカタログ・グループを決定します(第2.6.3項「アプリケーション・ロールに対するプレゼンテーション・サービスの権限の設定」を参照)。
次のコマンドを入力します。
runcat.cmd | runcat.sh -cmd report -offline <catalog path> -outputFile <output file> -folder /system/privs -type "Security ACL" -accountsInPrivilege "group;;*" -fields "Path:Privilege"
カタログ・グループを参照する権限のリストを生成します。
カタログ・グループの参照を含むカタログ・オブジェクトのパスを決定します。
次のコマンドを入力します。
runcat.cmd | runcat.sh -cmd report -offline <catalog path> -outputFile <output file> -type "All" -accountsInACL "group;;*" -fields "Path:ACL"
カタログ・グループを使用または参照するカタログ・パスのリストを生成します。
この項では、アプリケーション・ロールにカタログ・グループを移行する方法について説明します。
注意: カタログ・グループはアプリケーション・ロールと異なり親から権限を継承できるため、カタログ・グループとアプリケーション・ロール間の直接的なマッピングはありません。 |
セキュリティの相違の確認
グループがアプリケーション・ロールに置き換えられる場合に発生する可能性がある動作の違いの詳細は、次の項を確認してください。
カタログ・オブジェクトに1つ以上のカタログ・グループが含まれる場合、グループからロールへの自動変換はエラーが発生しやすく、手動の介入が必要になる場合があります。移行中にすべての潜在的なセキュリティの相違を確認してログに記録し、潜在的なセキュリティの問題のためにさらに調査する必要があるカタログ・オブジェクトを推奨します。
カタログ・グループをアプリケーション・ロールに移行するには:
次のページから最上位レベルのカタログ・フォルダを確認します。
例:
http://example.com:9402/analytics/saw.dll?Admin
プレゼンテーション・サービスを停止し、次に移動します。
DOMAIN_HOME/bitools/bin/
たとえば、UNIXでは次のコマンドを実行します。
./stop.sh
移行の変更を取り消すことができないため、カタログをバックアップします。
tarまたはzipなどのツールを使用します。
カタログ・グループをアプリケーション・ロールに移行し、グループをJaznファイル形式にエクスポートします。
オプションで、新しいアプリケーション・ロールの先頭に'_GRP2ROLE_'を付けるかどうかを制御します。
次のコマンドを入力します。
runcat.cmd/runcat.sh -cmd migrateWebcatGroupsToApproles -offline<catalog path> -outputFile <output JAZN File> [-noGroupPrefix]
新しいロールをインポートするために使用するJaznファイルを生成します。
アップグレード中にカタログ・グループを削除し、アプリケーション・ロールで置き換えます。
-noGroupPrefixを指定しないかぎり、新しいアプリケーション・ロールに接頭辞を付けます。
注意: 移行ログ・ファイルでは、次のように移行中にセキュリティの相違を強調表示できます。複数のカタログ・グループが親/子関係を持つ場合、詳細な調査と手動の介入が必要な可能性があるオブジェクトとしてフラグが付けられます。セキュリティの相違がある可能性があるオブジェクトのORACLE_HOME/user_projects/domains/bi/servers/obips1/logs/ migratewebcatgroups_<timestamp>.logファイルを参照してください。ファイル形式は親/子関係を持つグループ名の<Object path>です。 |
11gから12cに移行する場合、このタスクを使用します。
11gから12cに移行中にカタログ・グループをアプリケーション・ロールに移行するには:
プレゼンテーション・サービスを停止します。
移行の変更を取り消すことができないため、このコマンドを実行する前にカタログをバックアップします。
tarまたはzipなどのツールを使用します。
カタログ・グループおよびメンバーシップ情報を決定します。
次のコマンドを入力します。
runcat.cmd | runcat.sh -cmd report -offline <catalog path> -outputFile <output file> -type "Accounts" -accounts "group;;*" -fields "Account Name:Group Members" [-jaznFormat] [-excludeJaznHeader] [-expandGroups] [-noGroupPrefix]
プレーン・テキストまたはJazn形式のカタログ・グループおよび各グループ内の関連付けられたメンバーのリストを生成します。
説明:
jaznFormat
Jazn形式の出力ファイルを生成します(既存のグループから変換される新しいロールをインポートするために使用されます)。
excludeJaznHeader
コンテンツを既存のJaznファイルに挿入できるように、ヘッダーなしでJaznファイルを生成します。
expandGroups
子カタログ・グループのメンバーを展開およびリストするか、アプリケーション・ロール名のみリストします。
noGroupPrefix
-noGroupPrefixを指定しないかぎり、新しいアプリケーション・ロールに接頭辞を付けます。
カタログ・グループをアプリケーション・ロールに移行します(11gから12cにアップグレード中)。
次のコマンドを入力します。
runcat.cmd/runcat.sh -cmd upgradeCatalog -offline<catalog path> [-migrateGroups <withPrefix | noPrefix>]
オプションで、アップグレード中にカタログ・グループを削除し、アプリケーション・ロールで置き換えます。
オプションで、新しく置き換えられたアプリケーション・ロールが接頭辞を使用するかどうかを決定します。
手順3「カタログ・グループおよびメンバーシップ情報を決定します。」で作成したJaznファイルをセキュリティ・システムにインポートします。
リリース12.2.1以降で新しいカタログ・グループを作成しないことを強くお薦めします。
カタログ・グループは以前のリリースのように引き続き機能しますが、今後のリリースではサポートされません。今すぐカタログ・グループをアプリケーション・ロールに移行することをお薦めします。カタログ・グループをアプリケーション・ロールに移行した後、各オブジェクトに移動し、右クリックしてカタログ・グループを手動で削除する必要があります。
カタログ・グループを作成するには:
プレゼンテーション・サービスの「ホーム」ページで「管理」を選択します。
「カタログ・グループの管理」リンクをクリックします。
「新規カタログ・グループの作成」をクリックします。
「グループの追加」ダイアログで、グループの名前を入力します。
シャトル制御を使用して、このグループに含めるカタログ・グループ、ユーザーおよびアプリケーション・ロールを選択します。
ヒント: グループの継承と維持が複雑にならないようにするため、カタログ・グループにはアプリケーション・ロールを含めないことをお薦めします。特に、AuthenticatedUserロールは、作成した他のカタログ・グループに追加しないでください。これにより、ユーザーまたは認証されたユーザーが意図せずに別のカタログ・グループから権限を継承できないようにすることで、目的のカタログ・グループ(およびユーザー)のみが、指定した権限を持つようになります。 |
「OK」をクリックします。
カタログ・グループを削除するには:
これはグループを削除するだけで、権限および他のカタログ・オブジェクトの内部参照は削除されません。
プレゼンテーション・サービスの「ホーム」ページで「管理」を選択します。
「カタログ・グループの管理」リンクをクリックします。
「カタログ・グループの管理」ページで、削除するグループを1つ以上選択します。
目的のグループを見つけるには、「名前」フィールドにテキストを入力し、「検索」をクリックします。
「選択したグループの削除」をクリックします。
「OK」をクリックして、削除を確定します。
カタログ・グループを編集するには:
プレゼンテーション・サービスの「ホーム」ページで「管理」を選択します。
「カタログ・グループの管理」リンクをクリックします。
「カタログ・グループの管理」ページで編集するグループを選択します。
目的のグループを見つけるには、「名前」フィールドにテキストを入力し、「検索」をクリックします。
「他のグループ」ボタンをクリックすると、次の25個のグループがリストに表示されます。
「グループの編集」ダイアログで、名前の変更、またはアプリケーション・ロール、カタログ・グループおよびユーザーの追加や削除を行います。
「OK」をクリックします。
この項では、プレゼンテーション・サービスの権限について説明します。内容は次のとおりです。
プレゼンテーション・サービスの権限は、プレゼンテーション・サービスの機能にアクセスするためにユーザーが保持する権利を制御します。権限は、権限割当て表を使用して、特定のアプリケーション・ロール、個々のユーザーおよびカタログ・グループに対して付与または拒否されます。
パーミッションと同様に、権限は、明示的に設定されるか、またはロールやグループ・メンバーシップを通じて継承されます。権限の明示的な拒否は、付与され継承されたいかなる権限より優先されます。たとえば、列計算式を編集する権限へのアクセスを明示的に拒否されたユーザーが、その権限を継承しているアプリケーション・ロールのメンバーである場合、そのユーザーは列計算式を編集できません。
最も一般的に権限が付与されるロールは、BIContentAuthorまたはBIConsumerです。これにより、ユーザーはプレゼンテーション・サービスの共通の機能にアクセスできます。引き続き、カタログ・グループにも権限を付与できますが、アプリケーション・ロールへの付与に切り替えることをお薦めします。
プレゼンテーション・サービス管理の「権限の管理」ページから、プレゼンテーション・サービスの権限を、アプリケーション・ロール、個々のユーザーおよびカタログ・グループに対して設定できます。
詳細は、第2.6.3項「アプリケーション・ロールに対するPresentation Servicesの権限の設定」を参照してください。
表D-1には、管理可能な権限と、デフォルトでその権限へのアクセス権が付与されているアプリケーション・ロールが一覧表示されています。詳細については、参照リンクも表に示されています。
これらの権限は、Oracle Business Intelligenceインフラストラクチャに適用されます。組織がビルトイン・アプリケーションを使用している場合は、いくつかの権限が事前に構成されている場合があります。詳細は、アプリケーションのドキュメントを参照してください。
注意: KPIおよびKPIウォッチリストを構築する際、またはOracle Scorecard and Strategy Management内では、特定のタスクを実行するのに、特定の権限セットが必要になる場合があります。第D.2.3.3.4項「KPI、KPIウォッチリストおよびスコアカード用の権限の識別」を参照してください。 |
注意: Oracle BI EE接続にSmartViewからログインするために必要なBIプレゼンテーション・サービス権限は、次のとおりです(詳細は、表D-1を参照してください)。
「共有カタログ」フォルダを開くアクセス権も必要です。 |
表D-1 Oracle Business Intelligenceインフラストラクチャの権限とデフォルト設定
「アクション」権限を設定する必要があります。この権限は、ユーザーがアクション機能を使用できるかどうかを決定し、どのユーザー・タイプがアクションを作成できるかを指定します。次のリストで、これらの権限を説明します。
ナビゲート・アクションの作成 — どのユーザーがナビゲート・アクション・タイプを作成できるかを決定します。この権限が拒否されたユーザーのセッションには、ナビゲート・アクションの作成が可能なユーザー・インタフェース・コンポーネントは一切含まれません。たとえば、この権限が拒否されたユーザーが、Oracle BI Enterprise Editionグローバル・ヘッダーからアクションの作成を選択すると、ユーザーがアクション・タイプを選択するダイアログに「ナビゲート・アクション」オプションは含まれません(「BIコンテンツに移動」、「Webページに移動」など)。ただし、この権限が拒否されたユーザーは、保存済アクションを分析およびダッシュボードに追加することはできます。さらに、この権限が拒否されたユーザーは、アクションを含む分析またはダッシュボードからアクションを実行することができます。
起動アクションの作成 — どのユーザーが起動アクション・タイプを作成できるかを決定します。この権限が拒否されたユーザーのセッションには、起動アクションの作成が可能なユーザー・インタフェース・コンポーネントは一切含まれません。たとえば、この権限が拒否されたユーザーが、エージェント・エディタの「アクション」タブを選択し「新規アクションの追加」ボタンをクリックすると、ユーザーがアクション・タイプを選択するダイアログに「起動アクション」オプションは含まれません(「Webサービスの起動」、「HTTPリクエストの起動」など)。ただし、この権限が拒否されたユーザーは、保存済アクションを分析およびダッシュボードに追加することはできます。さらに、この権限が拒否されたユーザーは、アクションを含む分析またはダッシュボードからアクションを実行することができます。
埋込みHTMLが含まれるアクションの保存 — どのユーザーがWebサービス・アクション結果のカスタマイズにHTMLコードを埋め込むことができるかを決定します。この権限を割り当てると、ユーザーによるHTMLコードの実行が可能になりセキュリティ上のリスクが発生するため、注意が必要です。
「Oracle BI for Microsoft Officeへのアクセス」権限があると、Oracle BI EEの「ホーム」ページの「はじめに」エリアにある「BIデスクトップ・ツールのダウンロード」リンクに、次のオプションが表示されます。
Oracle BI for MS Office: Oracle BI Add-in for Microsoft Officeのインストール・ファイルをダウンロードします。
「Oracle BI for Microsoft Officeへのアクセス」権限は、分析の「コピー」リンクの表示には影響しません。このリンクは、常にそこで使用可能です。
Oracle BI for Microsoft Office用にダウンロードするインストール・ファイルの場所は、デフォルトで、instanceconfig.xmlファイルのBIforOfficeURL要素に指定されています。Oracle BI for Microsoft Officeと「コピー」オプションの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』を参照してください。
デフォルトでは、プレゼンテーション・サービスはクロスサイト・スクリプティング(XSS)から保護されています。XSSから保護するために、プレゼンテーション・サービスのフィールドへの入力をエスケープし、それをプレーン・テキストとして表示します。たとえば、保護不可能なユーザーがHTMLフィールドを使用して、ページからデータを盗むスクリプトを入力する場合があります。
デフォルトでは、エンド・ユーザーは、HTMLとしてフラグ付けされたコンテンツを保存できません。かわりに、「HTMLマークアップを含むコンテンツの保存」権限を持つ管理者だけが、HTMLコードを含むコンテンツを保存できます。「HTMLマークアップを含むコンテンツの保存」権限を持つユーザーは、fmap接頭辞の付いたイメージを保存できます。この権限が割り当てられていないユーザーが、fmap接頭辞の付いたイメージを保存しようとすると、エラー・メッセージが表示されます。
また、この権限を持つユーザーは、Oracle Scorecard and Strategy Managementにミッション・ステートメントとビジョン・ステートメントを保存できます。
KPIおよびKPIウォッチリストを構築する際、またはOracle Scorecard and Strategy Management内では(スコアカードの表示、作成、所有者への問合せなど)、特定のタスクを実行するのに、通常、特定の権限セットが必要になります。表D-2、表D-3および表D-4には、KPI、KPIウォッチリストおよびOracle Scorecard and Strategy Managementに関する次の情報がそれぞれ含まれています。
タスク・オブジェクト(アクション・リンク、KPIチャートなど)
タスク(ダッシュボードからの所有者への連絡や、スコアカード・エディタでのリンクの使用など)
タスクを実行するのに必要とされる権限(「デリバー - エージェントの作成」、「アクセス - ダッシュボードへのアクセス」など)。特定のタスクを実行するには、これらの各権限が必要になります。
これらのタスクを実行するのに必要な権限は、できるだけセットとしてグループ化し、セット名と(各権限名ではなく)、その他必要な権限があれば、それを加えています。セット名と、各セットに含まれる権限は次のとおりです。
Edit_scorecard_set1
含まれる権限:
アクセス - スコアカードへのアクセス
スコアカード - スコアカードの作成/編集
View_or_edit_scorecard_set2
含まれる権限:
アクセス - スコアカードへのアクセス
スコアカード - スコアカードの作成/編集またはスコアカード - スコアカードの表示
View_KPI_watchlist_on_dashboard_set3
含まれる権限:
アクセス - ダッシュボードへのアクセス
アクセス - スコアカードへのアクセス
Edit_KPI_with_KPI_Builder_set4
含まれる権限:
アクセス - KPI Builderへのアクセス
スコアカード - KPIの作成/編集
サブジェクト・エリア - <サブジェクト・エリア名>
Edit_KPI_watchlist_with_standalone_KPI_watchlist_editor_set5
含まれる権限:
アクセス - KPI Builderへのアクセス
スコアカード - KPIの作成/編集
View_KPI_watchlist_in_standalone_KPI_watchlist_editor_set6
含まれる権限:
アクセス - スコアカードへのアクセス
スコアカード - スコアカードの作成/編集またはスコアカード - スコアカードの表示
表D-2には、KPIタスクに必要な権限セットを示します。
表D-2 KPIタスクに必要な権限
タスク・オブジェクト | タスク | タスクを実行するために必要な権限 |
---|---|---|
アクション・リンク |
KPIエディタ1・タブを使用した、スコアカード・エディタ内でのKPIの作成、編集、削除 |
|
アクション・リンク |
KPIエディタ内部からの作成、編集、削除 |
|
エージェント |
スコアカード・エディタ内でのKPIのエージェントの作成 |
|
ビジネス所有者 |
KPIエディタ・タブを使用したスコアカード・エディタ内での変更 |
|
ビジネス所有者 |
KPIエディタ内での変更 |
|
KPI |
KPIエディタ・タブを使用した、スコアカード・エディタ内での作成または編集 |
KPIを作成する先のフォルダに対する読取り/書込み権限と、全祖先ディレクトリへの少なくとも読取り権限は持っている必要があります。 |
KPI |
KPIエディタ内部からの作成、編集、表示 KPIエディタには読取り専用モードはありません。 |
KPIを作成する先のフォルダに対する読取り/書込み権限と、全祖先ディレクトリへの少なくとも読取り権限は持っている必要があります。 |
KPI |
開いて、Oracle BI EEのホーム・ページ、お気に入りリストまたはカタログ・ブラウザからアンサー分析を表示 |
必要なアクセス、スコアカードまたはサブジェクト・エリアの特定の権限は必要ありません。 |
KPIディメンション・ターゲット値(ターゲット設定) |
ダッシュボード上のKPIウォッチリスト内での編集 |
|
KPIディメンション・ターゲット値(ターゲット設定) |
ダッシュボード上のスコアカード・ビュー2内での編集 |
|
関連ドキュメント |
KPIエディタ内部からの関連ドキュメントの追加、編集、削除 |
|
関連ドキュメント |
KPIエディタ・タブを使用した、スコアカード・エディタ内での関連ドキュメントの追加、編集、削除 |
|
表D-3には、KPIウォッチリスト・タスクに必要な権限セットを示します。
表D-3 KPIウォッチリスト・タスクに必要な権限
タスク・オブジェクト | タスク | タスクを実行するために必要な権限 |
---|---|---|
<デバイス>(たとえば、電子メール、ページャ、デジタル電話など) |
ダッシュボード上のKPIウォッチリストからの所有者への連絡 |
|
<デバイス> |
スタンドアロンKPIウォッチリスト・エディタ3内部からの所有者への連絡 |
|
アクション・リンク |
ダッシュボード上のKPIウォッチリストからの起動 |
ブラウザでポップアップを有効にしている必要があります。 |
アクション・リンク |
スタンドアロンKPIウォッチリスト・エディタ内部からの起動 |
|
分析リンク |
ダッシュボード上のKPIウォッチリスト・ビューからの分析リンクの使用 |
ブラウザでポップアップを有効にしている必要があります。 |
分析リンク |
スタンドアロンKPIウォッチリスト・エディタ内部からの分析リンクの使用 |
ブラウザでポップアップを有効にしている必要があります。 |
注釈 |
ダッシュボード上のKPIウォッチリストからの追加 |
|
注釈 |
スタンドアロンKPIウォッチリスト・エディタ内部からの追加 |
|
注釈 |
ダッシュボード上のKPIウォッチリストからの表示 |
|
注釈 |
スタンドアロンKPIウォッチリスト・エディタ内部からの表示 |
|
ビジネス所有者 |
スタンドアロンKPIウォッチリスト・エディタ内部からのKPIウォッチリストのビジネス所有者の変更 |
|
ビジネス所有者 |
スタンドアロンKPIウォッチリスト・エディタ内部からのKPIウォッチリスト内のビジネス所有者の表示 |
|
KPIチャート |
ダッシュボード上のKPIウォッチリストからのKPIチャートの表示 |
|
KPIチャート |
スタンドアロンKPIウォッチリスト・エディタ内部からのKPIチャートの表示 |
|
KPIディメンション・ターゲット値(ターゲット設定) |
スコアカード・エディタ内でのKPIウォッチリストのKPIディメンション・ターゲット値の編集 |
|
KPIディメンション・ターゲット値(ターゲット設定) |
スタンドアロンKPIウォッチリスト・エディタ内部からのKPIウォッチリストのKPIディメンション・ターゲット値の編集 |
|
KPIウォッチリスト |
ダッシュボードへの追加 |
|
KPIウォッチリスト |
スコアカード・エディタ内での作成または編集 |
|
KPIウォッチリスト |
スタンドアロンKPIウォッチリスト・エディタ内部からの作成または編集 |
KPIウォッチリストを作成する先のフォルダに対する読取り/書込み権限と、全祖先ディレクトリへの少なくとも読取り権限は持っている必要があります。 |
KPIウォッチリスト |
スタンドアロンKPIウォッチリスト・エディタ内部からの読取り専用表示 |
|
KPIウォッチリスト |
ダッシュボードでの表示 |
|
関連ドキュメント |
スタンドアロンKPIウォッチリスト・エディタ内部からの関連ドキュメント・リンクの使用 |
|
関連ドキュメント |
スタンドアロンKPIウォッチリスト・エディタ内部からの関連ドキュメントの追加、編集、削除 |
|
関連ドキュメント |
KPIウォッチリスト関連ドキュメントの追加、編集、削除 |
|
表D-4には、スコアカードおよびスコアカード・オブジェクトのタスクに必要な権限セットを示します。
表D-4 スコアカードおよびスコアカード・オブジェクトのタスクに必要な権限
タスク・オブジェクト | タスク | タスクを実行するために必要な権限 |
---|---|---|
<デバイス>(たとえば、電子メール、ページャ、デジタル電話など) |
ダッシュボード上のスコアカード・ビュー内の所有者への連絡 |
|
<デバイス> |
スコアカード・エディタ内の所有者への連絡 |
|
アクション・リンク |
ダッシュボード上のスコアカード・ビュー内での起動 |
ブラウザでポップアップを有効にしている必要があります。 |
アクション・リンク |
スコアカード・エディタ内での起動 |
|
「戦略」ペインまたは「イニシアティブ」ペイン内のオブジェクトのアクション・リンク |
スコアカード・エディタ内での作成、編集、削除 |
|
すべてのスコアカード・ノード4、ビュー、ドキュメント(KPIエディタは除外) |
スコアカード・エディタ内での読取り専用表示 |
|
分析リンク |
ダッシュボード上のスコアカード・ビューでの分析リンクの使用 |
ブラウザでポップアップを有効にしている必要があります。 |
分析リンク |
スコアカード・エディタでの分析リンクの使用 |
ブラウザでポップアップを有効にしている必要があります。 |
注釈 |
ダッシュボード上のスコアカード・ビュー内での追加 |
|
注釈 |
スコアカード・エディタ内のスコアカード・ビューでの追加 |
|
注釈 |
ダッシュボード上のスコアカード・ビューでの表示 |
|
注釈 |
スコアカード・エディタ内での表示 |
|
ビジネス所有者 |
スコアカード・エディタ内での変更 |
|
ビジネス所有者 |
スコアカード・エディタ内での表示 |
|
因果関係 |
スコアカード・エディタ内での作成、編集、削除 |
|
スコアカード・ノードのディメンション・ステータス・オーバーライド |
ダッシュボード上のスコアカード・ビューからのKPIディメンション・ステータスのオーバーライド(またはオーバーライドのキャンセル) |
KPIエディタで設定されているステータスをオーバーライドするには、KPIのビジネス所有者である必要もあります。 |
スコアカード・ノードのディメンション・ステータス・オーバーライド |
スコアカード・エディタ内でのKPIディメンション・ステータスのオーバーライド(またはオーバーライドのキャンセル) |
KPIエディタで設定されているステータスをオーバーライドするには、KPIのビジネス所有者である必要もあります。 |
スコアカード・ノードのディメンション・ステータス・オーバーライド |
ダッシュボード上のスコアカード・ビューでのKPIディメンション・ステータスの表示 |
|
スコアカード・ノードのディメンション・ステータス・オーバーライド |
スコアカード・エディタ内のスコアカード・ビューでのKPIディメンション・ステータスの表示 |
|
フィルタ |
スコアカード・エディタ内でのスコアカード・スマート・ウォッチリストのフィルタへのユーザーの追加 |
|
フィルタ |
ダッシュボード上のスコアカード・スマート・ウォッチリストでのユーザーのフィルタ処理 |
|
フィルタ |
スコアカード・エディタ内のスコアカード・スマート・ウォッチリストでのユーザーのフィルタ処理 |
|
イニシアティブ・ノード5 |
「イニシアティブ」タブまたはKPI詳細タブを使用したスコアカード・エディタ内での作成、編集、削除 |
|
KPIチャート |
ダッシュボード上のスコアカード・ビューでの表示 |
|
KPIチャート |
スコアカード・エディタ内での表示 |
|
ミッション・ステートメントまたはビジョン・ステートメント |
スコアカード・エディタ内での作成または編集 |
|
「権限」ダイアログ |
スコアカード・エディタ内での変更 |
|
パースペクティブ |
スコアカード・エディタ内での作成、編集、削除 |
|
関連ドキュメント |
スコアカード・エディタ内のスコアカード・ノードまたはスコアカード・ビューに対する追加、編集、削除 |
|
関連ドキュメント |
スコアカード・エディタでの関連ドキュメント・リンクの使用 |
|
スコアカード |
作成 |
スコアカード・フォルダに対する読取り/書込み権限と、全祖先ディレクトリへの少なくとも読取り権限は持っている必要があります。 |
スコアカード |
スコアカード・エディタを使用した編集 |
スコアカード・フォルダに対する読取り/書込み権限と、全祖先ディレクトリへの少なくとも読取り権限は持っている必要があります。 |
スコアカード・ビュー |
ダッシュボードへの追加 |
|
スコアカード・ビュー(ミッション・ステートメント、ビジョン・ステートメントおよびKPIウォッチリストは除外) |
スコアカード・エディタ内での作成、編集、削除 |
|
スコアカード・ビュー |
ダッシュボードでの表示 |
|
「設定」ダイアログ |
設定の変更(または表示) |
|
戦略ノード6 |
「目標」タブまたはKPI詳細タブを使用したスコアカード・エディタ内での作成、編集、削除 |
|
KPIエディタはKPI Builderとも呼ばれます。
スコアカード・ビュー(スコアカードのドキュメントとも呼ばれます)は、次の条件を満たすOracle BI EEカタログ・オブジェクトです。
スコアカード・エディタの「スコアカードのドキュメント」ペインを表示する。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』を参照してください。
それが作成された特定のスコアカードに関連付けられているか、ここでのみ編集できる。
スコアカードの戦略およびイニシアティブ情報を表示する。
次のビュー・タイプで構成されている。
原因と結果マップ
カスタム・ビュー
ミッション・ステートメント
スマート・ウォッチリスト
戦略マップ
戦略ツリー
戦略貢献ホイール
ビジョン・ステートメント
スタンドアロンKPIウォッチリスト・エディタは、スコアカード・エディタ外部で使用されるKPIウォッチリスト・エディタです。つまり、スコアカード・エディタ・タブに組み込まれていません。
スコアカード・ノードは、スコアカードの戦略ペイン・ツリーまたはイニシアティブ・ペイン・ツリーに属する目標またはイニシアティブか、これらのペイン内のイニシアティブまたは目標に属するKPIです。
イニシアティブ・ノードは、「イニシアティブ」ペイン内のイニシアティブまたはKPIです。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』を参照してください。
戦略ノードは、「戦略」ペイン内の目標またはKPIです。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』を参照してください。
プレゼンテーション・サービス管理の「セッション管理」ページを使用して、アクティブ・ユーザーと実行中の分析に関する情報の表示、リクエストの取消し、キャッシュの消去を実行できます。
プレゼンテーション・サービスでセッションを管理するには:
プレゼンテーション・サービスの「ホーム」ページで「管理」を選択します。
「セッション管理」リンクをクリックします。
「セッション管理」画面が表示され、次の表が示されます。
セッション表。ログインしているユーザーに対して作成されているセッションに関する情報を示します。
カーソル・キャッシュ表。分析のステータスを表示します。
実行中のリクエストをすべて取り消すには:
「実行中のリクエストの取消し」をクリックします。
「終了」をクリックします。
実行中の分析を1つ取り消すには:
カーソル・キャッシュ表で分析を識別し、「アクション」列で「取消」リンクをクリックします。
ユーザーは、分析が管理者によって取り消されたことを示すメッセージを受け取ります。
Webキャッシュをクリアするには:
カーソル・キャッシュ表で分析を識別し、「すべてのカーソルを閉じる」をクリックします。
「終了」をクリックします。
分析に関連付けられたキャッシュ・エントリをクリアするには:
カーソル・キャッシュ表で分析を識別し、「アクション」列で「閉じる」リンクをクリックします。
分析に関する情報の問合せファイルを表示するには:
カーソル・キャッシュ表で、分析を識別し、「ログの表示」リンクをクリックします。
注意: このログ・ファイルにデータを保存する場合は、問合せログをオンにする必要があります。 |
Oracle BIプレゼンテーション・サービスの権限およびOracle BIプレゼンテーション・サービス・カタログ項目のパーミッションでは、アクセス・コントロール・リスト(ACL)を使用して、プレゼンテーション・サービスの機能にアクセスする権限をどのユーザーが保持し、プレゼンテーション・サービス・カタログ項目に対して特定のユーザーがどの権限を保持するかを制御します。権限は、Oracle BIプレゼンテーション・サービスの「管理」ページを使用して設定します。パーミッションは、「分析」ユーザー・インタフェースまたは「カタログ・マネージャ」ユーザー・インタフェースを使用してプレゼンテーション・サービス・カタログのオブジェクトに設定します。
プレゼンテーション・サービスの機能にアクセスしようとすると、適切な権限がチェックされます。たとえば、Oracle Business Intelligenceのページを表示するには、アンサーへのアクセス権限が必要です。また、プレゼンテーション・サービス・カタログ項目に対してアクションを実行しようとすると、その項目のパーミッションがチェックされます。たとえば、Oracle Business Intelligenceの項目を表示するには、読取りアクセス権を持っているかどうか確認するために項目のパーミッションがチェックされます。
ACLに追加できるレコードには次の3タイプがあります。
個々のユーザーのレコード
個々のユーザーのレコードを管理するのは、特にユーザーが数千人いたりカタログ項目が数十万ある場合、難しいことです。
10gカタログ・グループのレコード
カタログ・グループは、単に下位互換性のために存在し、お薦めしません。それらを使用するかわりに、アプリケーション・ロールを使用するように変更してください。
11gアプリケーション・ロールのレコード
これらは、ACLを管理する方法としてお薦めします。
Oracle Business Intelligenceでは、3タイプのレコードを順にチェックしてユーザー・アクセスを判別します。ユーザーの有効な権限またはパーミッションを推定するには、ACLレコードを使用してユーザーの明示的レコードを探し(ある場合)、ユーザーが直接的または間接的にメンバーであるカタログ・グループのレコードを探し、明示的または暗黙的にユーザーに付与されているアプリケーション・ロールのレコードを探します。
この項には次のトピックが含まれます:
次のタスクでは、ユーザーの有効な権限およびパーミッションを判別するために実行される順次チェックについて説明します。
注意: ステップ1はステップ2に、ステップ2はステップ3に、ステップ3はステップ4に、ステップ4はステップ5にそれぞれ優先します。 |
注意: 個々のステップでは、「拒否」の権限ACLレコードは常に、他の権限付与に優先します。同様に、個々のステップでは、「アクセス権なし」のパーミッションACLレコードは常に、他のアクセス権付与に優先します。意味的に、権限「拒否」はパーミッション「アクセス権なし」と同じであるため、「拒否」という用語は権限とパーミッションの両方に対して同じ意味で使用します。 |
次のシーケンスは、ユーザー・レコードについて実行されるチェックを示しています。
該当ユーザーの明示的レコードが存在する場合は、そのアクセス権を返します。これで完了です。
該当ユーザーの明示的レコードが存在しない場合は、タスク2 - 該当ユーザーのカタログ・グループに対するレコードの有無チェック(10gとの下位互換性のためだけの非推奨の動作)に移動します。
次のシーケンスは、ユーザーのカタログ・グループについて実行されるチェックを示しています。
該当ユーザーが直接的、明示的に属するすべてのカタログ・グループのセットを取得します。
このセットには、該当ユーザーが暗黙的に属するカタログ・グループは含まれません。
このセットには次のものが含まれます。
プレゼンテーション・サービスの「管理」ページを使用して割り当てられたカタログ・グループ
WEBGROUPS BIセッション変数を使用して割り当てられたカタログ・グループ
メンバーとしてのアプリケーション・ロールを持つ、つまり該当ユーザーにそのアプリケーション・ロールが(明示的または暗黙的に)付与されているカタログ・グループ
注意: この機能は当初、すべてのカタログ・グループのアプリケーション・ロールへの即時変換を強制するのではなく、10gカタログ・グループの11gアプリケーション・ロールへの移行を支援するために提供されました。 |
次のようにして、カタログ・グループの現行セットのいずれかと一致するACLレコードがないかチェックします。
アクセスを拒否するレコードが存在する場合、アクセス拒否を返します。これで完了です。
それ以外で、アクセス権を付与するレコードが存在する場合、そのアクセス権付与すべての論理和を返します。たとえば、あるカタログ・グループが読取りアクセス権を持っていて、別のカタログ・グループが書込みアクセス権を持っていた場合、ユーザーは読取りアクセス権および書込みアクセス権を持っています。これで完了です。
それ以外の場合、カタログ・グループの現行セットと一致するレコードはありません。
カタログ・グループの現行セットの全カタログ・グループの親セットを取得します。つまり、カタログ・グループの現行セット自体が明示的にメンバーであるカタログ・グループをすべて取得します。この親セットが新たに、カタログ・グループの現行セットとなります。
親セットが空でない場合、次のようにして、カタログ・グループの現行セットのいずれかと一致するACLレコードがないかチェックします。に戻ります。
このようにして、明示的カタログ・グループが暗黙的カタログ・グループに優先(オーバーライド)します。
同様に、暗黙的"親"カタログ・グループが暗黙的"祖父母"カタログ・グループに優先し、暗黙的"祖父母"カタログ・グループが暗黙的"曽祖父母"カタログ・グループに優先するといったようになります。
注意: カタログ・グループのパーミッションの継承ロジックは、アプリケーション・ロールのパーミッションの継承ロジックとは異なります。 |
それ以外の場合、該当ユーザーのカタログ・グループにはレコードがありませんでした。タスク3 - 該当ユーザーのアプリケーション・ロールに対するレコードの有無チェックに移動します。
次のシーケンスは、ユーザーのアプリケーション・ロールについて実行されるチェックを示しています。
直接的、明示的アプリケーション・ロールと間接的、暗黙的アプリケーション・ロールの両方を含め、該当ユーザーのアプリケーション・ロールをすべて取得します。
たとえば、ユーザーにBI作成者アプリケーション・ロールが明示的に付与されている場合、ユーザーはBIコンシューマ・アプリケーション・ロールも暗黙的に持っています。
アプリケーション・ロール・セットのいずれかと一致するACLレコードがないかチェックします。
いずれかのレコードがアクセスを拒否する場合、アクセス拒否を返します。これで完了です。
それ以外で、いずれかのレコードがアクセス権を付与する場合、そのアクセス権付与すべての論理和を返します。したがって、あるアプリケーション・ロールが読取りアクセス権を持っていて、別のアプリケーション・ロールが書込みアクセス権を持っていた場合、ユーザーは読取りアクセス権と書込みアクセス権を持っています。これで完了です。
それ以外の場合、該当ユーザーのアプリケーション・ロールにはレコードがありません。
それ以外の場合、該当ユーザーのアプリケーション・ロールにはレコードがありませでした。タスク4 - デフォルト動作への戻しに移動します。
次のシーケンスは、「認証済ユーザー」という特別なアプリケーション・ロールについて実行されるチェックを示しています。
「認証済ユーザー」アプリケーション・ロールのレコードが存在する場合、そのレコードのアクセス権を返します。これで完了です。
注意: 「認証済ユーザー」アプリケーション・ロールは、厳密には該当ユーザーがこのアプリケーション・ロールも持っていても、タスク3 - 該当ユーザーのアプリケーション・ロールに対するレコードの有無チェックのユーザーのアプリケーション・ロールのリストに意図的に除外されています。 |
それ以外の場合、この特別なアプリケーション・ロールにはレコードがありません。タスク5 - 一致レコード一切なしに移動します。
アクセス拒否を返します。これで完了です。
図D-1に、アプリケーション・ロールによる権限の判別方法の例を示します。図の一番上にUser1のラベルが付いた四角形があり、User1にアプリケーション・ロール「エグゼクティブ」と「BI作成者」が明示的に付与されていることを示しています。User1の四角形の下には、四角形がさらに2つ接続されていて、左側が「エグゼクティブ」ロール、右側が「BI作成者」ロールを表しています。
「エグゼクティブ」ロールの四角形は、「エグゼクティブ」が「管理へのアクセス」権限を付与されていて、アプリケーション・ロール「財務」および「販売」が「エグゼクティブ」に付与されていることを示しています。
「BI作成者」ロールの四角形は、「BI作成者」が「カタログ」権限を付与され、「エージェント」権限を拒否されていて、アプリケーション・ロール「BIコンシューマ」が「BI作成者」に付与されていることを示しています。
「エグゼクティブ」ロールの四角形の下には、四角形がさらに2つ接続されていて、左側が「財務」ロール、右側が「販売」ロールを表しています。
「財務」ロールの四角形は、「財務」ロールが「スコアカード」権限を付与されていることを示しています。
「販売」ロールの四角形は、「販売」が「管理へのアクセス」権限を拒否され、「アンサーへのアクセス」権限を付与されていることを示しています。
最後に、「BI作成者」ロールの四角形の下に1つの四角形が接続されていて、この四角形が「BIコンシューマ」ロールを表しています。
「BIコンシューマ」ロールの四角形は、「BIコンシューマ」が「カタログ」権限を付与され、「エージェント」権限を付与されていることを示しています。
この例の内容は次のとおりです。
User1は明示的に「エグゼクティブ」ロールを持っているため、暗黙的に「財務」ロールと「販売」ロールも持っています。
また、User1は明示的に「BI作成者」ロールを持っているため、暗黙的に「BIコンシューマ」ロールも持っています。
したがって、User1のアプリケーション・ロールの扁平リストは、エグゼクティブ、BI作成者、財務、販売およびBIコンシューマとなります。
「エグゼクティブ」ロールの有効な権限は、拒否された「管理」権限、付与された「スコアカード」権限および付与された「アンサー」権限です。「販売」の拒否された「管理」権限は、常に拒否が優先されるため、「エグゼクティブ」の付与された権限に優先します。
「BI作成者」ロールの有効な権限は、付与された「カタログ」権限および拒否された「エージェント」権限です。「BI作成者」の拒否された「エージェント」権限は、常に拒否が優先されるため、「BIコンシューマ」の付与された権限に優先します。
User1に付与された権限は、全体で次のようになります。
拒否された「管理」権限(「販売」に対してこの権限が明確に拒否されているため)。
付与された「スコアカード」権限。
付与された「アンサー」権限。
付与された「カタログ」権限。
拒否された「エージェント」権限(「BI作成者」に対してこの権限が明確に拒否されているため)。
図D-2に、アプリケーション・ロールによるパーミッションの判別方法の例を示します。図の一番上にUser1のラベルが付いた四角形があり、User1にアプリケーション・ロール「エグゼクティブ」と「BI作成者」が明示的に付与されていることを示しています。User1の四角形の下には、四角形がさらに2つ接続されていて、左側が「エグゼクティブ」ロール、右側が「BI作成者」ロールを表しています。
「エグゼクティブ」ロールの四角形は、「エグゼクティブ」にDashboardAに対してアクセス権がなく、アプリケーション・ロール「財務」および「販売」が「エグゼクティブ」に付与されていることを示しています。
「BI作成者」ロールの四角形は、「BI作成者」ロールがDashboardDに対して開くアクセス権を持ち、DashboardEに対してアクセス権がなく、「BIコンシューマ」ロールが「BI作成者」に付与されていることを示しています。
「エグゼクティブ」ロールの四角形の下には、四角形がさらに2つ接続されていて、左側が「財務」ロール、右側が「販売」ロールを表しています。
「財務」ロールの四角形は、「財務」ロールがDashboardBに対して開くアクセス権を持っていることを示しています。
「販売」ロールの四角形は、「販売」ロールがDashboardAに対してアクセス権がなく、DashboardCに対してフル・コントロールを持っていることを示しています。
最後に、「BI作成者」ロールの四角形の下に1つの四角形が接続されていて、この四角形が「BIコンシューマ」ロールを表しています。
「BIコンシューマ」ロールの四角形は、「BIコンシューマ」ロールがDashboardDに対して変更アクセス権を、DashboardEに対して開くアクセス権を持っていることを示しています。
この例の内容は次のとおりです。
User1は明示的に「エグゼクティブ」ロールを持っているため、暗黙的に「財務」ロールと「販売」ロールも持っています。
また、User1は明示的に「BI作成者」ロールを持っているため、暗黙的に「BIコンシューマ」ロールも持っています。
したがって、User1のアプリケーション・ロールの扁平リストは、エグゼクティブ、BI作成者、財務、販売およびBIコンシューマとなります。
「エグゼクティブ」ロールの有効なパーミッションは、DashboardAに対するアクセス権なし、DashboardBに対する開くアクセス権、DashboardCに対するフル・コントロールです。「販売」ロールのDashboardAに対するアクセス権なしは、常に拒否が優先されるため、「エグゼクティブ」ロールの開くアクセス権に優先します。
「BI作成者」ロールの有効なパーミッションは、DashboardDに対する開くアクセス権および変更アクセス権、DashboardEに対するアクセス権なしです。「BI作成者」ロールのDashboardEに対するアクセス権なしは、常に拒否が優先されるため、「BIコンシューマ」ロールの開くアクセス権に優先します。
User1に付与された権限は、全体で次のようになります。
DashboardAに対するアクセス権なし(「販売」ロールに対してアクセス権が明確に拒否されているため)。
DashboardBに対する開くアクセス権。
DashboardCに対するフル・コントロール。
DashboardDに対する開くアクセス権と変更アクセス権(「BI作成者」ロールと「BIコンシューマ」ロールのアクセス権の論理和)。
DashboardEに対するアクセス権なし(「BI作成者」ロールに対してアクセス権が明確に拒否されているため)。
図D-3に、カタログ・グループによる権限の判別方法の例を示します。図の一番上にUser1のラベルが付いた四角形があり、User1がマネージャ・グループおよびカナダ・グループというカタログ・グループの明示的メンバーであることを示しています。User1の四角形の下には、四角形がさらに2つ接続されていて、左側がマネージャ・グループ、右側がカナダ・グループを表しています。
マネージャ・グループの四角形は、マネージャ・グループが「管理へのアクセス」権限を付与されていて、マネージャ・グループ自体がマーケティング・グループと販売グループの両方のメンバーであることを示しています。
カナダ・グループの四角形は、カナダ・グループが「カタログ」権限を付与され、「エージェント」権限を拒否されていて、カナダ・グループ自体がアメリカ・グループのメンバーであることを示しています。
マネージャ・グループの四角形の下には、四角形がさらに2つ接続されていて、左側がマーケティング・グループ、右側が販売グループを表しています。
マーケティング・グループの四角形は、マーケティング・グループが「スコアカード」権限を付与されていることを示しています。
販売グループの四角形は、販売グループが「管理へのアクセス」権限を拒否され、「アンサーへのアクセス」権限を付与されていることを示しています。
最後に、カナダ・グループの四角形の下に1つの四角形が接続されていて、この四角形がアメリカ・グループを表しています。
アメリカ・グループの四角形は、アメリカ・グループが「カタログ」権限を付与され、「エージェント」権限を付与されていることを示しています。
この例の内容は次のとおりです。
User1は明示的にマネージャ・グループに属しているため、暗黙的にマーケティング・グループと販売グループにも属しています。
また、User1は明示的にカナダ・グループに属しているため、暗黙的にアメリカ・グループにも属しています。
したがって、User1のカタログ・グループの初期リストは、マネージャ・グループとカナダ・グループとなります。必要な場合、User1のカタログ・グループの親リストは、マーケティング・グループ、販売グループおよびアメリカ・グループとなります。カタログ・グループの祖父母リストは、カタログ・グループ階層の深さが2レベルのみであるため、空です。
マネージャ・グループの有効な権限は、付与された「管理」権限、付与された「スコアカード」権限、および付与された「アンサー」権限です。マネージャ・グループの「管理」に対する明示的レコードは、常に近い方の祖先カタログ・グループが遠い方の祖先カタログ・グループに優先するため、販売グループの暗黙的レコードに優先します。
カナダ・グループの有効な権限は、付与された「カタログ」権限と、拒否された「エージェント」権限です。カナダ・グループの「カタログ」と「エージェント」の両方に対する明示的レコードは、常に近い方の祖先カタログ・グループが遠い方の祖先カタログ・グループに優先するため、アメリカ・グループの暗黙的レコードに優先します。
User1に付与された権限は、全体で次のようになります。
付与された「管理へのアクセス」権限(マネージャ・グループが販売グループに優先するため)。
付与された「スコアカード」権限。
付与された「アンサー」権限。
付与された「カタログ」権限(カナダ・グループがアメリカ・グループに優先するため)。
拒否された「エージェント」権限(カナダ・グループがアメリカ・グループに優先するため)。
図D-4に、カタログ・グループによるパーミッションの判別方法の例を示します。図の一番上にUser1のラベルが付いた四角形があり、User1がマネージャ・グループおよびカナダ・グループというカタログ・グループの明示的メンバーであることを示しています。User1の四角形の下には、四角形がさらに2つ接続されていて、左側がマネージャ・グループ、右側がカナダ・グループを表しています。
マネージャ・グループの四角形は、マネージャ・グループがDashboardAに対して開くアクセス権を持っていて、マネージャ・グループ自体がマーケティング・グループと販売グループの両方のメンバーであることを示しています。
カナダ・グループの四角形は、カナダ・グループがDashboardDに対して開くアクセス権を持ち、DashboardEに対してアクセス権がなく、カナダ・グループ自体がアメリカ・グループのメンバーであることを示しています。
マネージャ・グループの四角形の下には、四角形がさらに2つ接続されていて、左側がマーケティング・グループ、右側が販売グループを表しています。
マーケティング・グループの四角形は、マーケティング・グループがDashboardBに対して開くアクセス権を持っていることを示しています。
販売グループの四角形は、販売グループがDashboardCに対してフル・コントロールを持ち、DashboardAに対してアクセス権がないことを示しています。
最後に、カナダ・グループの四角形の下に1つの四角形が接続されていて、この四角形がアメリカ・グループを表しています。
アメリカ・グループの四角形は、アメリカ・グループがDashboardDに対して変更アクセス権を、DashboardEに対して開くアクセス権を持っていることを示しています。
この例の内容は次のとおりです。
User1は明示的にマネージャ・グループに属しているため、暗黙的にマーケティング・グループと販売グループにも属しています。
また、User1は明示的にカナダ・グループに属しているため、暗黙的にアメリカ・グループにも属しています。
したがって、User1のカタログ・グループの初期リストは、マネージャ・グループとカナダ・グループとなります。必要な場合、User1のカタログ・グループの親リストは、マーケティング・グループ、販売グループおよびアメリカ・グループとなります。カタログ・グループの祖父母リストは、カタログ・グループ階層の深さが2レベルのみであるため、空です。
マネージャ・グループの有効なパーミッションは、DashboardAに対する開くアクセス権、DashboardBに対する開くアクセス権、DashboardCに対するフル・コントロールです。マネージャ・グループのDashboardAに対する明示的レコードは、常に近い方の祖先カタログ・グループが遠い方の祖先カタログ・グループに優先するため、販売グループの暗黙的レコードに優先します。
カナダ・グループの有効なパーミッションは、DashboardDに対する開くアクセス権、DashboardEに対するアクセス権なしです。カナダ・グループのDashboardDとDashboardEの両方に対する明示的レコードは、常に近い方の祖先カタログ・グループが遠い方の祖先カタログ・グループに優先するため、アメリカ・グループの暗黙的レコードに優先します。
User1に付与された権限は、全体で次のようになります。
DashboardAに対する開くアクセス権(マネージャ・グループが販売グループに優先するため)。
DashboardBに対する開くアクセス権。
DashboardCに対するフル・コントロール。
DashboardDに対する開くアクセス権(カナダ・グループがアメリカ・グループに優先するため)。
DashboardEに対するアクセス権なし(カナダ・グループがアメリカ・グループに優先するため)。
この項では、ユーザーへの共有ダッシュボードの提供について説明します。内容は次のとおりです。
Oracle BIプレゼンテーション・カタログには、次の2つのメイン・フォルダがあります。
「マイ・フォルダ」 — 個々のユーザーの個人用ストレージが含まれます。計算された項目やグループなどのオブジェクトを保存する「サブジェクト・エリアのコンテンツ」フォルダが含まれます。
「共有フォルダ」 — ユーザー間で共有されるオブジェクトやフォルダが含まれます。ユーザー間で共有されるダッシュボードは、/「共有フォルダ」フォルダの下にある共通サブフォルダの下の「ダッシュボード」サブフォルダに保存されます。
注意: Oracle BIプレゼンテーション・カタログの分析に対する権限がユーザーに付与されていても、ユーザーが権限を持たないサブジェクト・エリアをこの分析が参照している場合、BIサーバーではこのユーザーは分析を実行できません。 |
Oracle BIプレゼンテーション・カタログをセットアップし、権限を設定した後、他のユーザーが使用できるように、共有ダッシュボードとコンテンツを作成できます。
共有ダッシュボードを作成するメリットの1つは、共有ダッシュボード内で作成するページが再利用できる点です。ユーザーは、共有ダッシュボードのページや自分で作成した新しいページを使用して専用のダッシュボードを作成できます。『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド.』で説明されているとおり、ページとコンテンツを追加できます。
複数のユーザーにデフォルトの共有ダッシュボードの変更を許可する予定の場合は、これらのユーザーをアプリケーション・ロールに入れることを検討してください。たとえば、Salesというアプリケーション・ロールとSalesHomeというデフォルトのダッシュボードを作成するとします。Salesアプリケーション・ロールを割り当てたユーザー40人のうち、SalesHomeダッシュボードのコンテンツの作成/変更権限が必要なユーザーは3人です。最初のSalesアプリケーション・ロールと同じ権限を持つSalesAdminアプリケーション・ロールを作成します。SalesHomeダッシュボードとコンテンツの変更が許可されたユーザー3人を、この新しいSalesAdminアプリケーション・ロールに追加し、Oracle BIプレゼンテーション・カタログで、該当する権限をこのロールに付与します。これにより、この3人のユーザーは、SalesHomeダッシュボードのコンテンツの作成と変更が許可されます。ダッシュボードのコンテンツの変更権限がユーザーに不要になった場合は、そのユーザーのロール割当てをSalesに変更できます。既存のSalesロール・ユーザーにダッシュボードのコンテンツの作成権限が必要になった場合は、そのユーザーのロール割当てをSalesAdminに変更できます。
共有ダッシュボードの作成の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のダッシュボードの管理に関する項を参照してください。
ユーザー・コミュニティにダッシュボードとコンテンツをリリースする前に、いくつかのテストを実行します。
ダッシュボードをテストするには:
適切な権限を持つユーザーが目的のコンテンツに正しくアクセスして表示していることを確認します。
適切な権限を持たないユーザーがダッシュボードにアクセスできないことを確認します。
スタイルとスキンが予想どおりに表示され、その他のビジュアル要素も予想どおりであることを確認します。
問題を検出した場合は修正して再テストします。満足する結果が得られるまで、このプロセスを繰り返します。
テストが完了した後、ダッシュボードが使用可能であることをユーザー・コミュニティに通知し、関連するネットワーク・アドレスを確実に提供します。
この項では、保存済カスタマイズの概要と、保存済カスタマイズの管理に関する情報について説明します。内容は次のとおりです。
保存済カスタマイズを使用すると、最もよく使用するアイテムや好みのアイテム(フィルタ、プロンプト、列のソート、分析でのドリル、セクションの展開と縮小など)を使用した現在の状態でダッシュボード・ページを保存し、後で表示できます。カスタマイズを保存することで、ユーザーは、ダッシュボード・ページにアクセスするたびにこれらを手動で選択する必要がなくなります。
適切な権限とダッシュボードのアクセス権を持つユーザーとグループは、次のアクティビティを行えます。
個人で使用するため、あるいは他のユーザーが使用するために、様々な選択の組合せを保存済カスタマイズとして保存します。
個人で使用するため、あるいは他のユーザーが使用するために、保存済カスタマイズをダッシュボード・ページのデフォルト・カスタマイズに指定します。
保存済カスタマイズを切り替えます。
この動作は次の方法で制限できます。
ユーザーは、割り当てられた保存済カスタマイズのみを表示できます。
ユーザーは、個人で使用する目的でのみカスタマイズを保存できます。
ユーザーは、個人使用および他のユーザーによる使用を目的としてカスタマイズを保存できます。
ダッシュボードのエンド・ユーザーと保存済カスタマイズの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』を参照してください。
この項では、保存済カスタマイズの管理に必要な権限について説明します。また、Oracle BIプレゼンテーション・カタログにおいて、保存済カスタマイズの格納と管理に関連する部分についても説明します。
Oracle BIプレゼンテーション・サービス管理で、ダッシュボード・エリアの次の権限と、主要なダッシュボード要素の権限設定によって、ユーザーまたはグループがカスタマイズを保存または割当てできるかどうかが制御されます。
カスタマイズの保存
デフォルト・カスタマイズの割当て
必要なアクセス・レベルに応じて、ユーザーまたはグループにどちらも割り当てないか、一方の権限または両方の権限を割り当てることができます。たとえば、どちらの権限も持たないユーザーは、デフォルト・カスタマイズとして割り当てられている保存済カスタマイズのみを表示できます。
この項では、ダッシュボード・ページの保存済カスタマイズを管理するためにユーザーに必要なパーミッションと、共有および個人用の保存済カスタマイズにパーミッションを設定するためのOracle BIプレゼンテーション・カタログ構造の関連部分について説明します。
Oracle BI EEの「権限」ダイアログで、「フル・コントロール」や「アクセス権なし」などのパーミッションをダッシュボートとページに設定します。これらのパーミッションは、カタログ内の他のオブジェクトにも同じ方法で割り当てます。
特定のダッシュボード・ページの保存済カスタマイズを操作するためのパーミッションは、ダッシュボード・ビルダーで使用可能な「ダッシュボードのプロパティ」ダイアログで設定します。このダイアログのリストでページを選択した後、次のいずれかのボタンをクリックします。
「共有のカスタマイズを保存できるユーザーの指定」は、誰がダッシュボード・ページの共有カスタマイズを保存できるかを指定する「権限」ダイアログを表示します。
「デフォルト・カスタマイズを割り当てることができるユーザーの指定」は、誰がダッシュボード・ページのデフォルト・カスタマイズを割り当てることができるかを指定する「権限」ダイアログを表示します。
次の項で、カタログ・オブジェクトとパーミッション・シナリオについて説明します。
ユーザーおよびグループの保存済カスタマイズに対する制御レベルは、Oracle BIプレゼンテーション・サービス管理で設定した権限に加え、主要な要素へのアクセス権にも依存します。たとえば、ユーザーとグループが、基礎となるダッシュボードの作成と編集、ダッシュボード・ビュー・プリファレンスのカスタマイズとしての保存、およびデフォルト・カスタマイズとしてのカスタマイズの他のユーザーへの割当てを実行できるようにするには、共有ストレージ内の主要要素へのフル・コントロール・パーミッションが必要です。一方、ユーザーとグループが、割り当てられたデフォルト保存済カスタマイズのみを表示できるようにするには、共有ストレージ内の主要要素への表示アクセス権のみが必要です。
カタログ内の主要要素には、次のフォルダが含まれます。
「共有記憶域」フォルダ
ダッシュボードの「共有記憶域」フォルダは、通常、親共有フォルダの「ダッシュボード」サブフォルダ内にあります。ダッシュボードは割り当てられた名前によって識別されます。ダッシュボードは、Oracle BIプレゼンテーション・カタログ内の任意の場所に保存できます。ダッシュボードを「ダッシュボード」というサブフォルダに保存すると、グローバル・ヘッダーの「ダッシュボード」リンクから表示されるダッシュボードのリストにそのダッシュボードの名前が表示されます。
パーミッション設定は、特定のダッシュボードを編集するためのアクセスを制御します。通常、パーミッションが_selectionsおよび「ダッシュボード」サブフォルダに継承される場合、ダッシュボードを編集可能なユーザーは、カスタマイズの保存とデフォルトの設定も可能です。特定のダッシュボード・フォルダへのアクセス権によって、ユーザーまたはグループがダッシュボードを編集できるかどうかが制御されます。
_selectionsフォルダには、ダッシュボード・ページごとに1つずつページ識別子のフォルダが含まれます。共有保存済カスタマイズはこのフォルダ内に存在します。ページ識別子のフォルダへのアクセス権によって、ユーザーまたはグループがそのページのカスタマイズを表示、保存または編集できるかどうかが制御されます。
_selectionsフォルダ内の_defaultsフォルダには、割り当てられたデフォルト・カスタマイズが含まれます。デフォルトが割り当てられている各グループがここに表示されます。このフォルダへのアクセス権によって、ユーザーまたはグループがデフォルトを割当てできるかどうかが制御されます。
「個人用ストレージ」フォルダ
ユーザーの個人用フォルダでは、_selectionsフォルダに個々のユーザーの保存済カスタマイズが含まれます。共有の_selectionsフォルダと同様に、個人用の_selectionsフォルダにも、各ダッシュボード・ページのページ識別子のフォルダが含まれます。ページ識別子のフォルダには、個人用の保存済カスタマイズと、個人用のデフォルト・カスタマイズのユーザーのプリファレンスを指定する_defaultlinkファイルが含まれます。
個人用の保存済カスタマイズのデフォルトは、割り当てられた共有カスタマイズのデフォルトをオーバーライドします。
注意: 保存済カスタマイズを持つダッシュボード・ページが削除された場合は、保存済カスタマイズもカタログから削除されます。基礎となるダッシュボード構成を変更した場合は(それ以降、ユーザーのアクセス時には保存済カスタマイズを無効にするなど)、デフォルトのコンテンツがダッシュボードに表示されます。 |
表D-5は、保存済カスタマイズを作成するためにユーザーに付与可能な典型的なユーザー・ロールと特定の権限設定について説明しています。「権限の設定」列に一覧表示されているフォルダ名は、前の項で説明されています。
表D-5 保存済カスタマイズのユーザー・ロールと権限設定
ユーザー・ロール | 権限の設定 |
---|---|
ITユーザーなど、次のタスクを実行する必要があるパワー・ユーザー
|
カタログの「共有」セクションで、次のフォルダにフル・コントロール・パーミッションが必要です。
通常は、追加の権限を割り当てる必要はありません。 |
管理者など、次のタスクを実行する必要がある技術ユーザー
ユーザーは、基礎となるダッシュボードを作成または編集したり、デフォルト・カスタマイズとしてビュー・カスタマイズを他のユーザーに割り当てることはできません。 |
カタログの「共有」セクションで、次のフォルダに表示パーミッションが必要です。
カタログの「共有」セクションで、次のフォルダに変更権限が必要です。
通常は、追加の権限を割り当てる必要はありません。 |
個人使用を目的にカスタマイズを保存する必要がある通常のユーザー |
Oracle BIプレゼンテーション・サービス管理で、次の権限が設定されている必要があります。
ダッシュボード・ページで、次のオプションが設定されている必要があります。
カタログでは通常、追加権限の設定は不要です。 |
割り当てられたデフォルト・カスタマイズのみの表示を必要とするカジュアル・ユーザー |
カタログの「共有」セクションで、次のフォルダに表示権限が必要です。
カタログでは通常、追加権限の設定は不要です。 |
設定された権限と付与された権限に応じて、保存済カスタマイズを作成、割当て、使用するためのユーザー権限およびグループ権限の様々な組合せを実現できます。
たとえば、パワー・ユーザーのグループは、本番環境ではダッシュボードを変更できませんが、保存済カスタマイズを作成し、それらをデフォルト・カスタマイズとして他のユーザーに割り当てることは許可されているものとします。このグループには次の権限設定が必要です。
ダッシュボードへの開くアクセス権。「カタログ」ページを使用します。
Oracle BIプレゼンテーション・カタログのダッシュボード・フォルダ内のサブフォルダ_selectionsおよび_defaultsへの変更アクセス権。ダッシュボード・ビルダーの「ダッシュボードのプロパティ」ダイアログを使用して割り当てます。ダイアログのリストでページを選択した後、「共有のカスタマイズを保存できるユーザーの指定」および「デフォルト・カスタマイズを割り当てることができるユーザーの指定」をクリックします。
この項では、他のユーザーの代理実行の有効化について説明します。内容は次のとおりです。
Oracle BIプレゼンテーション・サービスでは、あるユーザーが別のユーザーの代理で実行できます。ユーザー(プロキシ・ユーザーと呼ばれる)が別のユーザー(ターゲット・ユーザーと呼ばれる)の代理で実行する場合、プロキシ・ユーザーは、ターゲット・ユーザーが権限を持つカタログ内のオブジェクトにアクセスできます。
別のユーザーの代理実行を有効化すると、管理者が自分の業務の一部を直属の部下に委任する場合や、ITサポート・スタッフが別のユーザーのオブジェクトの問題をトラブルシューティングする場合などに役立ちます。
ユーザーが他のユーザーによる代理実行を可能にする方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』を参照してください。
ユーザーをプロキシ・ユーザーとして有効にした場合は、認可レベル(プロキシ・レベルと呼ばれる)も割り当てます。プロキシ・レベルは、ターゲット・ユーザーのカタログ・オブジェクトにアクセスするときに、プロキシ・ユーザーに付与されるパーミッションと権限を決定します。次のリストは、プロキシ・レベルを説明しています。
制限付き — パーミッションは、ターゲット・ユーザーがアクセス権を持つオブジェクトに対する読取り専用です。権限は、(ターゲット・ユーザーのアカウントではなく)プロキシ・ユーザーのアカウントによって決まります。
たとえば、プロキシ・ユーザーにはアンサーへのアクセス権限が割り当てられておらず、ターゲット・ユーザーには割り当てられているとします。プロキシ・ユーザーがターゲット・ユーザーとして実行するときに、ターゲット・ユーザーはアンサーにアクセスできません。
フル — パーミッションと権限はターゲット・ユーザーのアカウントから継承されます。
たとえば、プロキシ・ユーザーにはアンサーへのアクセス権限が割り当てられておらず、ターゲット・ユーザーには割り当てられているとします。プロキシ・ユーザーがターゲット・ユーザーとして実行するときに、ターゲット・ユーザーはアンサーにアクセスできます。
ユーザーがプロキシ・ユーザーとして動作できるようにし、そのユーザーに代理として実行権限が設定されている場合は、プレゼンテーション・サービスのグローバル・ヘッダーに「別ユーザーとして実行」オプションを表示し、代理実行するターゲット・ユーザーを選択できます。
ヒント: プロキシ・ユーザーがターゲット・ユーザーとして操作を実行するには、事前に、ターゲット・ユーザーが少なくとも一度はプレゼンテーション・サービスにサインインしてダッシュボードにアクセスしている必要があります。 |
注意: プロキシ・ユーザーが偽装できるユーザーの場合は、そのユーザーの代理として実行できるパーミッションを持ったユーザーを参照できます。これらのユーザーを表示するには、Oracle Business Intelligenceにログインして、「マイ・アカウント」ダイアログ・ボックスに移動し、「ユーザーに委任」タブを表示します。このタブに、代理で接続可能なユーザーと、代理で接続したときに保持するパーミッション(「制限付き」または「フル」)が表示されます。 |
他のユーザーの代理実行を可能にするには、次のタスクを実行します。
プロキシ・ユーザーとターゲット・ユーザーの関連付けをデータベース内で定義します。そのためには、プロキシ・ユーザー/ターゲット・ユーザーの関連付けごとに、次の項目を指定します。
プロキシ・ユーザーのID
ターゲット・ユーザーのID
プロキシ・レベル(フルと制限付きのどちらか)
たとえば、次のようなProxiesという表をデータベース内に作成するとします。
proxyId | targetId | proxyLevel |
---|---|---|
Ronald | Eduardo | フル |
Timothy | Tracy | 制限付き |
Pavel | Natalie | フル |
William | Sonal | 制限付き |
Maria | Imran | 制限付き |
プロキシ・ユーザーとターゲット・ユーザーの関連付けを定義した後、そのスキーマをBIサーバーの物理レイヤーにインポートする必要があります。スキーマのインポート方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
プロキシ・ユーザーを認証するには、関連付けられた初期化ブロックとともに、次の2つのセッション変数を作成する必要があります。どちらの変数の場合も、データベースのスキーマに従ってサンプルのSQL文を変更する必要があります。
PROXY — この変数は、プロキシ・ユーザーの名前を格納するために使用します。
ProxyBlockという初期化ブロックを使用し、次のようなコードを含めます。
select targetId
from Proxies
where UPPER(targetid) = UPPER('VALUEOF(NQ_SESSION.RUNAS)')
and UPPER(proxyid) = UPPER('VALUEOF(NQ_SESSION.RUNASORIGUSER)')
PROXYLEVEL — このオプションの変数は、制限付きとフルのいずれかのプロキシ・レベルを格納するために使用します。PROXYLEVEL変数を作成しない場合は、制限付きレベルが想定されます。
ProxyLevelという初期化ブロックを使用し、次のようなコードを含めます。
select proxyLevel
from Proxies
where UPPER(targetid) = UPPER('VALUEOF(NQ_SESSION.RUNAS)')
and UPPER(proxyid) = UPPER('VALUEOF(NQ_SESSION.RUNASORIGUSER)')
セッション変数の作成方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
instanceconfig.xmlファイルの様々な要素を使用して、プロキシ機能を構成します。
この手順を開始する前に、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』で、テキスト・エディタを使用したOracle Business Intelligence構成設定の更新に関する項に記載されている情報を十分に理解してください。
プロキシ機能を手動で構成するには:
『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の構成ファイルの場所に関する項で説明されているように、instanceconfig.xmlファイルを開いて編集します。
次のリストで説明されている要素を追加する必要のあるセクションを見つけます。
LogonParam: TemplateMessageName要素およびMaxValues要素の親要素として機能します。
TemplateMessageName: プロキシ・ユーザーとターゲット・ユーザーの表示に関連するタスクを実行するSQL文を含む、Custom Messagesフォルダ内のカスタム・メッセージ・テンプレートの名前を指定します。デフォルト名は、LogonParamSQLTemplateです。
TemplateMessageName要素で指定する名前は、カスタム・メッセージ・ファイル内のWebMessage要素で指定する名前と一致している必要があります。詳細は、第D.6.3.4項「プロキシ機能のカスタム・メッセージ・テンプレートの作成」を参照してください。
MaxValues: 「別ユーザーとして実行」ダイアログの「ユーザー」ボックスにリストするターゲット・ユーザーの最大数を指定します。プロキシ・ユーザーのターゲット・ユーザー数がこの値を上回ると、ターゲット・ユーザーのリストではなく、プロキシ・ユーザーがターゲット・ユーザーのIDを入力できる編集ボックスが表示されます。デフォルトは200です。
次の例に示すように、必要に応じて、要素とそれらの祖先要素を含めます。
<LogonParam><TemplateMessageName>LogonParamSQLTemplate</TemplateMessageName>
<MaxValues>100</MaxValues>
</LogonParam>
変更内容を保存し、ファイルを閉じます。
Oracle Business Intelligenceを再起動します。
次のタスクを実行するSQL文を含む、プロキシ機能のカスタム・メッセージ・テンプレートを作成する必要があります。
プロキシ・ユーザーが代理実行できるターゲット・ユーザーのリストを取得します。このリストは、「別ユーザーとして実行」ダイアログ・ボックスの「ユーザー」ボックスに表示されます。
プロキシ・ユーザーが、ターゲット・ユーザーとして実行できるかどうかを確認します。
ターゲット・ユーザーとして実行可能なプロキシ・ユーザーのリストを取得します。このリストは、ターゲット・ユーザーの「マイ・アカウント」画面に表示されます。
カスタム・メッセージ・テンプレートで、次のXML要素のこの情報を取得するためのSQL文を入力します。
要素 | 説明 |
---|---|
getValues | ターゲット・ユーザーおよび対応するプロキシ・レベルのリストを返すSQL文を指定します。
SQL文は次の1つまたは2つの列を返す必要があります。
|
verifyValue | 現在のユーザーが、指定されたターゲット・ユーザーとして実行できるかどうかを確認するSQL文を指定します。
このSQL文は、ターゲット・ユーザーが有効な場合は1つ以上の行を返し、ターゲット・ユーザーが無効な場合は空の表を返す必要があります。 |
getDelegateUsers | 現在のユーザーとして実行できるプロキシ・ユーザーおよび対応するプロキシ・レベルのリストを取得するためのSQL文を指定します。
SQL文は次の1つまたは2つの列を返す必要があります。
|
カスタム・メッセージ・テンプレートは、次のファイルのいずれかに作成できます。
ディレクトリ内のオリジナルのカスタム・メッセージ・ファイル
ディレクトリ内の別のXMLファイル
カスタム・メッセージ・テンプレートを作成するには:
オリジナルのカスタム・メッセージ・ファイルにカスタム・メッセージ・テンプレートを作成するには:
別のディレクトリに、オリジナルのカスタム・メッセージ・ファイルのバックアップを作成します。
別のディレクトリに開発用コピーを作成して、テキスト・エディタまたはXMLエディタで開きます。
個別のXMLファイルにカスタム・メッセージ・テンプレートを作成するには、BI_DOMAIN/bidata/components/OBIPS/customMessagesディレクトリにファイルを作成して開きます。
また、WebLogic Server上でアプリケーションとしてフォルダ(customMessagesなど)を構成して、Oracle BIプレゼンテーション・サービスに認識させる必要があります。詳細は、次の場所からアクセスできるOracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプのアプリケーションとモジュールのインストールに関する項を参照してください。
http://docs.oracle.com/cd/E23943_01/apirefs.1111/e13952/taskhelp/deployment/InstallApplicationsAndModules.html
WebMessage要素の開始タグと終了タグを追加してカスタム・メッセージ・テンプレートを開始します。例:
<WebMessage name="LogonParamSQLTemplate"> </WebMessage>
注意: WebMessage要素で指定する名前は、stanceconfig.xmlファイル内のTemplateMessageName要素で指定する名前と一致している必要があります。詳細は、第D.6.3.3項「プロキシ機能の構成ファイルの設定の変更」を参照してください。 |
</WebMessage>タグに続けて、次のようにします。
<XML>タグと</XML>タグを追加します。
<XML>タグと</XML>タグの間に、<logonParam name="RUNAS">タグと</logonParam>タグを追加します。
<logonParam name="RUNAS">タグと</logonParam>タグの間に、次のタグとそれぞれに対応するSQL文を一緒に追加します。
<getValues>と</getValues>
<verifyValue>と</verifyValue>
<getDelegateUsers>と</getDelegateUsers>
次のエントリは例です。
<?xml version="1.0" encoding="utf-8" ?> <WebMessageTables xmlns:sawm="com.example.analytics.web.messageSystem"> <WebMessageTable system="SecurityTemplates" table="Messages"> <WebMessage name="LogonParamSQLTemplate"> <XML> <logonParam name="RUNAS"> <getValues>EXECUTE PHYSICAL CONNECTION POOL "01 - Sample App Data (ORCL)"."Sample Relational Connection" select targetId from SAMP_USERS_PROXIES where proxyId='@{USERID}'</getValues> <verifyValue>EXECUTE PHYSICAL CONNECTION POOL "01 - Sample App Data (ORCL)"."Sample Relational Connection" select targetId from SAMP_USERS_PROXIES where proxyId='@{USERID}' and targetId='@{VALUE}'</verifyValue> <getDelegateUsers>EXECUTE PHYSICAL CONNECTION POOL "01 - Sample App Data (ORCL)"."Sample Relational Connection" select proxyId, proxyLevel from SAMP_USERS_PROXIES where targetId='@{USERID}'</getDelegateUsers> </logonParam> </XML> </WebMessage> </WebMessageTable> </WebMessageTables>
例のSQL文はデータベースのスキーマに従って変更する必要がある点に注意してください。例では、データベースと接続プールはどちらもProxyという名前で、proxyIdはPROXYER、targetIdはTARGETです。
オリジナル・ファイルの開発用コピーでカスタム・メッセージ・テンプレートを作成した場合は、customMessagesディレクトリ内のオリジナル・ファイルを、新たに編集したファイルで置き換えます。
新しいファイルをテストします。
(オプション)オリジナル・ファイルの開発用コピーでカスタム・メッセージ・テンプレートを作成した場合は、バックアップ・コピーと開発用コピーを削除します。
サーバーを再起動するか、「プレゼンテーション・サービス管理」画面の「ファイルとメタデータの再ロード」リンクをクリックして、カスタム・メッセージ・テンプレートをロードします。「管理」ページの詳細は、第D.2.1項 「管理」ページについてを参照してください。
プロキシ・ユーザーとして有効にするユーザーごとに、またはプロキシ・ユーザーとして有効にするメンバーが属するアプリケーション・ロールまたはカタログ・グループごとに、「代理として実行」権限を付与する必要があります。権限の割当て方法の詳細は、第D.2.3.2項「アプリケーション・ロールに対するプレゼンテーション・サービスの権限の設定」を参照してください。