1. Oracle Access Management管理者ガイド
  2. マルチデータ・センターの実装
  3. マルチデータ・センターの理解

17 マルチデータ・センターの理解

Oracle Access Managerでは、複数のデータ・センターにディレクトリ・サービス・データの同一コピーを配布できます。これらの複数のデータ・センター(マルチデータ・センターとも呼ばれる)によって、数百万人ものユーザーのアクセス管理要件をサポートするスケーラブルなデプロイメント・モデルが実現します。

Access Managerマルチデータ・センターのトポロジは、水平方向に拡大縮小します(複数ノードをクラスタ化することによって1つのデータ・センター内に収めたり、複数のデータ・センターにわたって構成することもできます)。このモデルによって、ロード・バランシングが実現するとともに、ノードまたはデータ・センターの1つが停止した場合のフェイルオーバーも可能になります。この章では、概要の詳細について説明します。

17.1 マルチデータ・センターの概要

Access Managerを使用する大規模な組織は一般的に、そのアプリケーションをマルチデータ・センター(MDC)全体にデプロイして、負荷を分散し、障害時リカバリに対応します。Access Managerをマルチデータ・センターにデプロイすると、データ・センター間のシングル・サインオン(SSO)の構成後に、ユーザー・セッションの詳細を透過的に転送できます。

データ・センターのスコープに含まれるものとしては、保護されたアプリケーション、Webゲート・エージェント、Access Managerサーバーおよびその他のインフラストラクチャ・エンティティ(アイデンティティ・ストアやデータベースなど)があります。

ノート:

Access Managerでは、アプリケーションを2つ以上のデータ・センターに分散するというシナリオもサポートされます。

Access Managerでサポートされるマルチデータ・センター・アプローチは、マスター/クローン型のデプロイメントであり、最初のデータ・センターがマスターとして指定され、1つ以上のクローン・データ・センターがそれをミラーリングします。(マスター・データ・センターとクローン・データ・センターは、それぞれサプライヤ・データ・センターとコンシューマ・データ・センターと呼ぶこともできます)。マルチデータ・センターの設定中に、セッション・アダプション・ポリシーが構成され、マスター・データ・センターの停止時のリクエストの送信先が決定されます。設定後、マスターからクローンへのデータのレプリケーション方法が指定されます。これは、自動ポリシー同期(APS)レプリケーション・サービスを使用するか、手動によって実行できます。

データ・センターには、アプリケーション、データ・ストア、ロード・バランサなどが含まれます。各データ・センターに、Access Managerのフル・インストールが含まれます。Access ManagerのインスタンスがインストールされているWebLogic Serverドメインが複数のデータ・センターにまたがることはありません。さらに、データ・センターは、ユーザー対データ・センターのアフィニティを保持します。図17-1に、マルチデータ・センターのシステム・アーキテクチャを示します。

図17-1 マルチデータ・センターのシステム・アーキテクチャ

図17-1の説明が続きます
「図17-1 マルチデータ・センターのシステム・アーキテクチャ」の説明

ノート:

グローバル・ロード・バランサは、HTTPトラフィックを地理的に最も近いデータ・センターにルーティングするように構成されます。Oracle Accessプロトコルのトラフィックの管理には、ロード・バランサは使用されません。

すべてのアプリケーションは、それぞれのローカル・データ・センターでAccess Managerクラスタに対して構成されるWebゲート・エージェントによって保護されます。どのWebゲートにも、プライマリ・サーバー1つと1つ以上のセカンダリ・サーバーがあります。各データ・センターのWebゲート・エージェントには、プライマリ・リストに同じデータ・センターからのAccess Managerサーバー・ノードがあり、セカンダリ・リストに他のデータ・センターからのノードがあります。

したがって、次の条件に該当するときは、ユーザー・リクエストを別のデータ・センターにルーティングすることも可能です。

  • ローカル・データ・センターが停止した

  • 負荷が一時的に増大し、トラフィックの再分散が発生した

  • 特定のアプリケーションが1つのデータ・センターのみにデプロイされている

  • 負荷分散は1つのデータ・センター内で行うが、フェイルオーバーはデータ・センター間で行うようにWebゲートが構成されている

この節では、以下のトピックについて説明します。

関連項目:

17.1.1 マルチデータ・センターのためのCookieの理解

SSO Cookie (OAM_ID、OAMAuthnおよびOAM_GITO)は、マルチデータ・センターによって拡張および使用されます。

この節では、以下のトピックについて説明します。

17.1.1.1 OAM_ID Cookie

OAM_ID Cookieは、Access ManagerのためのSSO Cookieであり、全データ・センターにわたってMDC動作を有効にするのに必要な属性を保持します。

同じSSOセッションでユーザーからの後続のリクエストが、MDCトポロジ内の別のデータ・センターにルーティングされる場合は、構成済のセッション・アダプション・ポリシーによりセッションの採用がトリガーされます。セッション・アダプションとは、そのトポロジ内の別のデータ・センターにユーザーのセッションが存在することを示す有効な認証Cookie (OAM_ID)の提示に基づいて、データ・センターがそのユーザーのローカル・セッションを作成する動作のことです。(これは、そのユーザーの再認証を伴うことも、そうでないこともあります。)

ユーザー・セッションがデータ・センターで作成されると、OAM_ID Cookieに次のものが付加され、更新されます。

  • データ・センターのclusterid
  • sessionid
  • latest_visited_clusterid

MDCのデプロイメントにおいて、OAM_IDはホスト・スコープのCookieとなります。そのドメイン・パラメータは、データ・センター全体でシングルトンである仮想ホスト名に設定され、ロード・バランサ・レベルのユーザー・トラフィック・ルーティング・ルール(地理的アフィニティなど)に基づいて、グローバル・ロード・バランサによってAccess Managerデータ・センター内のAccess Managerサーバーにマップされます。OAM_ID Cookieには、Access Managerサーバー以外のアプリケーションからはアクセスできません。

17.1.1.2 OAMAuthn WebゲートCookie

OAMAuthnは11gおよび12cのWebゲートCookieです。認証と認可に成功すると、保護されたリソースへのアクセス権がユーザーに付与されます。その時点で、ブラウザは、認証を行うデータ・センターのclusterid:sessionidを持つ有効なWebゲートCookieを取得します。

認可が後に続く認証が複数のデータ・センターにわたっている場合は、ユーザー・リクエストを認可するデータ・センターが、WebゲートCookieからそのセッションの作成元であるclusteridを取得することで、セッション・アダプションをトリガーします。(WebゲートCookieのホスト・スコープのため、Webゲートの各データ・センターのホスト名は同じである必要があります。)セッション・アダプションの後に、新しいセッションが現在のデータ・センター内に作成され、セッションの詳細が同期されます。

ノート:

WebゲートCookieを認可時に更新することはできないため、新規作成されたsessionidを将来の認可参照用に永続化することはできません。この場合は、リモートのsessionidとローカルのsessionidがセッション索引付けを通してリンクされます。データ・センターに対するそれ以降の認可コールのときに、新しいセッションが作成されるのは次の場合です。

  • MDCが有効化されている

  • WebゲートCookie内のsessionidに一致するセッションがローカルのデータ・センター内に存在しない

  • WebゲートCookie内のsessionidに一致するセッション索引を持つセッションが存在しない

  • 有効なセッションが(MDCセッション同期ポリシーに基づく)リモートのデータ・センターに存在する

これらの場合は、新しいセッションが、WebゲートCookie内のsessionidを参照するセッション索引とともに、ローカルのデータ・センター内で作成されます。

17.1.1.3 OAM_GITO (Global Inactivity Time Out) Cookie

OAM_GITOは、認可レスポンスとして設定されるドメインCookieです。

認証プロセスのセッション詳細がOAM_ID Cookieに記録されます。認可が別のデータ・センターにホップする場合は、認可リクエストを処理するデータ・センター内で新しいセッションを作成し、新しいセッションのセッション索引を受信sessionidとして設定することにより、セッション・アダプションが発生します。それ以降の認証リクエストでは、OAM_ID Cookie内のclusterid:sessionidマッピングのみが認識されているため、認可のためにセッションが別のデータ・センターにホップしても、そのことは認証リクエストの際に認識されません。このギャップに対処するために、OAM_GITO Cookie (複数のWebゲート・エージェントを対象とするタイムアウト追跡にも利用されます)が導入されています。

認可時に、OAM_GITO CookieがドメインCookieとして設定されます。それ以降の認証リクエストに対しては、OAM_GITO Cookieの内容が読み取られて、最新のセッション情報および非アクティブまたはアイドル・タイムアウトの値が特定されます。OAM_GITO Cookieに格納されているのは、次のデータです。

  • データ・センター識別子

  • セッション識別子

  • ユーザー識別子

  • 最終アクセス時間

  • トークン作成時間

ノート:

OAM_GITO Cookieでは、すべてのWebゲートおよびAccess Managerサーバーが共通ドメイン階層を共有することが必要です。たとえば、サーバー・ドメインが.us.example.comの場合は、すべてのWebゲートが(少なくとも) .example.comを共通ドメイン階層として持つ必要があります。これでOAM_GITO Cookieを.example.comドメインで設定できるようになります。

17.1.2 認可時のセッション・アダプション

マルチデータ・センターのセッション・アダプションは、認可フローの中でサポートされます。認証に成功した後、OAMAuthn Cookieには、認証が行われたデータ・センターのクラスタID詳細が付加されます。

認可時に、リクエストが別のデータ・センターにルーティングされる場合、Access Managerランタイムは、有効なリモート・セッションであるかどうかをチェックして、これがマルチデータ・センターのシナリオに該当するかどうかを判断します。有効なリモート・セッションが特定されると、セッション・アダプション・ポリシーごとにマルチデータ・センターのセッション・アダプション・プロセスがトリガーされます。

クローンのAccess ManagerクラスタがOracle Accessプロトコル(OAP)を使用してマスターのAccess Managerクラスタに対してセッションの詳細のバックエンド・リクエストを行うように、セッション・アダプション・ポリシーを構成することもできます。前のセッションを無効にして、ユーザーが一度に1つのデータ・センターのみでセッションを持つようにセッション・アダプション・ポリシーを構成することもできます。セッション・アダプション・プロセスの後に、認可リクエストを処理するデータ・センターに新しいセッションが作成されます。

ノート:

認可時のOAMAuthn Cookieの更新はサポートされていないため、新規作成されたセッションのセッション索引は、受信セッションIDのものに設定されます。

関連項目:

17.1.3 セッション索引付け

セッション索引とは、OAMAuth Cookieのセッション識別子を示します。

データ・センターへの認可コール中に、セッション索引を持つ新しいセッションが、ローカル・データ・センターに作成されます。これは、次の条件が満たされると発生します。

  • OAMAuth Cookie内のセッションIDに一致するセッションがローカルのデータ・センターに存在しない。

  • MDCが有効化されている。

  • OAMAuth Cookie内のセッションIDに一致するセッション索引を持つセッションが存在しない。

  • 有効なセッションがMDCセッション同期ポリシーに基づくリモートのデータ・センターに存在する。

17.1.4 サポートされるマルチデータ・センターのトポロジ

Access Managerでは、3つのマルチデータ・センター・トポロジ(アクティブ/アクティブ、アクティブ/パッシブおよびアクティブ/スタンバイの各モード)がサポートされます。

次の各項では、これらのモードの詳細を説明します。

17.1.4.1 MDCアクティブ/アクティブ・モード

アクティブ/アクティブ・トポロジ。この場合、マスターとクローンのデータ・センターが正確なレプリカであり、同時にアクティブとなります。

これらは、地理的位置などの定義済の基準に基づいて、様々なユーザーのセットに対応します。ロード・バランサによってトラフィックが適切なデータ・センターにルーティングされます。図17-2に、通常稼働時にアクティブ/アクティブ・モードに設定されているマルチデータ・センターを示します。

図17-2 アクティブ/アクティブ・デプロイメント・モード

図17-2の説明が続きます
「図17-2 アクティブ/アクティブ・デプロイメント・モード」の説明

図17-2では、ニューヨークのデータ・センターがマスターとして指定され、ポリシーおよび構成の変更はすべてこのデータ・センターのみで行われます。ロンドンのデータ・センターはクローンとして指定されており、REST APIを使用して定期的にデータをニューヨークのデータ・センターと同期させます。地理的に異なる場所(米国およびヨーロッパ)のユーザーを、(アクセスされるアプリケーションの近さではなく)データ・センターへの地理的な近さに基づいて、適切なデータ・センター(ニューヨークまたはロンドン)にルーティングするようにグローバル・ロード・バランサが構成されています。たとえば、米国にいるユーザー1からのリクエストはすべてニューヨークのデータ・センター(NYDC)にルーティングされ、ヨーロッパにいるユーザー2からのリクエストはすべてロンドンのデータ・センター(LDC)にルーティングされます。

ノート:

図17-2のAccess Managerクラスタは互いに独立しており、同一のOracle WebLogicドメインに属してはいません。WebLogicドメインが複数のデータ・センターにまたがることはお薦めしません。

この例では、仮にNYDCがリクエストで過負荷になった場合、グローバル・ロード・バランサはユーザー1のリクエストを、LDCにあるクローンのAccess Managerクラスタにルーティングするようになります。クローンのAccess Managerクラスタは、ユーザーのOAM_ID Cookieを使用して、マスター・クラスタの有効なセッションであるかどうかをチェックします。マスター・クラスタに有効なセッションがある場合、認証または再認証の要求なしで新しいセッションが作成されます。

さらに、クローンのAccess ManagerクラスタがOracle Accessプロトコル(OAP)を使用してマスターのAccess Managerに対してセッションの詳細のバックエンド・リクエストを行うように、セッション・アダプション・ポリシーを構成することもできます。リモート・セッション(NYDCのセッション)を無効にして、ユーザーが一度に1つのデータ・センターのみでセッションを持つようにセッション・アダプション・ポリシーを構成することもできます。

図17-3は、マスター・クラスタが過負荷のとき、または停止したときにユーザーがどのように再ルーティングされるかを示しています。マスターのAccess Managerクラスタが完全に停止すると、クローンのAccess Managerクラスタは、ユーザー1のセッションの詳細を取得するよう試みます。マスターのAccess Managerクラスタは完全にアクセス不能であるため、ユーザー1は、強制的に再認証され、クローンのAccess Managerクラスタで新しいセッションを確立します。この場合は、前のセッションで保存されていた情報はすべて失われます。

図17-3 アクティブ/アクティブ・モードのフェイルオーバー

図17-3の説明が続きます
「図17-3 アクティブ/アクティブ・モードのフェイルオーバー」の説明

ノート:

エージェント・フェイルオーバーのあるアクティブ/アクティブ・トポロジでは、エージェントのAccess Managerサーバーが一方のデータ・センターではプライマリとして構成され、他方のデータ・センターではセカンダリとして構成され、これによってフェイルオーバーのシナリオが支援されます。

関連項目:

アクティブ/アクティブ・マルチデータ・センター・トポロジ・デプロイメント
17.1.4.2 MDCアクティブ/パッシブ・モード

アクティブ/パッシブ・トポロジは、プライマリのデータ・センターが稼働可能であり、クローンのデータ・センターはそうでない場合です。このトポロジでは、プライマリのデータ・センターに障害が発生した場合に、合理的な時間内でクローンの稼働を開始させることができます。したがって、アクティブ/パッシブ・モードは、データ・センターの1つがパッシブで、サービスが開始されていません。

この場合、データ・センターはすぐに稼働可能になる必要はありませんが、プライマリのデータ・センターが停止した場合には合理的な時間内に稼働を開始させる必要があります。ポリシー・データは常に同期されますが、MDC設定を行う必要はありません。

17.1.4.3 MDCアクティブ/ホット・スタンバイ・モード

アクティブ/ホット・スタンバイ。この場合、データ・センターの1つがホット・スタンバイ・モードです。この場合、アクティブ・データ・センターが停止していないかぎり、トラフィックはホット・スタンバイ・データ・センターにルーティングされません。

この場合、トラフィックに対応する追加のデータ・センターは毎日は必要ありませんが、1つは常に用意しておきます。アクティブ/ホット・スタンバイ・モードでのデプロイは、アクティブ/アクティブ・モードのステップに従いますが、ホット・スタンバイとして定義されているセンターにトラフィックをルーティングしません。ホット・スタンバイ・センターは引き続きデータを同期しますが、ロード・バランサまたは管理者によってトラフィックをそのセンターに転送したときにのみ使用されます。

17.2 マルチデータ・センター・デプロイメント

マルチデータ・センター・デプロイメントでは、各データ・センターにAccess Managerのフル・インストールが含まれ、WebLogic Serverドメインが複数のデータ・センターにまたがることはありません。

グローバル・ロード・バランサによってユーザーからデータ・センターへのアフィニティが維持されますが、次の場合にユーザー・リクエストが別のデータ・センターにルーティングされることもあります。

  • データ・センターがダウンした。

  • 負荷が一時的に増大し、トラフィックの再分散が発生した。

  • 各データ・センターが他のミラーではない。(たとえば、アプリケーションの中には1つのデータ・センターにしかデプロイできないものがあります)

  • Webゲートが、データ・センター内でロード・バランシングを行い、複数データ・センターにまたがるフェイルオーバーを行うように構成されている。

図17-4に、基本的なマルチデータ・センター・デプロイメントを示します。

図17-4 マルチデータ・センター・デプロイメント

図17-4の説明が続きます
「図17-4 マルチデータ・センター・デプロイメント」の説明

次の各項で、様々なデプロイメント・シナリオを説明します。

ノート:

バック・チャネル通信に使用されるOAP接続では、ロード・バランシングやフェイルオーバーはサポートされないので、ロード・バランサを使用する必要があります。

17.2.1 セッション・アダプション: 再認証、セッション無効化、セッション・データ取得なし

次のシナリオは、再認証、リモート・セッションの無効化およびリモート・セッション・データの取得なしにセッション・アダプション・ポリシーが構成されている場合のフローを示しています。

ユーザーにはDC1とのアフィニティがあることを前提としています。

  1. ユーザーがDC1によって認証されます。

    認証に成功すると、OAM_ID Cookieは、DC1を参照する一意のデータ・センター識別子が付加され、ユーザーはDC1内のAccess Managerで保護されたアプリケーションにアクセスできるようになります。

  2. DC2内にデプロイされたアプリケーションにアクセスすると、ユーザーはグローバル・ロード・バランサによってDC2にルーティングされます。

  3. DC2内のAccess Managerに対して、DC1で発行された付加情報付きOAM_ID Cookieが提示されます。

    検証に成功すると、DC2のAccess ManagerはこのユーザーがリモートのDC1からルーティングされたことを認識します。

  4. DC2のAccess Managerはセッション・アダプション・ポリシーを調べます。

    このセッション・アダプション・ポリシーは、再認証、リモート・セッション無効化およびリモート・セッション・データ取得を行わないように構成されています。

  5. DC2のAccess Managerは、DC1のOAM_ID Cookieで提示された情報(存続期間、ユーザー)を使用してローカル・ユーザー・セッションを作成し、静的セッション情報($userレスポンス)を再初期化します。

  6. DC2のAccess Managerは、OAM_ID Cookieを自身のデータ・センター識別子で更新します。

    データ・センター・チェーンもOAM_ID Cookieに記録されます。

  7. 次に、ユーザーはDC1内のAccess Managerで保護されているアプリケーションにアクセスし、グローバル・ロード・バランサによって再びDC1にルーティングされます。

  8. DC1のAccess Managerに対して、DC1が発行してDC2で更新されたOAM_ID Cookieが提示されます。

    検証に成功すると、DC1のAccess ManagerはこのユーザーのセッションがDC1とDC2の両方にあることを認識します。

  9. DC1のAccess Managerは、OAM_ID Cookieで参照されているセッションの特定を試みます。

    • 見つかった場合は、DC1のセッションが更新されます。

    • 見つからない場合、DC1のAccess Managerは、再認証、リモート・セッション無効化およびリモート・セッション・データ取得なしで構成されているセッション・アダプション・ポリシーを調べます。

  10. DC1のAccess Managerは、自身のデータ・センター識別子でOAM_ID Cookieを更新し、データ・センター・チェーンをDC2と同様に記録します。

17.2.2 セッション・アダプション: 再認証なし、セッション無効化およびセッション・データ取得あり

次のシナリオは、再認証がなく、リモート・セッションの無効化とリモート・セッション・データの取得でセッション・アダプション・ポリシーが構成されている場合のフローを示しています。

ユーザーにはDC1とのアフィニティがあることを前提としています。

  1. ユーザーがDC1によって認証されます。

    認証に成功すると、OAM_ID Cookieに、DC1を参照する一意のデータ・センター識別子が付加されます。

  2. DC2内にデプロイされたアプリケーションにアクセスすると、ユーザーはグローバル・ロード・バランサによってDC2にルーティングされます。

  3. DC2内のAccess Managerに対して、DC1で発行された付加情報付きOAM_ID Cookieが提示されます。

    検証に成功すると、DC2のAccess ManagerはこのユーザーがリモートのDC1からルーティングされたことを認識します。

  4. DC2のAccess Managerはセッション・アダプション・ポリシーを調べます。

    このセッション・アダプション・ポリシーは、再認証は行わないが、リモート・セッション無効化およびリモート・セッション・データ取得を行うように構成されています。

  5. DC2のAccess Managerは、DC1のAccess Managerへのバックチャネル(OAP)コール(セッション識別子が含まれる)を行い、セッション・データを取得します。

    DC1のセッションは、データ取得の後に終了となります。このステップが不正なセッション参照のために失敗すると、ローカル・セッションが作成されます。「セッション・アダプション: 再認証、セッション無効化、セッション・データ取得なし」を参照してください。

  6. DC2のAccess Managerは、OAM_ID Cookieで提示された情報(存続期間、ユーザー)を使用してローカル・ユーザー・セッションを作成し、静的セッション情報($userレスポンス)を再初期化します。

  7. DC2のAccess Managerは、OAM_ID Cookieを自身のデータ・センター識別子で書き換えます。

  8. 次に、ユーザーはDC1のAccess Managerで保護されているアプリケーションにアクセスし、グローバル・ロード・バランサによってDC1にルーティングされます。

  9. DC1のAccess Managerに対して、DC2で発行されたOAM_ID Cookieが提示されます。

    検証に成功すると、DC1のAccess ManagerはこのユーザーのセッションがDC2にあることを認識します。

  10. DC1のAccess Managerは、DC2のAccess Managerへのバックチャネル(OAP)コール(セッション識別子が含まれる)を行い、セッション・データを取得します。

    セッションが見つかった場合は、取得したデータを使用してセッションが作成されます。見つからない場合は、DC1のOAMサーバーによって新しいセッションが作成されます。DC2のセッションは、データ取得の後に終了となります。

17.2.3 セッション・アダプション: 再認証およびセッション無効化なし、オンデマンドのセッション・データ取得あり

マルチデータ・センターでは、非ローカル・セッションが終了されず、ローカル・セッションがリモートDCから取得されたセッション・データを使用して作成されることを除き、再認証なしのセッション・アダプションをサポートします。

OAM_ID Cookieが更新され、現在どのデータ・センターにアクセスしているかを示す属性が含まれることに注意してください。

17.2.4 異なるデータ・センターで処理される認証および認可リクエスト

認証リクエストの処理はニューヨークのデータ・センター(NYDC)で行われるが、ユーザー・アフィニティが理由で認可リクエストはロンドンのデータ・センター(LDC)に提示されるシナリオについて考えます。

リモート・セッション終了が有効化されている場合は、マルチデータ・センターをシームレスに操作するためにOAM_ID Cookie、OamAuthn/ObSSO認可CookieおよびGITO Cookieの組合せが必要になります。このフロー(およびその後の図17-5)で、これを示します。ユーザーとNYDCとの間にアフィニティがあることを前提とします。

  1. APP1にアクセスすると、ユーザーはNYDCによる認証を受けます。

    認証に成功すると、OAM_ID Cookieに、NYDCを参照する一意のデータ・センター識別子が付加されます。これに続く認可コールは、アクセスされるリソースのプライマリ・サーバー、つまりNYDCによって処理されます。認可が行われると、NYDCの識別子(クラスタID)を保持する認可Cookieが生成され、ユーザーにはAPP1へのアクセス権が付与されます。

  2. ユーザーは、LDCにあるAPP2へのアクセスを試みます。

  3. APP2のWebゲートは、LDCに有効なセッションが見つからず、認証を開始します。

    ユーザー・アフィニティが理由で、認証リクエストはNYDCにルーティングされ、ここでシームレスに認証が行われます。OamAuthn Cookieの内容が生成され、APP2のWebゲートと共有されます。

  4. APP2のWebゲートは、APP2のプライマリ・サーバー、LDCに後続の認可リクエストと生成された認可Cookieを転送します。

    認可時に、LDCはこれがマルチデータ・センターのシナリオであり、有効なセッションがNYDCに存在すると判断します。この場合の認可は、構成済のセッション・アダプション・ポリシーによりリモート・セッションを同期させることによって行われます。

  5. 認可時にLDCで新しいセッションが作成され、受け取ったセッションIDが新しいセッションの索引として設定されます。

    これ以降の認可コールは、索引によるセッション検索でLDC内の有効なセッションが返されるかぎり、受け入れられます。認可のたびに、GITO CookieがクラスタID、セッションIDおよびアクセス日時で更新されます。GITO Cookieは認可レスポンスとして毎回書き換えられます。

    同じユーザーからのそれ以降の認証リクエストをNYDCが受け取った場合は、OAM_ID CookieとGITO Cookieの情報を使用して、どのデータ・センターにそのユーザーの最新のセッションがあるかが特定されます。構成済のセッション・アダプション・ポリシーに基づいて、マルチデータ・センターのフローがシームレスにトリガーされます。

図17-5 異なるデータ・センターで処理されるリクエスト

図17-5の説明が続きます
「図17-5 異なるデータ・センターで処理されるリクエスト」の説明

17.2.5 ログアウトとセッション無効化

マルチデータ・センターのシナリオでは、ログアウトによって確実にすべてのデータ・センターのすべてのサーバー側セッションとすべての認証Cookieがクリアされます。セッション無効化の場合は、バックチャネルを介してセッション・アーティファクトを終了させても、Webゲートで保持されているセッションCookieおよび状態情報が削除されることはありません。

ただし、サーバー・セッションがないため認可に失敗し、その結果として再認証が行われます。セッション無効化を行わない場合は、ログアウトによって、現在のSSOセッションに属するすべてのサーバー側セッションがすべてのデータ・センターからクリアされます。このフロー(およびその後の図17-6)で、ログアウトを示します。ユーザーとNYDCとの間にアフィニティがあることを前提とします。

  1. NYDCとのアフィニティを持つユーザーが、NYDCでの認証成功後にAPP1へのアクセス権を獲得します。

  2. ユーザーは、APP2へのアクセスを試みます。

    この時点で、ユーザー・セッションがSSOの一部としてNYDCおよびLDCに存在します。

  3. ユーザーは、APP1からログアウトします。

    アフィニティが理由で、このログアウト・リクエストはNYDCに到達します。

  4. NYDCのサーバーは、ユーザーのSSOセッションを終了させ、すべてのSSOパートナからログアウトします。

  5. NYDCのサーバーはOAPセッション終了リクエストを、SSOセッションに関連付けられているすべての関連データ・センターに送信します。これには、LDCも含まれます。

    この結果として、SSOに関連付けられているすべてのユーザー・セッションがすべてのデータ・センターからクリアされます。

図17-6 ログアウトとセッション無効化

図17-6の説明が続きます
「図17-6 ログアウトとセッション無効化」の説明

17.2.6 ストレッチ・クラスタ・デプロイメント

地理的に非常に近接し、保証された待ち時間が5ミリ秒未満のデータ・センターでは、ストレッチ・クラスタ・デプロイメントを選択できます。

この場合、前項で説明した従来のマルチデータ・センターのデプロイメントとは異なり、1つのOAMクラスタが複数のデータ・センターにわたって拡張され、1つのデータ・センターに一部のOAMノードがあり、別のデータ・センターに残りのノードがあります。デプロイメントは2つのデータ・センターに分散していますが、Access Managerはこれを単一のクラスタとして扱います。ポリシー・データベースは、データ・センターのいずれかに存在することになります。ストレッチ・クラスタ・デプロイメントには、次の制限が適用されます。

  • Access Managerは、ノードの同期を維持するために、基礎となるWebLogicおよびコヒーレンス層に依存します。データ・センター間の待ち時間は、常に5ミリ秒未満である必要があります。待ち時間のスパイクは、不安定および予期しない動作を引き起こす可能性があります。

  • ストレッチ・クラスタ・デプロイメントでは、実行時のデータ・センター間の傍受通信が、従来のマルチデータ・センター・デプロイメントの場合よりも比較的多くなります。後者の場合、データ・センター間のランタイム通信は、データ・センター間でセッションの採用が必要となるユースケースに制限されています。

  • データ・センター全体にわたって単一のクラスタであるので、従来のマルチデータ・センター・デプロイメントと同じレベルの信頼性と可用性を提供しません。ポリシー・データベースが単一点障害となる可能性があります。従来のマルチデータ・センター・デプロイメントでは、各データ・センターが自立し、他のデータ・センターから独立して動作することで、より高い信頼性を提供します。

図17-7はストレッチ・クラスタ・デプロイメントを示し、その次の図17-8は、従来のMDCデプロイメントを示しています。ストレッチ・クラスタ・デプロイメントよりも従来のマルチ・データ・センター・デプロイメントをお薦めします。

図17-7 ストレッチ・クラスタ・デプロイメント

図17-7の説明が続きます
「図17-7 ストレッチ・クラスタ・デプロイメント」の説明

図17-8 従来のMDCデプロイメント

図17-8の説明が続きます
「図17-8 従来のMDCデプロイメント」の説明

関連項目:

サポートされるマルチデータ・センターのトポロジ

17.3 アクティブ/アクティブ・マルチデータ・センター・トポロジ・デプロイメント

アクティブ/アクティブ・トポロジでは、マスターとクローンのデータ・センターは互いの正確なレプリカです(アプリケーション、データ・ストアなど)。

これらは同時にアクティブであり、定義済の基準(たとえば地理的位置)に基づいて、それぞれ異なるユーザー・セットに対応します。ロード・バランサによってトラフィックが適切なデータ・センターにルーティングされます。同一のAccess Managerクラスタが両方のロケールにデプロイされ、ニューヨークがマスター、ロンドンがクローンとして指定されます。

ノート:

エージェント・フェイルオーバーのあるアクティブ/アクティブ・トポロジでは、エージェントのAccess Managerサーバーが一方のデータ・センターではプライマリとして構成され、他方のデータ・センターではセカンダリとして構成され、これによってフェイルオーバーのシナリオが支援されます。

図17-9に、アクティブ/アクティブ・モードのマルチデータ・センター・デプロイメントのトポロジを示します。ニューヨークのデータ・センターがマスターとして指定され、ポリシーおよび構成の変更はすべてこのデータ・センターのみで行われます。ロンドンのデータ・センターはクローンとして指定されており、MDC admin REST APIを使用して定期的にデータをニューヨークのデータ・センターと同期させます。地理的に異なる場所(米国およびヨーロッパ)のユーザーを、(アクセスされるアプリケーションの近さではなく)データ・センターへの地理的な近さに基づいて、適切なデータ・センター(ニューヨークまたはヨーロッパ)にルーティングするようにグローバル・ロード・バランサが構成されています。たとえば、米国にいるユーザー1からのリクエストはすべてニューヨークのデータ・センター(NYDC)にルーティングされ、ヨーロッパにいるユーザー2からのリクエストはすべてロンドンのデータ・センター(LDC)にルーティングされます。

図17-9 アクティブ/アクティブ・トポロジ

図17-9の説明が続きます
「図17-9 アクティブ/アクティブ・トポロジ」の説明

グローバル・ロード・バランサはセッションの固定性を維持するように構成されているので、ユーザーが特定のデータ・センターに割り当てられた後は、そのユーザーからのリクエストはすべて同じデータ・センターにルーティングされます。この例では、ユーザー1は常にニューヨークのデータ・センターにルーティングされ、ユーザー2はロンドンのデータ・センターにルーティングされます。

各データ・センターでのユーザー・リクエストは、アクセスされるアプリケーションに応じて異なるWebゲートによって捕捉されます。各Webゲートには、プライマリ・サーバーとして構成された同じデータ・センター内のAccess Managerクラスタの様々なノードがあります。この場合、Webゲートはローカル・データ・センターのロード・バランシングとフェイルオーバーを行います。

ノート:

管理者は、負荷の特性に応じて様々な順序で柔軟に各Webゲートのプライマリ・サーバーを構成できます。各データ・センターでモニタリング・スクリプトを実行すると、Access Managerコンポーネント(Webゲートやサーバー)が応答しなくなったことが検出されるので、管理者はロード・バランサを再構成してユーザー・トラフィックを別のデータ・センターに転送できます。

負荷を全世界に分散するために、任意の数のクローン・データ・センターを構成できます。唯一の条件は、MDC admin REST APIを使用してすべてのクローン・データ・センターが単一のマスターと同期されていることです。次の図17-10には、5つのデータ・センターにまたがるアクティブ/アクティブのマルチデータ・センター・デプロイメントを示します。

図17-10 複数のデータ・センターにまたがるアクティブ/アクティブ・トポロジ

図17-10の説明が続きます
「図17-10 複数のデータ・センターにまたがるアクティブ/アクティブ・トポロジ」の説明

17.4 Access Managementコンポーネント間のロード・バランシング

前述のトポロジは、エンド・ユーザーのHTTPトラフィックを様々なデータ・センターにルーティングするグローバルおよびローカルのロード・バランサを示しています。顧客は、ロード・バランサをAccess Managerのコンポーネント間にデプロイし、仮想ホスト名を使用してAccess Managerコンポーネントの構成を単純化することができます。

たとえば、NYDCの各Webゲートでプライマリ・サーバーをssonode1.ny.acme.com、ssonode2.ny.acme.comなどと構成するかわりに、すべてが同じ仮想ホスト名(たとえばsso.ny.acme.com)を指し、ロード・バランサがDNSを解決してクラスタ内の各ノードに転送することもできます。ただし、Access Managerコンポーネント間にロード・バランサを導入するときは、次の制約事項に注意してください。

  • OAP接続は永続的であり、アイドル状態になっている場合でも、構成可能な期間の間はそれらの接続をオープンしておく必要があります。

  • ロード・バランサが接続を終了する前に、接続をリサイクルするようにWebゲートを構成する必要があります。ただし、ロード・バランサがTCPリセットをWebゲートとサーバーの両方に送信でき、確実に接続がクリーンアップされる場合は除きます。

  • ロード・バランサは、OAP接続を各WebゲートのアクティブなAccess Managerサーバー間で均等に分散する(OAP接続を接続元IPに従って分散する)必要があります。このようにしない場合は、負荷の偏りが発生する可能性があります。

図17-11に、ローカルのロード・バランサ(LBR 3およびLBR 4)が各データ・センターのクラスタのフロント・エンドとなっているデプロイメント・トポロジのバリエーションを示します。mod_wl_ohsによって、これらのローカル・ロード・バランサとしてOracle HTTP Server (OHS)を使用できます。OAPトラフィックはデータ・センター内のWebゲートとAccess Managerクラスタとの間を流れますが、ロード・バランサがDNSルーティングを実行することによって、仮想ホスト名が使用できるようになります。

「Access Managerサーバーのヘルスのモニタリング」を参照してください。

図17-11 Access Managerコンポーネントのロード・バランシング

図17-11の説明が続きます
「図17-11 Access Managerコンポーネントのロード・バランシング」の説明

図17-12に、デプロイメント・トポロジのもう1つのバリエーションを示します。このトポロジでは、グローバル・ロード・バランサ(GLBR2)が導入されており、ローカル・ロード・バランサ(LBR3およびLBR4)のフロント・エンドとなっています。この場合は、データ・センター内だけでなく、データ・センター間でのホスト名の仮想化が可能になります。各データ・センター内のWebゲートは、ロード・バランシングはローカルで行うが、フェイルオーバーはリモートで行うように構成されます。このトポロジの主な利点の1つは、スタックの全レイヤーで高可用性が保証されることです。データ・センターのAccess Managerクラスタ全体が停止した場合でも、そのデータ・センターのWebゲートは他のデータ・センターのAccess Managerクラスタにフェイルオーバーします。

図17-12 ローカル・ロード・バランサのフロント・エンドとなるグローバル・ロード・バランサ

図17-12の説明が続きます
「図17-12 ローカル・ロード・バランサのフロント・エンドとなるグローバル・ロード・バランサ」の説明

17.5 タイムアウトおよびセッション同期の理解

次の各項で、マルチデータ・センターにおけるセッション・タイムアウトおよび同期の扱いについて説明します。

17.5.1 最大セッション制約

資格証明コレクタ・ユーザーのアフィニティによって、ユーザー当たりの最大セッション制約が確実に遵守されます。

ユーザー当たりの許容最大セッション数を検証するためのマルチデータ・センター・セッション・ストアはありません。

17.5.2 アイドル・タイムアウトに関するマルチデータ・センターのポリシー構成

OAM_IDおよびOAM_GITOのCookieを使用してアイドル(非アクティブ)タイムアウトが計算され、適用されます。ただし、OAM_GITO Cookieを設定できるのは、Webゲート間に共通のサブドメインがある場合のみです。したがって、マルチデータ・センターのポリシーは、OAM_GITO Cookieが設定されているかどうかに基づいて構成する必要があります。

表17-1は、ポリシー構成をまとめたものです。

表17-1 アイドル・タイムアウトに関するマルチデータ・センターのポリシー構成

OAM_GITO設定済 マルチデータ・センターのポリシー

はい

アイドル・タイムアウトは最新のOAM_GITO Cookieから計算されます

SessionMustBeAnchoredToDataCenterServicingUser=<true/false>

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds>

SessionContinuationOnSyncFailure=<true/false>

MDCGitoCookieDomain=<sub domain>

いいえ

OAM_GITOが使用できないため、アイドル・タイムアウトはOAM_ID Cookieから計算されます

SessionMustBeAnchoredToDataCenterServicingUser=false

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds>

SessionContinuationOnSyncFailure=<true/false>

#MDCGitoCookieDomain= この設定はコメント化または削除する必要があります。

17.5.3 マルチデータ・センターのセッションの失効

セッション失効の管理は、ユーザーがアフィニティを持つデータ・センターによって行われます。

ユーザーと特定のデータ・センターとのアフィニティは、グローバル・トラフィック・マネージャまたはロード・バランサに基づきます。

17.5.4 セッション同期とマルチデータ・センターのフェイルオーバー

ユーザーのリクエストに対応する有効なセッションがリモート・データ・センターに存在する場合、MDCセッション同期化ポリシーに基づいて、リモート・セッションの属性は、現行リクエストを処理するデータ・センターに移行され同期されます。同期が失敗しても、データ・センター間のWebゲート・フェイルオーバーがMDCでサポートされているため、データ・センターは引き続きリクエストされたリソースにアクセスできます。

Access Managerサーバー側セッションは、シングル・サインオン(SSO)資格証明に基づいて作成および維持されます。セッションの中で保存される属性には(これに限定されるわけではありません)、ユーザー識別子、アイデンティティ・ストア参照、サブジェクト、カスタム属性、パートナ・データ、クライアントIPアドレスおよび認証レベルがあります。SSOが許可されるのは、サーバーがユーザーのリクエストに対応する有効なセッションを特定できる場合です。

マルチデータ・センターのシナリオでは、ユーザー・リクエストがデータ・センター間をホップするときに、そのリクエストを処理するデータ・センターが、正当なセッションかどうかの検証をローカルで、およびデータ・センター間で行う必要があります。特定のリクエストに対する有効なセッションがリモートのデータ・センターに存在する場合は、MDCセッション同期ポリシーに基づいてリモート・セッションを現在のデータ・センターに移行する必要があります。(「マルチデータ・センター・デプロイメント」を参照してください。)このセッション同期のときに、リモート・セッションからのすべてのセッション属性が、現在のリクエストを処理するデータ・センターで新規作成されたセッションに同期されます。

マルチデータ・センターでは、データ・センター間のWebゲートのフェイルオーバーもサポートされます。Webゲートが別のデータ・センターにフェイルオーバーするときは、最初のデータ・センターのサーバーが停止しているため、セッション・データの同期はできません。したがって、2つ目のデータ・センターがSessionContinuationOnSyncFailureの設定に基づいて、セッション・アダプションを続行するかどうかを決定します。trueのときは、リモートのデータ・センターへのOAP通信が失敗しても、現在のリクエストを処理するデータ・センターはCookie内の必須属性に基づいてローカルに新規セッションを作成できます。これで、同期エラーがあってもリクエストされたリソースへのシームレスなアクセスが可能になります。表17-2は、セッション同期とフェイルオーバーの代表的なシナリオをまとめたものです。この表のパラメータの詳細は、表C-2を参照してください。

表17-2 セッション同期とフェイルオーバーのシナリオ

MDCデプロイメント MDCポリシー リモート・セッションの検証 リモートDCからのユーザーを処理するDCでのセッション同期 リモート・セッションの終了 ユーザーに対するチャレンジ

アクティブ/アクティブ

SessionMustBeAnchoredToDataCenterServicingUser=true

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds>

SessionContinuationOnSyncFailure= false

MDCGitoCookieDomain=<sub domain>

はい

はい

はい

有効なセッションがリモート・データ・センターで見つからないとき

アクティブ/アクティブ

SessionMustBeAnchoredToDataCenterServicingUser=false

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<millisecon

ds>

SessionContinuationOnSyncFailure= false

MDCGitoCookieDomain=<sub domain>

はい

はい

いいえ

有効なセッションがリモート・データ・センターで見つからないとき

アクティブ/スタンバイ

SessionMustBeAnchoredToDataCenterServicingUser=true

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<millisecon

ds>

SessionContinuationOnSyncFailure= false

MDCGitoCookieDomain=<sub domain>

検証できない(リモートDCが停止しているため)

いいえ(リモートDCが停止しているため)

終了できない(リモート・データ・センターが停止しているため)

はい

アクティブ/スタンバイ

SessionMustBeAnchoredToDataCenterServicingUser=true

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds>

SessionContinuationOnSyncFailure= true

MDCGitoCookieDomain=<sub domain>

検証できない(リモート・データ・センターが停止しているため)

いいえ(リモート・データ・センターが停止しているため)

終了できない(リモート・データ・センターが停止しているため)

いいえ

有効なCookie内の詳細情報を使用してローカル・セッションを作成することにより、シームレスなアクセスを提供

17.6 マルチデータ・センター環境のレプリケート

マルチデータ・センター環境のデータは、初期設定手順の一部としてマスター(サプライヤ)からクローン(コンシューマ)にレプリケートする必要があります。

この初期レプリケーションの後に、データ・センター全体で次のアーティファクトを定期的に同期する必要があります。

  • Webゲート・プロファイル: Webゲート・プロファイルがクローンにレプリケートされる間、プライマリ・サーバー・リストおよびログアウトURLの詳細がクローン・データ・センターの情報で更新されます。

  • 認証モジュール

  • OAMプロキシ構成

  • セッション・マネージャ構成

  • ポリシーおよびパートナ・データ

関連項目:

17.6.1 WLSTを使用したデータのレプリケート

データの初期レプリケーション(マルチデータ・センターの設定時)は、WLSTを使用して手動で実行する必要があります。

この初期レプリケーションの後に、WLSTコマンドまたは自動ポリシー同期レプリケーション・サービスを使用して、すでに複製されたデータを同期できます。WLSTを使用する場合、パートナ・プロファイルおよびポリシーがマスター・データ・センターからエクスポートされ、クローン・データ・センターにインポートされます。マルチデータ・センター環境でのデータのレプリケーションは必要であり、WLSTをこの目的に使用することが、これを達成する最低限の方法です。

関連項目:

17.6.2 自動ポリシー同期を使用したデータの同期

自動ポリシー同期(APS、レプリケーション・サービスとも呼ばれる)は、マスター・データ・センターからクローン・データ・センターにデータを自動的にレプリケートするのに使用されるREST APIのセットです。

これは、Access Managerのデータを複数データ・センター間で同期させるように構成できます。APSを実行するには、データ・センター間の有効なレプリケーション承諾が存在する必要があります。「マルチデータ・センター同期の理解」を参照してください。

ノート:

APSは、データ・センターの同期を維持することのみを目的として設計されており、初めから完全なレプリケーションを実行する場合には使用されません。ベース・ラインを確立するには、最初にWLSTを使用してデータをレプリケートする必要があります。

17.7 マルチデータ・センターに関する推奨事項

この項では、マルチデータ・センター機能に関する推奨事項を示します。

17.7.1 共通ドメインの使用

Webゲートはドメイン・スコープ指定とし、すべてのWebゲートおよびOAM Server資格証明コレクタで1つの共通ドメインを推測できるようにすることをお薦めします。これで、Webゲートが、OAM Serverとの間で共有される暗号化GITO Cookieを設定できるようになります。

たとえば、Webゲートがapplications.abc.comで構成され、OAM Server資格証明コレクタがserver.abc.comで構成されている場合は、GITO Cookieの設定に使用される共通ドメインはabc.comです。共通ドメインを推測できないシナリオの場合は、GITO Cookieを設定することは意味がありません。あるデータ・センターが他のデータ・センターの最新ユーザー・セッションを認識していないこともあるためです。この結果として、そのデータ・センターは古いセッション・データに基づいてセッション・アイドル・タイムアウトを計算し、他にアクティブなセッションがどこかに存在しているとしても、ユーザーの再認証が必要になる可能性があります。

ノート:

SessionContinuationOnSyncFailureプロパティが設定されているときは、同様の問題がサーバー・フェイルオーバー時に発生します。期待される動作は、OAM_ID Cookieの内容からセッションを取り出すことです。実際の非アクティブ・タイムアウト値をGITO Cookieから取り出すことが不可能であるため、再認証が発生します。

WebゲートおよびOAMサーバーの共通Cookieドメインがないときは、アイドル・タイムアウトの問題に対処するために、構成を次のとおりに変更してください。

  • MDCGitoCookieDomainプロパティを入力プロパティ・ファイルから削除した後に、WLSTのenableMultiDataCentreModeコマンドを実行します。

  • 認可中はWebゲートCookieをリフレッシュできないため、WebゲートCookieの有効期間の値をセッション・アイドル・タイムアウト・プロパティの値よりも低く設定します。セッション・アイドル・タイムアウトの値が30分で、WebゲートCookieの有効期間の値が15分とすると、認証を行うデータ・センターでは15分ごとにセッションがリフレッシュされます。

17.7.2 DCCおよびOAM_GITOに関する事項

OAM_GITO Cookieは、DCCを使用する場合は適用されません。

理由は次のとおりです。

  • #MDCGitoCookieDomain=設定をコメント・アウトする必要があります。

  • SessionMustBeAnchoredToDataCenterServicingUserパラメータをfalseに設定する必要があります。

  • WebゲートCookieの有効期限の間隔の詳細は、「共通ドメインの使用」を参照してください。

    。

17.7.3 外部ロード・バランサの使用

Access Managerでは、11g SDK APIを使用してセッション・データを取得しますが、このAPIでは、構成済プライマリ・サーバー・セット内でのSDKベースのロード・バランシングがサポートされていません。外部のTCPベースのロード・バランサを、高パフォーマンスが期待されているデータ・センター・ノードのOAPエンドポイントのフロント・エンドとして使用します。

ノート:

プライマリとセカンダリのOAMサーバー間のフェイルオーバーは、11g SDK APIの現行リリースでサポートされています。

17.7.4 最大セッション数の遵守

一般的なマルチデータ・センターのシナリオでは、ユーザーの認証は、そのユーザーが地理的にアフィニティを持つデータ・センターに対して行われます。まれなシナリオとして、特定のユーザーのユーザー認証とセッション作成が複数のメンバー・データ・センターにわたる場合は(地理的アフィニティと負荷スパイクを回避)、マルチデータ・センター・トポロジ全体でのそのユーザーの最大セッション数は遵守されません。

17.7.5 認可時にWebゲートCookieをリフレッシュできない

認可中はWebゲートCookieをリフレッシュできないため、WebゲートCookieの有効期間の値をセッション・アイドル・タイムアウト・プロパティの値よりも低く設定します。

セッション・アイドル・タイムアウトの値が30分で、WebゲートCookieの有効期間の値が15分とすると、認証を行うデータ・センターでは15分ごとにセッションがリフレッシュされます。WebゲートCookieの有効期限を2分未満に設定することをお薦めします。