SAML Holder-of-Key (プロジェクトでの HTTP バインディングコンポーネントの使用)

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

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