| Oracle® Real User Experience Insightユーザーズ・ガイド 13.3.1.0 for Linux x86-64 E98302-02 |
|
 前 |
 次 |
OAMを使用している場合は、次に示すOAMバージョンに関連する適切なセクションを参照してください。 別のソリューションを使用している場合でも、「シングル・サインオン(SSO)プロファイルの定義」を使用してRUEIを使用してSSOを監視できます。
Oracle Access Manager(OAM)トラフィック内のユーザーIDを識別するように、RUEIを構成できます。 OAMバージョン10.1.4.x(以上)がサポートされます。 OAMベース・トラフィックを監視する手順は、次のとおりです。
ObSSOcookieです。 次に、保存をクリックします。 カスタマイズされたCookie実装がOAMサーバーで使用される場合は、OAM管理者に問い合せてください。 OAM Cookieのカスタマイズの情報は、Oracle Access Manager管理者ガイドに記載されています。 ObSSOcookieです。 RUEIで使用するためのOAMサーバーの構成手順は、Oracle Real User Experienceインストレーション・ガイドに記載されています。
例11-1 OAMベース・トラフィックのレポート
データ・ブラウザでのユーザーIDのレポートは、識別名(DN)に基づいています。 例を図11-1に示します。
Oracle Access Manager(OAM)トラフィック内のユーザーIDを識別するように、RUEIを構成できます。 OAMバージョン11g (R2PS3 BP02)がサポートされます。 OAMベース・トラフィックを監視する手順は、次のとおりです。
目的のアプリケーションを選択し、ユーザーセクションをクリックします。
新規ソースの追加をクリックします。 図7-32に示すダイアログが表示されます。
「検索タイプ」メニューで、Oracle Access Manager 11gオプションを選択します。
RUEIを使用するためにOAMサーバーを構成する手順は、「Oracle Real User Experienceインストレーション・ガイド」に記載されています。
OAMベース・トラフィックのレポート
データ・ブラウザのユーザーIDsのレポートは、OAM LDAPに記録されたユーザーのuid属性に基づきます。
シングル・サインオン(SSO)とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。 アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。 SSOには次の利点があります。
ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。
同じIDに対するパスワードの再入力に要する時間を省きます。
ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。
SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。
SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。 このためには、SSOプロファイルを作成します。
SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。 次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。 図11-2に、アプリケーション認証が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プロファイルを定義する手順は、次のとおりです。
注意:
SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。 こうしておかないと、予期しない結果がもたらされる可能性があります。 一致ルールが適用される順序を変更できる方法は、「RUEI内でのルール順序設定の制御」を参照してください。
最高レベルのフィルタはドメインです。 ドメインを変更または微調整するには、URLの部分を指定します。 プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。 つまり、空白フィルタは使用できません。 ワイルド・カード文字(*)は、「ポートの検索」フィールド内では指定できず、標準以外のポート(つまりポート80/443)に着信するネットワーク・トラフィックは、ポート番号が明示的に指定されないかぎり、SSOプロファイルに関連付けられません。 指定できるポート番号は1つのみです。 追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。 ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。 フィルタの適用順序を制御する方法は、「RUEI内でのルール順序設定の制御」を参照してください。
準備ができたら、次へをクリックします。 図11-4に示すダイアログが表示されます。
次に、終了をクリックします。 指定したSSOプロファイル定義の概要が表示されます。 例を図11-5に示します。
この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。 この詳細は次の項に記載されています。
ユーザー識別を定義した結果は、ユーザー情報(XLS形式)レポートのクライアントカテゴリで確認できます。 レポートの詳細は、「レポートの操作」を参照してください。
SSOプロファイルを定義後に変更するには、その概要を使用します。 以下のタブを使用することができます。
識別: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。 ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。 新規フィルタを追加するには、新規フィルタの追加をクリックします。 既存のフィルタを変更するには、そのフィルタをクリックします。 図11-6に示すようなダイアログが表示されます。
図11-6 SSOプロファイル・フィルタの編集ダイアログ
ダイアログの最下部にあるメモは、現在のルール順序設定スキームを示します。 これについては、「RUEI内でのルール順序設定の制御」で説明しています。
構成: 使用される認証トークンとCookieを指定します。
ユーザー: ユーザーIDをアプリケーション内で識別する方法を指定します。 これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。
