| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
マルチデータ・センター・デプロイメントでは、各データ・センターにAccess Managerのフル・インストールが含まれ、WebLogic Serverドメインが複数のデータ・センターにまたがることはありません。
グローバル・ロード・バランサによってユーザーからデータ・センターへのアフィニティが維持されますが、次の場合にユーザー・リクエストが別のデータ・センターにルーティングされることもあります。
データ・センターがダウンした。
負荷が一時的に増大し、トラフィックの再分散が発生した。
各データ・センターが他のミラーではない。(たとえば、アプリケーションの中には1つのデータ・センターにしかデプロイできないものがあります)
Webゲートが、データ・センター内でロード・バランシングを行い、複数データ・センターにまたがるフェイルオーバーを行うように構成されている。
図17-4に、基本的なマルチデータ・センター・デプロイメントを示します。
次の各項で、様々なデプロイメント・シナリオを説明します。
ノート:
バック・チャネル通信に使用されるOAP接続では、ロード・バランシングやフェイルオーバーはサポートされないので、ロード・バランサを使用する必要があります。
次のシナリオは、再認証、リモート・セッションの無効化およびリモート・セッション・データの取得なしにセッション・アダプション・ポリシーが構成されている場合のフローを示しています。
ユーザーにはDC1とのアフィニティがあることを前提としています。
ユーザーがDC1によって認証されます。
認証に成功すると、OAM_ID Cookieは、DC1を参照する一意のデータ・センター識別子が付加され、ユーザーはDC1内のAccess Managerで保護されたアプリケーションにアクセスできるようになります。
DC2内にデプロイされたアプリケーションにアクセスすると、ユーザーはグローバル・ロード・バランサによってDC2にルーティングされます。
DC2内のAccess Managerに対して、DC1で発行された付加情報付きOAM_ID Cookieが提示されます。
検証に成功すると、DC2のAccess ManagerはこのユーザーがリモートのDC1からルーティングされたことを認識します。
DC2のAccess Managerはセッション・アダプション・ポリシーを調べます。
このセッション・アダプション・ポリシーは、再認証、リモート・セッション無効化およびリモート・セッション・データ取得を行わないように構成されています。
DC2のAccess Managerは、DC1のOAM_ID Cookieで提示された情報(存続期間、ユーザー)を使用してローカル・ユーザー・セッションを作成し、静的セッション情報($userレスポンス)を再初期化します。
DC2のAccess Managerは、OAM_ID Cookieを自身のデータ・センター識別子で更新します。
データ・センター・チェーンもOAM_ID Cookieに記録されます。
次に、ユーザーはDC1内のAccess Managerで保護されているアプリケーションにアクセスし、グローバル・ロード・バランサによって再びDC1にルーティングされます。
DC1のAccess Managerに対して、DC1が発行してDC2で更新されたOAM_ID Cookieが提示されます。
検証に成功すると、DC1のAccess ManagerはこのユーザーのセッションがDC1とDC2の両方にあることを認識します。
DC1のAccess Managerは、OAM_ID Cookieで参照されているセッションの特定を試みます。
見つかった場合は、DC1のセッションが更新されます。
見つからない場合、DC1のAccess Managerは、再認証、リモート・セッション無効化およびリモート・セッション・データ取得なしで構成されているセッション・アダプション・ポリシーを調べます。
DC1のAccess Managerは、自身のデータ・センター識別子でOAM_ID Cookieを更新し、データ・センター・チェーンをDC2と同様に記録します。
次のシナリオは、再認証がなく、リモート・セッションの無効化とリモート・セッション・データの取得でセッション・アダプション・ポリシーが構成されている場合のフローを示しています。
ユーザーにはDC1とのアフィニティがあることを前提としています。
ユーザーがDC1によって認証されます。
認証に成功すると、OAM_ID Cookieに、DC1を参照する一意のデータ・センター識別子が付加されます。
DC2内にデプロイされたアプリケーションにアクセスすると、ユーザーはグローバル・ロード・バランサによってDC2にルーティングされます。
DC2内のAccess Managerに対して、DC1で発行された付加情報付きOAM_ID Cookieが提示されます。
検証に成功すると、DC2のAccess ManagerはこのユーザーがリモートのDC1からルーティングされたことを認識します。
DC2のAccess Managerはセッション・アダプション・ポリシーを調べます。
このセッション・アダプション・ポリシーは、再認証は行わないが、リモート・セッション無効化およびリモート・セッション・データ取得を行うように構成されています。
DC2のAccess Managerは、DC1のAccess Managerへのバックチャネル(OAP)コール(セッション識別子が含まれる)を行い、セッション・データを取得します。
DC1のセッションは、データ取得の後に終了となります。このステップが不正なセッション参照のために失敗すると、ローカル・セッションが作成されます。「セッション・アダプション: 再認証、セッション無効化、セッション・データ取得なし」を参照してください。
DC2のAccess Managerは、OAM_ID Cookieで提示された情報(存続期間、ユーザー)を使用してローカル・ユーザー・セッションを作成し、静的セッション情報($userレスポンス)を再初期化します。
DC2のAccess Managerは、OAM_ID Cookieを自身のデータ・センター識別子で書き換えます。
次に、ユーザーはDC1のAccess Managerで保護されているアプリケーションにアクセスし、グローバル・ロード・バランサによってDC1にルーティングされます。
DC1のAccess Managerに対して、DC2で発行されたOAM_ID Cookieが提示されます。
検証に成功すると、DC1のAccess ManagerはこのユーザーのセッションがDC2にあることを認識します。
DC1のAccess Managerは、DC2のAccess Managerへのバックチャネル(OAP)コール(セッション識別子が含まれる)を行い、セッション・データを取得します。
セッションが見つかった場合は、取得したデータを使用してセッションが作成されます。見つからない場合は、DC1のOAMサーバーによって新しいセッションが作成されます。DC2のセッションは、データ取得の後に終了となります。
マルチデータ・センターでは、非ローカル・セッションが終了されず、ローカル・セッションがリモートDCから取得されたセッション・データを使用して作成されることを除き、再認証なしのセッション・アダプションをサポートします。
OAM_ID Cookieが更新され、現在どのデータ・センターにアクセスしているかを示す属性が含まれることに注意してください。
認証リクエストの処理はニューヨークのデータ・センター(NYDC)で行われるが、ユーザー・アフィニティが理由で認可リクエストはロンドンのデータ・センター(LDC)に提示されるシナリオについて考えます。
リモート・セッション終了が有効化されている場合は、マルチデータ・センターをシームレスに操作するためにOAM_ID Cookie、OamAuthn/ObSSO認可CookieおよびGITO Cookieの組合せが必要になります。このフロー(およびその後の図17-5)で、これを示します。ユーザーとNYDCとの間にアフィニティがあることを前提とします。
APP1にアクセスすると、ユーザーはNYDCによる認証を受けます。
認証に成功すると、OAM_ID Cookieに、NYDCを参照する一意のデータ・センター識別子が付加されます。これに続く認可コールは、アクセスされるリソースのプライマリ・サーバー、つまりNYDCによって処理されます。認可が行われると、NYDCの識別子(クラスタID)を保持する認可Cookieが生成され、ユーザーにはAPP1へのアクセス権が付与されます。
ユーザーは、LDCにあるAPP2へのアクセスを試みます。
APP2のWebゲートは、LDCに有効なセッションが見つからず、認証を開始します。
ユーザー・アフィニティが理由で、認証リクエストはNYDCにルーティングされ、ここでシームレスに認証が行われます。OamAuthn Cookieの内容が生成され、APP2のWebゲートと共有されます。
APP2のWebゲートは、APP2のプライマリ・サーバー、LDCに後続の認可リクエストと生成された認可Cookieを転送します。
認可時に、LDCはこれがマルチデータ・センターのシナリオであり、有効なセッションがNYDCに存在すると判断します。この場合の認可は、構成済のセッション・アダプション・ポリシーによりリモート・セッションを同期させることによって行われます。
認可時にLDCで新しいセッションが作成され、受け取ったセッションIDが新しいセッションの索引として設定されます。
これ以降の認可コールは、索引によるセッション検索でLDC内の有効なセッションが返されるかぎり、受け入れられます。認可のたびに、GITO CookieがクラスタID、セッションIDおよびアクセス日時で更新されます。GITO Cookieは認可レスポンスとして毎回書き換えられます。
同じユーザーからのそれ以降の認証リクエストをNYDCが受け取った場合は、OAM_ID CookieとGITO Cookieの情報を使用して、どのデータ・センターにそのユーザーの最新のセッションがあるかが特定されます。構成済のセッション・アダプション・ポリシーに基づいて、マルチデータ・センターのフローがシームレスにトリガーされます。
マルチデータ・センターのシナリオでは、ログアウトによって確実にすべてのデータ・センターのすべてのサーバー側セッションとすべての認証Cookieがクリアされます。セッション無効化の場合は、バックチャネルを介してセッション・アーティファクトを終了させても、Webゲートで保持されているセッションCookieおよび状態情報が削除されることはありません。
ただし、サーバー・セッションがないため認可に失敗し、その結果として再認証が行われます。セッション無効化を行わない場合は、ログアウトによって、現在のSSOセッションに属するすべてのサーバー側セッションがすべてのデータ・センターからクリアされます。このフロー(およびその後の図17-6)で、ログアウトを示します。ユーザーとNYDCとの間にアフィニティがあることを前提とします。
NYDCとのアフィニティを持つユーザーが、NYDCでの認証成功後にAPP1へのアクセス権を獲得します。
ユーザーは、APP2へのアクセスを試みます。
この時点で、ユーザー・セッションがSSOの一部としてNYDCおよびLDCに存在します。
ユーザーは、APP1からログアウトします。
アフィニティが理由で、このログアウト・リクエストはNYDCに到達します。
NYDCのサーバーは、ユーザーのSSOセッションを終了させ、すべてのSSOパートナからログアウトします。
NYDCのサーバーはOAPセッション終了リクエストを、SSOセッションに関連付けられているすべての関連データ・センターに送信します。これには、LDCも含まれます。
この結果として、SSOに関連付けられているすべてのユーザー・セッションがすべてのデータ・センターからクリアされます。
地理的に非常に近接し、保証された待ち時間が5ミリ秒未満のデータ・センターでは、ストレッチ・クラスタ・デプロイメントを選択できます。
この場合、前項で説明した従来のマルチデータ・センターのデプロイメントとは異なり、1つのOAMクラスタが複数のデータ・センターにわたって拡張され、1つのデータ・センターに一部のOAMノードがあり、別のデータ・センターに残りのノードがあります。デプロイメントは2つのデータ・センターに分散していますが、Access Managerはこれを単一のクラスタとして扱います。ポリシー・データベースは、データ・センターのいずれかに存在することになります。ストレッチ・クラスタ・デプロイメントには、次の制限が適用されます。
Access Managerは、ノードの同期を維持するために、基礎となるWebLogicおよびコヒーレンス層に依存します。データ・センター間の待ち時間は、常に5ミリ秒未満である必要があります。待ち時間のスパイクは、不安定および予期しない動作を引き起こす可能性があります。
ストレッチ・クラスタ・デプロイメントでは、実行時のデータ・センター間の傍受通信が、従来のマルチデータ・センター・デプロイメントの場合よりも比較的多くなります。後者の場合、データ・センター間のランタイム通信は、データ・センター間でセッションの採用が必要となるユースケースに制限されています。
データ・センター全体にわたって単一のクラスタであるので、従来のマルチデータ・センター・デプロイメントと同じレベルの信頼性と可用性を提供しません。ポリシー・データベースが単一点障害となる可能性があります。従来のマルチデータ・センター・デプロイメントでは、各データ・センターが自立し、他のデータ・センターから独立して動作することで、より高い信頼性を提供します。
図17-7はストレッチ・クラスタ・デプロイメントを示し、その次の図17-8は、従来のMDCデプロイメントを示しています。ストレッチ・クラスタ・デプロイメントよりも従来のマルチ・データ・センター・デプロイメントをお薦めします。
