test

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

第 4 章 Access Manager を使用する場合の論理設計

ソリューションライフサイクルの論理設計段階では、ソリューションにおける論理コンポーネントの相互関係を示す論理アーキテクチャーを設計します。論理アーキテクチャーと技術要件段階で作成した使用状況分析とによって配備シナリオが作成され、このシナリオが配備設計段階でのインプットとなります。この章は、Sun Java TM System Access Manager の論理設計に関する次の節で構成されています。

論理アーキテクチャーについて

論理アーキテクチャーによって、ソリューションの実装に必要なソフトウェアコンポーネントが明確にされ、それらコンポーネントの相互関係が示されます。論理アーキテクチャーと技術要件段階で決定した QoS 要件とによって配備シナリオが作成されます。配備シナリオは、次の配備設計段階で行う配備アーキテクチャー設計のための基礎となります。

論理アーキテクチャーの設計

論理アーキテクチャーを設計する際には、技術要件段階で確認したユースケースを使用して、ソリューションに必要なサービスを提供する Java Enterprise System (Java ES) コンポーネントを決定します。最初に指定したコンポーネントに対してサービスを提供するコンポーネントについても、すべて列挙する必要があります。

Java ES コンポーネントは、提供するサービスに応じて、多層アーキテクチャーのコ ンテキスト内に配置します。コンポーネントが多層アーキテクチャーの一部であることを理解すると、コンポーネントによって提供されるサービスを分配する方法を決めたり、スケーラビリティーや可用性などの Quality of Service (QoS) を実現する方針を決めたりするのに役立ちます。

論理アーキテクチャーおよびソリューションライフサイクルの詳細は、『Sun Java Enterprise System 2005Q4 Deployment Planning Guide』を参照してください。

Access Manager コンポーネント

Access Manager の配備には、次の製品およびコンポーネントが含まれます。

Web コンテナ

Access Manager は、次のいずれかの Web コンテナ内で実行する必要があります。

サポートされる各 Web コンテナの特定のバージョンについては、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。

Directory Server

Access Manager には、次のエンティティー用に LDAP ディレクトリサーバーが必要です。

Access Manager 情報ツリー

Access Manager 7 2005Q4 では、Access Manager 情報ツリーを格納するために Sun Java System Directory Server が必要です。Access Manager が作成および維持する Access Manager 情報ツリーには、システムアクセスに関係する次の情報が保持されます。

アイデンティティーリポジトリ

Access Manager には、ユーザーやグループなどのユーザーデータを格納するためのアイデンティティーリポジトリが必要です。以前のバージョンの Access Manager では、アイデンティティーリポジトリとして Sun Java System Directory Server が必要でした。しかし、Access Manager 7 2005Q4 では、Sun Java System Directory Server に加えて、LDAP バージョン 3 (LDAP v3) 互換のディレクトリサーバーもサポートされています。

セッションフェイルオーバー用の Message Queue および Berkeley DB

セッションフェイルオーバーの実装を計画している場合は、Access Manager に次のコンポーネントが必要です。

Access Manager を使用する Java ES コンポーネント

通常、Access Manager は次の Java ES コンポーネント製品とともに配備されます。

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) の要約も記載されています。