1. ユーザーズ・ガイド
  2. OAMおよびSSOベース・トラフィックの監視
機械翻訳について

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

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

OAMを使用している場合は、次に示すOAMバージョンに関連する適切なセクションを参照してください。 別のソリューションを使用している場合でも、「シングル・サインオン(SSO)プロファイルの定義」を使用してRUEIを使用してSSOを監視できます。

OAM 11gベース・トラフィックのモニタリング

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

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

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

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

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

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

データ・ブラウザのユーザーIDsのレポートは、OAM LDAPに記録されたユーザーのuid属性に基づきます。

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

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

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

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

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

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

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

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

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

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

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

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

  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に基づく必要があります。 こうしておかないと、監視対象トラフィックはアプリケーション関連トラフィックとしてレポートされ、拡張レポート作成による利点は得られません。

SSOプロファイルの作成

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

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

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


    図11-2の説明が続きます
    「図11-2 新規シングル・サインオン・ダイアログ」の説明

  2. SSOプロファイルの名前を指定します。 これは、スイート、サービス、アプリケーションおよびSSOプロファイルを通じて一意である必要があります。 SSOプロファイルの名前は後で変更できません。
  3. 残りのフィールドを使用して、SSOプロファイルの有効範囲を指定します。 有効範囲はページURLの部分として定義されます。 この情報を入力すると、「フィルタのプレビュー」列を通じて定義の効果を確認できます。

    ノート:

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

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

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

    準備ができたら、「次へ」をクリックします。 図11-3に示すダイアログが表示されます。

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


    図11-3の説明が続きます
    「図11-3 シングル・サインオン・サーバー情報ダイアログ」の説明

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

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

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


    図11-4の説明が続きます
    「図11-4 SSOプロファイルの概要」の説明

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

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

SSOプロファイルの変更

SSOプロファイルを定義後に変更するには、その概要を使用します。 以下のタブを使用することができます。

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

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

    図11-5の説明が続きます
    「図11-5 「SSOプロファイル・フィルタの編集」ダイアログ」の説明

    ダイアログの最下部にあるノートは、現在のルール順序設定スキームを示します。 これについては、「RUEI内でのルール順序設定の制御」で説明しています。

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

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

SSO構成の検証

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

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