ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2.2) for All Platforms
B69533-09
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

22 11g Webゲートが関与するセッションの集中ログアウトの構成

この章では、11g Webgateが関与するセッションに対するAccess Managerの単一のログアウト(グローバル・ログアウト)について説明します。Access Managerでは、単一のログアウトはアクティブなセッションを終了するプロセスを意味します。ログアウトには、カスタム・ログアウト・スクリプトではなく、Access Managerが提供するログアウト・メカニズムを使用することをお薦めします。このメカニズムについては、この章で説明します。

この章の内容は次のとおりです。


関連項目:

エージェントに応じて、様々なログアウトの実装ステップが必要になります。

  • 第25章の10g Webゲート・ログアウト

  • 第24章のOSSOエージェント(mod_osso)ログアウト

22.1 前提条件

この章に示すタスクを実行するには、次の前提条件を満たす必要があります。

  • Access Managerによってエージェントが構成され登録されたWebサーバー上に、アプリケーションがデプロイされていなければなりません。

  • サポートされている任意のWebサーバーおよびプラットフォーム上では、1つのOAMエージェントが実行されていて、Access Manager 11gに登録されている必要があります(第16章)。

  • ポリシーは、Access Manager 11gアプリケーション・ドメイン内のリソースを保護するように構成する必要があります(第20章)。

22.2 Access Manager 11gの集中ログアウトの概要

特に明記しないかぎり、この章の情報は、デフォルトの埋込み資格証明コレクタ(ECC)を使用するOAM 11g Webgateエージェントに適用されます。

この項では次のトピックを記載しています:

22.2.1 11g Webgateの集中ログアウトについて

Access Managerは、セッションに集中ログアウト(グローバル・ログアウト)を提供します。集中ログアウトとは、アクティブなセッションを終了するプロセスのことであり、次の事項を意味します。

  • アプリケーションが、SSO環境で使用する固有のログアウト・ページを提供することはできません。

  • アプリケーションは、Webgate Administratorが指定するログアウトURLを参照する値でログアウト・リンクを構成できるようにする必要があります。


注意:

アプリケーションでADF認証サーブレットを使用することをお薦めします。これにより、このサーブレットはOPSSとインタフェース接続し、OPSSでドメイン全体の構成パラメータを使用してログアウトURLを指定できます。この方法であれば、ログアウトの構成を変更するためにアプリケーションの変更や再デプロイが必要になることがありません。

パートナ・アプリケーションとは異なり、外部アプリケーション(Yahoo!メールなど)では、認証がOAMに委任されません。また、ログアウト制御もOAMシングル・サインオン・サーバーに引き渡されません。これらのアプリケーションのログアウトはユーザーの責任となります。

表22-1に、集中ログアウトが行われる状況を示します。ログアウトURLが見つかり、Cookie (11g Webgateの場合はOAMAuthnCookie、10g Webgateの場合はObSSOcookie)が削除された場合。Webgateはユーザーをログアウトさせて、ユーザーの再認証を要求します。

表22-1 集中ログアウトの状況

状況 説明

明示的

クライアントの状態が無効化されてセッションが終了。リソースに再度アクセスしようとする場合、クライアントは再認証を行なわなければなりません。

  • ユーザーがログアウトしたとき

  • 管理者がセッションを終了させたとき

  • アイデンティティ側の変化に基づいてセッションが終了された時

暗黙的

定められたセッション・タイムアウト時間内にユーザー・アクティビティがなかった場合、そのユーザーは自動的にログアウトされてパートナにリダイレクトされ、新しいセッションIDが付与されて資格証明のために新しいプロンプトが表示されます。これは、リソースに対して低レベルの認証が構成されていない場合に実行されます。

Access Managerの場合、logout.htmlにサーバー・ログアウトへの明示的なリダイレクトが指定されていないかぎり、10g Webgateが単にログアウトURLに遭遇しただけではユーザーはログアウトされません。Webgateは、サーバー・ログアウトへユーザーをリダイレクトします。

22.2.2 11g Webgateのログアウト・パラメータ

一般的に、SSOエンジンは、集中ログアウトの際にuser-session-exists要求を受け取ります。セッション管理エンジンはセッションを参照し、the-session-exists応答で応答します。SSOエンジンは、Clear Session要求を送信します。セッション管理エンジンはトークンとセッション・コンテキストを削除します。その後、SSOエンジンは、Session Cleared応答を送信します。

ユーザー・トークンとセッション・コンテキストを削除するとサーバー側の状態が削除されますが、これにはサーバー側に設定されたOAM_ID Cookieを削除することが含まれます。エージェントに通知が行われると、エージェントはアプリケーションのクライアント側状態を削除します。

OAMサーバーからの11g Webgateのログアウトを構成するには、Logout Callback URLが必要になります(表16-3)。11gエージェントの集中ログアウトでは、Cookieをloggedoutからemptyに設定し、ログアウト時にOAMAuthnCookie_<ホスト:ポート>_<ランダムの数値>を期限切れにして、これを明示的に削除します(Cookieを空状態やログアウトされた状態のままにするのではありません)。

11g Webgateと10g Webgateには若干違いがあり、Logout Callback URLのURI部分のみ一致します。

SSOエンジンはOAMサーバー上の集中ログアウト・ページをサポートし、次の処理を行います。

  • ログアウト時に11g WebgateのLogout Callback URLをコールバックします。

    WebgateのパラメータLogout Callback URLは、ホスト:ポート部分のないURI形式(推奨)を使用して構成できます。OAMサーバーは、元の要求に含まれるホスト:ポートを基に動的に完全なURLを作成して、そのURLをコールバックします。これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAMサーバーは、コールバックURLを再構築することなく直接コールバックします。

  • ログアウト後に、end_url(問合せパラメータとして渡される)にランディングします。

11g Webgate登録ページのいくつかの要素は、11g Webgateの集中ログアウトを可能にします。登録後はObAccessClient.xmlファイルに表22-2の情報が格納されます。

表22-2 登録後のログアウトの詳細(ObAccessClient.xml)

要素 説明

ログアウトURL

10gおよび11g Webgate

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはCookieを削除し(10g WebgateではObSSOCookie、11g WebgateではOAMAuthnCookie)、Access Managerに保護されたリソースにユーザーが再アクセスしたときに改めて認証を要求します。

  • 一致する場合、Webgateログアウト・ハンドラが起動します。

  • ログアウトURLが構成されていない場合の要求URLの確認は「logout.」に対して行われ、このURLが見つかった場合も(「logout.gif」と「logout.jpg」を除く)ログアウト・ハンドラがトリガーされます。

Default = [](未設定)

注: これは、カスタマイズしたローカル・ログアウト・ページから初期ログアウトをトリガーするために使用する、標準の10g Webゲート構成パラメータです。これについては、「11g OAMサーバー使用時の10g Webゲートの集中ログアウト構成」の説明を参照してください。

11g Webgateのみのその他のログアウト

11g Webgateシングル・サインオフの動作については、次の要素と値によって、集中ログアウトURL、コールバックURLおよびエンドURLへのリダイレクトが自動化されます。これは、カスタマイズされたローカルのログアウト・ページからのみ、10g Webgateのシングル・サインオンを置き換えます。

ログアウト・コールバックURL

コールバック時にCookieを削除するoam_logout_successへのURLです。これには、host:portのないURI形式を指定でき(推奨)、この場合、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。例:

デフォルト = /oam_logout_success

これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAMサーバーは、コールバックURLを再構築することなく直接コールバックします。

リクエストURLがログアウト・コールバックURLに一致したとき、Webgateは自身のcookieを消去してレスポンスで.gifイメージをストリーミングします。これはOSSOエージェントの動作に似ています。

Webgateがサーバーのログアウト・ページにリダイレクトすると、"end" URLが問合せパラメータ(end_url=http://host:port/...")として記録され、ログアウト後にOAMサーバーがリダイレクトする先のページになります。

注: リモート登録テンプレートでは、このパラメータの名前はlogoutCallbackUrlです(表16-10)。

他のOracle Access Managementサービスは、サーバー上の中央のログアウト・ページをサポートします。end_urlは、OPSS組込みアプリケーションから渡されるターゲットURL問合せパラメータに依存しています。関連項目: 「Oracle ADFコード・アプリケーションの集中ログアウト構成」。

ログアウト・リダイレクトURL

このパラメータは、エージェントの登録が完了すると、自動的に移入されます。デフォルトでは、OAMサーバーのホスト名とデフォルト・ポートの14200に基づきます。例:

デフォルト = http://OAMServer_host:14200/oam/server/logout

ログアウトURLは、ログアウト・ハンドラをトリガーします。これは、OAMAuthnCookie_<host:port>_<random number>を削除して、ユーザーが次回Access Managerにより保護されたリソースにアクセスするときに、再認証を義務付けます。

  • Webgateログアウト・ハンドラがトリガーされると、このハンドラはログアウト・リダイレクトURLパラメータに指定された集中ログアウト・ページにリダイレクトします(ログアウト・リダイレクトURLパラメータが指定されている場合)。

  • 明示的に消去され、構成されていない場合は、10gの動作がトリガーされます。ローカル・ログアウト・ページでは、カスタマイズされたスクリプトを使用して集中ログアウト・ページにリダイレクトが可能で、必要な場合は追加的なサード・パーティのCookieを削除できます。

ログアウト・ターゲットURL

この値は、ログアウト時にOPSSアプリケーションがWebgateに渡す問合せパラメータの名前です。この問合せパラメータは、ログアウト後のランディング・ページのターゲットURLを指定します。

デフォルト: end_url

注: end_url値は、jps-config.xmlのparam.logout.targeturlを使用して構成されます。

  • ログアウト・ターゲットURLが設定されている場合、Webgateはログアウト・リクエストの問合せパラメータで渡された値を探し、それをOAMサーバーへのリダイレクトURL内のend_url問合せパラメータとして渡します。

  • ログアウト・ターゲットURLが設定されていない場合、Webgateはデフォルト名「end_url」を探し、そのend_url問合せパラメータを一緒に渡します。

22.3 11g Webgateの集中ログアウト構成

この項では次のトピックを記載しています:


関連項目:

22.3.1 ECC使用時の11g Webgateの集中ログアウト構成

11gリソースWebgateの登録時または編集時には、ここで説明するようにログアウト・パラメータを構成します。


注意:

LogOutUrlパラメータがすでに11g Webgate用に(/oamsso/logout.html以外の値で)構成されている場合は、LogOutUrlパラメータの一部としても存在していることを確認してください。


関連項目:

「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」

11g Webgateの集中ログアウト構成方法

  1. 登録方法の選択については、第16章「OAM 11gエージェントの登録および管理」を参照してください。

  2. エージェント登録の作成や編集を行なう時は、使用環境に適したログアウト値を含めてください(表22-2)。

    • ログアウトURL

    • ログアウト・コールバックURL

    • ログアウト・リダイレクトURL

    • ログアウト・ターゲットURL

  3. 通常どおりにエージェントの登録を完了して、保存します。

  4. マルチDNSドメイン: Access Manager 11g SSO用に構成されたマルチDNSドメインがある場合は、次のステップを実行します。


    注意:

    Logout Callback URLは各Webゲートに固有のものにできますが、各Webゲートに対してLogout Callback URLを作成するには、OAMサーバーに対して各ドメインの各Webゲートのホストとポートを指定するだけで十分です。Logout Callback URLが参照するファイルは、Webゲートのインストール・ディレクトリにあるlogout.htmlスクリプトとは異なるものでなければなりません。

    1. Logout Callback URLを、各リソースWebゲート上のlogOutUrlsパラメータの2つ目の値として構成します。

      Logout Callback URLは、ドメイン内のSSO Cookieを消去するためのリクエストを送る必要があるWebゲート上の場所です。Logout Callback URLをlogout.htmlにできません。

    2. ファイルが、Logout Callback URLで示される場所(通常はlogout.htmlと同じ場所)にある各Webサーバー上に物理的に存在していることを確認します。

      たとえば、logout.htmlと同じ場所にlogout.pngという名前のファイルを構成する場合、logout.pngのLogout Callback URLの値は次のようになります。

      /oamsso/logout.png

  5. 「グローバル・サインオンと集中ログアウトの検証」に示すステップを実行します。

22.3.2 外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成

DCCは、エージェントからログアウト・リクエストを受信すると、次の処理を実行します。

  • 必要に応じて、ログアウト・リクエストを復号化します。

  • end_urlを取得し、必要に応じてエージェントのhost:portを使用して完全なURLを作成します。

  • DCC Cookieを消去します(DCCCtxCookie)。

  • ログアウト・リクエストをバックチャネル経由で送信して、セッションを終了します。

  • Logout Callback URLLogout Callback URLsにより、訪問したすべてのエージェントへのリンクを含むログアウト・ページを、この情報を保持しているOAMサーバーから取得するか、ログアウト・ページをローカルに作成するために、OAMサーバーから訪問者のリストのみを取得し、DCC上のこのページにユーザーをリダイレクトします。

  • ログアウトが完了したら、end_urlに戻ります。

DCCとは別のリソースWebゲートのログアウトを構成するには:

  1. DCCログアウト用のPerlスクリプトに、Webゲートのホストの$WEBGATE_HOME/oamsso-bin/*pl上にある、Perlの実行可能ファイルの実際の場所が含まれていることを確認してください。

  2. リソースWebゲート: DCCのlogout.plをポイントするように、「ログアウト・リダイレクトURL」を変更します。

    1. リソースWebゲート登録の検出: 「OAMエージェント登録の検索」を参照してください。

    2. DCCのlogout.plをポイントするように、「ログアウト・リダイレクトURL」を変更します。例:


      http://DCCWGhost:port/oamsso-bin/logout.pl

      注意:

      DCCは、Webゲート登録ページ内の「ログアウト・リダイレクトURL」パラメータを無視します。ただし、リソースWebゲートの「ログアウト・リダイレクトURL」がlogout.*以外の場合、そのURLはDCCの「ログアウト・リダイレクトURL」で定義されている必要があります。表19-34「認証用の資格証明コレクタと関連フォームの指定」を参照してください。

  3. 「グローバル・サインオンと集中ログアウトの検証」に示すステップを実行します。

22.4 グローバル・サインオンと集中ログアウトの検証

この項では次のトピックを記載しています:

22.4.1 グローバル・サインオンの確認

シングル・サインオンによるグローバル・ログインの監視には次の手順を使用します。

前提条件

  • エージェントとサーバーがAccess Managerによって登録され、実行されていなければなりません。

  • Access Managerアプリケーション・ドメイン内で、SSOを制御するリソースとポリシーを定義する必要があります。

グローバル・サインオンの監視方法

  1. ブラウザから、保護されたリソースのURLを入力します。

  2. ログイン・ページで、正しい資格証明を使用してサインインします。

  3. リソースが提供されることを確認します。ログアウトはしないでください。

  4. 同じブラウザ・ウィンドウで、別の保護されたリソースのURLを入力し、再認証を求められずにそのリソースが提供されることを確認します。

22.4.2 混在するエージェント・タイプを持つグローバル・サインオンの検証

次の手順を使用して、同じ認証レベルを持つ様々なアプリケーションとエージェントによるシングル・サインオンによるグローバル・ログインを監視します。

たとえば、次の場所に次のパートナがあるものとします。

  • OSSOパートナ、http://host1.example.com:7777/private/index.html、mod_ossoを使用して保護

  • Webgateパートナ、http://host2.example.com:8888/mydomain/finance/index.html、OAMエージェントを使用して保護

同じブラウザ・セッション内で、1回のサインインにより、どちらかのエージェントによって保護されたすべてのアプリケーションにアクセスすることができます。

前提条件

  • エージェントとサーバーがAccess Managerによって登録され、実行されていなければなりません。

  • Access Managerアプリケーション・ドメイン内で、リソースとポリシーを定義する必要があります。

  • どちらのパートナも、同じ認証レベルで保護されていなければなりません。

  • この章の説明に従ってシングル・サインオンが構成されていなければなりません。

様々なエージェント・タイプによるグローバル・サインオンの監視方法

  1. OSSOエージェントに保護されたアプリケーション:

    1. ブラウザから、OSSOで保護されたリソースのURLを入力します。

    2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

    3. 保護されたリソースを使用できることを確認します。

    4. 同じブラウザ・セッションを維持して、ステップ2に進みます。

  2. 同じブラウザ・セッション、OAMエージェントに保護されたアプリケーション:

    1. ステップ1と同じブラウザ・セッションで、OAMエージェントに保護されたリソースのURLを入力します。

    2. 保護されたリソースを使用できることと、ログイン・ページが表示されないことを確認します。

  3. ブラウザ・セッションをログアウトします。

  4. 新しいブラウザ・セッション、OAMエージェントに保護されたアプリケーション:

    1. 新しいブラウザ・セッションで、OAMに保護されたリソースのURLを入力します。

    2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

    3. 保護されたリソースを使用できることを確認します。

    4. 同じブラウザ・セッションを維持して、ステップ5に進みます。

  5. 同じブラウザ・セッション、OSSOエージェントに保護されたアプリケーション:

    1. ステップ4と同じブラウザ・セッションで、OSSOエージェントに保護されたリソースのURLを入力します。

    2. 保護されたリソースを使用できることと、ログイン・ページが表示されないことを確認します。

22.4.3 集中ログアウトの監視

次の手順を使用して集中ログアウトを監視します。

  • OAMエージェントの場合はログアウトURLがサーバーへのリダイレクトを行い、その後の要求によってCookieが特定されないようにCookieが消去されて無効化されます。

  • mod_ossoの場合は、各エージェントがそのCookieを破棄します。ログアウトURLがサーバー上のグローバル・ログアウト・ページへのリダイレクトを行い、各パートナがそのサーバーにCookieを送ります。

前提条件

  • エージェントが登録されて実行されていなければなりません。

  • リソースはAccess Managerアプリケーション・ドメインによって保護されている必要があります。

  • シングル・サインオンは、Access Managerアプリケーション・ドメイン内で、認証および認可のためのポリシーと応答によって構成されている必要があります。

集中ログアウトの監視方法

  1. 1つのアプリケーション:

    1. ブラウザから、保護されたリソースのURLを入力します。

    2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

    3. 保護されたリソースを使用できることを確認します。

    4. 新しいブラウザ・タブまたはウィンドウを開いて同じリソースにアクセスし、2回目のアクセス時に新たなログインが要求されないことを確認します。

    5. 1つのタブからログアウトします。

    6. もう一度そのリソースにアクセスして、ログイン・ページが表示されることを確認します。

  2. 2つのアプリケーション:

    1. ブラウザから、保護されたリソースのURLを入力します。

    2. ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。

    3. 新しいタブまたはウィンドウで、別の保護されたアプリケーションにアクセスし、2つ目のアプリケーションで新たなログインを要求されないことを確認します。

    4. 1つ目のアプリケーションからログアウトします。

    5. 2つ目のアプリケーションにアクセスして、ログイン・ページが表示されることを確認します。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引