セキュリティー機構を設定する (プロジェクトでの HTTP バインディングコンポーネントの使用)

プロジェクトでの HTTP バインディングコンポーネントの使用

セキュリティー機構を設定する

この節では、Tango を介して使用できる次のセキュリティー機構と、各選択項目のサーバー設定オプションについて説明します。これらのセキュリティー機構の詳細については、Security Mechanisms を参照してください。

使用できるセキュリティー機構は次のとおりです。

対称キーによるユーザー名認証

対称キーによるユーザー名認証機構では、アプリケーションの完全性と機密性が保護されます。対称キー暗号化方式は、メッセージの署名と暗号化の両方に使用される単一の共有秘密鍵を基にしています。通常は、公開キー暗号化方式より高速です。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。
デフォルトユーザー: デフォルトのユーザー名とパスワードか UsernameCallbackHandler を設定します。あるいは、これらのオプションを空白にしておいて実行時にユーザーを指定します。
GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

表 12 対称キーによるユーザー名認証の設定プロパティー


プロパティー	説明	値
認証トークン	指定されたメッセージパートの署名や暗号化に使用するサポートトークンを指定します。オプションには、「ユーザー名」、「X509」、「SAML」、「発行済み」、または「なし」があります。	ユーザー名
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。アルゴリズム群により、実際のアルゴリズムおよび許容されるキーの長さが指定されます。代替の機構により、どのアルゴリズムをどのように使用するかが定義されます。通常、この属性の値はセキュリティーバインディングによって参照され、そのセキュリティーバインディングの下で実行されるすべての暗号化操作に使用するアルゴリズムを指定します。デフォルト値は Basic 128 ビットです。一部のアルゴリズム群の設定、特に 256 ビットの暗号化を使用するアルゴリズム群では、Java Runtime Environment (JRE) で無制限強度の暗号化を設定する必要があります。無制限強度の暗号化をダウンロードして設定する方法については、`http://java.sun.com/products/jce/javase.html` または `http://java.sun.com/javase/downloads/index_jdk5.jsp#docs` を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは次のとおりです。 Strict: 「使用前に宣言する」という一般的な原則に従って、セキュリティーヘッダーに項目が追加されます。 Lax: WSS: SOAP Message Security に準拠した任意の順序で、セキュリティーヘッダーに項目が追加されます。ただし、Lax が選択されている場合でも、WSIT は Strict に従います。 Lax (Timestamp First): セキュリティーヘッダー内の最初の項目が wsse:Timestamp でなければならないという点を除き、Lax と同じです。 Lax (Timestamp Last): セキュリティーヘッダー内の最後の項目が wsse:Timestamp でなければならないという点を除き、Lax と同じです。	Strict
派生キーを必要とする	派生キーが必要であることを指定します。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。たとえばセキュリティー保護された通信の使用時など、繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。このオプションと「派生キーを必要とする」の両方が有効になっている場合は、派生キーが使用されます。それ以外の場合は、元のセッションキーが使用されます。セキュリティー保護されたセッションと高信頼性メッセージ配信に関する注: 高信頼性メッセージングはセキュリティー機構とは無関係に使用できます。ただし、セキュリティー機構とともに使用する場合、高信頼性メッセージングにはセキュリティー保護されたセッションを使用する必要があります。セキュリティー機構を選択する前に「高信頼性メッセージング」を選択した場合、セキュリティー保護されたセッションがセキュリティー機構に対して自動的に設定されます。セキュリティー保護されたセッションがセキュリティー機構に対して選択されている場合で、セキュリティー機構を指定する前に高信頼性メッセージングオプションを選択しなかったときは、セキュリティー保護されたセッションが機能するためには高信頼性メッセージングを手動で選択する必要があります。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。詳細については、前述の「派生キーを必要とする」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名の確認を必要とする	レスポンダが要求内の署名を処理することを指定します。WSS のバージョンが 1.1 の場合は、攻撃のリスクを低減するためにこのオプションを選択してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名を暗号化	主署名と署名確認要素を暗号化する必要があるかどうかを指定します。	チェックボックスが選択されている場合、有効になっていることを示します。
署名前に暗号化	メッセージ保護の順序として、SOAP コンテンツを暗号化してから SOAP 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。

相互証明書セキュリティー

相互証明書セキュリティー機構では、認証とメッセージ保護によるセキュリティーを使用して、完全性と機密性が保護されます。この機構では、アプリケーションのクライアント側とサーバー側の両方に、キーストアおよびトラストストアのファイルが必要です。

相互証明書セキュリティーの WS Security を設定する例については、Using the WSIT Mutual Certificates Security Mechanism with the HTTP BC を参照してください。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア (別名なし): トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

表 13 相互証明書セキュリティーの設定プロパティー


プロパティー	説明	値
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
派生キーを必要とする	派生キーが必要であることを指定します。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。たとえばセキュリティー保護されたセッションの使用時など、繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。詳細については、表 12 の「セキュリティー保護されたセッションを確立する」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。詳細については、前述の「派生キーを必要とする」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名を暗号化	主署名と署名確認要素を暗号化する必要があるかどうかを指定します。	チェックボックスが選択されている場合、有効になっていることを示します。
署名前に暗号化	メッセージ保護の順序として、SOAP コンテンツを暗号化してから SOAP 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。

トランスポートセキュリティー (SSL)

トランスポートセキュリティー機構では、メッセージ移送時の認証と機密性のために SSL が使用されます。トランスポートレイヤーのセキュリティーは、Secure Sockets Layer (SSL) でセキュリティー保護された HTTP トランスポート (HTTPS) を基にしています。このポイントツーポイントのセキュリティー機構は、認証、メッセージの完全性、および機密性のために使用できます。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。
GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。
GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

表 14 トランスポートセキュリティー (SSL) の設定プロパティー


プロパティー	説明	値
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
クライアント証明書を必要とする	検証のためにクライアント証明書をサーバーに提供する必要があることを指定します。 SSL によるセキュリティー機構を使用する場合、サーバーは初期ハンドシェーク中および検証中に再度、クライアント証明書を要求します。	チェックボックスが選択されている場合、無効になっていることを示します。

SSL を使用したメッセージ認証

SSL を使用したメッセージ認証機構は、暗号化によってセキュリティー保護された識別情報または認証トークンをメッセージに添付し、機密性保護のために SSL を使用します。認証は、ユーザー名サポートトークンまたは X.509 サポートトークンによって指定されます。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。
GlassFish のユーザー: 認証にユーザーデータベースを必要とする機構を使用するために、GlassFish の file レルムにユーザーを追加します。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

表 15 SSL を使用したメッセージ認証の設定プロパティー


プロパティー	説明	値
認証トークン	指定されたメッセージパートの署名や暗号化に使用するサポートトークンを指定します。オプションには、「ユーザー名」、「X509」、「SAML」、「発行済み」、または「なし」があります。	ユーザー名
WSS バージョン	Web Services Security 仕様のどのバージョンに従うかを指定します。オプションは 1.0 と 1.1 です。 WSS 1.1 を有効にすると、クライアントによって生成された暗号化済みのキーをサーバーで再利用できます。これにより、応答の過程で対称キーを作成し、クライアントの公開キーを使用して暗号化し (負荷が大きい RSA 操作でもある)、暗号化したキーをメッセージで送信する (マークアップの領域を使用し、Base64 操作も必要) ことが不要になり、時間を節約できます。WSS 1.1 を有効にすると、暗号化されたヘッダーも有効になります。	1.1
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。詳細については、表 12 の「セキュリティー保護されたセッションを確立する」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「セキュリティーセッションに派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名の確認を必要とする	レスポンダが要求内の署名を処理することを指定します。WSS のバージョンが 1.1 の場合は、攻撃のリスクを低減するためにこのオプションを選択してください。	チェックボックスが選択されている場合、有効になっていることを示します。

SSL を使用した SAML 承認

SSL を使用した SAML 承認機構は、承認トークンをメッセージに添付します。機密性保護のために SSL が使用されます。この機構では、エンドユーザーに関する承認情報が SAML トークンで伝送されます。トークンの送信側は、実際に SAML トークンで資格情報を保証しています。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア (別名なし): クライアントの証明書および信頼できるルートが格納されているトラストストアの別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。
SAML コールバックハンドラ: SAML コールバックハンドラを指定します。デフォルトの SAML コールバックハンドラはないので、SAML コールバックハンドラを使用するにはそれを作成する必要があります。
SSL: クライアントおよびサーバーのキーストアファイルとトラストストアファイルを指すようにシステムを設定します。

表 16 SSL を使用した SAML 承認の設定プロパティー


プロパティー	説明	値
SAML バージョン	どのバージョンの SAML トークンを使用するかを指定します。SAML バージョンは、セキュリティーランタイムではなくコールバックハンドラで確認すべきものです。 SAML トークンは、`http://www.oasis-open.org/specs/index.php` から入手可能な「WSS: SAML Token Profile」ドキュメントで定義されています。	1.1 (Profile 1.0)
WSS バージョン	Web Services Security 仕様のどのバージョンに従うかを指定します。オプションは 1.0 と 1.1 です。 WSS 1.1 を有効にすると、クライアントによって生成された暗号化済みのキーをサーバーで再利用できます。これにより、応答の過程で対称キーを作成し、クライアントの公開キーを使用して暗号化し (負荷が大きい RSA 操作でもある)、暗号化したキーをメッセージで送信する (マークアップの領域を使用し、Base64 操作も必要) ことが不要になり、時間を節約できます。WSS 1.1 を有効にすると、暗号化されたヘッダーも有効になります。	1.1
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
クライアント証明書を必要とする	検証のためにクライアント証明書をサーバーに提供する必要があることを指定します。 SSL によるセキュリティー機構を使用する場合、サーバーは初期ハンドシェーク中および検証中に再度、クライアント証明書を要求します。	チェックボックスが選択されている場合、無効になっていることを示します。
署名の確認を必要とする	レスポンダが要求内の署名を処理することを指定します。WSS のバージョンが 1.1 の場合は、攻撃のリスクを低減するためにこのオプションを選択してください。	チェックボックスが選択されている場合、有効になっていることを示します。

承認証明書

承認証明書機構は、完全性と機密性のために対象キーを使用するセキュリティー保護されたメッセージを使用します。また、クライアント承認証明書を使用して、メッセージ署名に関連付けられたトークンで申請する内容を補強します。クライアントはサービスの証明書を認識し、要求は特殊な識別情報によって承認されている必要があります。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。

表 17 承認証明書の設定プロパティー


プロパティー	説明	値
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。詳細については、表 12 の「セキュリティー保護されたセッションを確立する」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。詳細については、前述の「派生キーを必要とする」を参照してください。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「セキュリティーセッションに派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名の確認を必要とする	レスポンダが要求内の署名を処理することを指定します。WSS のバージョンが 1.1 の場合は、攻撃のリスクを低減するためにこのオプションを選択してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名を暗号化	主署名と署名確認要素を暗号化する必要があるかどうかを指定します。	チェックボックスが選択されている場合、有効になっていることを示します。
署名前に暗号化	メッセージ保護の順序として、SOAP コンテンツを暗号化してから SOAP 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。

SAML Sender-Vouches と証明書

この機構は、相互証明書を使用してメッセージの完全性と機密性を提供し、Sender-Vouches SAML トークンを使用して承認を提供します。Sender-Vouches 方式では、SOAP メッセージとその SOAP メッセージに追加される SAML 表明の間の対応が確立されます。(SAML 表明内の) SAML 主体ステートメントの主体と SOAP メッセージコンテンツの間の対応を確立するのに使用される確認証拠は、証明エンティティーによって提供されます。

メッセージペイロードには署名と暗号化を行う必要があります。要求者は、要求者が代行している実体の資格情報 (SAML 表明内にある) を保証します。イニシエータトークンは X.509 トークンであり、署名に使用されます。受信者トークンも X.509 トークンであり、暗号化に使用されます。サーバーの場合はこれが逆になり、受信者トークンは署名トークン、イニシエータトークンは暗号化トークンです。SAML トークンが承認に使用されます。

SAML Sender-Vouches と証明書を使用して WS Security を設定する例については、Using the SAML Sender Vouches with Certificates Security Mechanism with the HTTP BC を参照してください。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア (別名なし): クライアントの証明書および信頼できるルートが格納されているトラストストアの別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。
SAML コールバックハンドラ: SAML コールバックハンドラを指定します。デフォルトの SAML コールバックハンドラはないので、SAML コールバックハンドラを使用するにはそれを作成する必要があります。

表 18 SAML Sender-Vouches と証明書の設定プロパティー


プロパティー	説明	値
SAML バージョン	どのバージョンの SAML トークンを使用するかを指定します。SAML バージョンは、セキュリティーランタイムではなくコールバックハンドラで確認すべきものです。 SAML トークンは、`http://www.oasis-open.org/specs/index.php` から入手可能な「WSS: SAML Token Profile」ドキュメントで定義されています。	1.1 (Profile 1.0)
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
派生キーを必要とする	派生キーが必要であることを指定します。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。詳細については、表 12 の「セキュリティー保護されたセッションを確立する」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。詳細については、前述の「派生キーを必要とする」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名を暗号化	主署名と署名確認要素を暗号化する必要があるかどうかを指定します。	チェックボックスが選択されている場合、有効になっていることを示します。
署名前に暗号化	メッセージ保護の順序として、SOAP コンテンツを暗号化してから SOAP 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。

SAML Holder-of-Key

この機構は、クライアントの公開キーおよび承認情報を伝送する (信頼できる機関から発行された) 署名付き SAML 表明を含んだメッセージの完全性と機密性を、相互証明書を使用して保護します。Holder-of-Key (HOK) 方式では、SOAP メッセージとその SOAP メッセージに追加される SAML 表明の間の対応が確立されます。詳細については、http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf で「SAML Token Profile」ドキュメントを参照してください。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア (別名なし): クライアントの証明書および信頼できるルートが格納されているトラストストアの別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。
SAML コールバックハンドラ: SAML コールバックハンドラを指定します。デフォルトの SAML コールバックハンドラはないので、SAML コールバックハンドラを使用するにはそれを作成する必要があります。

表 19 SAML Holder-of-Key の設定プロパティー


プロパティー	説明	値
SAML バージョン	どのバージョンの SAML トークンを使用するかを指定します。SAML バージョンは、セキュリティーランタイムではなくコールバックハンドラで確認すべきものです。 SAML トークンは、`http://www.oasis-open.org/specs/index.php` から入手可能な「WSS: SAML Token Profile」ドキュメントで定義されています。	1.1 (Profile 1.0)
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
派生キーを必要とする	派生キーが必要であることを指定します。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。詳細については、表 12 の「セキュリティー保護されたセッションを確立する」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。詳細については、前述の「派生キーを必要とする」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名を暗号化	主署名と署名確認要素を暗号化する必要があるかどうかを指定します。	チェックボックスが選択されている場合、有効になっていることを示します。
署名前に暗号化	メッセージ保護の順序として、SOAP コンテンツを暗号化してから SOAP 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。

STS 発行トークン

信頼できるセキュアトークンサービス (STS) によって発行されたトークンを使用してメッセージの完全性と機密性を保護します。

この機構を Web サービスに使用するには、使用するセキュリティー機構でこのオプションを選択します。サービスから参照できるセキュリティートークンサービスが必要です。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。クライアントのトラストストアに STS の証明書が格納されている必要があります。更新済みの GlassFish 証明書を使用していれば、この証明書の別名は wssip です。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。
STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。

表 20 STS 発行トークンの設定プロパティー


プロパティー	説明	値
発行者アドレス	メッセージで提供されるセキュリティートークンを受け入れる発行者 (STS) のアドレスを指定します。要素のタイプはエンドポイント参照です。STS には、セキュリティートークンの発行、交換、および検証に使用される一連のインタフェースが含まれています。たとえば、JAX-WS サービスの場合、発行者アドレスは `http://localhost:8080/jaxws-sts/sts` です。	http://localhost:8080/jaxws-sts/sts
発行者メタデータアドレス	発行者のメタデータを取得するアドレスを指定します。これは単に URL です。たとえば、JAX-WS サービスの場合、発行者メタデータアドレスは `http://localhost:8080/jaxws-sts/sts` です。	http://localhost:8080/jaxws-sts/sts
トークンタイプ	サービスプロバイダが必要とする SAML トークンのタイプを指定します。たとえば、`urn:oasis:names:tc:SAML1.0:assertion` です。オプションは 1.0、1.1、または 2.0 です。	1.1
キータイプ	サービスプロバイダが必要とするキーのタイプを指定します。選択肢は公開キーまたは対称キーです。対称キー暗号化方式は共有シークレットを基にしており、通常は公開キー暗号化方式より高速です。公開キー暗号化方式は、全員に公開されるキーを基にしており、主に暗号化に使用されますが、署名の検証にも使用可能です。発行済みトークン機構だけに適用されます。	対称キー
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
発行済みトークンに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「発行済みトークンに派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。詳細については、表 12 の「セキュリティー保護されたセッションを確立する」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。詳細については、前述の「発行済みトークンに派生キーを必要とする」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名の確認を必要とする	レスポンダが要求内の署名を処理することを指定します。WSS のバージョンが 1.1 の場合は、攻撃のリスクを低減するためにこのオプションを選択してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名を暗号化	主署名と署名確認要素を暗号化する必要があるかどうかを指定します。	チェックボックスが選択されている場合、有効になっていることを示します。
署名前に暗号化	メッセージ保護の順序として、SOAP コンテンツを暗号化してから SOAP 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。

STS 発行トークンとサービス証明書

「STS 発行トークン」に似ていますが、クライアントは指定の STS によって発行された SAML トークンを使用して認証するようにサービスから要求されます。また、サービス証明書を使用して機密性保護が実現される点も異なります。サービス証明書は、サービスを認証するため、およびメッセージ保護を提供するためにクライアントで使用されます。GlassFish の場合は、デフォルトの証明書 s1as が付属しています。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。
STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。

表 21 STS 発行トークンとサービス証明書の設定プロパティー


プロパティー	説明	値
発行者アドレス	メッセージで提供されるセキュリティートークンを受け入れる発行者 (STS) のアドレスを指定します。要素のタイプはエンドポイント参照です。STS には、セキュリティートークンの発行、交換、および検証に使用される一連のインタフェースが含まれています。たとえば、JAX-WS サービスの場合、発行者アドレスは `http://localhost:8080/jaxws-sts/sts` です。	http://localhost:8080/jaxws-sts/sts
発行者メタデータアドレス	発行者のメタデータを取得するアドレスを指定します。これは単に URL です。たとえば、JAX-WS サービスの場合、発行者メタデータアドレスは `http://localhost:8080/jaxws-sts/sts` です。	http://localhost:8080/jaxws-sts/sts
トークンタイプ	サービスプロバイダが必要とする SAML トークンのタイプを指定します。たとえば、`urn:oasis:names:tc:SAML1.0:assertion` です。オプションは 1.0、1.1、または 2.0 です。	1.1
キータイプ	サービスプロバイダが必要とするキーのタイプを指定します。選択肢は公開キーまたは対称キーです。対称キー暗号化方式は共有シークレットを基にしており、通常は公開キー暗号化方式より高速です。公開キー暗号化方式は、全員に公開されるキーを基にしており、主に暗号化に使用されますが、署名の検証にも使用可能です。発行済みトークン機構だけに適用されます。	対称キー
キーサイズ	要求する対称キーのサイズをビット数で指定します。これは、望ましいセキュリティー強度を示す情報として指定されます。有効な選択肢は 128、192、および 256 です。セキュリティートークンは、要求されたキーサイズの使用を強制されるわけではなく、STS も、同じキーサイズのトークンの発行を強制されるわけではありません。ただし、受信者はできるかぎり、指定された値以上の強度を持つキーを使用するように努めるべきです。発行済みトークン機構だけに適用されます。	128
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
派生キーを必要とする	派生キーが必要であることを指定します。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。詳細については、表 12 の「セキュリティー保護されたセッションを確立する」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。詳細については、前述の「派生キーを必要とする」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名の確認を必要とする	レスポンダが要求内の署名を処理することを指定します。WSS のバージョンが 1.1 の場合は、攻撃のリスクを低減するためにこのオプションを選択してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名を暗号化	主署名と署名確認要素を暗号化する必要があるかどうかを指定します。	チェックボックスが選択されている場合、有効になっていることを示します。
署名前に暗号化	メッセージ保護の順序として、SOAP コンテンツを暗号化してから SOAP 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。

STS 発行承認トークン

「STS 発行トークン」に似ていますが、クライアントは指定の STS によって発行された SAML トークンを使用して認証されます。承認トークンがメッセージ署名への署名に使用されます。

メッセージの完全性と機密性は、サービス用の暗号化された短期キーを使用して保護されます。短期キーでは、キーハンドルが破棄されたときに交換キーの値を暗号化サービスプロバイダ (CSP) から削除するアルゴリズムが使用されます。サービスでは、指定の STS によって発行された SAML トークンでメッセージが承認されていることが要求されます。

この機構の場合、サービスでは、セキュリティー保護された通信が信頼できる STS によって承認されていることが要求されます。サービスは、クライアントを直接信頼するのではなく、指定の STS によって発行されたトークンを信頼します。つまり、STS はクライアントを安全に認証するための 2 番目のサービスの役割を果たします。

サーバー側の要件

このセキュリティー機構に関しては、次のサーバー側オプションを設定する必要があります。

キーストア: キーストアを設定して、サービス証明書と非公開キーを識別する別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: トラストストアを設定して、クライアントの証明書および信頼できるルートが格納されている別名を指定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。

クライアント側の要件

このセキュリティー機構に関しては、次のクライアント側オプションを設定する必要があります。

キーストア: キーストアを設定して、クライアントの証明書の別名を指定します。GlassFish キーストアの場合、ファイルは keystore.jks、別名は xws-security-client です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。
トラストストア: サーバーの証明書および信頼できるルートが格納されているトラストストアを設定します。GlassFish トラストストアの場合、ファイルは cacerts.jks、別名は xws-security-server です。ただし、GlassFish のデフォルトの証明書ストアを更新済みであると想定しています。STS 機構を使用する場合、クライアントはサービスではなく STS のトラストストアと証明書別名を指定します。GlassFish ストアの場合、ファイルは cacerts.jks、別名は wssip です。
STS: サービスから参照できるセキュリティートークンサービスが必要です。STS は個別の (非 STS) セキュリティー機構を使用してセキュリティー保護されます。このアプリケーションのクライアント側のセキュリティー設定は、アプリケーションに対して選択されたセキュリティー機構ではなく、STS に対して選択されたセキュリティー機構によって決まります。

表 22 STS 発行承認トークンの設定プロパティー


プロパティー	説明	値
発行者アドレス	メッセージで提供されるセキュリティートークンを受け入れる発行者 (STS) のアドレスを指定します。要素のタイプはエンドポイント参照です。STS には、セキュリティートークンの発行、交換、および検証に使用される一連のインタフェースが含まれています。たとえば、JAX-WS サービスの場合、発行者アドレスは `http://localhost:8080/jaxws-sts/sts` です。	http://localhost:8080/jaxws-sts/sts
発行者メタデータアドレス	発行者のメタデータを取得するアドレスを指定します。これは単に URL です。たとえば、JAX-WS サービスの場合、発行者メタデータアドレスは `http://localhost:8080/jaxws-sts/sts` です。	http://localhost:8080/jaxws-sts/sts
トークンタイプ	サービスプロバイダが必要とする SAML トークンのタイプを指定します。たとえば、`urn:oasis:names:tc:SAML1.0:assertion` です。オプションは 1.0、1.1、または 2.0 です。	1.1
キータイプ	サービスプロバイダが必要とするキーのタイプを指定します。選択肢は公開キーまたは対称キーです。対称キー暗号化方式は共有シークレットを基にしており、通常は公開キー暗号化方式より高速です。公開キー暗号化方式は、全員に公開されるキーを基にしており、主に暗号化に使用されますが、署名の検証にも使用可能です。発行済みトークン機構だけに適用されます。	対称キー
キーサイズ	要求する対称キーのサイズをビット数で指定します。これは、望ましいセキュリティー強度を示す情報として指定されます。有効な選択肢は 128、192、および 256 です。セキュリティートークンは、要求されたキーサイズの使用を強制されるわけではなく、STS も、同じキーサイズのトークンの発行を強制されるわけではありません。ただし、受信者はできるかぎり、指定された値以上の強度を持つキーを使用するように努めるべきです。発行済みトークン機構だけに適用されます。	128
アルゴリズム群	対称キーベースまたは非対称キーベースのセキュリティートークンによる暗号化操作を実行するために必要なアルゴリズム群を指定します。詳細については、表 12 の「アルゴリズム群」を参照してください。	Basic 128 ビット
セキュリティーヘッダーのレイアウト	セキュリティーヘッダーに項目を追加する際に適用するレイアウト規則を指定します。オプションは、Strict、Lax、Lax (Timestamp First)、および Lax (Timestamp Last) です。詳細については、表 12 の「セキュリティーヘッダーのレイアウト」を参照してください。	Strict
X509 トークンに派生キーを必要とする	X509 トークンには派生キーが必要であることを指定します。詳細については、前述の「派生キーを必要とする」を参照してください。派生キーは、パスワードまたはほかのユーザーデータから作成される暗号化キーです。アプリケーションでは、必要に応じて派生キーを使用してセッションキーを作成できるため、特定のキーを保存する必要がなくなります。繰り返し行われるメッセージ交換に同じセッションキーを使用することは、リスクと見なされることがあります。そのようなリスクを低減するには、「X509 トークンに派生キーを必要とする」を有効にしてください。	チェックボックスが選択されている場合、有効になっていることを示します。
発行済みトークンに派生キーを必要とする	発行済みトークンには派生キーが必要であることを指定します。詳細については、前述の「X509 トークンに派生キーを必要とする」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティー保護されたセッションを確立する (Secure Conversation)	セキュリティー保護されたセッションでは、複数メッセージ交換のシーケンスが最初に開始されたときに、コンシューマとプロバイダの間で共有セキュリティーコンテキストを確立できます。後続のメッセージ (派生メッセージの場合もある) ではセッションキーを使用することにより、全体的なセキュリティーが向上するとともに、各メッセージのセキュリティー処理のオーバーヘッドが減少します。詳細については、表 12 の「セキュリティー保護されたセッションを確立する」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
セキュリティーセッションに派生キーを必要とする	セキュリティー保護されたセッションには派生キーが必要であることを指定します。詳細については、前述の「X509 トークンに派生キーを必要とする」を参照してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名の確認を必要とする	レスポンダが要求内の署名を処理することを指定します。WSS のバージョンが 1.1 の場合は、攻撃のリスクを低減するためにこのオプションを選択してください。	チェックボックスが選択されている場合、有効になっていることを示します。
署名を暗号化	主署名と署名確認要素を暗号化する必要があるかどうかを指定します。	チェックボックスが選択されている場合、有効になっていることを示します。
署名前に暗号化	メッセージ保護の順序として、SOAP コンテンツを暗号化してから SOAP 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。