プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11g リリース2 (11.1.2.3) for All Platforms
E61950-08
目次へ移動
目次
前
前 		次
次

21.5 SSO Cookieの理解

ここでは、Access Manager 11gによるシングル・サインオンの概要を示します。

次のトピックが含まれています:

21.5.1 ユーザー・ログイン時のシングル・サインオンCookie

ユーザー・ログイン中に、シングル・サインオンを設定またはクリアできます。

表21-6に、Cookieの詳細をまとめます。

表21-6 SSO Cookie

ユーザー・ログインで設定されるSSO Cookie 設定元 説明

OAM_ID Cookie

OAMサーバーの埋込み資格証明コレクタ

ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。

関連項目: 「OAM_ID Cookie」。

OAMAuthnCookie

11g Webゲート

アクセスする各11g Webgateによって設定されます。11g WebgateおよびOAMサーバーで認識されるキーで保護されます。有効なOAMAuthnCookieがセッションに必要です。

ノート: 異なる11g Webgateで保護されるアプリケーションにユーザーがアクセスする場合、複数のOAMAuthnCookieを使用します。

「OAM WebゲートのOAMAuthnCookie」を参照してください。
   

10g Webgateにアクセスする場合のみ、10g WebgateのドメインベースCookieが設定されます。OAMサーバーでのみ認識されるキーで保護されます。すべてのWebgateに対して1つのグローバル共有秘密キーです。

ノート: このCookieによって、Access Manager 11gと以前のエージェントの間の下位互換性および相互運用性が実現します。

「10g WebgateのObSSOCookie」を参照してください。

OAM_REQ

OAMサーバーの埋込み資格証明コレクタ

認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定またはクリアされる一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。

ノート: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

「OAM_REQ Cookie」を参照してください。

OAMRequestContext

11g Webゲート

11g Webgateによって設定またはクリアされ、11g WebgateおよびOAMサーバーで認識されるキーで保護されます。

Internet Explorerブラウザの場合:

--RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextは一時的なCookieになります。

--RequestContextCookieExpTimeが設定されている場合、OAMRequestContext Cookieは、Expiresディレクティブを使用して設定されている時間で、有効期限が切れます。これには、クライアント・ホストとWebサーバー・ホスト間の時間同期が必要です。

IE以外のすべてのブラウザでは、RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextはデフォルトの5分間か、Max-Ageディレクティブを使用して設定されている時間で有効期限が切れます。

関連項目: 「OAMRequestContext」

表15-2

DCCCtxCookie

外部資格証明コレクタ

外部資格証明コレクタ(DCC)の場合は、埋込み資格証明コレクタ(ECC)で作成されるOAM_REQと同様になります。

「DCCCtxCookie」を参照してください。

OHS-host-port

Oracle HTTP Server

Oracle HTTP Server (OHS)でOSSOエージェント(mod_osso)にアクセスする場合のみ設定されます。mod_ossoエージェントおよびOAMサーバーで認識されるキーで保護されます。

ノート: このCookieによって、Access Manager 11gと以前のエージェントの間の下位互換性および相互運用性が実現します。

「mod_osso Cookies」を参照してください。

OAM_GITO Cookie

OAMサーバー

OSSO 10gおよびAccess Manager 11gの間の下位互換性および相互運用性を実現します。このCookieはOAMサーバーによって作成され、OAMサーバーまたはmod_ossoエージェントによってアクセスまたは変更されます。

「mod_osso Cookies」を参照してください。

OpenSSO Cookie

OpenSSOプロキシ

「OpenSSO Cookie (iPlanetDirectoryPro)」を参照してください。

認証および認可ポリシーの構成の詳細は、「リソースの保護およびSSOの有効化ポリシーの管理」を参照してください。

21.5.2 シングル・サインオン・サーバーおよびエージェントCookie

次の各項では、SSOサーバーおよびエージェントのCookieについて説明します。

21.5.2.1 OAM_ID Cookie

OAM_ID Cookieは、OAMサーバーが適用範囲になります。OAM_IDは、ユーザーが資格証明のチャレンジを受けたときにOAMサーバーによって生成され、サーバーへのリダイレクトごとにそのサーバーに送信されます。OAM_IDは、OAMサーバーのみが認識するキーで保護されます。

ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。

  • Cookieが存在しない場合、ユーザー認証が開始されます。認証に成功した後、ユーザー・コンテキストおよびトークンがSSOエンジンによって設定されます。Cookieは、グローバル・ユーザーID (GUID)、作成時間およびアイドル・タイムアウトの詳細で設定されます。Cookieの情報はSSOサーバー・キーで暗号化され、SSOエンジンでのみ復号化できます。

  • Cookieが存在する場合、Cookieが復号化され、サインインのフローが認証されたユーザーで終了します。

21.5.2.2 OAM WebゲートのOAMAuthnCookie

認証の成功後にOAMサーバーから受け取った認証トークンを使用して各OAM Webゲートで設定された1つのOAMAuthnCookie_<host:port>_<random number>があります。有効なOAMAuthnCookieがセッションに必要です。

SSL接続: 管理者は、SSLを構成してエージェントおよびサーバーの簡易または証明書モードを指定し、SSL接続でのみObSSOCookieの送信を可能にしてCookieが安全でないWebサーバーに送信されることを防止します。詳細は、「OAMサーバーとWebゲート間の通信について」を参照してください。

Cookieの有効期間: OAM WebゲートおよびOAMAuthnCookieでは、有効なトークン(またはCookie)時間を制御するtokenValidityPeriodパラメータで有効期間が管理されます。

このキーは、OAM WebゲートおよびSSOエンジンで識別され、OAMAuthnCookieの暗号化に使用されます。SSOエンジン・キー(SSOエンジンでのみ識別)は、OAM_ID OAMサーバーCookieの暗号化に使用されます。

21.5.2.3 10g WebgateのObSSOCookie

Access Manager 11gは、10g Webgateで保護されているリソースにアクセスする各ユーザーまたは各アプリケーションに対して、キーベースCookieであるObSSOCookieを設定します。エージェントの登録中にキーが設定され、エージェントおよびSSOエンジンで識別されます(両方で共有されます)。このキーは、OAMサーバー(またはSSOエンジン)キーとは異なります。

ObSSOcookieを削除すると10g Webgateからユーザーがログアウトするので、アクセス・システムで保護されるリソースを次にリクエストするときにユーザーの再認証が必要になります。

WebGateは、認証に成功するとObSSOCookieをユーザーのブラウザに送信します。このCookieは、同等またはそれ以下のレベルの認証を必要とする他の保護されたリソースの認証メカニズムとして使用できます。ユーザーがブラウザまたは別のリソースへのアクセスをリクエストすると、リクエストがOAMサーバーに送信されます。ユーザーがログインし、ObSSOCookieが設定されます。OAMサーバーは、ObSSOCookieを含むURLを使用したセッション・トークンを生成します。ユーザーに認可資格証明を求めるかわりに後続の認可でCookieが使用される場合、シングル・サインオンが有効です。

Cookieが生成されると、Cookieの一部が暗号化されたセッション・ トークンとして使用されます。シングル・サインオンCookieは、ユーザー名およびパスワードなどのユーザー資格証明を含みません。

SSL接続: 管理者は、SSLを構成してエージェントおよびサーバーの簡易または証明書モードを指定し、SSL接続でのみObSSOCookieの送信を可能にしてCookieが安全でないWebサーバーに送信されることを防止します。詳細は、「OAMサーバーとWebゲート間の通信について」を参照してください。

Cookieの有効期間: 管理者は、OAMエージェント登録の目的のCookieセッション時間を指定できます。詳細は、「コンソールを使用したOAMエージェントの登録」を参照してください。

21.5.2.4 OAM_REQ Cookie

認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定またはクリアされる一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。

資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。

高可用性構成では、インフラストラクチャ・セキュリティ・カスタムWLSTコマンドを使用してリクエスト・キャッシュ・タイプをBASICからCOOKIEに変更する必要があります。

ノート:

Oracle共通ホームからWLSTスクリプトを起動する必要があります。『Oracle Fusion Middlewareの管理のコマンドライン・インタフェースの起動方法に関する項を参照してください。

関連項目:

  • WebLogic Server WLSTコマンド・リファレンス

  • 表21-6

21.5.2.5 OAMRequestContext

OAMRequestContextは、12cリソースのWebゲートによって設定またはクリアされ、12c WebゲートとOAMサーバーそれぞれで認識されるキーで保護されます。

資格証明が収集され、認証が実行される一方で、このCookieは、保護されたリソースへのユーザーの元のリクエストの状態を格納するように構成されます。

  • Internet Explorerブラウザの場合:

    • RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextは一時的なCookieになります。

    • RequestContextCookieExpTimeが設定されている場合、OAMRequestContext Cookieは、Expiresディレクティブを使用して設定されている時間で有効期限が切れます。これには、クライアント・ホストとWebサーバー・ホスト間の時間同期が必要です。

  • IE以外のすべてのブラウザでは、RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextはデフォルトの5分間か、Max-Ageディレクティブを使用して設定されている時間で有効期限が切れます。

関連項目:

表15-2のRequestContextCookieExpTime

21.5.2.6 DCCCtxCookie

DCCCtxCookieは、外部資格証明コレクタ(DCC)にのみ作用します。DCCCtxCookieは、認証時に必要な各種のコンテキスト情報を保存するために、DCCで使用されます。

これに含まれる情報は、認証が完了した時点で元のリクエストを再作成するため、サーバー・アフィニティを保持するため、および反復複数ステップの認証を実行するために必要です。

デフォルトでは、DCCCtxCookieは、認証スキームに基づいて資格証明を収集するために、DCCが最初にリダイレクトされたときに設定されます(フォームによる認証スキームでは、ブラウザが最初にログイン・フォームにリダイレクトされたとき)。

DCCの場合、認証後にOAMサーバーが、認証レスポンスでDCCに向けてDCCセッション・トークンを発行します。その後で、DCCはこのトークンを使用してホストベースのDCC Cookieを設定し、次の処理を実行します。

  • 認証時にDCC Cookieが提示された場合: DCCは、DCCキーを使用してトークンを復号し、部分的なトークンの検証をローカルに実行します(整合性チェック、トークンの有効期間チェック)。この検証をパスすると、DCCはOAMサーバーに対するOAPチャネルで、タイムアウトについての完全なトークンの検証を実行します。

  • DCC Cookieが存在しない場合: これは、最初の認証であることを示すため、資格証明コレクションが開始し、資格証明のサニティ・チェックと構文チェックを実行してから、その資格証明を検証するためにOAMサーバーに送信します。

関連項目:

「DCC対応の11g Webゲートと認証ポリシーの構成」

21.5.2.7 DCCCtxCookie_COUNT

DCCCtxCookie_COUNT Cookieは、DCCCtxCookieの分割後に生成されるCookieの数を保持します。DCCCtxCookie_COUNT Cookieによって数が決まる一方、構成パラメータMaxSplittedCookieSizeによって各DCCCtxCookie Cookieのサイズが決まります。デフォルトでは、サイズは4KBに設定されます。

この機能により、Webゲートでは大規模なDCCCtxCookie Cookieを処理できるようになります。DCCCtxCookieのサイズが4 KBを超える場合、ブラウザによってはサポートされず、ユーザー認証が失敗することがあります。DCCCtxCookie Cookieを各サイズが4 KB以下の複数のCookieに分割するには、Webゲートの構成パラメータMaxSplittedCookieSizeに適切な値を設定します。DCCCtxCookie Cookieの分割後に生成されるCookieの数は、DCCCtxCookie_COUNT Cookieによって追跡管理されます。

たとえば、リクエストされたURLが長すぎる場合、DCCCtxCookie Cookieのサイズは6 KBになります。デフォルト設定では、DCCCtxCookieは次のように2つのCookieに分割されます。

DCCCtxCookie_HOST:PORT_1 (サイズ: 4 KB)

DCCCtxCookie_HOST:PORT_2 (サイズ: 2 KB)

長いURLの処理中に'不正なリクエスト'エラーが発生する可能性があります。このエラーを回避するには、httpd.confファイルを編集し、LimitRequestFieldSizeパラメータを追加します。LimitRequestFieldSizeのデフォルト値は8 KBです。

21.5.2.8 mod_osso Cookie

mod_ossoモジュールは、OracleASアプリケーションの認証を提供するOracle HTTP Serverモジュールです。ユーザーがOracleAS Single Sign-Onサーバーにログインした後、OracleAS Single Sign-Onで保護されるアプリケーションを有効化してユーザー名およびパスワードのかわりにHTTPヘッダーを受け入れるOracle HTTP Serverにこのモジュールが存在します。これらのヘッダーの値がmod_osso Cookieに格納されます。アプリケーション・サーバーに格納されるmod_ossoは、シングル・サインオン・サーバーの唯一のアプリケーションとして認証プロセスを簡易化します。このため、mod_ossoは、OracleASアプリケーションに透過的な認証を実現します。

これらのアプリケーションの管理者は、アプリケーションをSDKに統合する負担がなくなります。mod_ossoは、ユーザーを認証した後、アプリケーションがユーザーを認可するために使用できる単純なヘッダー値を送信します。

OAM_GITO Cookie

Access Manager 11gとともに動作する複数のタイプのエージェント(mod_ossoおよびWebゲート)でタイムアウトをサポートする特別なケースで必要になります。サーバー側のセッション・マネージャは、セッションの検証中に有効期間およびタイムアウトのCookieの妥当性を確認できます。エンティティのセッションのログアウトでログアウトがすべてのエンティティに伝播していることを確認するには、OSSOエージェント(mod_osso)のグローバル・ログアウトが必要です。

ユーザーがOSSO 10gにより認証されると、OSSOサーバーによってOAM_GITO Cookieが設定されます。パートナCookie (OHS Cookie)が設定されると、OHSはサーバーのリクエストをルーティングしません。かわりに、OHSはアクセスのたびにOAM_GITO Cookieを復号化し、最後のアクティビティのタイムスタンプを更新します。リクエストの処理中に、現在の時間がGITOタイムアウト(最終アクティビティ時間 + GITOタイムアウト)を超えたことをパートナが検出すると、リクエストが強制認証モードでOSSO 10gに送信されます。リクエストが強制認証モードでOSSOサーバーに達すると、サーバーはSSO_ID Cookieを無視して、新しいリクエストとして資格証明のユーザーを要求します。認証に成功した後、SSO_IDおよびOAM_GITO Cookieが更新されます。

『WebLogic Server WLSTコマンド・リファレンス』に従ってeditGITOValues WLSTコマンドを使用すると有効になります。

OssoSecureCookiesディレクティブ

OssoSecureCookiesディレクティブを追加して、すべてのCookieにSecureフラグを設定します。これにより、HTTPSで保護された接続のCookieのみの送信がブラウザに通知されます。mod_osso構成(mod_osso.conf)のこのディレクティブの例は、次のとおりです。

<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoSecureCookies on
OssoConfigFile osso/osso.conf
<Location /j2ee/webapp>
require valid-user
AuthType Basic
</Location>
</IfModule>

詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。

21.5.2.9 OpenSSO Cookie (iPlanetDirectoryPro)

OpenSSOプロキシがセッション検証をトリガーした後、エージェントがOpenSSO Cookieを検出します。OpenSSO Cookieのデフォルト名は、iPlanetDirectoryProです。

OpenSSOエージェントは、認証されてログインした後、ユーザーがOpenSSO Cookieを持っているかどうかを検証します。持っていない場合、OpenSSOエージェントがユーザー認証リクエストを開始します。SSOユーザー・ログインおよび認証フロー中に、OpenSSO Cookieが作成され、ユーザーのブラウザに設定されます。このCookieにはOpenSSOセッション識別子が含まれます。

エンド・ユーザー・セッション検証では、OpenSSOエージェントが保護されているアプリケーションへのリクエストを捕捉し、OpenSSO Cookieを検出します。

ユーザー・シングル・ログアウト時に、OpenSSOプロキシはユーザー・ログアウト・リクエストを受信して、ユーザーをOAMログアウトURLに転送します。OpenSSOプロキシは、OpenSSO Cookieを復号化して、OpenSSOセッション識別子をフェッチし、そこからOAMセッションIDをフェッチします。OpenSSOプロキシは、ログアウト・リクエストをOAMセッションIDとともに、OpenSSOログアウト・イベントを介して、コントローラに送信します。

  • SSOユーザー・ログインおよび認証フロー

  • エンド・ユーザー・セッションの検証フロー

  • ユーザー・シングル・ログアウト・フロー

前
前 		次
次
目次へ移動
目次