test

Sun Java System Access Manager 7 2005Q4 配備計画ガイド

Access Manager 論理アーキテクチャーの例

ここでは、Access Manager ソリューションの論理アーキテクチャーの例として、次のシナリオを取り上げます。

Access Manager の Web 配備

Access Manager 配備では一般に Web ブラウザを使用して、Web サーバー上に配備されたアプリケーションまたはリソースにアクセスします。アプリケーションまたはリソースは Access Manager により保護されるため、通信は、Web サーバーにインストールされたポリシーエージェントを使用して行われます。さらに、Web サーバーに Access Manager SDK を配備することもできます。このシナリオの場合、マシン上の Web サーバーの数や、複数のマシンに配備される Access Manager のインスタンスに関して制限はありません。たとえば、1 台のマシンで複数の Web サーバーを稼働させ、それぞれに Access Manager のインスタンスを配備することもできます。同様に、複数の Web サーバーを別々のマシン上で稼働させ、それぞれに Access Manager のインスタンスを配備することもできます。

次の図に、Access Manager の Web 配備シナリオを示します。

図 4–1 Access Manager の Web 配備

Web 配備シナリオ

Access Manager の複数サーバー配備

Access Manager を複数のサーバーに配備する場合、2 台以上のホストサーバーに、それぞれ 1 つ以上の Access manager インスタンスを配備します。それぞれの Access Manager インスタンスは同じ Directory Server にアクセスします。配備環境に応じて、Directory Server インスタンスをマルチマスターレプリケーション (MMR) 設定にすることができます。

1 番目のホストサーバーにインストールされた Access Manager インスタンスは、Directory Server のインスタンスを指し示します。Java ES インストーラを使用したインストールでは、実際の配備に応じて既存の Directory Server が、既存のディレクトリ情報ツリー (DIT) を使用するか、使用しないかを選択できます。

Java ES インストーラを実行して、その他のサーバーに Access Manager のそれ以外のインスタンスをインストールし、既存の DIT を使用して、Access Manager インスタンスが Directory Server を指し示すようにします。このとき Access Manager は、Directory Server がすでに存在しているものと認識しているため、情報を一切 Directory Server に書き込みません。

次の図には、1 つの Directory Server に対して、異なるホストサーバー上に配備され た複数の Access Manager インスタンスを示しています。

図 4–2 1 つの Directory Server に対する複数の Access Manager インスタンス

1 つの Directory Server に対する複数の Access Manager インスタンス

詳細については、「複数のホストサーバーへの Access Manager のインストール」を参照してください。

Java アプリケーションの配備

別の一般的な Access Manager のシナリオでは、Java アプリケーションは配備先のサーバーに直接インストールされた Access Manager SDK にアクセスできます。このシナリオでは、1 つ以上の Access Manager インスタンスが稼働する Sun Java System Web Server または Sun Java System Application Server など Web コンテナのインスタンスを持つ追加サーバーが必要になります。 このサーバーは、情報を管理してシングルサインオン (SSO) を提供します。次の図は、Java アプリケーションの配備シナリオを示しています。

図 4–3 Java アプリケーションの配備

Java アプリケーションの配備シナリオ

Access Manager セッションフェイルオーバー配備

Access Manager は、Web コンテナから独立したセッションフェイルオーバーの実装を提供しています。その際、Sun Java System Message Queue (Message Queue) を通信ブローカとして使用し、Sleepycat Software, Inc. の Berkeley DB をセッションストアデータベースとして使用します。Access Manager セッションフェイルオーバーは、単一のハードウェアまたはソフトウェアの障害発生時に、ユーザーの認証セッション状態を維持するため、セッション情報を失ったり、ユーザーに再ログインを要求したりせずに、ユーザーのセッションをセカンダリ Access Manager インスタンスにフェイルオーバーできます。

Access Manager セッションフェイルオーバーの概要

Access Manager 7 2005Q4 セッションフェイルオーバーには、次のコンポーネントが含まれます。

Access Manager のセッションフェイルオーバーは、次の Message Queue のパブリッシュ/サブスクライブ (トピック送信先) 配信モデルに従います。

  1. ユーザーがセッションの開始、更新、または終了を行うと、Access Manager はセッションの作成、更新、または削除に関するメッセージを Message Queue ブローカクラスタにパブリッシュします。

  2. Berkeley DB クライアント (amsessiondb) は Message Queue ブローカクラスタにサブスクライブし、セッションメッセージを読み取って、データベースにセッション操作を格納します。

Access Manager インスタンスが、単一のハードウェアまたはソフトウェアの問題によって失敗した場合、そのインスタンスに関連付けられているユーザーのセッションが、次のように、セカンダリ Access Manager インスタンスにフェイルオーバーします。

  1. セカンダリ Access Manager インスタンスは、Message Queue ブローカクラスタに、ユーザーのセッション情報に対するクエリ要求をパブリッシュします。

  2. Message Queue ブローカクラスタの同じセッション要求トピックにサブスクライブしている Berkeley DB クライアント (amsessiondb) は、クエリー要求を受信し、セッションデータベースから対応するエントリを取得して、ユーザーのセッション情報をセッション応答トピックとともに Message Queue ブローカクラスタにパブリッシュします。

  3. セッション応答トピックにサブスクライブしているセカンダリ Access Manager インスタンスは、ユーザーのセッションを伴う応答を受信し、セッション情報を失ったり、ユーザーが再度ログオンしたりすることなく続行できます。

Message Queue ブローカが失敗すると、Access Manager は非セッションフェイルオーバーモードで動作します。あとで Message Queue ブローカが再起動すると、Access Manager はセッションフェイルオーバーモードに戻ります。

Message Queue コンポーネントおよびパブリッシュ/ サブスクライブ配信モデルにつ いては、『 Sun Java System Message Queue 技術の概要』を参照してください。

セッションフェイルオーバー配備シナリオ

次の図に、2 台のホストサーバーから構成され、それぞれ Access Manager インスタ ンス (Web コンテナ上に配備)、Message Queue ブローカークラスタ、および Berkeley DB クライアント (amsessiondb) を実行している基本的なシナリオを示します。ロードバランサはクライアント要求を Access Manager インスタンスに分配しています。両方の Access Manager インスタンスは同じ Directory Server にアクセスします。これは図に示されていません。

図 4–4 Access Manager セッションフェイルオーバー基本配備シナリオ

Access Manager 基本セッションフェイルオーバー配備シナリオ

図に示すような、それぞれ同じ Directory Server にアクセスするサイトを追加できます。ただし、セッションフェイルオーバーは、サイト内の Access Manager に対してのみ実行され、現在のリリースでは、サイト間のセッションフェイルオーバーはサポートされていません。

詳細については、「Access Manager セッションフェイルオーバーの実装」を参照してください。

Access Manager および Portal Server の配備

Java Enterprise System 2005Q4 リリースでは、Access Manager とPortal Server を同じ物理サーバーにインストールするか、複数のサーバーにインストールできます。

単一のサーバーへのインストール

このシナリオでは、Access Manager と Portal Server を同じ物理サーバーにインストールします。同じサーバーまたはリモートサーバーに、Directory Server をインストールするか、すでにインストールされている Directory Server にアクセスする必要があります。

これらのコンポーネントをインストールするには、Java Enterprise System インストーラを単独のセッションで実行し、次のように選択します。

複数のサーバーへのインストール

このシナリオでは、Portal Server は、リモートサーバーからローカルサーバー上の Access Manager にアクセスします。ローカルサーバーまたはリモートサーバーに、Directory Server をインストールするか、すでにインストールされている Directory Server にアクセスする必要があります。

Access Manager および Portal Server の配備については、『Sun Java System Portal Server 配備計画ガイド』を参照してください。

連携管理

2001 年、Sun Microsystems はほかの企業とともに Liberty Alliance Project に加わりました。このプロジェクトでは、アイデンティティーベースのインフラストラクチャー、ソフトウェア、および Web サービスを開発するための標準を定義しました。

まず Access Manager が実装したのは、アカウント連携、認証ドメイン、およびシン グルサインオン (SSO) を含む Identity Federation Framework (Liberty ID-FF) 仕様で す。それ以降のリリースの Access Manager には、Liberty ID-FF 仕様のバージョン 1.2 および Liberty Identity Web Services Framework (Liberty ID-WSF) のバージョン 1.0 仕様で定義されている新機能が追加されました。Web サービスには、アイデンティティーベースのサービスプロバイダに格納された種々の属性からなるアイデンティティーデータをインターネットを介して取得および更新するためのフレームワークが含まれます。アイデンティティープロバイダとサービスプロバイダ間の通信に必要な、クライアントアプリケーションプログラミングインタフェース (API) も提供されています。

Access Manager 7 2005Q4 では、さらに機能が追加されています。たとえば、Access Manager は、ビジネスパートナにアウトソーシングされたアプリケーションに対するユーザーアカウントを一括連携することや、アイデンティティープロバイダとサービスプロバイダ間で設定済みロールをマッピングすることを可能にします。

詳細は、『Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide』を参照してください。このマニュアルでは、上記の機能の開発に使用されたオープンな標準仕様を紹介し、それらがどのように Access Manager に実装されているかを説明しています。さらに、統合 Web サービスに関する情報およびアプリケーションプログラミングインタフェース (API) の要約も記載されています。