ヘッダーをスキップ

Oracle® Real User Experience Insightユーザーズ・ガイド 12cリリース2 (12.1.0.3) for Linux x86-64 B70760-01 |
| 目次 | 索引

前 | 次 |

# 11 OAMおよびSSOベース・トラフィックの監視

この章では、OAMベース・トラフィック内におけるユーザー・アクティビティの監視方法について説明します。また、SSOメカニズムを介してユーザー・アクセス制御を管理するWebトラフィックの監視についても説明します。

## 11.1 OAMベース・トラフィックの監視

Oracle Access Manager(OAM)トラフィック内のユーザーIDを識別するように、RUEIを構成できます。OAMバージョン10.1.4.x(以上)がサポートされます。OAMベース・トラフィックを監視する手順は、次のとおりです。

1. 目的のアプリケーションを選択し、「ユーザー」セクションをクリックします。

2. 「新規ソースの追加」をクリックします。図8-30に示すダイアログが表示されます。

3. 「検索タイプ」メニューで「Oracle Access Manager」オプションを選択します。

4. 「ソース値」フィールドに、監視対象のOAMベース・トラフィック内でユーザー識別を追跡するために使用するCookieの名前を指定します。デフォルトでは、これは`ObSSOcookie`です。次に、「保存」をクリックします。カスタマイズされたCookie実装がOAMサーバーで使用される場合は、OAM管理者に問い合せてください。OAM Cookieのカスタマイズの情報は、Oracle Access Manager管理者ガイドに記載されています。

5. 「構成」→「アプリケーション」→「セッション・トラッキング」の順に選択します。現時点で定義されているCookieの設定が表示されます。例を図12-4に示します。

6. 「新規Cookieの追加」をクリックします。図12-3に示すダイアログが表示されます。

7. 「Cookieタイプ」メニューでOAMオプションを選択します。

8. 「Cookie名」フィールドに、監視対象のOAMベース・トラフィック内でユーザー識別を追跡するために使用するCookieを指定します。デフォルトでは、これは`ObSSOcookie`です。次に、「保存」をクリックします。

RUEIで使用するためのOAMサーバーの構成手順は、Oracle Real User Experienceインストレーション・ガイドに記載されています。

OAMベース・トラフィックのレポート

データ・ブラウザでのユーザーIDのレポートは、識別名(DN)に基づいています。例を図11-1に示します。

図11-1 OAMトラフィックのレポートの例

「図11-1 OAMトラフィックのレポートの例」の説明

## 11.2 シングル・サインオン(SSO)プロファイルの定義

シングル・サインオン(SSO)とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。SSOには次の利点があります。

- ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。

- 同じIDに対するパスワードの再入力に要する時間を省きます。

- ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。

SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。

SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。このためには、SSOプロファイルを作成します。

### 11.2.1 SSO対応トラフィックの監視方法の概要

SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。図11-2に、アプリケーション認証がSSOサーバーで有効化されている場合に機能する仕組みを示します。

図11-2 SSO対応アプリケーション・トラフィック内の認証フロー

「図11-2 SSO対応アプリケーション・トラフィック内の認証フロー」の説明

図11-2に示す認証フローは、次の順序を取ります。

1. ユーザーが、保護されたURLへのアクセスを試行します。アプリケーション・サーバーが、リクエストされたアプリケーションの認証Cookieが存在するかどうかをチェックします。Cookieが見つかった場合は、ユーザーがすでにログオンしていることを意味し、追加認証は不要です。

2. ユーザーは、アプリケーション・サーバーによってSSOサーバーにリダイレクトされます。また、アプリケーション・サーバーは、アプリケーションURLをSSOサーバーに提供し、SSOサーバーがユーザー・ログオン後の移動先を把握できるようにします。SSOサーバーは、既存の認証Cookieを検証することで、ユーザーが(別のアプリケーションによって)認証済かどうかもチェックすることに注意してください。

3. ユーザーが既存の認証Cookieに基づいて認識されない場合、SSOサーバーは、ログイン・ページでユーザーの資格証明を要求します。資格証明は、ユーザーによってユーザー名とパスワードの組合せで指定されます。

4. ユーザーの資格証明が、SSOサーバー・データベース内の対応するエントリと照合されます。検証されると、SSO Cookieによって認証が維持されます。このCookieの名前は、SSOプロファイルの作成時に指定する必要があります。

5. SSOサーバーが、ユーザーの属性をフェッチします。実際にフェッチされる属性は実装固有であり、RUEIには無関係です。

6. SSOサーバーが、手順2で提供されたURLを使用して、フェッチされた属性をパートナ・アプリケーション・サーバーに渡します。トークン引数がこのURLに追加されることに注意してください。このトークン引数の名前は、SSOプロファイルの作成時に指定する必要があります。アプリケーション・サーバーは、通常、ユーザーへの独自のCookieの発行も行います。これは、アプリケーションまたはスイートの定義中に構成されます。

最後に、手順1、2および5で使用されるネットワーク回線は、RUEIの監視対象トラフィックの有効範囲内である必要があることに注意してください。

SSOプロファイルとSSOアプリケーション

SSOプロファイルとSSOアプリケーションは、密接に関連していますが、RUEI内では独立したエンティティとしてレポートされることを理解しておく必要があります。このため、SSOプロファイルとSSOアプリケーションの定義は、相互排他的にする必要があります。つまり、それぞれが独自のドメインおよびCookieに基づく必要があります。こうしておかないと、監視対象トラフィックはアプリケーション関連トラフィックとしてレポートされ、拡張レポート作成による利点は得られません。

### 11.2.2 SSOプロファイルの作成

SSOプロファイルを定義する手順は、次のとおりです。

1. 「構成」→「アプリケーション」→「シングル・サインオン」の順に選択し、「新規SSOプロファイル」をクリックします。図11-3に示すダイアログが表示されます。

   図11-3 新規シングル・サインオンダイアログ

   「図11-3 新規シングル・サインオン・ダイアログ」の説明

2. SSOプロファイルの名前を指定します。これは、スイート、サービス、アプリケーションおよびSSOプロファイルを通じて一意である必要があります。SSOプロファイルの名前は後から変更できないため、注意してください。

3. 残りのフィールドを使用して、SSOプロファイルの有効範囲を指定します。有効範囲はページURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。

   注意: SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。こうしておかないと、予期しない結果がもたらされる可能性があります。一致規則の適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

   最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、SSOプロファイルは関連付けられないことに注意してください。指定できるポート番号は1つのみです。追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。

   ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。フィルタの適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。

   次に、「次へ」をクリックします。図11-4に示すダイアログが表示されます。

   図11-4 シングル・サインオン・サーバー情報ダイアログ

   「図11-4 シングル・サインオン・サーバー情報ダイアログ」の説明

4. このダイアログを使用し、使用しているSSO認証サーバーに関する情報を指定します。セッションCookie名、認証トークンを含んでいるURL引数、および監視対象トラフィックでのユーザーの識別方法を指定する必要があります。これは通常、URL引数と値を使用して定義します。ただし、Cookie、リクエスト・ヘッダーまたはレスポンス・ヘッダーあるいはXPath式で指定することもできます。

   次に、「終了」をクリックします。指定したSSOプロファイル定義の概要が表示されます。例を図11-5に示します。

   図11-5 SSOプロファイルの概要

   「図11-5 SSOプロファイルの概要」の説明

この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。この詳細は次の項に記載されています。

ユーザー識別を定義した結果は、ユーザー情報(XLS形式)レポートの「クライアント」カテゴリで確認できます。レポートの詳細は、第2章「レポートの操作」を参照してください。

### 11.2.3 SSOプロファイルの変更

SSOプロファイルを定義後に変更するには、その概要を使用します。次のタブがあります。

- 識別: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。新規フィルタを追加するには、「新規フィルタの追加」をクリックします。既存のフィルタを変更するには、そのフィルタをクリックします。図11-6に示すようなダイアログが表示されます。

  図11-6 「SSOプロファイル・フィルタの編集」ダイアログ

  「図11-6 「SSOプロファイル・フィルタの編集」ダイアログ」の説明

  ダイアログの最下部にあるメモは、現在のルール順序設定スキームを示します。この詳細は、12.9項「RUEI内でのルール順序設定の制御」に記載されています。

- 構成: 使用される認証トークンとCookieを指定します。

- ユーザー: ユーザーIDをアプリケーション内で識別する方法を指定します。これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。

### 11.2.4 SSO構成の検証

SSO対応アプリケーションの動作およびレポートが正しいかどうかを検証する場合、重要ポイントは、ユーザーIDが正しいかどうかを検査することです。データ・ブラウザ内のレポートを定期的に確認することをお薦めします(「すべてのセッション」→「ユーザーID」→セッションとページ・ビュー)。たとえば、未識別(匿名)ユーザーの数が予想より多い場合などです。

また、SSO対応アプリケーション内のURLがアプリケーション関連データとしてレポートされていないかどうかも検証する必要があります。レポートされている場合は、問題があることを示している可能性があります。