test

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 管理ガイド

メッセージセキュリティーについて

メッセージセキュリティーの概要

「メッセージセキュリティー」を使用する場合、メッセージ内にセキュリティー情報が挿入され、その情報がメッセージとともにネットワークレイヤー経由でメッセージの送信先に届けられます。メッセージセキュリティーは、『J2EE 1.4 Tutorial』の「Security」の章で説明されているトランスポートレイヤーセキュリティーとは異なり、メッセージトランスポートからメッセージ保護を分離して伝送後もメッセージを保護されたままにするために使用することができます。

「Web Services Security: SOAP Message Security (WS-Security)」は、米国 Sun Microsystems, Inc. を含むすべての主要な Web サービステクノロジプロバイダによって共同開発された、相互運用可能な Web サービスセキュリティーを実現するための OASIS 国際標準です。WS-Security のメッセージセキュリティーメカニズムは、SOAP 経由で送信される Web サービスメッセージを XML 暗号化と XML デジタル署名を使ってセキュリティー保護する、というものです。WS-Security 仕様には、X.509 証明書、SAML アサーション、ユーザー名/パスワードなどの各種セキュリティートークンを使って SOAP Web サービスメッセージの認証および暗号化を実現する方法が規定されています。

WS-Security 仕様については、http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf を参照してください。

Application Server のメッセージセキュリティーの理解

Application Server は、Web サービスのクライアント側コンテナとサーバー側コンテナにおいて、WS-Security 標準に対する統合化されたサポートを提供します。この機能は統合化されているため、Application Server のコンテナがアプリケーションに代わって Web サービスセキュリティーを適用します。また、そうしたセキュリティーで Web サービスアプリケーションを保護する際、アプリケーションの実装を変更する必要はありません。Application Server は、これを実現する目的で、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーを、コンテナおよびコンテナ内に配備されたアプリケーションにバインドする機能を提供しています。

メッセージセキュリティーの責任の割り当て

Application Server でメッセージセキュリティー設定の主要責任者として期待されるのは、「システム管理者」ロールと「アプリケーション配備担当者」ロールです。場合によっては、「アプリケーション開発者」もその責任の一端を担うことがありますが、通常は、システム管理者またはアプリケーション配備者のいずれかのロールが既存アプリケーションをセキュリティー保護し、開発者が関与することも、実装が変更されることもありません。次の各節では、各種ロールの責任を定義します。

システム管理者

システム管理者は次の責任を負います。

システム管理者は、管理コンソールを使用してサーバーセキュリティーの設定を管理し、コマンド行ツールを使用して証明書データベースを管理します。Platform Edition の証明書と非公開鍵は、キーストア内に格納され、keytool を使って管理されます。Standard Edition と Enterprise Edition の証明書と非公開鍵は、NSS データベース内に格納され、certutil を使って管理されます。このマニュアルは主にシステム管理者を対象にしています。メッセージセキュリティータスクの概要については、「メッセージセキュリティーのための Application Server の設定」を参照してください。

アプリケーション配備担当者

アプリケーション配備担当者は次の責任を負います。

これらのセキュリティータスクについては、『Developers’ Guide』の「Securing Applications」の章で説明されています。この章へのリンクについては、「詳細情報」を参照してください。

アプリケーション開発者

アプリケーション開発者はメッセージセキュリティーを有効にできますが、そのようにする責任はありません。メッセージセキュリティーの設定をシステム管理者が行う場合、すべての 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 クライアント証明書認証が同じ目的で使用される方法に類似しています。デジタル署名は、メッセージコンテンツのソースを認証するためにメッセージ受信者によって検証されます (このソースはメッセージ送信者と異なる可能性がある。)

デジタル署名を使用する場合、有効なキーストアおよびトラストストアファイルを Application Server 上に設定する必要があります。このトピックの詳細については、「証明書ファイルについて」を参照してください。

暗号化について

暗号化の目的は、対象読者だけが理解できるようにデータを変更することです。これは、元のコンテンツを暗号化された要素に置き換えることにより行われます。公開鍵暗号方式に関して言えば、暗号化はメッセージを読み取ることができる関係者の ID を確立するために使用されます。

暗号化を使用する場合は、暗号化をサポートする JCE プロバイダがインストールされている必要があります。このトピックの詳細については、「JCE プロバイダを設定する」を参照してください。

メッセージ保護ポリシーについて

メッセージ保護ポリシーは、要求メッセージ処理と応答メッセージ処理に対して定義され、ソース認証または受信者認証に関する要件として表現されます。ソース認証ポリシーは、メッセージを送信したエンティティーまたはメッセージのコンテンツを定義したエンティティーの ID がメッセージ内で確立され、その ID をメッセージ受信者が認証できる、という要件を表します。受信者認証ポリシーは、メッセージを受信可能なエンティティーの ID をメッセージ送信者が確立できるようにメッセージが送信される、という要件を表します。プロバイダは、特定のメッセージセキュリティーメカニズムを適用することで、SOAP Web サービスメッセージにおけるメッセージ保護ポリシーを実現します。

要求と応答に対するメッセージ保護ポリシーが定義されるのは、特定のプロバイダがコンテナ内に設定される時です。また、アプリケーションまたはアプリケーションクライアントの Sun 固有の配備記述子内で、アプリケーション固有のメッセージ保護ポリシー (Web サービスのポートまたは操作の粒度でのポリシー) を設定することも可能です。いずれにせよ、メッセージ保護ポリシーを定義する場合、クライアントの要求と応答に対するメッセージ保護ポリシーは、サーバーのそれと一致する (等しい) 必要があります。アプリケーション固有のメッセージ保護ポリシーの定義方法の詳細については、『Developers’ Guide』の「Securing Applications」の章を参照してください。

メッセージセキュリティー用語の解説

次に、このマニュアルで使用する用語について説明します。これらの概念については、「メッセージセキュリティーのための Application Server の設定」でも説明しています。

Web サービスのセキュリティー保護

Application Server 上に配備された Web サービスをセキュリティー保護するには、アプリケーションの配備先コンテナ、またはそのアプリケーションがサービスを提供する Web サービスエンドポイントのいずれかに対し、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーをバインドします。Application Server のクライアント側コンテナで SOAP レイヤーメッセージセキュリティー機能を設定するには、クライアントコンテナ、またはクライアントアプリケーションによって宣言されたポータブルサービス参照のいずれかに対し、SOAP レイヤーメッセージセキュリティープロバイダとメッセージ保護ポリシーをバインドします。

Application Server のインストール時に、SOAP レイヤーメッセージセキュリティープロバイダが Application Server のクライアント側コンテナとサーバー側コンテナ内に設定され、コンテナまたはコンテナ内に配備された個々のアプリケーションまたはクライアントからバインドして利用できるようになります。インストール中、プロバイダにはある単純なメッセージ保護ポリシーが設定されます。このポリシーをコンテナまたはコンテナ内のアプリケーションまたはクライアントにバインドした場合、すべての要求メッセージと応答メッセージに含まれるコンテンツのソースが、XML デジタル署名によって認証されるようになります。

Application Server の管理インタフェースを使えば、既存のプロバイダをバインドして Application Server のサーバー側コンテナから利用できるようにしたり、プロバイダが適用するメッセージ保護ポリシーを変更したり、別のメッセージ保護ポリシーを備えた新しいプロバイダ設定を作成したりできます。これらの操作については、「セキュリティーに関する管理コンソールタスク」で定義しています。アプリケーションクライアントコンテナの SOAP メッセージレイヤーセキュリティー設定でも、これと同様の管理操作を実行できます。それらについては、「アプリケーションクライアントのメッセージセキュリティーを有効にする」で定義しています。

Application Server では、メッセージレイヤーセキュリティーはデフォルトで無効になっています。Application Server のメッセージレイヤーセキュリティーを設定するには、「メッセージセキュリティーのための Application Server の設定」に要約されている手順に従ってください。Application Server 上に配備されたすべての Web サービスアプリケーションを Web サービスセキュリティーで保護するには、「メッセージセキュリティーのプロバイダを有効にする」の手順に従ってください。

上記の手順 (Application Server の再起動が必要な場合もあり) を実行し終わると、Application Server 上に配備されたすべての Web サービスアプリケーションに Web サービスセキュリティーが適用されるようになります。

アプリケーション固有の Web サービスセキュリティーの設定

アプリケーション固有の Web サービスセキュリティー機能をアプリケーションアセンブリで設定するには、アプリケーションの Sun 固有の配備記述子内で message-security-binding 要素を定義します。これらの message-security-binding 要素は、特定のプロバイダまたはメッセージ保護ポリシーを Web サービスエンドポイントまたはサービス参照に関連付けるために使用されます。また、この要素を修飾することで、それらのプロバイダやポリシーが対応するエンドポイントまたは参照サービスの特定のポートやメソッドに適用されるようにすることも可能です。

アプリケーション固有のメッセージ保護ポリシーの定義方法の詳細については、『Developers’ Guide』の「Securing Applications」の章を参照してください。「詳細情報」に、この章へのリンクがあります。

サンプルアプリケーションのセキュリティー保護

Application Server には、xms という名前のサンプルアプリケーションが付属しています。xms アプリケーションは、J2EE EJB エンドポイントと Java サーブレットエンドポイントの両方を使って実装された、単純な Web サービスです。両エンドポイントは同一のサービスエンドポイントインタフェースを共有しています。このサービスエンドポイントインタフェースには、単一の操作 sayHello が定義されています。この操作は、文字列引数を 1 つ受け取り、その呼び出し引数の前に Hello が付加された String を返します。

xms サンプルアプリケーションは、Application Server の WS-Security 機能を使って既存の Web サービスアプリケーションをセキュリティー保護する方法を示す目的で提供されています。サンプルに付属する手順では、Application Server の WS-Security 機能を有効にして xms アプリケーションを保護する方法が説明されています。また、このサンプルは、WS-Security 機能をアプリケーションに直接バインドする方法 (「アプリケーション固有の Web サービスセキュリティーの設定」を参照) も示しています。

xms サンプルアプリケーションは次のディレクトリにインストールされます。install-dir/samples/webservices/security/ejb/apps/xms/。

xms サンプルアプリケーションのコンパイル、パッケージ化、および実行に関する詳細については、『Developers’ Guide』の「Securing Applications」の章を参照してください。

メッセージセキュリティーのための Application Server の設定

要求および応答ポリシー設定のアクション

次の表は、メッセージ保護ポリシーの設定と、その結果として WS-Security SOAP メッセージセキュリティープロバイダによって実行されるメッセージセキュリティー処理を示したものです。

表 10–1 メッセージ保護ポリシーと WS-Security SOAP メッセージセキュリティー処理との対応づけ

メッセージ保護ポリシー 

結果として実行される WS-Security SOAP メッセージ保護処理 

auth-source="sender" 

メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に wsse:UsernameToken (パスワード付き) が格納されます。

auth-source="content" 

SOAP メッセージ本体のコンテンツが署名されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内にメッセージ本体の署名が ds:Signature として格納されます。

auth-source="sender" 

auth-recipient="before-content" 

または 

auth-recipient="after-content" 

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に wsse:UsernameToken (パスワード付き) と xenc:EncryptedKey が格納されます。xenc:EncryptedKey には、SOAP メッセージ本体の暗号化に使用した鍵が格納されます。この鍵は受信者の公開鍵で暗号化されます。

auth-source="content" 

auth-recipient="before-content" 

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。xenc:EncryptedData が署名されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に xenc:EncryptedKey と ds:Signature として格納されます。xenc:EncryptedKey には、SOAP メッセージ本体の暗号化に使用した鍵が格納されます。この鍵は受信者の公開鍵で暗号化されます。

auth-source="content" 

auth-recipient="after-content" 

SOAP メッセージ本体のコンテンツが、署名されたあと暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に xenc:EncryptedKey と ds:Signature が格納されます。xenc:EncryptedKey には、SOAP メッセージ本体の暗号化に使用した鍵が格納されます。この鍵は受信者の公開鍵で暗号化されます。

auth-recipient="before-content" 

または 

auth-recipient="after-content" 

SOAP メッセージ本体のコンテンツが暗号化され、その結果得られた xend:EncryptedData で置換されます。メッセージに wsse:Security ヘッダーが格納され、そのヘッダー内に xenc:EncryptedKey が格納されます。xenc:EncryptedKey には、SOAP メッセージ本体の暗号化に使用した鍵が格納されます。この鍵は受信者の公開鍵で暗号化されます。

ポリシーを何も指定しない。 

モジュールはセキュリティー処理を一切行いません。 

Procedureその他のセキュリティー機能を設定する

Application Server は、SOAP 処理レイヤー内に統合化されたメッセージセキュリティープロバイダを使用して、メッセージセキュリティーを実装します。メッセージセキュリティープロバイダは、Application Server のその他のセキュリティー機能に依存します。

手順

  1. バージョン 1.5.0 より前のバージョンの Java SDK を使用し、暗号化技術を使用する場合は、JCE プロバイダを設定します。

    JCE プロバイダの設定については、「JCE プロバイダを設定する」を参照してください。

  2. ユーザー名トークンを使用する場合は、必要に応じてユーザーデータベースを設定します。ユーザー名およびパスワードトークンを使用する場合は、適切なレルムを設定し、このレルムに適切なユーザーデータベースを設定する必要があります。

    ユーザーデータベースの設定については、「レルムを編集する」を参照してください。

  3. 必要に応じて証明書と非公開鍵を管理します。

    証明書と非公開鍵の管理については、「証明書ファイルについて」を参照してください。

次の手順

Application Server の機能の設定が完了し、メッセージセキュリティープロバイダがそれらの機能を使用できるようになると、Application Server とともにインストールされたプロバイダを有効にできます。その手順については、「メッセージセキュリティーのプロバイダを有効にする」を参照してください。

ProcedureJCE プロバイダを設定する

J2SE 1.4.x に付属している JCE (Java Cryptography Extension) プロバイダは、RSA 暗号化をサポートしていません。通常、WS-Security で定義されている XML 暗号化は RSA 暗号化に基づいているため、WS-Security を使って SOAP メッセージを暗号化するには、RSA 暗号化をサポートする JCE プロバイダをダウンロードおよびインストールする必要があります。

注 –

RSA は RSA Data Security, Inc. が開発した公開鍵暗号化技術です。この略語は、この技術の開発者である Rivest、Shamir、および Adelman を表しています。

Java SDK バージョン 1.5 で Application Server を実行している場合は、JCE プロバイダは正しく設定されています。Java SDK バージョン 1.4.x で Application Server を実行している場合は、次のようにJCE プロバイダを JDK 環境の一部として静的に追加できます。

手順

  1. JCE プロバイダの JAR (Java ARchive) ファイルをダウンロードし、インストールします。

    次の URL で、RSA 暗号化をサポートする JCE プロバイダのリストが提供されています。http://java.sun.com/products/jce/jce14_providers.html。

  2. JCE プロバイダの JAR ファイルを java-home/jre/lib/ext/ にコピーします。

  3. Application Server を停止します。

    Application Server を停止せずにこの手順の最後で再起動した場合、JCE プロバイダは Application Server に認識されません。

  4. 任意のテキストエディタで java-home/jre/lib/security/java.security プロパティーファイルを編集します。このファイルに、前述の手順でダウンロードした JCE プロバイダを追加します。

    java.security ファイルに、このプロバイダを追加する詳細手順が含まれています。基本的には、類似したプロパティーを持つ場所に次の形式の行を追加する必要があります。


    security.provider.n=provider-class-name

    この例では、n は、Application Server がセキュリティープロバイダを評価する際に使用する優先順位を示します。ここで追加した JCE プロバイダには、n を 2 に設定します。

    たとえば、Legion of the Bouncy Castle JCE プロバイダをダウンロードした場合は、次のような行を追加します。


    security.provider.2=org.bouncycastle.jce.provider.
   BouncyCastleProvider

    Sun セキュリティープロバイダが、値 1 の最高の優先順位に設定されていることを確認してください。


    security.provider.1=sun.security.provider.Sun

    各レベルにセキュリティープロバイダがただ 1 つだけ設定されるように、ほかのセキュリティープロバイダのレベルを下位に調整します。

    次に示す例は、必要な JCE プロバイダを提供し、既存のプロバイダを正しい位置に保持する java.security ファイルのサンプルです。


    security.provider.1=sun.security.provider.Sun
security.provider.2=org.bouncycastle.jce.provider.
   BouncyCastleProvider
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.rsajca.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider

  5. ファイルを保存して、閉じます。

  6. Application Server を再起動します。