test

Sun Java System Access Manager 7.1 配備計画ガイド

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 インスタンス

詳細は、『Sun Java System Access Manager 7.1 Postinstallation Guide』の第 3 章「Deploying Multiple Access Manager Instances」を参照してください。

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) を通信ブローカとして使用し、Berkeley DB をデフォルトのセッションストアデータベースとして使用します。Access Manager セッションフェイルオーバーは、単一のハードウェアまたはソフトウェアの障害発生時に、ユーザーの認証セッション状態を維持するため、セッション情報を失ったり、ユーザーに再ログインを要求したりせずに、ユーザーのセッションをセカンダリ Access Manager インスタンスにフェイルオーバーできます。

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

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

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 3.7 UR1 技術の概要』を参照してください。

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

次の図に、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 に対してのみ実行され、現在のリリースでは、サイト間のセッションフェイルオーバーはサポートされていません。

詳細は、『Sun Java System Access Manager 7.1 Postinstallation Guide』の第 6 章「Implementing Session Failover」を参照してください。

Access Manager および Portal Server の配備

Java Enterprise System 5 リリースでは、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 7.1 配備計画ガイド』を参照してください。

連携管理、SAML、および Web サービス

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

まず Access Manager が実装したのは、アカウント連携およびシングルサインオン (SSO) のためのフレームワークを構成する Liberty Identity Federation Framework (Liberty ID-FF) 仕様です。それ以降のリリースの Access Manager には、Liberty ID-FF 仕様のVersion 1.2 および Liberty Identity Web Services Framework (Liberty ID-WSF) の Version 1.0 仕様で定義されている新機能が追加されました。

Liberty ID-WSF フレームワークは、Liberty Alliance Project のビジネスモデルをサポートするために使用できる Web サービススタックを定義します。サービスの例には、個人プロファイルサービス、ディスカバリサービス、認証サービス、SOAP バインディングサービスなどがあります。これらの Web サービスでは、主体認証、連携、およびプライバシ保護のために Liberty ID-FF を利用します。

Access Manager は、セキュリティー情報を交換するための Security Assertion Markup Language (SAML) サービスも実装します。SAML 1.0 および 1.1 の両方の仕様がサポートされています。

詳細は、『Sun Java System Access Manager 7.1 Federation and SAML Administration Guide 』を参照してください。このガイドには、仕様の概要と、Access Manager でこれらの仕様がどのように実装されているかについての情報が記載されています。さらに、アプリケーションプログラミングインタフェース (API) の設定情報、ユースケース、および要約も記載されています。

Sun Java System Federation Manager

Sun Java System Federation Manager 7.0 2005Q4 は軽量のサーバーアプリケーションで、企業はこれを利用することで、相互運用性のあるアイデンティティーサービスおよび認証サービスを、Liberty Alliance Project 仕様に基づいて迅速に構築できます。これらのサービスは、Web アクセス管理ソリューションや認証局など、連携に関する既存の技術または新しく配備された技術と連動し、またそれらの技術を補完します。

Federation Manager を使用すると、再利用可能な標準ベースのフレームワークを構築して、セキュリティー表明、ユーザー属性、およびポリシーをパートナーの分散ネットワーク上で交換することができます。Federation Manager は、任意の Liberty または SAML 準拠製品と組み合わせて使用できるスタンドアロン製品です。Federation Manager を使用するために Access Manager をインストールする必要はありません。詳細は、次のマニュアルコレクションを参照してください。

http://docs.sun.com/coll/1321.1

Sun Java System Application Server 9.0 または Web サービス用の Sun Java System Access Manager Policy Agent 2.2

Sun Java System Application Server 9.0 または Web サービス用の Sun Java System Access Manager Policy Agent 2.2 は、Sun Java System Application Server Platform Edition 9.0 のプラグインとして動作し、Liberty Alliance Project トークンプロファイルおよび Web Services-Interoperability Basic Security Profiles (WS-I BSP) の両方に対して、メッセージレベルのセキュリティーとサポートを提供します。このエージェントは HTTP 認証エージェントと SOAP 認証エージェントの両方を提供し、すべての認証決定のために Access Manager 7.1 を使用します。

エージェントのインストール手順などの詳細は、『Sun Java System Access Manager Policy Agent 2.2 Guide for Sun Java System Application Server 9.0/Web Services 』へのリンクを参照してください。

注 –

Sun Java System Application Server Platform Edition 9.0 は Java Enterprise System 5 コンポーネントではありません。詳細は、次のマニュアルコレクションを参照してください。

http://docs.sun.com/coll/1343.3