Web Services Security と Java Platform, Enterprise Edition セキュリティーの関係
この項では、Web Services Security (メッセージ・レベルのセキュリティー) モデルと Java™ Platform, Enterprise Edition (Java EE) セキュリティー・モデルとの関係について説明します。また、Java EE のロール・ベースの許可検査に関する情報も含まれています。
WebSphere Application Server は、 Java Specification Requests (JSR) 101 および JSR 109 をサポートします。JSR 101 および 109 は、 Java EE アーキテクチャー向けの Web サービスを定義します。 これにより、Java EE コンポーネント・アーキテクチャーで Web サービスを開発および実行することができます。
WebSphere Application Server セキュリティー (Java EE ロール・ベースのセキュリティー) による Web サービスの保護

Web サービス・ポートは、Java EE ロール・ベースのセキュリティーを使用して保護できます。Web サービスの送信側は、HTTP ヘッダーを使用して基本認証データを送信します。 SSL (HTTPS) を使用すると、トランスポートを保護できます。 WebSphere Application Server が SOAP メッセージを受け取ると、 Web コンテナーはユーザー (この例では user1) を認証し、 呼び出しのためのセキュリティー・コンテキストを設定します。セキュリティー・コンテキストが設定されると、 SOAP ルーター・サーブレットは、Web サービスの実装に要求を送信します (実装は、JavaBeans またはエンタープライズ Bean ファイルのどちらでも可)。 エンタープライズ Bean 実装の場合 、EJB コンテナーは user1 の ID に対して許可検査を実行します。
Web サービス・ポートは、Java EE ロールを使用して保護することもできます。次に、SOAP 要求が Web サービス実装にディスパッチされる前に 、Web コンテナーによって許可が実行されます。
Web Services Security によるメッセージ・レベルでの Web サービスの保護
Web Services Security を使用して、メッセージ・レベルで Web サービスを保護することもできます。 この場合、メッセージの特定部分に対するデジタル署名や暗号化が可能になります。 Web Services Security は、SOAP メッセージ内でのセキュリティー・トークンの伝搬もサポートします。 次のシナリオでは、Web サービス・ポートが Java EE ロール・ベースのセキュリティーでは保護されておらず、エンタープライズ Bean が Java EE ロール・ベースのセキュリティーで保護されていることを前提としています。

この場合、Web サービス・ポートは、 Java EE ロール・ベースのセキュリティーでは保護されていません。Web サービス・エンジンは、クライアントが Web サービス・ポートにメッセージを送信する前に、 SOAP メッセージを処理します。 Web Services Security ランタイムは、 セキュリティー制約に従って、SOAP ヘッダー内のセキュリティー・トークンのデジタル署名、 暗号化、または生成 (および挿入) などを行います。 この場合、user1 とパスワードを使用して <wsse:UsernameToken> が生成されます。 サーバー・サイド (受信側) では、Web サービスは着信メッセージを処理し 、Web Services Security はセキュリティー制約に従って処理を行います。 この実行内容には、メッセージに対する適切な署名、 適切な暗号化および暗号化解除、セキュリティー・トークンの認証、および 認証済みの ID によるセキュリティー・コンテキストのセットアップが含まれます。 (この場合、user1 は認証済みの ID です。) 最後に、SOAP メッセージが Web サービス実装にディスパッチされます (実装がエンタープライズ Bean ファイルである場合は、Enterprise JavaBeans (EJB) コンテナーが user1 に対して許可検査を実行します)。SSL をこのシナリオで使用することもできます。
2 つのシナリオの混合
2 番目のシナリオでは 、Web Services Security が Java ロール・ベースのセキュリティーを補完できることを示します。例えば、SSL をトランスポート・レベルで使用可能にして、セキュアなチャネルを提供することができます。 さらに、Web サービス実装がエンタープライズ Bean ファイルである場合は、 許可検査を実行することにより、EJB ロール・ベースの認証を利用することができます。 Web Services Security ランタイムは、 セキュリティー・インフラストラクチャーを活用して、 セキュリティー・コンテキストに認証済みの ID を設定できます。 認証済みの ID は、Java EE リソース (または他のリソース・タイプ) へのダウンストリーム呼び出しで使用できます。
2 つのシナリオを結合すると微妙な結果になります。 例えば、HTTP トランスポートが、HTTP ヘッダー内に user1 とパスワードを持つ基本認証データを送信している場合は、user99 および letmein とともに <wsse:UsernameToken> も SOAP ヘッダーに 挿入されます。 前のシナリオでは、2 つの認証が実行されています。 一方の認証は Web コンテナーが user1 の認証用に実行し、 もう一方の認証は Web Services Security が user99 の認証用に実行します。 Web Services Security ランタイムは、 Web コンテナーが実行されてから稼働し、 user99 はセキュリティー・コンテキストに設定される認証済みの ID です。
Web Services Security は、SOAP の送信側から受信側 に Java Message Service (JMS) 経由でセキュリティー・トークンも伝搬します。
Java EE ロール・ベースの許可検査
Web サービスには標準的な許可は存在していません。 ただし、IBM は Microsoft Corporation と共同で、Security in a Web Services World: A Proposed Architecture and Roadmap という Web サービスのセキュリティー白書ロードマッ プを公開しました。この中には WS-Authorization 仕様に対する提案がなされています。 しかし、WS-Authorization 仕様はまだ公表されていません。
既存の Web Services Security の実装は、Java EE 仕様または Java Specification Requirements (JSR) 109 仕様の Web サービスに基づいています。Web Services Security の実装は、Java EE ロール・ベースの許可検査を利用します。概念的な情報については、『ロール・ベースの許可』を参照してください。メソッド・レベルの許可検査が必要な Web サービスを開発する場合は、ステートレス・セッション Bean を使用して Web サービスをインプリメントする必要があります。 ステートレス・セッション Bean を使用した Web サービスの実装方法について詳しくは、ご使用のプログラミング・モデルに応じて、トピック『JAX-WS を使用した Web サービス・アプリケーションの実装』または『JAX-RPC を使用した Web サービス・アプリケーションの実装』を参照してください。また、『エンタープライズ Bean アプリケーションの保護』も参照してください。サーブレットとしてインプリメントされる Web サービスを開発する場合は、簡単な許可または URL ベースの許可を Web コンテナーで使用することができます。 ただし、そのような状況においては、許可検査のために Web Services Security の ID を使用することはできません。 代わりに、トランスポートの ID を使用することができます。 HTTP 経由で SOAP を使用する場合、ID は HTTP トランスポートにあります。