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

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

EJB セキュリティーの認証プロトコル

Secure Authentication Service (SAS) および Common Secure Interoperability Version 2 (CSIv2) という、2 つの認証プロトコルから選択できます。

SAS は、WebSphere Application Server のこれまでのすべてのリリースで使用されている認証プロトコルであり、後方互換性を考慮して保守されています。 オブジェクト管理グループ (OMG) では、複数のベンダーが安全に相互運用できるように、 CSIv2 と呼ばれる認証プロトコルを定義しました。 CSIv2 は、WebSphere Application Server に実装され、 SAS よりもフィーチャーが多く、戦略的なプロトコルと考えられます。

セキュアな WebSphere Application Server 環境で Enterprise Java Beans (EJB) メソッドを起動するには、 認証プロトコルでセキュリティーのレベルと認証のタイプを決定する必要があります。 この決定は、所定のクライアントとサーバーとの間で要求ごとに行います。 メソッド起動時に、 オブジェクトの相互運用オブジェクト参照 (IOR) により決定されるサーバーの認証要件と、 クライアントの構成により決定されるクライアントの認証要件を組み合わせ、 そのクライアントとサーバーのペアに固有の認証ポリシーを作り出すのが、認証プロトコルの仕事です。

認証ポリシーでは例えば以下の決定を行いますが、 これらの決定はすべてクライアントとサーバーの構成に基づいて行われます。

両方のプロトコル (SAS および CSIv2) が同時に機能するような構成も可能です。 サーバーが両方のプロトコルをサポートする場合は、SAS および CSIv2 用の構成を記述するタグ付きコンポーネントを含む IOR をエクスポートします。クライアントが両方のプロトコルをサポートする場合は、CSIv2 および SAS 用のタグ付きコンポーネントを読み取ります。 クライアントが両方をサポートし、サーバーも両方をサポートする場合は、CSIv2 が使用されます。 ただし、サーバーが SAS をサポートし (例えば、WebSphere Application Server の旧リリースであるため)、クライアントが両方をサポートしている場合、 SAS プロトコルが両者に共通しているため、クライアントはこの要求について SAS を選択します。

プロトコルを選択するには、クライアント・サイドで com.ibm.CSI.protocol プロパティーを指定し、 サーバー・サイドで管理コンソールを使用して構成します。 詳細は、SAS および CSIv2 プロパティーについての項目に記載されています。

Common Secure Interoperability 仕様、バージョン 2

Common Secure Interoperability 仕様、 バージョン 2 (CSIv2) は、相互運用可能な認証、代行、 および特権を使用可能にする Security Attribute Service (SAS) を定義します。 CSIv2 SAS プロトコルと SAS プロトコルはまったく異なるものです。 CSIv2 SAS は CSIv2 のサブコンポーネントであり、 SSL および EJB 仕様バージョン 2.1 とのインターオペラビリティーをサポートしています。

Security Attribute Service

Common Secure Interoperability 仕様、バージョン 2 Security Attribute Service (CSIv2 SAS) プロトコルは、 General Inter-ORB Protocol (GIOP) 要求のサービス・コンテキスト内でプロトコル・エレメントを交換し、 接続ベースのトランスポートを介して送られるメッセージに応答するように設計されています。 このプロトコルは、 Secure Sockets Layer (SSL) および Transport Layer Security (TLS) を介して使用可能であるようなトランスポート層セキュリティーを使用してメッセージを保護し (すなわち、保全性と機密性の両方またはその一方)、 サーバー/クライアント認証を行う環境での使用を目的としています。 このプロトコルは、 基礎にあるトランスポートに関係した問題を解決するために適用可能なクライアント認証、 代行、および特権の機能を備えています。 CSIv2 SAS プロトコルは、 セキュアなトランスポートを一元管理できる高水準プロトコルとして機能することで、 インターオペラビリティーを容易にします。

接続および要求インターセプター

WebSphere Application Server で使用する認証プロトコルは、 アドオン Interoperable Inter-ORB Protocol (IIOP) サービスです。 IIOP は要求と応答の通信プロトコルで、 2 つのオブジェクト・リクエスト・ブローカー (ORB) 間でメッセージを送信する場合に使用されます。 クライアントの ORB によりサーバーの ORB に対して行われる要求ごとに、 関連付けられた応答がサーバーの ORB によってクライアントの ORB に戻されます。 要求が流れるより先に、クライアント ORB とサーバー ORB 間の接続が、 TCP/IP トランスポート (SSL は TCP/IP のセキュアなバージョンです) を介して確立されていなければなりません。 クライアント ORB は、認証プロトコルのクライアント接続インターセプターを呼び出し、 これを使用してサーバー上にあるオブジェクトの IOR 内のタグ付きコンポーネントを読み取ります。 前に述べたように、要求についての認証ポリシーは、ここで確立されます。 認証ポリシー (サーバー構成とクライアント構成を合体したもの) が与えられていると、 接続の強度が ORB に戻されます。 ORB は該当する接続を実行します。通常は SSL を介した接続です。

接続が確立されると、 クライアント ORB は認証プロトコルのクライアント要求インターセプターを呼び出し、 それを使用して、トランスポートによって確立されたもの以外のセキュリティー情報を送信します。 このセキュリティー情報には、サーバーが認証するユーザー ID およびパスワードのトークン、 サーバーが検証する認証メカニズム固有のトークン、 あるいは ID アサーション・トークンが含まれています。 ID アサーションは、あるサーバーが別のサーバーを信頼する方法で、 要求元のクライアントを再認証または再検証する必要がありません。 ただし、アップストリーム・サーバーを信頼するには、サーバーに対していくつかの作業が必要です。 この追加セキュリティー情報は、 サービス・コンテキスト のメッセージと共に送信されます。 サービス・コンテキストには登録済みの ID があり、 サーバー ORB が、どのプロトコルがこの情報を送信しているかを判別できるようにしています。

サービス・コンテキストに固有の ID があるという事実は、 WebSphere Application Server が SAS と CSIv2 の両方を同時にサポートするためのもう 1 つの方法になります。 これは、両方のプロトコルが、異なるサービス・コンテキスト ID を持つためです。 クライアント要求インターセプターがメッセージへのサービス・コンテキストの追加を終了すると、 メッセージはサーバー ORB に送信されます。

サーバー ORB は、メッセージを受信すると、認証プロトコルのサーバー要求インターセプターを呼び出します。 このインターセプターは、プロトコルが認識するサービス・コンテキスト ID を探します。 サーバーが SAS と CSIv2 の両方をサポートしている場合は、 2 つの異なるサーバー要求インターセプターが呼び出され、 両方のインターセプターは異なるサービス・コンテキスト ID を探します。

ただし与えられた要求に対するサービス・コンテキストを検出するのは、一方のインターセプターのみです。 サーバー要求インターセプターはサービス・コンテキストを検出すると、その中の情報を読み取ります。 メソッドがセキュリティー・サーバーに呼び出され、クライアント ID を認証または検証します。 セキュリティー・サーバーは、この情報をリジェクトするか、あるいは信任状を戻します。 クレデンシャルには、許可で適切な決定が行われるように、 ユーザー・レジストリーから取り出されたクライアントに関する追加情報が含まれています。 許可は、ユーザーが要求を呼び出すことができるかどうかを、 メソッドに適用された役割とユーザーに与えられた役割に基づいて判別するプロセスです。

CSIv2 サーバー要求インターセプターは、サービス・コンテキストを検出しなかった場合、 トランスポート接続を調べて、クライアント証明書チェーンが送信されているかどうかを確認します。 このプロセスが実行されるのは、SSL クライアント認証がクライアントとサーバーの間で構成されている場合です。

クライアント証明書チェーンが 検出される場合は、識別名 (DN) が証明書から抽出され、 これを使用してユーザー・レジストリー内の ID にマップします。 ユーザー・レジストリーが Lightweight Directory Access Protocol (LDAP) の場合、LDAP レジストリー構成で定義されている検索フィルターによって、 証明書をレジストリーのエントリーにマップする方法が決まります。 ユーザー・レジストリーがローカル OS の場合、 識別名 (DN) の最初の属性が、レジストリーのユーザー ID にマップされます。 この属性は、通常は共通名です。

証明書がマップされない場合は、信任状が作成されず、要求はリジェクトされます。 有効なセキュリティー情報が提示されないと、メソッド要求がリジェクトされ、 NO_PERMISSION 例外が応答と一緒に戻されます。 ただし、セキュリティー情報が提示されない場合、 要求の非認証クレデンシャルが作成され、許可エンジンがメソッドを起動するかどうかを決定します。 Enterprise JavaBean (EJB) メソッドを起動する非認証クレデンシャルでは、 メソッドにセキュリティー役割が定義されないか、 あるいは特別の Everyone 役割がメソッドに定義されます。

メソッドの起動が EJB コンテナーで完了すると、 サーバー要求インターセプターがもう一度呼び出されてサーバーの認証を完了し、 新規の応答サービス・コンテキストが作成されて、 クライアント要求インターセプターに結果を通知します。 この処理は、要求をステートフル にするという目的の場合に一般的です。 ステートフルな要求が行われる場合は、クライアントとサーバー間の最初の要求についてのみ、 セキュリティー情報の送信が必要になります。 後続のすべてのメソッド要求では、サーバーがセッション表に保管されたクレデンシャルをルックアップできるように、 固有のコンテキスト ID のみの送信が必要となります。 コンテキスト ID は、クライアントとサーバー間の接続内で固有です。

最後に、クライアント要求インターセプターが、 情報を提供する応答サービス・コンテキストとともに応答をサーバーから受信して、メソッド要求サイクルが完了します。 これにより、クライアント・サイドのステートフルなコンテキスト ID が確認され、再利用できるようになります。

ステートフルなクライアントは、 プロパティー com.ibm.CSI.performStateful (true/false) を介して指定されます。 ステートフルなサーバーは、管理コンソール構成を介して指定されます。

認証プロトコルのフロー

要求ごとの認証ポリシー

指定された要求の認証ポリシーによって、 クライアントとサーバー間のセキュリティー保護が決定します。 クライアントまたはサーバーの認証プロトコルの構成で、 必要なフィーチャー、サポートされるフィーチャー、およびサポートされないフィーチャーを記述できます。 クライアントがあるフィーチャーを必要とする場合、 クライアントは、フィーチャーを必要とするかまたはサポートするサーバーとのみ通信できます。 サーバーがあるフィーチャーを必要とする場合、 サーバーは、フィーチャーを必要とするかまたはサポートするクライアントとのみ通信できます。 クライアントがあるフィーチャーをサポートしている場合、 そのクライアントは、そのフィーチャーをサポートしているかまたは必要とするサーバーと通信できますが、 そのフィーチャーをサポートしていないサーバーとも通信できます。 サーバーがあるフィーチャーをサポートする場合、 サーバーは、フィーチャーをサポートするかまたは必要とするクライアントと通信できますが、 フィーチャーをサポートしない、またはそのフィーチャーをサポートしないことを選択しているクライアントと も通信できます。

例えば、クライアント証明書認証をサポートするクライアントの場合、 自己署名証明書を生成するかまたは認証局 (CA) からそれを取得するには、 いくつかのセットアップが必要です。 クライアントによっては、これらのアクションを完了する必要がない場合もあるので、 このフィーチャーをサポートされないものとして構成することもできます。 このように決定すると、このクライアントは、 クライアント証明書認証を必要とするセキュア・サーバーとは通信できません。 その代わり、このクライアントは、 サーバーに対する認証の手段としてユーザー ID とパスワードを使用するように選択することができます。

一般に、フィーチャーをサポートすることが、フィーチャーを構成する最も一般的な方法です。 この方法はフィーチャーを必要とするというよりむしろ容認するため、 実行時に最も順調に実行できる方法でもあります。 ドメインでのセキュア・サーバーの構成方法がわかっていれば、 クライアントが正常なメソッド起動を確実に実行し、 さらに最高のセキュリティーを確保できるような適切な組み合わせを選択できます。 すべてのサーバーが、クライアント証明書、 およびユーザー ID とパスワードによるクライアントの認証の両方をサポートすることがわかっている場合、 一方を必須にして、他方はサポートしないようにしてください。 ユーザー ID とパスワード、およびクライアント証明書の両方が、 クライアントでもサーバーでもサポートされる場合は、どちらの認証も実行されますが サーバーではユーザー ID とパスワードが優先されます。 このアクションは、CSIv2 仕様の要件に基づいています。




サブトピック
Common Secure Interoperability Version 2 のフィーチャー
ダウンストリーム・サーバーに対する ID アサーション
信頼性検証での ID アサーション
メッセージ層認証
関連タスク
通信の保護
概念トピック    

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

最終更新: Jan 21, 2008 11:31:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/csec_corba.html