| Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11gリリース1 (11.1.1) E67347-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11gリリース1 (11.1.1) E67347-01 |
|
前 |
次 |
この章では、Oracle Adaptive Access Managerのマルチテナント・アクセス制御について説明します。マルチテナント・アクセス制御は、複数のテナントの管理ユーザーの操作性が様々になるように、各組織のOAAM管理コンソールをカスタマイズする方法です。
マルチテナントとは、サーバーで単一のソフトウェア・インスタンスを実行して複数のクライアント組織にサービスを提供するという、ソフトウェア・アーキテクチャの原則の1つです。マルチテナント・アーキテクチャにおいては、各クライアント組織はインスタンスに対して個別にカスタマイズしたアプリケーションを使用している感覚で操作できます。
図30-1は、マルチテナント・アクセス制御のシナリオを示しています。
これは、クライアント(ブラウザ)からのアプリケーション・リクエストです。通常、URLがアプリケーションIDにマップされ、アプリケーションIDが組織IDにマップされます。
各ユーザーは、1つの組織IDのみに属します。これは、ユーザーが使用するテナント・アプリケーションおよびOAAMポリシーの稼働範囲を識別します。
共有インフラストラクチャ/共有アプリケーション
図30-1に示す例では、オンライン・バンキング・アプリケーション(同じサーバーの同じインスタンス)に、アプリケーションの外観がクライアントごとに異なったものになるように、データ・パーティションが含まれています。
アプリケーションの認識
各組織は、他の組織とは異なるアプリケーションになるように、オンライン・バンキング・アプリケーションをカスタマイズできます。各アプリケーションは、アプリケーションID (Bank1、Bank2、Bank3およびBank4)に対応しています。
各カスタマのデータの固有性を確実にするために、アプリケーションIDを組織IDにマッピングして、OAAM管理で使用できるようにします。
クライアント・アプリケーションのアプリケーションIDが組織IDにマップされます。ユーザーは、初めてアプリケーションにアクセスしたときに組織IDに自動プロビジョニングされます。アプリケーションを組織IDにマップする方法の詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』のアプリケーションIDおよびユーザー・グループの決定に関する説明を参照してください。
アプリケーションIDは、OAAMサーバーでカスタマのページがパーソナライズおよびブランディングされる際に使用されます。これらは、カスタマ・アプリケーションのカスタマイズに使用する構成プロパティのセットがOAAM管理で判別される際に使用されます。ユーザー・インタフェース・ブランディングのカスタマイズの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』のユーザー・インタフェース・ブランディングのカスタマイズに関する説明を参照してください。
ユーザーからは、(オンライン・バンキング)アプリケーションが複数のテナントにより共有されていることはわかりません。ユーザーは、そのアプリケーションにアクセスするとき、銀行アプリケーションの特定のURLを通過するか、組織IDを別の2つのいずれかの方法で伝達します。OAAMサーバーは、このURLを使用して適切なページを表示できます。続いて、ユーザーは、組織IDにマップされているユーザーIDを入力します。
ただし、複数の銀行が共通のURLを共有している場合、OAAMサーバーはユーザーがどこからログインしているかを認識できないため、汎用の銀行画面を表示します。次のいずれかのシナリオに対してOAAMサーバーを構成できます。例1では、ユーザーがユーザーIDと組織IDを入力し、OAAMサーバーがその組合せに基づいて表示するページを決定します。例2では、ユーザーがユーザーIDを入力し、OAAMサーバーは、組織ID参照によって、表示する適切なページを判断できます。例3では、ユーザーはURLにアクセスするとすぐに適切な画面にダイレクトされます。
マルチテナントのアクセス制御を設定するには、このセッションの手順を実行します。
マルチテナントのアクセス制御を設定するには、次の手順を実行します。
プロパティ検索ページで、検索する名前としてbharosa.multitenant.booleanを指定します。
「検索」をクリックします。
bharosa.multitenant.booleanプロパティの値をtrueに変更します。このプロパティが見つからない場合は、このプロパティを作成してtrueに設定します。
CSR管理ユーザーに対して特定の組織へのアクセスを提供するには、CSR管理ユーザーがその組織に所属している必要があります。
どの時点においても、CSRまたはCSRマネージャは複数の組織にサービスを提供できます。割り当てられている組織のすべてのケースを表示できるようになります。
CSRが変更された場合や、組織に追加された場合、設定は現在のログインではなく次回のログイン時に有効になります。
以前のリリースから移行する場合、マルチテナント・アクセス制御は初期設定時にはオフになっているため、何も変更しなくてもこれまでと同じように操作できます。マルチテナント・アクセス制御が必要な場合は、設定する必要があります。マルチテナントを設定すると、アクセス制御が適用されます。たとえば、以前のリリースでCSRが組織1に所属していた場合、アクセス制御の適用後も、CSRは組織1内のすべてのケースに引き続きアクセスできます。以前にアクセス制御を使用していない場合、CSRはすべてのケースにアクセスできます。ここで、マルチテナント・アクセス制御を設定すると、組織1からのケースのみを表示できるようになります。11gへのアップグレード前にCSRが5つの異なる組織からの5つの異なるケースを操作していた場合、それらのケースにはアクセスできなくなります。
これを実現するには、この組織IDと完全に同じ名前の組織が存在する必要があり、その組織をCSR管理ユーザーに割り当てる必要があります。
WebLogicユーザーとしてWebLogic管理コンソールにログインします。
http://hostname:port/console
hostnameは管理サーバーのホスト名、portは管理サーバーがリクエストをリスニングするポートのアドレス(デフォルトでは7001)です。
組織IDの名前と完全に一致するWebLogicセキュリティ・レルムを使用して、グループまたは組織を作成します。たとえば、Bank1などを使用します。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプ 11gのグループの作成に関する説明を参照してください。
必要に応じて、このグループまたは組織をCSRおよびCSRマネージャに割り当てます。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプ 11gのグループへのユーザーの追加に関する説明を参照してください。
異なる組織間でユーザーを移動するには:
WebLogicユーザーとしてWebLogic管理コンソールにログインします。
http://hostname:port/console
hostnameは管理サーバーのホスト名、portは管理サーバーがリクエストをリスニングするポートのアドレス(デフォルトでは7001)です。
「レルム名の設定」ページの「セキュリティ・レルム」で、「ユーザーとグループ」→「ユーザー」に移動します。
CSRおよびCSRマネージャからグループまたは組織を削除し、新しいグループまたは組織をCSRおよびCSRマネージャに追加することにより、グループまたは組織のユーザー・メンバーシップを変更します。
変更は、CSRおよびCSRマネージャが次にログインしたときから有効になります。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプ 11gのユーザーの変更に関する説明を参照してください。
OIDを介してユーザーおよびグループを追加する場合は、Oracle Fusion Middleware Oracle Identity Management用チュートリアルのOracle Internet Directoryへのユーザーおよびグループの追加に関する説明を参照してください。
この項では、OAAMでのマルチテナント・アクセス制御の使用環境に関するサマリーと例を提供します。マルチテナント・アクセス制御は、ケース管理データ・アクセス、組織IDに基づいたフィルタリング、およびセッション検索結果に基づいたフィルタリングにのみ適用できます。Oracle Adaptive Access Managerでは、OAAM管理コンソールのデータ管理およびセキュリティの担当者のビューを制御できません。
表30-1 CSRおよびエージェントのマルチテナント使用環境
| タスク | CSRの使用環境 | エージェントの使用環境 |
|---|---|---|
|
CSRケースの作成 |
CSRは、1つの組織IDを選択してケースを作成できます。 |
該当なし |
|
エージェント・ケースの作成 |
該当なし |
エージェントは、1つの組織IDを選択してケースを作成できます。 |
|
ケースの検索 |
CSRは、アクセス権を持つ組織IDを表示でき、そこから1つ(以上)の組織IDを選択できます。 |
エージェントは、アクセス権を持つ組織IDを表示でき、そこから1つ(以上)の組織IDを選択できます。 |
|
ケースの表示 |
CSRは、アクセス権を持つ組織のユーザーからのみケースを表示できます。 |
エージェントは、アクセス権を持つ組織のユーザーからのみケースを表示できます。エージェントがアクセス権を持つ組織IDに関連付けられたエスカレーション済ケースも、問合せ基準に一致している場合は、検索結果に含められます。 |
|
ケース詳細 |
CSRは、アクセス権を持つ組織に所属するユーザーに属するケースについて、ケース詳細を表示できます。CSRがアクセス権を持つ組織にユーザーが所属していない場合、そのケースは検索結果に表示されません。 |
エージェントは、アクセス権を持つ組織に所属するユーザーに属するケース、または自分の組織IDに関連付けられたケースについて、ケース詳細を表示できます。 |
|
ケース・アクション |
CSRは、表示されたケースに対してケース・アクションを実行できます。 |
エージェントは、表示されたケースに対してケース・アクションを実行できます。 |
|
セッション検索および詳細ページ |
CSRは、セッションの検索ページおよび詳細ページにはアクセスできません。 |
マルチテナント・アクセス制御が有効になっている場合、エージェントはセッション・ページまたはセッション検索からいずれの詳細ページにもナビゲートできません。マルチテナント・アクセス制御が無効になっている場合、エージェントは、リンクが使用可能になっていれば、セッション検索から詳細ページにアクセスできます。 |
|
セッションの検索 |
該当なし |
エージェントは、アクセス権を持つ組織に所属するユーザーに属するセッション、およびアクセス権を持つ組織に属するセッションを検索できます。 |
|
(組織IDの割当てが変更された)ケースの検索 |
CSRは、org1に割り当てられています。"org1"内のユーザーに対してケースを作成しました。 一定の期間、その組織のユーザーにサービスを提供しました。 その後、org1サービスから削除された後、彼はorg2へのサービス提供を開始しました。 この後で再びログインすると、org1のケースは(自分で作成したかどうかに関係なく)表示できなくなっています。表示および操作できるのは、org2に属するケースのみです。 |
CSRの使用環境と同じです。 |
|
セッションのリンク |
該当なし |
エージェントは、アクセス権を持つ組織に属するケースにセッションをリンクできます。 また、リンクの検索セッションにおいて、エージェントはアクセス権を持つ組織のセッションのみを表示できます。 |
次の各項で、マルチテナント・アクセス制御に関する一般的なユース・ケースの例について説明します。
Second Bankは、コンシューマ・バンキング・アプリケーションおよびビジネス・バンキング・アプリケーションの両方を保護するために、OAAMをデプロイしました。そのCSRは、2つの異なる組織に分かれています。一方の組織はコンシューマ・バンキングのカスタマのみを取り扱い、もう一方の組織はビジネス・バンキングのカスタマのみを取り扱います。これらのCSR組織それぞれに表示されるカスタマ・データを厳密に制御する必要があります。また、すべてのカスタマのデータにアクセスする必要のある上級CSRマネージャの組織もあります。コンシューマ・バンキングのCSRには、ケースの検索、表示、作成、編集時に、コンシューマ・バンキングのカスタマに関連するデータのみが表示されます。同様に、ビジネス・バンキングのCSRには、ビジネス・バンキングのカスタマのデータのみが表示されます。どちらの側にも、OAAMでこのようなデータの事前フィルタリングが行われていることさえわかりません。CSRマネージャは、コンシューマ・バンキングのカスタマ・アクティビティとビジネス・バンキングの両方のカスタマ・アクティビティに関連するデータを表示でき、すべてのケース・フロー操作を実行できます。
アクター: CSRおよびCSRマネージャ
設定: シナリオを設定するには:
マルチテナント・アクセス制御を有効にします。
組織IDと同じ名前を使用して、カスタマを取り扱うコンシューマ組織とビジネス組織を作成します。
一方の組織はコンシューマ・バンキングのカスタマのみを取り扱い、もう一方の組織はビジネス・バンキングのカスタマのみを取り扱います。これらのCSR組織それぞれに表示されるカスタマ・データを厳密に制御する必要があります。
管理者としてCSR1、CSR2およびCSRSeniorを作成します。
CSR1をコンシューマ組織に、CSR2をビジネス組織に、CSRSeniorをコンシューマ組織とビジネス組織に割り当てます。
CSR管理ユーザーに対して特定の組織へのアクセスを提供するには、CSR管理ユーザーがその組織に所属している必要があります。
コンシューマ・バンキングのCSR (CSR1)には、ケースの検索、表示、作成、編集時に、コンシューマ・バンキングのカスタマに関連するデータのみが表示されます。同様に、ビジネス・バンキングのCSR (CSR2)には、ビジネス・バンキングのカスタマのデータのみが表示されます。どちらの側にも、OAAMでこのようなデータの事前フィルタリングが行われていることさえわかりません。CSRマネージャ(CSRSenior)は、コンシューマ・バンキングのカスタマ・アクティビティとビジネス・バンキングの両方のカスタマ・アクティビティに関連するデータを表示でき、すべてのケース・フロー操作を実行できます。
フロー:
CSRがOAAM管理コンソールを開きます。
CSRには、適切なユーザー・インタフェース・ビューと、そのロールに許可されているコントロールのみが表示されます。
CSRには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。表示する権限のない組織IDに関連するユーザーまたはセッションのデータは表示されません。
CSRマネージャには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。表示する権限のない組織IDに関連するユーザーまたはセッションのデータは表示されません。
Second Bankは、コンシューマ・バンキング・アプリケーションおよびビジネス・バンキング・アプリケーションの両方を保護するために、OAAMをデプロイしました。そのセキュリティ・アナリストは、2つの異なるグループに分かれています。一方のグループはコンシューマ・バンキングの問題のみを調査し、もう一方のグループはビジネス・バンキングの問題のみを調査します。これらのセキュリティ・アナリスト組織それぞれに表示されるすべてのセッション、ポリシーおよびデータを厳密に制御する必要があります。また、すべてのデータにアクセスする必要のある上級セキュリティ・アナリスト・マネージャの組織もあります。コンシューマ・バンキングのセキュリティ・アナリストには、ケースの検索、表示、作成、編集時に、コンシューマ・バンキングのカスタマに関連するデータのみが表示されます。同様に、ビジネス・バンキングのセキュリティ・アナリストには、ビジネス・バンキングのデータのみが表示されます。どちらの側にも、OAAMでこのようなデータの事前フィルタリングが行われていることさえわかりません。セキュリティ・アナリストは、コンシューマ・バンキングとビジネス・バンキングの両方のアクティビティやポリシーなどに関連するデータを表示でき、すべてのケース・フロー操作を実行できます。同様に、マネージャには、ビジネス・バンキングのケースまたはデータのみ、あるいはカスタマ・バンキングのケースまたはデータのみが表示されるように選択できるフィルタがあります。
アクター: セキュリティ・アナリストおよびCSR
フロー:
CSRまたはアナリストが、OAAM管理コンソールを開きます。
CSRまたはアナリストには、適切なユーザー・インタフェース・ビューと、そのロールに許可されているコントロールのみが表示されます。
CSRまたはアナリストには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。表示する権限のない組織IDに関連するユーザーまたはセッションのデータは表示されません。
CSRまたはアナリスト・マネージャには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。表示する権限のない組織IDに関連するユーザーまたはセッションのデータは表示されません。
CSRマネージャは、組織IDに基づいて表示されるデータをフィルタリングできます。
Second Bankは、OAAMを既存のカスタマ・チケッティング・アプリケーションと統合することにしました。APIを使用してカスタマ・データを取得し、カスタマにかわってカスタマ・サービス・アクションを実行します。そのCSRは、2つの異なる組織に分かれています。一方の組織はコンシューマ・バンキングのカスタマのみを取り扱い、もう一方の組織はビジネス・バンキングのカスタマのみを取り扱います。これらのCSR組織それぞれに表示されるカスタマ・データを厳密に制御する必要があります。また、すべてのカスタマのデータにアクセスする必要のある上級CSRマネージャの組織もあります。APIを使用すると、統合を構成して、これらの異なる従業員グループに対する組織IDに基づいてカスタマ・データへのアクセスを制御できます。
アクター: CSR
フロー:
CSRがカスタム・コンソールを開きます。
CSRには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。
この項では、マルチテナント・アクセス制御の設定時に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。
bharosa.multitenant.booleanがtrueに設定されていることを確認します。falseに設定されている場合、マルチテナント・アクセス制御は無効です。デフォルトでは、マルチテナント・アクセス制御は無効です。
マルチテナント・アクセス制御が無効になっている場合は、次のようになります。
CSRおよび調査担当者は、ケースの作成時にすべての組織IDを表示でき、そのいずれかを選択できます。
「ケース」ホームページに、CSRおよび調査担当者に対してすべての組織IDが表示されます。
アクセス制御を適用するには、ログアウトしてから再びログインする必要があります。プロパティを変更すると、現在のログインではなく次回のログイン時に有効になります。
マルチテナント・アクセス制御を有効化および無効化しても、セキュリティ管理者およびシステム管理者のロールを持つユーザーに影響はありません。マルチテナント・アクセス制御は、ケース管理にのみ適用されます。ユーザーの使用環境に影響はありません。
はい。アクセス制御を適切に設定すると、CSRまたは調査担当者はその組織IDにアクセスできなくなります。その組織のケースにはアクセスできなくなります。プロパティを変更すると、現在のログインではなく次回のログイン時に有効になります。
