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