27 OAM Webゲートが関与するセッションの集中ログアウトの構成
OAM Webゲートが関与するセッションには、Access Managerの単一のログアウト(グローバル・ログアウト)を使用できます。Access Managerでは、単一のログアウトはアクティブなセッションを終了するプロセスを意味します。次の各トピックで説明する方法で(カスタム・ログアウト・スクリプトではなく)、Access Managerが提供するログアウト・メカニズムを使用することをお薦めします。
次の各トピックでは、OAM Webゲートを使用したセッションの集中ログアウトを構成する方法について説明します。
27.1 OAM Webゲートが関与する集中ログアウト・セッションの構成のための前提条件
ログアウト・セッションの構成を続行する前に、システム・レベル要件が満たされていることを確認します。
次に、この章のタスクを実行するための要件を示します。
-
Access Managerによってエージェントが構成され登録されたWebサーバー上に、アプリケーションがデプロイされていなければなりません。
-
サポートされている任意のWebサーバーおよびプラットフォーム上では、1つのOAMエージェントが実行されていて、Access Manager 12cに登録されている必要があります。
-
ポリシーは、Access Manager 12cアプリケーション・ドメイン内のリソースを保護するように構成する必要があります。
27.2 Access Managerの集中ログアウトの概要
集中ログアウトとは、アクティブなセッションを終了するプロセスのことです。OAMでは、セッションの集中ログアウトが提供されます。
特に明記しないかぎり、この章の情報は、デフォルトの埋込み資格証明コレクタ(ECC)を使用するOAM Webゲート・エージェントに適用されます。
この項では次のトピックを記載しています:
27.2.1 OAM Webゲートの集中ログアウトについて
Access Managerは、セッションに集中ログアウト(グローバル・ログアウト)を提供します。
集中ログアウトとは、アクティブなセッションを終了するプロセスのことであり、次の事項を意味します。
-
アプリケーションが、SSO環境で使用する固有のログアウト・ページを提供することはできません。
-
アプリケーションは、Webゲート管理者が指定したログアウトURLを指す値でログアウト・リンクを構成できるようにする必要があります。
ノート:
アプリケーションでADF認証サーブレットを使用することをお薦めします。これにより、このサーブレットはOPSSとインタフェース接続し、OPSSでドメイン全体の構成パラメータを使用してログアウトURLを指定できます。この方法であれば、ログアウトの構成を変更するためにアプリケーションの変更や再デプロイが必要になることがありません。
パートナ・アプリケーションとは異なり、外部アプリケーション(Yahoo!メールなど)では、認証がOAMに委任されません。また、ログアウト制御もOAMシングル・サインオン・サーバーに引き渡されません。これらのアプリケーションのログアウトはユーザーの責任となります。
表27-1に、集中ログアウトが行われる状況を示します。ログアウトURLに移動し、OAM WebゲートのOAMAuthnCookie Cookieが削除されている場合、Webゲートでは、ユーザーのログアウトが行われ、ユーザーの再認証が必要になります。
表27-1 集中ログアウトの状況
状況 | 説明 |
---|---|
明示的 |
クライアントの状態が無効化されてセッションが終了。リソースに再度アクセスしようとする場合、クライアントは再認証を行なわなければなりません。
|
暗黙的 |
定められたセッション・タイムアウト時間内にユーザー・アクティビティがなかった場合、そのユーザーは自動的にログアウトされてパートナにリダイレクトされ、新しいセッションIDが付与されて資格証明のために新しいプロンプトが表示されます。これは、リソースに対して低レベルの認証が構成されていない場合に実行されます。 Access Managerの場合、logout.htmlにサーバー・ログアウトへの明示的なリダイレクトが指定されていないかぎり、OAM Webゲートが単にログアウトURLに遭遇しただけではユーザーはログアウトされません。Webgateは、サーバー・ログアウトへユーザーをリダイレクトします。 |
27.2.2 OAM Webゲートのログアウト・パラメータ
一般に、集中ログアウトの際に、SSOエンジンはuser-session-exists
リクエストを受信し、Session Cleared
レスポンスを送信します。
SSOエンジンがuser-session-exists
リクエストを受信すると、セッション管理エンジンはセッションを参照し、the-session-exists
レスポンスで応答します。SSOエンジンは、Clear Session
要求を送信します。セッション管理エンジンはトークンとセッション・コンテキストをクリアします。その後、SSOエンジンは、Session Cleared
応答を送信します。
ユーザー・トークンとセッション・コンテキストをクリアするとサーバー側の状態がクリアされますが、これにはサーバー側に設定されたOAM_ID Cookieをクリアすることが含まれます。エージェントに通知が行われると、エージェントはアプリケーションのクライアント側状態をクリアします。
OAMサーバーからのOAM Webゲートのログアウトを構成するには、「ログアウト・コールバックURL」
が必要になります(表15-3)。12cエージェントの集中ログアウトでは、Cookieをloggedout
からempty
に設定し、ログアウト時にOAMAuthnCookie_<host:port>_<random number>を期限切れにして、これを明示的に削除します(Cookieを空状態やログアウトされた状態のままにするのではありません)。
SSOエンジンはOAMサーバー上の集中ログアウト・ページをサポートし、次の処理を行います。
-
ログアウト時にOAM Webgateの
Logout Callback URL
をコールバックしますWebゲートのパラメータ
「ログアウト・コールバックURL」
は、host:port部分のないURI形式(推奨)を使用して構成できます。OAMサーバーは、元の要求に含まれるホスト:ポートを基に動的に完全なURLを作成して、そのURLをコールバックします。これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAMサーバーは、コールバックURLを再構築することなく直接コールバックします。 -
ログアウト後に、
end_url
(問合せパラメータとして渡される)にランディングします。
OAM Webgate登録ページのいくつかの要素は、OAM Webgateの集中ログアウトを可能にします。登録後はObAccessClient.xmlファイルに表27-2の情報が格納されます。
表27-2 登録後のログアウトの詳細(ObAccessClient.xml)
要素 | 説明 |
---|---|
ログアウトURL OAM Webゲート |
ログアウトURLによってログアウト・ハンドラがトリガーされ、これによってCookie (OAM Webゲートの場合、OAMAuthnCookie)が削除されるため、Access Managerによって保護されたリソースにユーザーが次回アクセスすると、再認証が要求されます。
Default = [] (設定なし) ノート: これは、カスタマイズされたローカル・ログアウト・ページを通じて最初のログアウトをトリガーするために使用される標準のOAM Webゲート構成パラメータです。 |
OAM WebGateのみのその他のログアウト |
OAM WebGateのシングル・サインオフ動作では、以下の要素と値が、集中ログアウトURL、コールバックURL、およびエンドURLへのリダイレクトを自動化します。これは、カスタマイズされたローカルのログアウト・ページからのみ、OAM Webゲートのシングル・サインオフを置き換えます。 |
ログアウト・コールバックURL |
コールバック時にCookieをクリアする デフォルト = /oam_logout_success これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAMサーバーは、コールバックURLを再構築することなく直接コールバックします。 リクエストURLがログアウト・コールバックURLに一致したとき、Webgateは自身のcookieをクリアしてレスポンスで.gifイメージをストリーミングします。 Webgateがサーバーのログアウト・ページにリダイレクトすると、"end" URLが問合せパラメータ( ノート: リモート登録テンプレートでは、このパラメータの名前はlogoutCallbackUrlです(表15-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により保護されたリソースにアクセスするときに、再認証を義務付けます。
|
ログアウト・ターゲットURL |
この値は、ログアウト時にOPSSアプリケーションがWebgateに渡す問合せパラメータの名前です。この問合せパラメータは、ログアウト後のランディング・ページのターゲットURLを指定します。 デフォルト: end_url ノート: end_url値は、jps-config.xmlのparam.logout.targeturlを使用して構成されます。
|
27.3 OAM Webゲートの集中ログアウト構成
ECCとDCCの両方に対応するOAM Webゲートの集中ログアウトを構成できます。
この項では次のトピックを記載しています:
27.3.1 ECC使用時のOAM Webゲートの集中ログアウト構成
12cリソースWebゲートの登録時または編集時に、ログアウト・パラメータを構成します。
ノート:
LogOutUrl
パラメータがすでにOAM Webゲート用に(/oamsso/logout.html
以外の値で)構成されている場合は、LogOutUrl
パラメータの一部としても存在していることを確認してください。
OAM WebGateの集中ログアウト構成するには:
-
登録方法の選択については、「OAMエージェントの登録および管理」を参照してください
-
エージェント登録の作成や編集を行なう時は、使用環境に適したログアウト値を含めてください(表27-2)。
-
ログアウトURL
-
ログアウト・コールバックURL
-
ログアウト・リダイレクトURL
-
ログアウト・ターゲットURL
-
-
通常どおりにエージェントの登録を完了して、保存します。
-
マルチDNSドメイン: Access Manager 12c SSO用に構成されたマルチDNSドメインがある場合は、次のステップを実行します。
ノート:
「ログアウト・コールバックURL」
は各Webゲートで一意の値にできますが、各Webゲートに対して「ログアウト・コールバックURL」
を作成するには、OAMサーバーに対して各ドメインの各Webゲートのホストとポートを指定するだけで十分です。「ログアウト・コールバックURL」
が指しているファイルは、Webゲートのインストール・ディレクトリにあるlogout.htmlスクリプトとは異なるファイルである必要があります。-
「ログアウト・コールバックURL」
を、各リソースWebゲートのlogOutUrls
パラメータの2つ目の値として構成します。「ログアウト・コールバックURL」
は、ドメイン内のSSO Cookieをクリアするためのリクエストを送信する宛先のWebゲート上の場所です。Logout Callback URL
をlogout.htmlにできません。 -
ファイルが、
Logout Callback URL
で示される場所(通常はlogout.htmlと同じ場所)にある各Webサーバー上に物理的に存在していることを確認します。たとえば、logout.htmlと同じ場所にlogout.pngという名前のファイルを構成する場合、logout.pngの
Logout Callback URL
の値は次のようになります。/oamsso/logout.png
-
-
「グローバル・サインオンと集中ログアウトの検証」に示すステップを実行します。
27.3.2 外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成
DCCは、エージェントからログアウト・リクエストを受信すると、次の処理を実行します。
-
必要に応じて、ログアウト・リクエストを復号化します。
-
end_url
を取得し、必要に応じてエージェントのhost:portを使用して完全なURLを作成します。 -
DCC Cookieをクリアします(DCCCtxCookie)。
-
ログアウト・リクエストをバックチャネル経由で送信して、セッションを終了します。
-
Logout Callback URL
Logout Callback URLs
により、訪問したすべてのエージェントへのリンクを含むログアウト・ページを、この情報を保持しているOAMサーバーから取得するか、ログアウト・ページをローカルに作成するために、OAMサーバーから訪問者のリストのみを取得し、DCC上のこのページにユーザーをリダイレクトします。 -
ログアウトが完了したら、
end_url
に戻ります。
DCCとは別のリソースWebゲートのログアウトを構成するには::
-
DCCログアウト用のPerlスクリプトに、Webゲートのホストの
$WEBGATE_HOME/oamsso-bin/*pl
上にある、Perlの実行可能ファイルの実際の場所が含まれていることを確認してください。 -
リソースWebゲート: DCCのlogout.plをポイントするように、「ログアウト・リダイレクトURL」を変更します。
-
リソースWebゲート登録の検出: 「Webゲートの検索コントロール」を参照してください。
-
DCCのlogout.plをポイントするように、
「ログアウト・リダイレクトURL」
を変更します。たとえば:-
http://
DCCWGhost:port/
oamsso-bin/logout.pl
ノート:
DCCは、Webゲート登録ページ内の
「ログアウト・リダイレクトURL」
パラメータを無視します。ただし、リソースWebゲートの「ログアウト・リダイレクトURL」
がlogout.*
以外の場合、そのURLはDCCの「ログアウト・リダイレクトURL」
で定義されている必要があります。表24-3を参照してください -
-
-
「グローバル・サインオンと集中ログアウトの検証」に示すステップを実行します。
27.4 グローバル・サインオンと集中ログアウトの検証
様々なアプリケーションでのシングル・サインオンによるグローバル・ログインと、1つまたは2つのアプリケーションでの集中ログアウトを検証できます。
この項では次のトピックを記載しています:
27.4.1 グローバル・サインオンの確認
シングル・サインオンによるグローバル・ログインを監視できます。
次の前提条件を満たしている必要があります。
-
エージェントとサーバーがAccess Managerによって登録され、実行されていなければなりません。
-
Access Managerアプリケーション・ドメイン内で、SSOを制御するリソースとポリシーを定義する必要があります。
グローバル・サインオンを監視するには:
- ブラウザから、保護されたリソースのURLを入力します。
- ログイン・ページで、正しい資格証明を使用してサインインします。
- リソースが提供されることを確認します。ログアウトはしないでください。
- 同じブラウザ・ウィンドウで、別の保護されたリソースのURLを入力し、再認証を求められずにそのリソースが提供されることを確認します。
27.4.2 集中ログアウトの監視
OAMエージェントでの集中ログアウトを監視できます。
-
OAMエージェントの場合はログアウトURLがサーバーへのリダイレクトを行い、その後の要求によってCookieが特定されないようにCookieがクリアされて無効化されます。
次の前提条件を満たしている必要があります。
-
エージェントが登録されて実行されていなければなりません。
-
リソースはAccess Managerアプリケーション・ドメインによって保護されている必要があります。
-
シングル・サインオンは、Access Managerアプリケーション・ドメイン内で、認証および認可のためのポリシーと応答によって構成されている必要があります。
集中ログアウトを監視するには:
-
1つのアプリケーション:
-
ブラウザから、保護されたリソースのURLを入力します。
-
ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。
-
保護されたリソースを使用できることを確認します。
-
新しいブラウザ・タブまたはウィンドウを開いて同じリソースにアクセスし、2回目のアクセス時に新たなログインが要求されないことを確認します。
-
1つのタブからログアウトします。
-
もう一度そのリソースにアクセスして、ログイン・ページが表示されることを確認します。
-
-
2つのアプリケーション:
-
ブラウザから、保護されたリソースのURLを入力します。
-
ログイン・ページが表示されること、および正しい資格証明でサインインできることを確認します。
-
新しいタブまたはウィンドウで、別の保護されたアプリケーションにアクセスし、2つ目のアプリケーションで新たなログインを要求されないことを確認します。
-
1つ目のアプリケーションからログアウトします。
-
2つ目のアプリケーションにアクセスして、ログイン・ページが表示されることを確認します。
-