| Oracle® Real User Experience Insightユーザーズ・ガイド リリース11.1 for Linux x86-64 B63041-01 |
|
 前へ |
 次へ |
この章では、OAMベース・トラフィック内におけるユーザー・アクティビティの監視方法について説明します。また、SSOメカニズムを介してユーザー・アクセス制御を管理するWebトラフィックの監視についても説明します。
Oracle Access Manager(OAM)トラフィック内のユーザーIDを識別するように、RUEIを構成できます。OAMバージョン10.1.4.x(以上)がサポートされます。OAMベース・トラフィックを監視する手順は、次のとおりです。
目的のアプリケーションを選択し、「Users」セクションをクリックします。
「Add new source」をクリックします。図8-25に示すダイアログが表示されます。
「Search type」メニューで「Oracle Access Manager」オプションを選択します。
「Source value」フィールドに、監視対象のOAMベース・トラフィック内でユーザー識別を追跡するために使用するCookieの名前を指定します。デフォルトでは、これはObSSOcookieです。次に、「Save」をクリックします。カスタマイズされたCookie実装がOAMサーバーで使用される場合は、OAM管理者に問い合せてください。OAM Cookieのカスタマイズの情報は、Oracle Access Manager管理者ガイドに記載されています。
「Configuration」→「Applications」→「Session tracking」の順に選択します。現時点で定義されているCookieの設定が表示されます。例を図12-2に示します。
「Add new cookie」をクリックします。図12-3に示すダイアログが表示されます。
「Cookie type」メニューで「OAM」オプションを選択します。
「Cookie name」フィールドに、監視対象のOAMベース・トラフィック内でユーザー識別を追跡するために使用するCookieを指定します。デフォルトでは、これはObSSOcookieです。次に、「Save」をクリックします。
RUEIで使用するためのOAMサーバーの構成手順は、Oracle Real User Experienceインストレーション・ガイドに記載されています。
OAMベース・トラフィックのレポート
データ・ブラウザでのユーザーIDのレポートは、識別名(DN)に基づいています。例を図11-1に示します。
シングル・サインオン(SSO)とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。SSOには次の利点があります。
ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。
同じIDに対するパスワードの再入力に要する時間を省きます。
ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。
SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。
SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。このためには、SSOプロファイルを作成します。
SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。図11-2に、アプリケーション認証がSSOサーバーで有効化されている場合に機能する仕組みを示します。
図11-2に示す認証フローは、次の順序を取ります。
ユーザーが、保護されたURLへのアクセスを試行します。アプリケーション・サーバーが、リクエストされたアプリケーションの認証Cookieが存在するかどうかをチェックします。Cookieが見つかった場合は、ユーザーがすでにログオンしていることを意味し、追加認証は不要です。
ユーザーは、アプリケーション・サーバーによってSSOサーバーにリダイレクトされます。また、アプリケーション・サーバーは、アプリケーションURLをSSOサーバーに提供し、SSOサーバーがユーザー・ログオン後の移動先を把握できるようにします。SSOサーバーは、既存の認証Cookieを検証することで、ユーザーが(別のアプリケーションによって)認証済かどうかもチェックすることに注意してください。
ユーザーが既存の認証Cookieに基づいて認識されない場合、SSOサーバーは、ログイン・ページでユーザーの資格証明を要求します。資格証明は、ユーザーによってユーザー名とパスワードの組合せで指定されます。
ユーザーの資格証明が、SSOサーバー・データベース内の対応するエントリと照合されます。検証されると、SSO Cookieによって認証が維持されます。このCookieの名前は、SSOプロファイルの作成時に指定する必要があります。
SSOサーバーが、ユーザーの属性をフェッチします。実際にフェッチされる属性は実装固有であり、RUEIには無関係です。
SSOサーバーが、手順2で提供されたURLを使用して、フェッチされた属性をパートナ・アプリケーション・サーバーに渡します。トークン引数がこのURLに追加されることに注意してください。このトークン引数の名前は、SSOプロファイルの作成時に指定する必要があります。アプリケーション・サーバーは、通常、ユーザーへの独自のCookieの発行も行います。これは、アプリケーションまたはスイートの定義中に構成されます。
最後に、手順1、2および5で使用されるネットワーク回線は、RUEIの監視対象トラフィックの有効範囲内である必要があることに注意してください。
SSOプロファイルとSSOアプリケーション
SSOプロファイルとSSOアプリケーションは、密接に関連していますが、RUEI内では独立したエンティティとしてレポートされることを理解しておく必要があります。このため、SSOプロファイルとSSOアプリケーションの定義は、相互排他的にする必要があります。つまり、それぞれが独自のドメインおよびCookieに基づく必要があります。こうしておかないと、監視対象トラフィックはアプリケーション関連トラフィックとしてレポートされ、拡張レポート作成による利点は得られません。
SSOプロファイルを定義する手順は、次のとおりです。
「Configuration」→「Applications」→「Single Sign-On」の順に選択し、「New SSO profile」をクリックします。図11-3に示すダイアログが表示されます。
SSOプロファイルの名前を指定します。これは、スイート、サービス、アプリケーションおよびSSOプロファイルを通じて一意である必要があります。SSOプロファイルの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、SSOプロファイルの有効範囲を指定します。有効範囲はページURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「Filter preview」列に表示されます。
|
注意: SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。こうしておかないと、予期しない結果がもたらされる可能性があります。一致規則の適用順序を制御する方法は、12.8項「RUEI内でのルール順序設定の制御」を参照してください。 |
最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「Find Port」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、SSOプロファイルは関連付けられないことに注意してください。指定できるポート番号は1つのみです。追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。フィルタの適用順序を制御する方法は、12.8項「RUEI内でのルール順序設定の制御」を参照してください。
次に、「Next」をクリックします。図11-4に示すダイアログが表示されます。
このダイアログを使用し、使用しているSSO認証サーバーに関する情報を指定します。セッションCookie名、認証トークンを含んでいるURL引数、および監視対象トラフィックでのユーザーの識別方法を指定する必要があります。これは通常、URL引数と値を使用して定義します。ただし、Cookie、リクエスト・ヘッダーまたはレスポンス・ヘッダーあるいはXPath式で指定することもできます。
次に、「Finish」をクリックします。指定したSSOプロファイル定義の概要が表示されます。例を図11-5に示します。
この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。この詳細は次の項に記載されています。
ユーザー識別を定義した結果は、「XLS User Information」レポートの「Clients」カテゴリで確認できます。レポートの詳細は、第2章「レポートの操作」を参照してください。
SSOプロファイルを定義後に変更するには、その概要を使用します。次のタブがあります。
Identification: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。新規フィルタを追加するには、「Add new filter」をクリックします。既存のフィルタを変更するには、そのフィルタをクリックします。図11-6に示すようなダイアログが表示されます。
ダイアログの最下部にあるメモは、現在のルール順序設定スキームを示します。この詳細は、12.8項「RUEI内でのルール順序設定の制御」に記載されています。
Configuration: 使用される認証トークンとCookieを指定します。
User: ユーザーIDをアプリケーション内で識別する方法を指定します。これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。
SSO対応アプリケーションの動作およびレポートが正しいかどうかを検証する場合、重要ポイントは、ユーザーIDが正しいかどうかを検査することです。データ・ブラウザ内のレポートを定期的に確認することをお薦めします(「All sessions」→「User Id」→「Sessions and pageviews」)。たとえば、未識別(匿名)ユーザーの数が予想より多い場合などです。
また、SSO対応アプリケーション内のURLがアプリケーション関連データとしてレポートされていないかどうかも検証する必要があります。レポートされている場合は、問題があることを示している可能性があります。
