WebSphere Application Server, Version 6.1   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows, Windows Vista

             目次と検索結果のパーソナライズ化

トラスト・アソシエーション

トラスト・アソシエーション により、 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 がプロキシー・サーバーを経由しない要求を受け入れるのを防止することはできません。 この場合には、信頼性の検証にインターセプターは不要です。

WebSphere Application Server では、 以下のトラスト・アソシエーション・インターセプター (TAI) インターフェースがサポートされています。
com.ibm.ws.security.web.WebSealTrustAssociationInterceptor
WebSphere Application Server TAI インターフェースがインプリメントされた、この Tivoli TAI インターセプターにより、WebSEAL バージョン 4.1 のサポートが提供されます。 WebSEAL 5.1 以降のバージョンを使用する場合は、新規 com.ibm.wsspi.security.tai.TrustAssociationInterceptor インターフェースを実装した、新規 com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus インターセプターを使用するようマイグレーションすることが推奨されます。
com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus
新規 WebSphere Application Server インターフェースをインプリメントした、この TAI インターセプターのインプリメンテーションでは、WebSphere Application Server バージョン 5.1.1 およびそれ以降のバージョンがサポートされます。 このインターフェースでは WebSEAL バージョン 5.1 以降のバージョンはサポートされていますが、WebSEAL バージョン 4.1 はサポートされていません。 セキュリティー属性伝搬の説明については、セキュリティー属性の伝搬 を参照してください。

IBM WebSphere Application Server: WebSEAL の統合

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 サーバーに配信され、 そのリソースはクライアント・ユーザーに渡されます。

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 要求を介して伝送されます。

HTTP サーバー

WebSEAL サーバーで作成されるジャンクションは、 本製品のフロントエンドとして機能する HTTP サーバーに届く必要があります。しかし、HTTP サーバーには、トラスト・アソシエーションが使用されているかどうかはわかりません。 その点では、WebSEAL 製品ももう 1 つの HTTP クライアントであるにすぎず、その通常のルーチンの一環として、 HTTP 要求を本製品に送信します。HTTP サーバーでの唯一の要件は、 サーバー認証だけを使用する Secure Sockets Layer (SSL) 構成です。 この要件によって、ジャンクション内を流れる要求が保護されます。

Web コラボレーター

トラスト・アソシエーションが使用可能になっていると、 Web コラボレーターは、システム内で構成されるインターセプターを管理します。 Web コラボレーターは、これらのインターセプターをサーバーの再始動時にロードし、初期化します。 Web サーバーが要求を WebSphere Application Server に渡す場合、最終的には Web コラボレーターがその要求を受け取って、セキュリティー検査を行います。 次の 2 つのアクションを実行する必要があります。
  1. 要求を認証する
  2. 要求を許可する
HTTP 要求を渡してその要求を認証するために、Web オーセンティケーター が呼び出されます。 認証に成功すると、オーセンティケーターは申し分のない信任状レコードを戻し、 Web コラボレーターはこれを使用して、要求されたリソースを許可します。 許可が正常に行われると、Web コラボレーターは WebSphere Application Server に、 セキュリティー検査で異常がなかったこと、要求のあったリソースを提供できることを知らせます。

Web オーセンティケーター

Web オーセンティケーターは、Web コラボレーターの求めに応じて、指定の HTTP 要求の認証を行います。トラスト・アソシエーションが使用可能になっていることがわかっている場合、Web オーセンティケーターのタスクは、該当するトラスト・アソシエーション・インターセプターを見付けて、処理のための要求を送信することです。 Web オーセンティケーターは、使用可能なすべてのインターセプターを照会します。 ターゲット・インターセプターが見つからない場合は、トラスト・アソシエーションが使用できない場合と同様に、 Web オーセンティケーターが要求を処理します。

WebSEAL サーバーが送信する HTTP 要求の場合は、WebSEAL トラスト・アソシエーション・インターセプターが、Web オーセンティケーターに対して肯定応答を行います。続いて、インターセプターに対し、WebSEAL サーバーとのトラスト・アソシエーションを検証して、 新規のトラスト・アソシエーション・インターセプター (TAI) インターフェースを使用してサブジェクトを検索するか、 以前の TAI インターフェースを使用して元のユーザー・クライアントのユーザー ID を検索するよう、要求が行われます。

注: 新しいトラスト・アソシエーション・インターセプター (TAI) のインターフェースである、com.ibm.wsspi.security.tai.TrustAssociationInterceptor は、いくつかの新しい機能をサポートしており、既存の com.ibm.websphere.security.TrustAssociationInterceptor のインターフェースとは異なっています。

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) へのアクセスを保護する一方で、 認証とおおまかな許可、およびターゲット・アプリケーション・サーバーへの要求のルーティングを実行します。

トラスト・アソシエーション・インターセプター・フィーチャーの使用

ここでは、トラスト・アソシエーション・インターセプター (TAI) フィーチャーの利点についてさらに詳しく説明します。
  • RPSS は、WebSphere Application Server のユーザーをあらかじめ認証し、 認証済みのユーザーに関する信任状情報を本製品に送信することができます。 これによって本製品は、RPSS が認証を実行したことを信頼して、 あとでエンド・ユーザーに認証データを求めるプロンプトを出すことはしません。 RPSS と本製品の信頼関係の強さは、RPSS に特有で、TAI インプリメンテーションを介して実行されるトラスト・アソシエーションの基準によって決まります。この信頼のレベルは、 環境によっては緩和しなければならない場合もあります。 セキュリティーのテクノロジーに基づいて RPSS が信頼できない場合のぜい弱性について、 認知しておく必要があります。
  • エンド・ユーザーの信任状は、ほとんどの場合、RPSS 認証の場合と同様、 Hypertext Transfer Protocol (HTTP) ヘッダーの一部として、特別なフォーマットで送信されます。 信任状は、特別なヘッダーまたは Cookie の場合もあります。 渡されるデータはインプリメンテーションに特有であり、TAI フィーチャーはこの事実を考慮して、それに対応します。 TAI インプリメンテーションはクレデンシャルのデータを処理し、新規 TAI インターフェースを使用してサブジェクトを戻すか、 または以前の TAI インターフェースを使用してエンド・ユーザーを表すユーザー ID を戻します。 WebSphere Application Server は、 セキュリティー・ポリシーを実行するためにその情報を使用します。



関連概念
認証メカニズム
関連タスク
サード・パーティー HTTP リバース・プロキシー・サーバーの統合
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 5:05:53 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/csec_trust.html