トラスト・アソシエーション により、 IBM WebSphere Application Server セキュリティーとサード・パーティー製セキュリティー・サーバーとを統合することができます。具体的には、 リバース・プロキシー・サーバーがフロントエンド認証サーバーとして機能できるようになる一方で、この製品は、 製品自体の許可ポリシーを、プロキシー・サーバーから渡された信任状に適用します。
このような統合構成の要求は、 特に 1 つの製品で顧客のあらゆるニーズに対応できない場合や、 マイグレーションが難しい場合に、ますます差し迫ってきています。 本項では、このアプローチの概念的なバックグラウンドについて述べます。
このセットアップでは、WebSphere Application Server は、詳細なアクセス制御をさらに活用するバックエンド・サーバーとして使用されます。 リバース・プロキシー・サーバーは、認証済みユーザーのクレデンシャルを含む HTTP 要求を、 WebSphere Application Server に渡します。 WebSphere Application Server は、その信任状を使用して要求を許可します。
WebSphere Application Server がトラスト・アソシエーションをサポートできるという着想は、この製品のアプリケーション・セキュリティーが、リバース・プロキシー・サーバーから受信した HTTP 要求を認識し、処理することを意味します。WebSphere Application Server とプロキシー・サーバーは、この製品がプロキシー・サーバーを完全に信頼する代わりに、プロキシー・サーバーは、認証ポリシーを、WebSphere Application Server にディスパッチされるすべての Web 要求に適用するという契約を結びます。この信頼性は、 受信したすべての要求について、製品環境内のインターセプターによって検証されます。 検証は、プロキシー・サーバーとインターセプターの間で合意に達した方法で行われます。
トラスト・アソシエーション・モードで実行しても、WebSphere Application Server がプロキシー・サーバーを経由しない要求を受け入れるのを防止することはできません。 この場合には、信頼性の検証にインターセプターは不要です。
WebSEAL と WebSphere Application Server セキュリティーの統合を実現するには、WebSEAL サーバーをリバース・プロキシー・サーバーとしてフロントエンドに配置します。 WebSEAL の管理という視点から、一方の端に WebSEAL を、他方の端に本製品の Web サーバーを配置したジャンクションが構築されます。ジャンクションとは、WebSEAL サーバーから別のサーバーへのパスを確立するために作成される論理接続です。
このセットアップでは、本製品の保護ドメインに保管されている Web リソースに対する要求が WebSEAL サーバーに実行依頼され、ここで、WebSEAL のセキュリティー・レルムに照らして認証されます。要求元ユーザーにジャンクションへのアクセス権があれば、要求はジャンクションを経由して WebSphere Application Server の HTTP サーバーへ、次いでアプリケーション・サーバーへと伝送されます。
一方、WebSphere Application Server はジャンクション経由で入ってくるすべての要求を検証し、送信元が信頼できる相手であることを確認します。 このプロセスは、「信頼性の検証」として参照され、WebSEAL 製品が指定するインターセプターによって実行されます。 検証に成功すると、WebSphere Application Server は、クライアント・ユーザーが Web リソースにアクセスするのに必要な許可を得ているかどうかを調べた上で、要求を許可します。 要求が許可されると、Web リソースが Web サーバーを介して WebSEAL サーバーに配信され、 そのリソースはクライアント・ユーザーに渡されます。
Policy Director は、すべての Web 要求を、 その Web コンポーネントである WebSEAL サーバーに委任します。 サーバーの主要機能の 1 つは、要求元ユーザーの認証を行うことです。 WebSEAL サーバーは、 Lightweight Directory Access Protocol (LDAP) ディレクトリーを参照します。 また、グローバルのシングル・サインオン (GSO) を使用する場合のように、元のユーザー ID を別のユーザー ID にマップする場合もあります。
認証を正常に行うために、サーバーは、要求を通す際に、WebSphere Application Server に対するクライアントの役割を果たします。 サーバー自体を WebSphere Application Server に対して識別するためには、 サーバー独自のユーザー ID とパスワードが必要です。 この ID は、WebSphere Application Server のセキュリティー・レルムで有効でなければなりません。 WebSEAL サーバーは、HTTP 要求内の基本認証情報を、 独自のユーザー ID とパスワードで置き換えます。 さらに、アプリケーション・サーバーが許可を決定するためのベースとして使用する ID を持つように、 WebSphere Application Server は、要求側クライアントの信任状を判別しなければなりません。 この情報は、Tivoli Access Manager ユーザー・クレデンシャルを値 として持つ iv-creds と呼ばれるヘッダーを作成することにより、HTTP 要求を介して伝送されます。
Web オーセンティケーターは、Web コラボレーターの求めに応じて、指定の HTTP 要求の認証を行います。トラスト・アソシエーションが使用可能になっていることがわかっている場合、Web オーセンティケーターのタスクは、該当するトラスト・アソシエーション・インターセプターを見付けて、処理のための要求を送信することです。 Web オーセンティケーターは、使用可能なすべてのインターセプターを照会します。 ターゲット・インターセプターが見つからない場合は、トラスト・アソシエーションが使用できない場合と同様に、 Web オーセンティケーターが要求を処理します。
WebSEAL サーバーが送信する HTTP 要求の場合は、WebSEAL トラスト・アソシエーション・インターセプターが、Web オーセンティケーターに対して肯定応答を行います。続いて、インターセプターに対し、WebSEAL サーバーとのトラスト・アソシエーションを検証して、 新規のトラスト・アソシエーション・インターセプター (TAI) インターフェースを使用してサブジェクトを検索するか、 以前の TAI インターフェースを使用して元のユーザー・クライアントのユーザー ID を検索するよう、要求が行われます。
WebSphere Application Server のバージョン 4 から バージョン 5.x まで は、com.ibm.websphere.security.TrustAssociationInterceptor.java インターフェースを サポートしています。 WebSphere Application Server バージョン 6.0.x 以降 では、com.ibm.wsspi.security.tai.TrustAssociationInterceptor インターフェースを サポートしています。
トラスト・アソシエーション・インターセプター・インターフェースの目的は、リバース・プロキシー・セキュリティ ー・サーバー (RPSS) を公開されたエントリー・ポイントとして、認証とおおまかな許可を実行することです。これに 対して、WebSphere Application Server は詳細なアクセス制御を実行します。 トラスト・アソシエーションにより公開の範囲とリスクが削減され、セキュリティーが向上します。
典型的な e-business のインフラストラクチャーでは、企業の分散環境は、 Web アプリケーション・サーバー、Web サーバー、既存システム、 および 1 つ以上の RPSS (Tivoli WebSEAL 製品など) で構成されています。 Web サーバー内部に登録されているこのようなリバース・プロキシー・サーバー、 フロントエンド・セキュリティー・サーバー、またはセキュリティー・プラグインが、 Web サーバーおよび Web アプリケーション・サーバーへの HTTP アクセス要求を保護します。 これらの RPSS は、Uniform Resource Identifier (URI) へのアクセスを保護する一方で、 認証とおおまかな許可、およびターゲット・アプリケーション・サーバーへの要求のルーティングを実行します。