STS 発行トークンとサービス証明書 (プロジェクトでの HTTP バインディングコンポーネントの使用)

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

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

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

この機構を 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 に対して選択されたセキュリティー機構によって決まります。

表 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 本体全体に署名することを指定します。暗号化キーと署名キーは、同じソースキーから派生させる必要があります。選択されていない場合、デフォルトの動作は「暗号化前に署名」です。	チェックボックスが選択されている場合、無効になっていることを示します。