ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド
11gリリース2 (11.1.2.2)
B70199-06
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

28 CSRおよびエージェント操作のためのマルチテナント・アクセス制御

この章では、Oracle Adaptive Access Managerのマルチテナント・アクセス制御について説明します。マルチテナント・アクセス制御では、複数のテナントの管理ユーザーの操作性が様々になるように、各組織のOAAM管理コンソールへのアクセスを処理します。

この章には次の項が含まれます:

28.1 マルチテナント・アクセス制御

マルチテナントとは、サーバーで単一のソフトウェア・インスタンスを実行して複数のクライアント組織にサービスを提供するという、ソフトウェア・アーキテクチャの原則の1つです。マルチテナント・アーキテクチャにおいては、各クライアント組織はインスタンスに対して個別にカスタマイズしたアプリケーションを使用している感覚で操作できます。

図28-1は、マルチテナント・アクセス制御のシナリオを示しています。

図28-1 マルチテナント・アクセス制御のシナリオ

図28-1の説明が続きます
「図28-1 マルチテナント・アクセス制御のシナリオ」の説明

アプリケーションID

これは、クライアント(ブラウザ)からのアプリケーション・リクエストです。通常、URLがアプリケーションIDにマップされ、アプリケーションIDが組織IDにマップされます。

組織ID

各ユーザーは、1つの組織IDのみに属します。これによって、ユーザーがどのテナント・アプリケーションを使用しているか、およびOAAMポリシーがそのアプリケーションに対して実行される範囲が識別されます。

共有インフラストラクチャ/共有アプリケーション

図28-1に示す例では、オンライン・バンキング・アプリケーション(同じサーバーの同じインスタンス)に、アプリケーションの概観がクライアントごとに異なったものになるように、データ・パーティションが含まれています。

アプリケーションの認識

各組織は、他の組織とは異なるアプリケーションになるように、オンライン・バンキング・アプリケーションをカスタマイズできます。各アプリケーションは、アプリケーションID (Bank1、Bank2、Bank3およびBank4)に対応しています。

28.2 アプリケーションID (クライアント側)から組織ID (管理側)へのマッピング

各カスタマのデータの一意性を確保するために、クライアント・アプリケーションのアプリケーションIDを組織IDにマッピングして、OAAM管理で使用できるようにします。

ユーザーは、初めてアプリケーションにアクセスしたときに組織IDに自動プロビジョニングされます。アプリケーションを組織IDにマップする方法の詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』アプリケーションIDおよびユーザー・グループの決定に関する説明を参照してください。

アプリケーションIDは、OAAMサーバーでカスタマのページがパーソナライズおよびブランディングされる際に使用されます。これらは、カスタマ・アプリケーションのカスタマイズに使用する構成プロパティのセットがOAAM管理で判別される際に使用されます。ユーザー・インタフェース・ブランディングのカスタマイズの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』ユーザー・インタフェース・ブランディングのカスタマイズに関する説明を参照してください。

28.3 マルチテナントのアクセス制御の設定

マルチテナントのアクセス制御を設定するには、このセッションの手順を実行します。

28.3.1 マルチテナントのアクセス制御の設定

マルチテナントのアクセス制御を設定するには、次の手順を実行します。

  1. プロパティ検索ページで、検索する名前としてbharosa.multitenant.booleanを指定します。

  2. 「検索」をクリックします。

  3. bharosa.multitenant.booleanプロパティの値をtrueに変更します。このプロパティが見つからない場合は、このプロパティを作成してtrueに設定します。

28.3.2 CSRに対する特定の組織へのアクセスの提供

CSR管理ユーザーに対して特定の組織へのアクセスを提供するには、CSR管理ユーザーがその組織に所属している必要があります。

どの時点においても、CSRまたはCSRマネージャは複数の組織にサービスを提供できます。割り当てられている組織のすべてのケースを表示できるようになります。

CSRが変更された場合や、組織に追加された場合、設定は現在のログインではなく次回のログイン時に有効になります。

以前のリリースから移行する場合、マルチテナント・アクセス制御はデフォルトではオフになっているため、何も変更しなくてもこれまでと同じように操作できます。マルチテナント・アクセス制御が必要な場合は、設定する必要があります。マルチテナントを設定すると、アクセス制御が適用されます。たとえば、以前のリリースでCSRが組織1に所属していた場合、アクセス制御の適用後も、CSRは組織1内のすべてのケースに引き続きアクセスできます。以前にアクセス制御を使用していない場合、CSRはすべてのケースにアクセスできます。ここで、マルチテナント・アクセス制御を設定すると、組織1からのケースのみを表示できるようになります。11gへのアップグレード前にCSRが5つの異なる組織からの5つの異なるケースを操作していた場合、それらのケースにはアクセスできなくなります。

28.3.2.1 WebLogicの使用

これを実現するには、この組織IDと完全に同じ名前の組織が存在する必要があり、その組織をCSR管理ユーザーに割り当てる必要があります。

  1. WebLogicユーザーとしてWebLogic管理コンソールにログインします。

    http://hostname:port/console

    hostnameは管理サーバーのホスト名、portは管理サーバーがリクエストをリスニングするポートのアドレス(デフォルトでは7001)です。

  2. 組織IDの名前と完全に一致するWebLogicセキュリティ・レルムを使用して、グループまたは組織を作成します。たとえば、Bank1などを使用します。

    Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプ 11gのグループの作成に関する説明を参照してください。

  3. 必要に応じて、このグループまたは組織をCSRおよびCSRマネージャに割り当てます。

    Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプ 11gのグループへのユーザーの追加に関する説明を参照してください。

異なる組織間でユーザーを移動するには:

  1. WebLogicユーザーとしてWebLogic管理コンソールにログインします。

    http://hostname:port/console
    

    hostnameは管理サーバーのホスト名で、portは管理サーバーがリクエストをリスニングするポートのアドレス(デフォルトは7001)です。

  2. 「セキュリティ・レルム」で、「レルム名の設定」ページの「ユーザーとグループ」「ユーザー」を選択します。

  3. CSRおよびCSRマネージャからグループまたは組織を削除し、新しいグループまたは組織をCSRおよびCSRマネージャに追加することにより、グループまたは組織のユーザー・メンバーシップを変更します。

    変更は、CSRおよびCSRマネージャが次にログインしたときから有効になります。

    Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプ 11gのユーザーの変更に関する説明を参照してください。

28.3.2.2 Oracle Internet Directoryへのユーザーおよびグループの追加

OIDを介してユーザーおよびグループを追加する場合は、Oracle Fusion Middleware Oracle Identity Management用チュートリアルのOracle Internet Directoryへのユーザーおよびグループの追加に関する説明を参照してください。

28.3.2.3 LDAPストアへのユーザーおよびグループの追加

外部LDAPストアでユーザーおよびグループの作成を行う場合は、2.5.1項「外部LDAPストアでのOAAM管理ロールおよびユーザーの作成」を参照してください。

28.4 ケース管理でのマルチテナント・アクセス制御

この項では、OAAMでのマルチテナント・アクセス制御の使用環境に関するサマリーと例を提供します。マルチテナント・アクセス制御は、ケース管理データ・アクセス、組織IDに基づいたフィルタリング、およびセッション検索結果に基づいたフィルタリングにのみ適用できます。Oracle Adaptive Access Managerでは、OAAM管理コンソールのデータ管理およびセキュリティの担当者のビューを制御できません。

表28-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の使用環境と同じです。

セッションのリンク

該当なし

エージェントは、アクセス権を持つ組織に属するケースにセッションをリンクできます。

また、リンクの検索セッションにおいて、エージェントはアクセス権を持つ組織のセッションのみを表示できます。


28.5 マルチテナント・アクセス制御のユース・ケース

次の各項で、マルチテナント・アクセス制御に関する一般的なユース・ケースの例について説明します。

28.5.1 CSRおよびCSRマネージャのアクセス制御

Second Bankは、コンシューマ・バンキング・アプリケーションおよびビジネス・バンキング・アプリケーションの両方を保護するために、OAAMをデプロイしました。そのCSRは、2つの異なる組織に分かれています。一方の組織はコンシューマ・バンキングのカスタマのみを取り扱い、もう一方の組織はビジネス・バンキングのカスタマのみを取り扱います。これらのCSR組織それぞれに表示されるカスタマ・データを厳密に制御する必要があります。また、すべてのカスタマのデータにアクセスする必要のある上級CSRマネージャの組織もあります。コンシューマ・バンキングのCSRには、ケースの検索、表示、作成、編集時に、コンシューマ・バンキングのカスタマに関連するデータのみが表示されます。同様に、ビジネス・バンキングのCSRには、ビジネス・バンキングのカスタマのデータのみが表示されます。どちらの側にも、OAAMでこのようなデータの事前フィルタリングが行われていることさえわかりません。CSRマネージャは、コンシューマ・バンキングのカスタマ・アクティビティとビジネス・バンキングの両方のカスタマ・アクティビティに関連するデータを表示でき、すべてのケース・フロー操作を実行できます。

アクター: CSRおよびCSRマネージャ

設定: シナリオを設定するには:

  1. マルチテナント・アクセス制御を有効にします。

  2. 組織IDと同じ名前を使用して、カスタマを取り扱うコンシューマ組織とビジネス組織を作成します。

    一方の組織はコンシューマ・バンキングのカスタマのみを取り扱い、もう一方の組織はビジネス・バンキングのカスタマのみを取り扱います。これらのCSR組織それぞれに表示されるカスタマ・データを厳密に制御する必要があります。

  3. 管理者としてCSR1、CSR2およびCSRSeniorを作成します。

  4. CSR1をコンシューマ組織に、CSR2をビジネス組織に、CSRSeniorをコンシューマ組織とビジネス組織に割り当てます。

    CSR管理ユーザーに対して特定の組織へのアクセスを提供するには、CSR管理ユーザーがその組織に所属している必要があります。

    コンシューマ・バンキングのCSR (CSR1)には、ケースの検索、表示、作成、編集時に、コンシューマ・バンキングのカスタマに関連するデータのみが表示されます。同様に、ビジネス・バンキングのCSR (CSR2)には、ビジネス・バンキングのカスタマのデータのみが表示されます。どちらの側にも、OAAMでこのようなデータの事前フィルタリングが行われていることさえわかりません。CSRマネージャ(CSRSenior)は、コンシューマ・バンキングのカスタマ・アクティビティとビジネス・バンキングの両方のカスタマ・アクティビティに関連するデータを表示でき、すべてのケース・フロー操作を実行できます。

フロー:

  1. CSRがOAAM管理コンソールを開きます。

  2. CSRには、適切なユーザー・インタフェース・ビューと、そのロールに許可されているコントロールのみが表示されます。

  3. CSRには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。表示する権限のない組織IDに関連するユーザーまたはセッションのデータは表示されません。

  4. CSRマネージャには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。表示する権限のない組織IDに関連するユーザーまたはセッションのデータは表示されません。

28.5.2 エージェントのアクセス制御

Second Bankは、コンシューマ・バンキング・アプリケーションおよびビジネス・バンキング・アプリケーションの両方を保護するために、OAAMをデプロイしました。そのセキュリティ・アナリストは、2つの異なるグループに分かれています。一方のグループはコンシューマ・バンキングの問題のみを調査し、もう一方のグループはビジネス・バンキングの問題のみを調査します。これらのセキュリティ・アナリスト組織それぞれに表示されるすべてのセッション、ポリシーおよびデータを厳密に制御する必要があります。また、すべてのデータにアクセスする必要のある上級セキュリティ・アナリスト・マネージャの組織もあります。コンシューマ・バンキングのセキュリティ・アナリストには、ケースの検索、表示、作成、編集時に、コンシューマ・バンキングのカスタマに関連するデータのみが表示されます。同様に、ビジネス・バンキングのセキュリティ・アナリストには、ビジネス・バンキングのデータのみが表示されます。どちらの側にも、OAAMでこのようなデータの事前フィルタリングが行われていることさえわかりません。セキュリティ・アナリストは、コンシューマ・バンキングとビジネス・バンキングの両方のアクティビティやポリシーなどに関連するデータを表示でき、すべてのケース・フロー操作を実行できます。同様に、マネージャには、ビジネス・バンキングのケースまたはデータのみ、あるいはカスタマ・バンキングのケースまたはデータのみが表示されるように選択できるフィルタがあります。

アクター: セキュリティ・アナリストおよびCSR

フロー:

  1. CSRまたはアナリストが、OAAM管理コンソールを開きます。

  2. CSRまたはアナリストには、適切なユーザー・インタフェース・ビューと、そのロールに許可されているコントロールのみが表示されます。

  3. CSRまたはアナリストには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。表示する権限のない組織IDに関連するユーザーまたはセッションのデータは表示されません。

  4. CSRまたはアナリスト・マネージャには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。表示する権限のない組織IDに関連するユーザーまたはセッションのデータは表示されません。

  5. CSRマネージャは、組織IDに基づいて表示されるデータをフィルタリングできます。

28.5.3 CSRケースのAPIデータのアクセス制御

Second Bankは、OAAMを既存のカスタマ・チケッティング・アプリケーションと統合することにしました。APIを使用してカスタマ・データを取得し、カスタマにかわってカスタマ・サービス・アクションを実行します。そのCSRは、2つの異なる組織に分かれています。一方の組織はコンシューマ・バンキングのカスタマのみを取り扱い、もう一方の組織はビジネス・バンキングのカスタマのみを取り扱います。これらのCSR組織それぞれに表示されるカスタマ・データを厳密に制御する必要があります。また、すべてのカスタマのデータにアクセスする必要のある上級CSRマネージャの組織もあります。APIを使用すると、統合を構成して、これらの異なる従業員グループに対する組織IDに基づいてカスタマ・データへのアクセスを制御できます。

アクター: CSR

フロー:

  1. CSRがカスタム・コンソールを開きます。

  2. CSRには、そのロール(組織ID)に許可されている適切なデータのみが表示されます。

28.6 トラブルシューティング/FAQ

この項では、マルチテナント・アクセス制御の設定時に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。

28.6.1 マルチテナント・アクセス制御を設定したはずなのに、CSRや調査担当者がまだすべてのケースにアクセスできる

bharosa.multitenant.booleantrueに設定されていることを確認します。falseに設定されている場合、マルチテナント・アクセス制御は無効です。デフォルトでは、マルチテナント・アクセス制御は無効です。

マルチテナント・アクセス制御が無効になっている場合は、次のようになります。

  • CSRおよび調査担当者は、ケースの作成時にすべての組織IDを表示でき、そのいずれかを選択できます。

  • 「ケース」ホームページに、CSRおよび調査担当者に対してすべての組織IDが表示されます。

28.6.2 マルチテナント・アクセス制御を設定し、プロパティがtrueに設定されていることを確認したのに、CSRおよび調査担当者がすべてのケースにアクセスできる

アクセス制御を適用するには、ログアウトしてから再びログインする必要があります。プロパティを変更すると、現在のログインではなく次回のログイン時に有効になります。

28.6.3 マルチテナント・アクセス制御を設定するとセキュリティ管理者およびシステム管理者は影響を受けるか

マルチテナント・アクセス制御を有効化および無効化しても、セキュリティ管理者およびシステム管理者のロールを持つユーザーに影響はありません。マルチテナント・アクセス制御は、ケース管理にのみ適用されます。ユーザーの使用環境に影響はありません。

28.6.4 CSRおよび調査担当者は複数の組織にアクセスできるか

はい。複数の組織に割り当てることができます。

28.6.5 以前のアクセスに関係なくCSRまたは調査担当者のアクセスを特定の組織のみに制限できるか

はい。アクセス制御を適切に設定すると、CSRまたは調査担当者はその組織IDにアクセスできなくなります。その組織のケースにはアクセスできなくなります。プロパティを変更すると、現在のログインではなく次回のログイン時に有効になります。

28.6.6 CSRおよび調査担当者がケースにアクセスできない何がいけないのでしょうか。

CSRおよび調査担当者がケースにアクセスできるように、適切なロールおよび組織に割り当てられていることを確認してください。