Application Server は、Web サービスのクライアント側コンテナとサーバー側コンテナにおいて、WS-Security 標準に対する統合化されたサポートを提供します。この機能は統合化されているため、Application Server のコンテナがアプリケーションに代わって Web サービスセキュリティーを適用します。また、そうしたセキュリティーで Web サービスアプリケーションを保護する際、アプリケーションの実装を変更する必要はありません。Application Server は、これを実現する目的で、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーを、コンテナおよびコンテナ内に配備されたアプリケーションにバインドする機能を提供しています。
Application Server でメッセージセキュリティー設定の主要責任者として期待されるのは、「システム管理者」ロールと「アプリケーション配備担当者」ロールです。場合によっては、「アプリケーション開発者」もその責任の一端を担うことがありますが、通常は、システム管理者またはアプリケーション配備者のいずれかのロールが既存アプリケーションをセキュリティー保護し、開発者が関与することも、実装が変更されることもありません。次の各節では、各種ロールの責任を定義します。
システム管理者は次の責任を負います。
Application Server 上のメッセージセキュリティープロバイダの設定。
ユーザーデータベースの管理。
キーストアおよびトラストストアファイルの管理。
暗号化を使用し、バージョン 1.5.0 より前のバージョンの Java SDK を実行している場合の JCE (Java Cryptography Extension) プロバイダの設定。
サンプルサーバーのインストール。ただし、これを行うのは、xms サンプルアプリケーションを使ってメッセージレイヤー Web サービスセキュリティーの使用方法を示す場合だけです。
システム管理者は、管理コンソールを使用してサーバーセキュリティーの設定を管理し、コマンド行ツールを使用して証明書データベースを管理します。開発者プロファイルとクラスタプロファイルでは、証明書と非公開鍵はキーストア内に格納され、keytool を使って管理されます。一方、エンタープライズプロファイルでは、証明書と非公開鍵は NSS データベース内に格納され、certutil を使って管理されます。このマニュアルは主にシステム管理者を対象にしています。メッセージセキュリティータスクの概要については、「メッセージセキュリティーのための Application Server の設定」を参照してください。
アプリケーション配備担当者は次の責任を負います。
必要なすべてのアプリケーション固有メッセージ保護ポリシーをアプリケーションアセンブリ時に指定 (それらのポリシーが上流行程の役割 (開発者またはプログラマ) によって指定されていなかった場合)。
Sun 固有の配備記述子を変更し、アプリケーション固有メッセージ保護ポリシー情報 (message-security-binding 要素) を Web サービスエンドポイントとサービス参照に指定。
アプリケーション開発者はメッセージセキュリティーを有効にできますが、そのようにする責任はありません。メッセージセキュリティーの設定をシステム管理者が行う場合、すべての Web サービスがセキュリティー保護されます。コンテナにバインドされているプロバイダまたは保護ポリシーと異なるものをアプリケーションにバインドする必要がある場合、アプリケーション配備担当者がメッセージセキュリティーの設定を行います。
アプリケーション開発者またはプログラマは次の責任を負います。
アプリケーション固有メッセージ保護ポリシーがアプリケーションで必要かどうかの判断。必要な場合、その必要なポリシーがアプリケーションアセンブリで指定されているかどうかの確認。それにはアプリケーション配備担当者に連絡します。
WS-Security 仕様は、セキュリティートークンを使って SOAP Web サービスメッセージを認証および暗号化するための拡張可能なメカニズムを提供します。Application Server とともにインストールされる SOAP レイヤーメッセージセキュリティープロバイダを使えば、ユーザー名 / パスワードセキュリティートークンと X.509 証明書セキュリティートークンによる SOAP Web サービスメッセージの認証と暗号化を行えます。Application Server の今後のリリースでは、SAML アサーションなどのほかのセキュリティートークンを採用したプロバイダも追加される予定です。
Application Server は、SOAP メッセージ内で「ユーザー名トークン」を使ってメッセージ「送信者」の認証 ID を確立します。パスワードが埋め込まれたユーザー名トークンを含むメッセージの受信者は、そのメッセージの送信者がそのトークンによって識別されるユーザーとして振る舞うことを許可されているかどうかを検証するために、その送信者がユーザーの秘密情報 (パスワード) を知っているかどうかを確認します。
ユーザー名トークンを使用する場合、有効なユーザーデータベースを Application Server 上に設定する必要があります。
Application Server は、XML デジタル署名を使ってメッセージの「コンテンツ」に認証 ID をバインドします。クライアントはデジタル署名を使用して、呼び出し元 ID を確立します。トランスポートレイヤーセキュリティーを使用する場合も、基本認証または SSL クライアント証明書認証を使う場合も、呼び出し元 ID を確立する方法はほぼ同様です。デジタル署名は、メッセージコンテンツのソースを認証するためにメッセージ受信者によって検証されます (このソースはメッセージ送信者と異なる可能性がある)。
デジタル署名を使用する場合、有効なキーストアおよびトラストストアファイルを Application Server 上に設定する必要があります。このトピックの詳細については、「証明書ファイルについて」を参照してください。
暗号化の目的は、対象読者だけが理解できるようにデータを変更することです。これは、元のコンテンツを暗号化された要素に置き換えることにより行われます。公開鍵暗号方式に関して言えば、暗号化はメッセージを読み取ることができる関係者の ID を確立するために使用されます。
暗号化を使用する場合は、暗号化をサポートする JCE プロバイダがインストールされている必要があります。このトピックの詳細については、「JCE プロバイダの設定」を参照してください。
メッセージ保護ポリシーは、要求メッセージ処理と応答メッセージ処理に対して定義され、ソース認証または受信者認証に関する要件として表現されます。ソース認証ポリシーは、メッセージを送信したエンティティーまたはメッセージのコンテンツを定義したエンティティーの ID がメッセージ内で確立され、その ID をメッセージ受信者が認証できる、という要件を表します。受信者認証ポリシーは、メッセージを受信可能なエンティティーの ID をメッセージ送信者が確立できるようにメッセージが送信される、という要件を表します。プロバイダは、特定のメッセージセキュリティーメカニズムを適用することで、SOAP Web サービスメッセージにおけるメッセージ保護ポリシーを実現します。
要求と応答に対するメッセージ保護ポリシーが定義されるのは、特定のプロバイダがコンテナ内に設定される時です。また、アプリケーションまたはアプリケーションクライアントの Sun 固有の配備記述子内で、アプリケーション固有のメッセージ保護ポリシー (Web サービスのポートまたは操作の粒度でのポリシー) を設定することも可能です。いずれにせよ、メッセージ保護ポリシーを定義する場合、クライアントの要求と応答に対するメッセージ保護ポリシーは、サーバーのそれと一致する (等しい) 必要があります。アプリケーション固有のメッセージ保護ポリシーの定義方法の詳細については、『Developer’s Guide』の「Securing Applications」の章を参照してください。
次に、このマニュアルで使用する用語について説明します。これらの概念については、「メッセージセキュリティーのための Application Server の設定」でも説明しています。
認証レイヤー
「認証レイヤー」とは、認証処理を実行する必要のあるメッセージレイヤーです。Application Server は、SOAP レイヤーにおいて Web サービスメッセージセキュリティーを適用します。
認証プロバイダ
Application Server のこのリリースでは、Application Server は、「認証プロバイダ」を呼び出して SOAP メッセージレイヤーセキュリティーを処理します。
「クライアント側プロバイダ」は、署名またはユーザー名/パスワードを使って要求メッセージのソース ID を確立したり、対象の受信者だけがメッセージを参照できるように暗号化を使って要求メッセージを保護したりします。また、クライアント側プロバイダは、受信した応答を正常に復号化することで、その許可された受信者としてコンテナを確立したり、応答内のパスワードまたは署名を検証してその応答に関連付けられたソース ID を認証したりもします。Application Server 内に設定されているクライアント側プロバイダを使えば、ほかのサービスのクライアントとして機能するサーバー側コンポーネント (サーブレットと EJB コンポーネント) によって送信される要求メッセージと受信される応答メッセージを保護することができます。
「サーバー側プロバイダ」は、受信した要求を正常に復号化することで、その許可された受信者としてコンテナを確立したり、要求内のパスワードまたは署名を検証してその要求に関連付けられたソース ID を認証したりします。また、サーバー側プロバイダは、署名またはユーザー名/パスワードを使って応答メッセージのソース ID を確立したり、対象の受信者だけがメッセージを参照できるように暗号化を使って要求メッセージを保護したりもします。「サーバー側プロバイダ」を呼び出すのはサーバー側コンテナだけです。
デフォルトサーバープロバイダ
「デフォルトサーバープロバイダ」は、特定のサーバープロバイダがバインドされていない任意のアプリケーションに対して呼び出されるサーバープロバイダを識別するために使用されます。「デフォルトサーバープロバイダ」は「デフォルトプロバイダ」とも呼ばれます。
デフォルトクライアントプロバイダ
「デフォルトクライアントプロバイダ」は、特定のクライアントプロバイダがバインドされていない任意のアプリケーションに対して呼び出されるクライアントプロバイダを識別するために使用されます。
要求ポリシー
「要求ポリシー」は、認証プロバイダが実行する要求処理に関連付けられた認証ポリシー要件を定義します。ポリシーはメッセージ送信者による順序で示されるので、「コンテンツのあと」ではメッセージ受信者が署名の検証前にメッセージを復号化することを意味します。
応答ポリシー
「応答ポリシー」は、認証プロバイダが実行する応答処理に関連付けられた認証ポリシー要件を定義します。ポリシーはメッセージ送信者による順序で示されるので、「コンテンツのあと」ではメッセージ受信者が署名の検証前にメッセージを復号化することを意味します。