| Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド 11gリリース1（11.1.1） B56247-01 |
|
 戻る |
 次へ |
この章では、WebサービスおよびWebサービス・クライアントでポリシーを構成して、サービスのクオリティ（QoS）の要件を実現する方法を説明します。また、関連するOracle WebLogic Serverの構成およびこれらのポリシーを使用するために必要な設定についても説明します。
事前定義済ポリシーは、付録B「事前定義済ポリシー」で説明されています。この付録は、ポリシーの形式に関する最も信頼性の高い情報源です。利便性を考慮して、この章でも付録の情報の一部を掲載しています。
この章では次の項について説明します。
次に示す一連の質問で、要件に最適なセキュリティ・ポリシーを確認できます。
セキュリティ・ポリシーの基本的な要件は何ですか。ユーザーのみを認証する必要があるのか、メッセージ保護のみが必要なのか、両方が必要なのかを決定してください。
認証のみが必要ですか。その場合は、手順2に進みます。
認可のみが必要ですか。その場合は、「認可ポリシー」を参照してください。
認証および認可が必要ですか。その場合は、手順3に進みます。
メッセージ保護のみが必要ですか。その場合は、「メッセージ保護のみのポリシーと構成手順」を参照してください。
認証およびメッセージ保護の両方が必要ですか。その場合は、手順4に進みます。
認証のみが必要な場合は、考慮する必要のある基本的な質問が2つあります。
トークンをどこに組み込みますか。トランスポート・レイヤーとSOAPヘッダーのどちらにトークンを組み込みますか。
特定タイプのトークンを使用する必要がありますか。認証のみのポリシーでサポートされている資格証明は、ユーザー名/パスワード・トークン、SAMLトークンおよびKerberosトークンです。
認証および認可が必要な場合は、次の内容を考慮する必要があります。
認証とメッセージ保護の両方が必要な場合は、次の内容を考慮する必要があります。
メッセージ保護をトランスポート・レイヤーで処理しますか。その場合は、Username over SSL、SAML over SSL（Sender-Vouches）、SAML over SSL（Token Bearer）、HTTP token over SSLの4つのポリシー・セットから選択します。
1つのポリシー・セット（wss_http_token_over_ssl_client_policyおよびwss_http_token_over_ssl_service_policy）では、認証もトランスポート・レイヤーで処理されます。その他3つのポリシーでは、認証はSOAPヘッダーで行われます。
WS-Security V1.0またはv1.1標準を使用している場合は、認証とメッセージ保護の両方がSOAPヘッダーで行われます。5組のポリシーで、ユーザー名/パスワード、SAMLおよびX.509証明書のトークンがサポートされています。
詳細は、「メッセージ保護および認証ポリシーと構成手順」を参照してください。
メッセージ保護では、メッセージ機密保護のためのメッセージの暗号化と、メッセージ整合性のためのメッセージへの署名が行われます。Oracle Fusion Middlewareの事前定義済ポリシーと、メッセージ保護アサーション・テンプレートのいずれかを使用して作成するポリシーには、メッセージ機密保護かメッセージ整合性、あるいはその両方のオプションがあります。
次の手順は、メッセージが保護されるよう、クライアントおよびサービスを構成するために実行が必要な操作をまとめたものです。
適切なメッセージ保護ポリシーをクライアントおよびサービスのそれぞれに添付します。
メッセージ整合性が必要な場合には、メッセージに署名する必要があります。
メッセージ機密保護が必要な場合には、メッセージを暗号化する必要があります。
必要な公開鍵と秘密鍵を、クライアントおよびサービスのキーストアに追加します。この手順を実行するには、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを構成しておく必要があります。
メッセージ保護には、メッセージ機密保護とメッセージ整合性の2つの概念があります。
メッセージの機密保護には、送信ユーザーおよび受信ユーザーのアイデンティティのみでなく、データの機密性も関係します。メッセージのコンテンツを暗号化し、送信ユーザーおよび受信ユーザーのアイデンティティを不明瞭化することで機密保護が実現されます。送信者は受信者の公開鍵を使用してメッセージを暗号化します。メッセージは受信者の秘密鍵でのみ正常に復号化できるため、送信中に第三者によってメッセージが読み取られることはありません。このプロセスを実現するには、受信者の公開鍵が含まれているデジタル証明書が送信者のキーストアに存在している必要があります。
メッセージ整合性は、認証局がメッセージにデジタルで署名することにより実現します。デジタル署名は、SOAPメッセージの送信者を認証したり、SOAPメッセージの整合性（SOAPメッセージが送信中に変更されていないこと）を保証したりするために使用されます。
デジタル署名がSOAPメッセージに適用されると、メッセージから一意のハッシュが生成されます。このハッシュは送信者の秘密鍵で暗号化されます。メッセージを受信すると、受信者は送信者の公開鍵を使用してハッシュを復号化します。
|
注意: 通常、証明書を検証するために受信者のキーストアに送信者の公開鍵を格納しておく必要はありません。キーストアにルート証明書があれば、証明書チェーンを検証できます。ただし、ThumbprintやSerialIssuerメカニズムなど、メッセージに送信者の公開鍵が存在しない場合は、送信者の公開鍵を受信者のキーストアに格納する必要があります。 |
送信者のみが秘密鍵を使用してハッシュを暗号化できるため、これで送信者を認証できます。また、受信者はメッセージとともに送信されるハッシュと、受信者側で生成するハッシュを比較できるため、SOAPメッセージが送信中に改ざんされていないことを証明できます。
次の内容を実行することで、メッセージ保護アサーション・テンプレートおよび事前定義済ポリシーを、リクエストやレスポンス・メッセージの保護に使用できます。
メッセージの署名
メッセージの暗号化
メッセージの署名および暗号化
メッセージの復号化
署名の検証
メッセージの復号化と署名の検証
事前定義済メッセージ保護ポリシー用のFusion Middleware Controlユーザー・インタフェースでは、図9-1に示すように、署名、暗号化またはその両方を行うメッセージ部分を簡単に指定できます。本文全体、アイデンティティ固有のヘッダー要素や本文要素に対して署名、暗号化またはその両方を行うことができます。
SOAPエンベロープ内に格納できないデータをSOAPメッセージの添付ファイルとしてパッケージングすることは、Webサービス分野では標準的なことになってきています。プライマリSOAPメッセージでは、添付ファイルまたはMIMEヘッダー付きの添付ファイルとして追加のエンティティを参照できます。
各SwA添付ファイルはMIME部分であり、MIMEヘッダーを含みます。「アタッチメントを含める」では、添付ファイルは署名されますが、その添付ファイルに対応するMIMEヘッダーは署名されません。「MIMEヘッダーとともにアタッチメントを含める」では、添付ファイルとMIMEヘッダーの両方が署名されます。
次のポリシーでメッセージ保護が行われます。この章の後半部分にあるポリシーごとの項では、各ポリシーでどのようにメッセージ保護が実装されるかについて説明しています。
oracle/wss10_message_protection_client_policy
oracle/wss10_message_protection_service_policy
oracle/wss10_username_id_propagation_with_msg_protection_client_policy
oracle/wss10_username_id_propagation_with_msg_protection_service_policy
oracle/wss10_username_token_with_message_protection_client_policy
oracle/wss10_username_token_with_message_protection_service_policy
oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_username_token_with_message_protection_ski_basic256_service_policy
oracle/wss10_x509_token_with_message_protection_client_policy
oracle/wss10_x509_token_with_message_protection_service_policy
oracle/wss10_saml_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_protection_service_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy
oracle/wss11_message_protection_client_policy
oracle/wss11_message_protection_service_policy
oracle/wss11_kerberos_token_with_message_protection_client_policy
oracle/wss11_kerberos_token_with_message_protection_service_policy
oracle/wss11_saml_token_with_message_protection_client_policy
oracle/wss11_saml_token_with_message_protection_service_policy
oracle/wss11_username_token_with_message_protection_client_policy
oracle/wss11_username_token_with_message_protection_service_policy
oracle/wss11_x509_token_with_message_protection_client_policy
oracle/wss11_x509_token_with_message_protection_service_policy
WS-Security 1.0およびWS-Security 1.1標準の両方がサポートされています。Webサービスとクライアントの両方が共通して共有する標準をサポートしているアサーション・テンプレートまたは事前定義済ポリシーを使用します。新たに開始する場合は、オプションの数が多く、必要なPKIデプロイメントが少ないため、WS-Security 1.1標準を使用します。
アサーション・テンプレートでは、メッセージ本文の完全な署名および暗号化だけでなく、部分的な署名および暗号化もサポートされています。SOAPメッセージ保護が可能なアサーション・テンプレートまたは事前定義済ポリシーの場合、デフォルトの動作はSOAPメッセージ本文全体を署名および暗号化して保護することです。必要な場合には、選択した要素を保護するように、アサーションおよびポリシーを構成できます。
「SSLの構成が必要なポリシー」または「双方向SSLの構成が必要なポリシー」にあげたポリシーを使用する場合、SSL用のキーストアを構成する必要があります。
SSLでは、ネットワークを介して接続される2つのアプリケーションが互いのアイデンティティを認証できるようにし、アプリケーション間で交換されるデータを暗号化することで、安全な接続を提供します。
認証によって、サーバーと、必要に応じてクライアントが、ネットワーク接続の反対側にあるアプリケーションのアイデンティティを検証できます。暗号化によって、ネットワーク上で伝送されるデータを意図した受信者のみが認識できるようになります。クライアント証明書（双方向SSL）は、ユーザーの認証に使用できます。
この項では、SSL経由でリクエストを送信するようにWebサービス・クライアントとWebLogic Server Webサービス・コンテナを設定する方法を説明します。
Webサービス・アプリケーションでSSLを使用するには、次の作業を実行する必要があります。
WebLogic ServerのキーストアとSSL設定を構成します。
Webサービス・クライアントのキーストアとSSL設定を構成します。
これらの手順については、次の項で説明します。
SSLの構成が必要な事前定義済ポリシーは次のとおりです。
oracle/wss_http_token_over_ssl_service_policy
oracle/wss_http_token_over_ssl_client_policy
oracle/wss_saml_token_bearer_over_ssl_service_policy
oracle/wss_saml_token_bearer_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss_username_token_over_ssl_service_policy
oracle/wss_username_token_over_ssl_client_policy
さらに、次のテンプレートを使用して、SSLを必要とする新しいポリシーを作成できます。
oracle/wss_http_token_over_ssl_service_template
oracle/wss_http_token_over_ssl_client_template
oracle/wss_saml_token_bearer_over_ssl_service_template
oracle/wss_saml_token_bearer_over_ssl_client_template
oracle/wss_saml_token_over_ssl_service_template
oracle/wss_saml_token_over_ssl_client_template
oracle/wss_username_token_over_ssl_service_template
oracle/wss_username_token_over_ssl_client_template
これらのアサーションおよびポリシーの詳細は、付録C「事前定義済アサーション・テンプレート」および付録B「事前定義済ポリシー」を参照してください。
双方向SSLの構成が必要な事前定義済ポリシーは次のとおりです。
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy
oracle/wss_username_token_over_ssl_client_policy（相互認証を選択した場合）
oracle/wss_username_token_over_ssl_service_policy（相互認証を選択した場合は、）
oracle/wss_http_token_over_ssl_client_policy（相互認証を選択した場合）
oracle/wss_http_token_over_ssl_service_policy（相互認証を選択した場合）
さらに、次のテンプレートを使用して、双方向SSLを必要とする新しいポリシーを作成できます。
oracle/wss_saml_token_over_ssl_client_template
oracle/wss_saml_token_over_ssl_service_template
秘密鍵、デジタル証明書および信頼できる認証局（CA）証明書によって、WebLogic Server環境でアイデンティティと信頼が確立され、検証されます。
この項では、WebLogic Serverにキーストアを構成するために必要な手順の概要を説明します。詳細は、次の2つの資料を参照してください。
詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプ。特に「サーバー: 構成: キーストア」に関するトピック。
『Oracle Fusion Middleware Securing Oracle WebLogic Server』。特にアイデンティティと信頼の構成に関する項。
WebLogic Serverには、デフォルトのアイデンティティ・キーストアDemoIdentity.jksとデフォルトの信頼キーストアDemoTrust.jksが構成されています。さらに、WebLogic Serverでは、JDKのcacertsファイル内の認証局を信頼しています。このデフォルトのキーストア構成は、テストや開発を目的とする場合に適しています。ただし、これらのキーストアは本番環境では使用しないでください。
サーバーのアイデンティティと信頼を構成する手順は次のとおりです。
Sun社のkeytoolユーティリティまたはEntrust社やVerisign社のような信頼できるベンダーから、デジタル証明書、秘密鍵および信頼できるCA証明書を取得し、キーストアに含めます。
証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。
秘密鍵、デジタル証明書および信頼できる認証局（CA）には、Privacy Enhanced Mail（PEM）形式を使用することをお薦めします。
keytoolユーティリティを使用する場合、デフォルトの鍵のペア生成アルゴリズムはDigital Signature Algorithm（DSA）です。WebLogic ServerではDSAはサポートされていません。WebLogic Serverを使用する場合は、RSAなど、別の鍵のペア生成および署名アルゴリズムを指定してください。Sun社のkeytoolユーティリティの詳細は、「keytool - Key and Certificate Management Tool」（http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html）の説明を参照してください。
WebLogic Serverキットで提供されるデジタル証明書、秘密鍵および信頼できるCA証明書も使用できます。デモ用のデジタル証明書、秘密鍵および信頼できるCA証明書は、開発環境でのみ使用してください。
アイデンティティ用に1つと信頼用に1つ、キーストアを作成します。キーストア形式にはJavaキーストア（JKS）を使用することをお薦めします。
秘密鍵と信頼できるCAをキーストアにロードします。
コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
アイデンティティと信頼キーストアを構成するサーバーの名前をクリックします。
「構成」→「キーストア」を選択します。
「キーストア」フィールドで、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納および管理する方法を選択します。選択できるオプションは次のとおりです。
カスタムIDとカスタム信頼: ユーザーが作成するアイデンティティと信頼キーストア。
デモIDとデモ信頼: デモ用のアイデンティティと信頼キーストア。..\server\libディレクトリおよびJDK cacertsキーストアにあり、デフォルトで構成されています。開発目的にのみ使用してください。
カスタムIDとJava標準信頼: ユーザーが作成するキーストアと、JAVA_HOME\jre\lib\securityディレクトリのcacertsファイルに定義されている信頼できるCA。
カスタムIDとコマンドライン信頼: ユーザーが作成するアイデンティティ・キーストアと、信頼キーストアの場所を指定するコマンドライン引数。
「ID」セクションで、アイデンティティ・キーストアの属性を定義します。
カスタムIDキーストア: アイデンティティ・キーストアへの完全修飾パス。
カスタムIDキーストアのタイプ: キーストアのタイプ。一般に、この属性にはJavaキーストア（JKS）を指定します。空白のままにすると、デフォルトでJKSに設定されます。
カスタムIDキーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアで、書込みにはパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。
|
注意: デモ・アイデンティティ・キーストアのパスフレーズは、DemoIdentityKeyStorePassPhraseです。 |
「信頼 」セクションで、信頼キーストアのプロパティを定義します。
キーストアとして「Java標準信頼キーストア」を選択する場合、キーストアの作成時に定義したパスワードを指定します。パスワードを確認します。
カスタム信頼を選択した場合、次の属性を定義します。
カスタム信頼キーストア: 信頼キーストアへの完全修飾パス。
カスタム信頼キーストアのタイプ: キーストアのタイプ。一般に、この属性にはJKSを指定します。空白のままにすると、デフォルトでJKSに設定されます。
カスタム信頼キーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアで、書込みにはパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。
変更内容は自動的にアクティブ化されます。
一方向SSLでは、サーバーはクライアントに証明書を提示する必要がありますが、クライアントがサーバーに証明書を提示する必要はありません。
「SSLに関するキーストアの構成」の説明に従ってWebLogic Serverインスタンスのアイデンティティと信頼キーストアを構成したら、そのSSL属性を構成します。これらの属性では、「構成: キーストア」ページで指定したキーストア内のアイデンティティ鍵と証明書の場所を示します。この情報を指定するには、「構成: SSL」ページを使用します。
この項では、WebLogic ServerにSSLを構成するために必要な手順の概要を説明します。詳細は、『Oracle Fusion Middleware Securing Oracle WebLogic Server』を参照してください。
SSLの構成手順は次のとおりです。
WebLogic Server管理コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
SSLを構成するサーバーの名前をクリックします。
「構成」→「SSL」ページを選択し、WebLogic Serverのアイデンティティ（証明書と秘密鍵）と信頼（信頼できるCA）の場所を選択します。
秘密鍵の別名とパスワードのSSL属性を設定します。
ページの下部で、「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
WebLogic Serverが内部サーバーとエクスポート可能クライアントとの間で何回エクスポート可能鍵を使用したら新しい鍵を生成する必要があるか、使用できる回数を指定します。新しい鍵を生成するまでに鍵を使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。
「相互クライアント証明書の動作」コントロールを「クライアント証明書を要求しない」に設定します。
インバウンドとアウトバウンドのSSL証明書検証方法を指定します。選択できるオプションは次のとおりです。
組込みSSLの検証のみ: 組込みの信頼できるCAベースの検証を使用します。これがデフォルトです。
組込みSSLの検証および証明書パス検証プロバイダ: 組込みの信頼できるCAベースの検証を使用し、追加の検証を実行するために構成済のCertPathValidatorプロバイダを使用します。
双方向SSLでは、サーバーはクライアントに、またクライアントはサーバーに証明書を提示します。SSLハンドシェイクを完了する前に、クライアントに有効で信頼できる証明の送信を要求するようにWebLogic Serverを構成できます。
「SSLに関するキーストアの構成」の説明に従って、WebLogic Serverインスタンスのアイデンティティと信頼キーストアを構成した後、使用するポリシーまたはテンプレートで必要な場合は、「双方向SSLの構成が必要なポリシー」の説明に従って双方向SSL属性を構成できます。
この項では、WebLogic ServerにSSLを構成するために必要な手順の概要を説明します。詳細は、『Oracle Fusion Middleware Securing Oracle WebLogic Server』を参照してください。
双方向SSLの構成手順は次のとおりです。
WebLogic Server管理コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
SSLを構成するサーバーの名前をクリックします。
「構成」→「SSL」ページを選択し、WebLogic Serverのアイデンティティ（証明書と秘密鍵）と信頼（信頼できるCA）の場所を選択します。
秘密鍵の別名とパスワードのSSL属性を設定します。
ページの下部で、「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
WebLogic Serverが内部サーバーとエクスポート可能クライアントとの間で何回エクスポート可能鍵を使用したら新しい鍵を生成する必要があるか、使用できる回数を指定します。新しい鍵を生成するまでに鍵を使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。
必要に応じて、「サーバーの証明書を使用」コントロールを設定します。このコントロールを設定すると、WebLogic ServerでホストされているWebサービス・クライアントが、HTTPSを介して接続を開始するときにサーバー証明書/鍵をクライアント・アイデンティティとして使用する必要があるかどうかが決まります。
「相互クライアント証明書の動作」コントロールを「クライアント証明書を要求(強制する)」に設定します。
インバウンドとアウトバウンドのSSL証明書検証方法を指定します。選択できるオプションは次のとおりです。
組込みSSLの検証のみ: 組込みの信頼できるCAベースの検証を使用します。これがデフォルトです。
組込みSSLの検証および証明書パス検証プロバイダ: 組込みの信頼できるCAベースの検証を使用し、追加の検証を実行するために構成済のCertPathValidatorプロバイダを使用します。
中核となるWebLogic Serverのセキュリティ・サブシステムでは、デフォルトのキーストアに格納されている秘密鍵とX.509証明書のペアをSSLに使用します。
WebLogic Serverでリクエストのデジタル署名に使用されるX.509証明書を、Webサービス・クライアントが信頼できるようにする必要があります。次のいずれかを実行します。
WebLogic Serverが、信頼できる認証局から発行された、クライアントが自動的に信頼するデジタル証明書を取得するようにします。
WebLogic Serverが信頼する個々の証明書をすべてリストした証明書レジストリを作成し、クライアントが登録されたこれらの証明書を信頼するようにします。
Webサービス・クライアントに関するSSLの構成手順は次のとおりです。
クライアント・アプリケーションで使用するキーストアを作成します。アプリケーション・ユーザーごとに1つのクライアント・キーストアを作成することをお薦めします。
この手順の実行には、keytoolユーティリティを使用できます。開発目的の場合、最初はkeytoolユーティリティを使用するのが最も簡単な方法です。
秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。
証明書の鍵が暗号化とデジタル署名の両方に使用できることを確認します。Oracleでは、鍵の長さは1024ビット以上である必要があります。
クライアントのJVMに次のプロパティが設定されていることを確認します。
javax.net.ssl.trustStore: 信頼ストアが含まれるファイルの名前。
javax.net.ssl.trustStoreType: デフォルトのTrustManagerで使用するキーストア・オブジェクトのタイプ。
javax.net.ssl.trustStorePassword: デフォルトのTrustManagerで使用するキーストア・オブジェクトのパスワード。
クライアントでリクエストのデジタル署名に使用されるX.509証明書をWebLogic Serverが検証でき、WebLogic Serverがその証明書をクライアントへの応答の暗号化に使用できるようにする必要があります。次のいずれかを実行します。
クライアント・アプリケーションが、信頼できる認証局から発行された、WebLogic Serverが自動的に信頼するデジタル証明書を取得するようにします。
WebLogic Serverが信頼する個々の証明書をすべてリストした証明書レジストリを作成し、クライアントが登録されたこれらの証明書のいずれかを使用するようにします。
Webサービス・クライアントに関するSSLの構成手順は次のとおりです。
クライアント・アプリケーションで使用するキーストアを作成します。アプリケーション・ユーザーごとに1つのクライアント・キーストアを作成することをお薦めします。
この手順の実行には、keytoolユーティリティを使用できます。開発目的の場合、最初はkeytoolユーティリティを使用するのが最も簡単な方法です。
秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。
証明書の鍵が暗号化とデジタル署名の両方に使用できることを確認します。Oracleでは、鍵の長さは1024ビット以上である必要があります。
クライアントのJVMに次のプロパティが設定されていることを確認します。
javax.net.ssl.trustStore: 信頼ストアが含まれるファイルの名前。
javax.net.ssl.trustStoreType: デフォルトのTrustManagerで使用するキーストア・オブジェクトのタイプ。
javax.net.ssl.trustStorePassword: デフォルトのTrustManagerで使用するキーストア・オブジェクトのパスワード。
javax.net.ssl.keyStore: キーストア・オブジェクトが含まれるファイルの名前。
javax.net.ssl.keyStoreType: キーストア・オブジェクトのタイプ。
javax.net.ssl.keyStorePassword: キーストア・オブジェクトのパスワード。
SOAPメッセージの署名と暗号化を行うには、最初にWebLogicドメイン用のWeb Services Managerキーストアを作成して構成する必要があります。このキーストアは、WebLogicドメイン内でSOAPメッセージの公開鍵と秘密鍵の格納に使用されます。
|
注意: この章で別途説明するように、Web Services Managerランタイムでは、SSLに使用されるWebLogic Serverキーストアを使用しません。 |
署名と暗号化キーは、SOAPメッセージの署名、検証、暗号化、復号化に使用されます。
キーストアの構成はドメイン単位で行います。ドメイン内のすべてのWebサービスおよびWebサービス・クライアントはこのキーストアを使用します。
Web Services Managerで使用されるキーストアを設定するには、次の手順を実行します。
「Javaキーストアの作成方法」の説明に従って、keytoolを使用してJavaキーストアを作成します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページの下部近くにある「キーストア」コントロールのプラス記号（+）をクリックして開き、「構成」をクリックします。
図9-2に示すように、Web Services Managerの「キーストアの構成」ページが表示されます。
「キーストア管理の構成」チェック・ボックスがまだ選択されていない場合は、選択します。
作成するキーストアのパスと名前を入力します。デフォルトのキーストア名はdefault-keystore.jksですが、変更できます。ただし、キーストアのタイプはJKSである必要があり、変更できません。
キーストアのパスワードを入力して確認します。
署名と暗号化キーの別名とパスワードを入力します。パスワードを確認します。
署名と暗号化キーの別名とパスワードによって、鍵の格納と取得に使用される文字列の別名とパスワードが定義されます。
「OK」をクリックして変更内容を送信します。
このページのフィールドを変更した場合、変更内容を反映するにはOracle Enterprise Manager Fusion Middleware Controlを再起動する必要があります。
クライアントのX.509トークンで必要な署名と暗号化キーを格納するには、Javaキーストア（JKS）のキーストアを作成する必要があります。鍵は、認証やデータ整合性など、様々な用途に使用されます。たとえば、次のような用途があります。
データに署名するには、署名者の秘密鍵が必要です。
署名を検証するには、信頼できるCA証明書と、秘密鍵に一致する公開鍵が必要です。
データを暗号化するには、受信者の公開鍵が必要です。
データを復号化するには、公開鍵に対応する秘密鍵が必要です。
これらの信頼できる証明書、公開鍵および秘密鍵はキーストアに格納されます。次の項では、信頼できる証明書を取得できる場所と、これらのキーストアの作成および使用方法を説明します。
Verisign社やEntrust社のような認証局（CA）から証明書を取得し、キーストアに含めることができます。証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。
Javaキーストア（JKS）は、Sun社によって定義された独自のキーストア形式です。鍵と証明書をJKSで作成し管理するには、keytoolユーティリティを使用します。keytoolユーティリティを使用すると、次のタスクを実行できます。
公開鍵と秘密鍵のペアを作成し、他のパーティに属する公開鍵を信頼できるものとして指定し、キーストアを管理します。
証明書リクエストを適切な認証局（CA）に発行し、認証局から返された証明書をインポートします。
独自の公開鍵と秘密鍵のペアおよび関連する証明書を管理します。これにより、独自の鍵と証明書を使用して自分自身を他のユーザーやサービスに対して認証できます。このプロセスは自己認証と呼ばれます。また、デジタル署名を使用したデータ整合性および認証サービスにも独自の鍵と証明書を使用できます。
通信するピアの公開鍵をキャッシュします。鍵は証明書の形式でキャッシュされます。
次の項では、keytoolユーティリティを使用してJKSを作成および管理する方法の概要を説明します。キーストアの作成方法、および秘密鍵のペアとCA証明書のロード方法を取り上げます。keytoolユーティリティのコマンドや引数の詳細は、次のWebサイト・アドレスにアクセスして参照してください。
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html
新しい秘密鍵と自己署名証明書を作成します。
秘密鍵を作成するには、genKeyコマンドを使用します。既存の秘密鍵がなければ、新しい秘密鍵が作成されます。次のコマンドでは、署名アルゴリズムRSA-SHA1とtest.jksキーストアの別名テストを使用して、RSA鍵が生成されます。
keytool -genkey -alias test -keyalg "RSA" -sigalg "SHA1withRSA" -dname "CN=test, C=US" -keystore test.jks
keytoolユーティリティから必要な鍵とキーストアのパスワードを要求するプロンプトが表示されます。DSA鍵はサポートされていません。コマンドで、必ずパラメータ-keyalg RSAを渡してください。
キーストアを表示します。
次のコマンドでは、キーストアの内容が表示されます。キーストアのパスワードを要求するプロンプトが表示されます。
keytool -list -v -keystore test.jks
信頼できるCA証明書をキーストアにインポートします。
証明書のインポートには、-importコマンドを使用します。次のコマンドでは、信頼できるCA証明書がtest.jksキーストアにインポートされます。既存のキーストアがない場合、新しいキーストアが作成されます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。
keytool -import -alias aliasfortrustedcacert -trustcacerts -file trustedcafilename -keystore test.jks
証明書リクエストを生成します。
リクエストの生成には、-certreqコマンドを使用します。次のコマンドでは、テスト別名の証明書リクエストが生成されます。CAから証明書または証明書チェーンが返されます。
keytool -certreq -alias test -sigalg "RSAwithSHA1" -file certreq_file -storetype jks -keystore test.jks
自己署名証明書を信頼できるCA証明書で置き換えます。
既存の自己署名証明書をCAの証明書で置き換える必要があります。これを実行するには、-importコマンドを実行します。次のコマンドでは、test.jksキーストアの信頼できるCA証明書で置き換えます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。
keytool -import -alias test -file trustedcafilename -keystore test.jks
資格証明ストア・プロバイダは、Webサービスやその他のアプリケーションの資格証明を格納、取得および削除する手段を提供します。
たとえば、oracle/wss_http_token_client_policyポリシーには、csf-keyプロパティが含まれており、そのデフォルト値はbasic.credentialsです。この資格証明は、資格証明ストア・プロバイダに格納されます。
資格証明ストア・プロバイダを構成するには、次の手順を実行します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「資格証明」をクリックします。
図9-3に示すように、資格証明プロバイダの構成ページが表示されます（この図では、「資格証明ストア・プロバイダ」コントロールがすでに開かれています）。
「マップの作成」をクリックし、図9-4に示すようにマップ名oracle.wsm.securityを入力します。
「キーの作成」をクリックします。図9-5に示すように、「キーの作成」ダイアログ・ボックスが表示されます。
選択されていない場合は、マップ名oracle.wsm.securityを選択します。
キー名を入力します。
キーのタイプを「パスワード」または「汎用」から選択します。パスワード資格証明には、ユーザー名とパスワードを格納できます。汎用資格証明には、資格証明オブジェクトを格納できます。
パスワード資格証明の場合、ユーザー名とパスワードを入力します。
「OK」をクリックします。
この項では、WebLogic Serverのセキュリティ機能について説明します。この機能の詳細は、『Oracle Fusion Middleware Securing Oracle WebLogic Server』およびOracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプで説明されています。この項では、セキュリティ機能と構成ポリシーとの関係を中心に、セキュリティ機能の概要のみを解説します。
使用するセキュリティ・ポリシーによって、WebLogic Serverに構成が必要なセキュリティ・プロバイダのタイプが決まります。ポリシーはトークンのタイプに基づいて次のようなカテゴリに分類できます。
ユーザー名トークンを使用するポリシーでは、NameCallbackとPasswordCallbackを処理できる認証プロバイダが必要です。WebLogicのデフォルト認証プロバイダは、OAM認証プロバイダと同様、これに該当します。
次のポリシーはこのカテゴリに分類されます。
oracle/wss_http_token_service_policy
oracle/wss_username_token_service_policy
oracle/wss_username_token_over_ssl_service_policy
oracle/wss11_username_token_with_message_protection_service_policy
oracle/wss10_username_token_with_message_protection_service_policy
oracle/wss10_username_token_with_message_protection_ski_basic256_service_policy
X.509トークンおよびSAMLトークンを使用するポリシーでは、NameCallbackを介して境界認証を処理できる認証プロバイダ（またはIDアサーション・プロバイダ）が必要です。Webサービス・ランタイムでは、ユーザーにかわりトークンを処理してユーザー名を判定し、Oracle Platform Security Service（OPSS）レイヤーを起動して認証を完了します。このように、セキュリティ・プロバイダはX.509トークンやSAMLトークンを直接処理しないため、WebLogicのプロバイダはこのようなタイプのトークンをサポートする必要がありません。
次のポリシーはこのカテゴリに分類されます。
oracle/wss10_x509_token_with_message_protection_service_policy
oracle/wss10_saml_token_service_policy
oracle/wss10_saml_token_with_message_protection_service_policy
oracle/wss_saml_token_over_ssl
oracle/wss_saml_token_bearer_over_ssl_service_policy
oracle/wss10_saml_hok_token_with_message_protection_service_policy
oracle/wss11_saml_token_with_message_protection_service_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy
oracle/wss11_x509_token_with_message_protection_service_policy
ObossoCookieトークンを使用するポリシーでは、このタイプのトークンを処理できる唯一のプロバイダであるOAM IDアサーション・プロバイダを使用する必要があります。
このカテゴリに分類されるのは、oracle/wss_oam_token_service_policyポリシーのみです。
特に作成が必要なWebLogicセキュリティ・プロバイダはOAM IDアサーション・プロバイダのみです。また、oracle/wss_oam_token_service_policyポリシーを使用する場合にのみ作成する必要があります。
それ以外のすべてのポリシーの場合、NameCallbackおよびPasswordCallbackコールバック、またはNameCallbackのみで資格証明を検証できるWebLogic認証プロバイダを必要に応じて使用できます。つまり、適宜プロバイダを選択し、WebLogicのデフォルト認証プロバイダを使用して埋込みのLDAPデータストアに対してユーザーを認証したり、デフォルトのIDアサーション・プロバイダを使用したりできるということです。手順の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する項を参照してください。
ただし、Oracle Access Managerをすでに使用しているか、これから使用する予定がある場合、「OAM認証プロバイダとIDアサーション・プロバイダの使用方法」に説明されているように、OAM認証プロバイダでほとんどの構成オプションが提供される場合があります。
OAM認証プロバイダは、NameCallbackおよびPasswordCallbackコールバック、またはNameCallbackのみを処理します。
OAM IDアサーション・プロバイダは、ObssoCookieトークンを処理します。
前提条件として、Oracle Access Managerも構成する必要があります。
このプロバイダの構成方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する項を参照してください。
図9-6は、OAM認証プロバイダの典型的な認証ユースケースです。
ユーザーのWebサービス・クライアントが、いずれかのユーザー名トークン・ポリシーで保護されているWebサービスにアクセスしようとすると、WebLogic Serverからユーザーに資格証明のチャレンジが表示されます。WebLogicセキュリティ・フレームワークは、資格証明が検証され、認証されたサブジェクトが生成されるまで、認証プロバイダのリストを循環して使用します。
この場合、OAM認証プロバイダは認証要件を満たします。資格証明がOracle Access Managerのアクセス・サーバーに渡され、構成済のエンタープライズOracle Virtual Directoryに対して検証されます。
このプロセスは、X.509およびSAMLトークンを必要とするポリシーの場合と似ています。Webサービス・ランタイム環境は、Webサービスに代わってX.509またはSAMLトークンを検証します。次に、X.509またはSAMLログイン・モジュールが、検証されたトークンからユーザー名を抽出し、NameCallbackを介してWebLogic Serverセキュリティ・フレームワークに渡します。
OAM認証プロバイダなど、NameCallbackを処理する構成済の認証プロバイダ（またはIDアサーション・プロバイダ）をここで呼び出すことができます。
この場合、OAM認証プロバイダは、ユーザーが存在するかどうかのみを確認します（IDアサーション・モード）。存在する場合、ユーザーはアサートされ、サブジェクトが確立します。
OAM IDアサーション・プロバイダは、ObssoCookieトークンを使用して、oracle/wss_oam_token_service_policyポリシーで保護されているWebサービスにアクセスしようとするユーザーのアイデンティティをアサートします。
oracle/wss_oam_token_service_policyポリシーで保護されているWebサービスには、SOAPヘッダー内でObssoCookieトークンを提示する必要があります。つまり、WebサービスはObssoCookieトークンを使用しますが、トークンの生成方法には関与しません。具体的には、WebLogic Serverセキュリティ・サービスはトークンのタイプを検出し、OAM IDアサーション・プロバイダを起動します。次に、OAM IDアサーション・プロバイダはObssoCookieトークンをOracle Access Managerアクセス・サーバーに対して検証し、ユーザー名を取得します。ユーザー名は、認証されたサブジェクトにプリンシパルとして組み込まれます。
Webサービス・クライアントは、ObssoCookieトークンを取得してWebサービスに送信する必要があります。これは通常、Webゲートを介して行います。Webゲートは、（Oracle Access Managerに構成されている認証スキームに応じて）Webサービス・クライアント・ユーザーに資格証明のチャレンジを表示し、ユーザーを認証します。Webゲートは、認証が成功すると、ユーザーのブラウザにObssoCookieを送信します。
次に、Webサービス・クライアントは、SOAPリクエストでObssoCookieトークンをWebサービスに送信します。
SAMLおよびKerberosポリシーには、ログイン・モジュールが関連付けられています。このモジュールは、ポリシーを構成するアサーションによって決まります。SAMLポリシーをWebサービスに添付する場合、ログイン・ポリシーを編集して必要な変更を加える必要があります。Kerberosログイン・モジュールの設定は、任意で構成できます。
（他のポリシー・タイプに関連付けられているログイン・モジュールには、Webサービス・ポリシーに固有の設定はありません。）
表9-1は、使用可能なログイン・モジュールとそれを使用するポリシーの一覧です。
表9-1 SAMLおよびKerberosログイン・モジュールと関連ポリシー
| ログイン・モジュール・サービス名 | 説明 | 設定可能な属性と値 |
|---|---|---|
|
saml.loginmodule |
SAMLログイン・モジュールは、Java Authentication and Authorization Service（JAAS）ログイン・モジュールで、SAMLアサーションを受け入れてログインを実行します。SAMLログイン・モジュールは、SAMLアサーションから作成されたプリンシパルのログイン・コンテキストを使用して、Webサービスを実行できるようにします。 |
発行者。SAMLトークンの発行者の名前。デフォルトはwww.oracle.comです。 |
|
krb5.loginmodule |
Kerberosログイン・モジュール |
principal。使用するプリンシパルの名前です。testuserのような単純なユーザー名の場合と、host/testhost.eng.sun.comのようなサービス名の場合があります。keyTabの複数のプリンシパルに対する複数の資格証明がある場合、または特定のチケット・キャッシュのみを使用する場合、使用するプリンシパルの設定にprincipalオプションを使用できます。 useKeyTab。trueまたはfalse。モジュールがkeyTabからプリンシパルの鍵を取得できるようにするには、trueに設定します（デフォルト値はfalse）。keyTabが設定されていない場合は、モジュールはKerberos構成ファイルでkeyTabを検索します。Kerberos構成ファイルに指定されていない場合は、ファイル{user.home}{file.separator}krb5.keytabを検索します。 storeKey。プリンシパルの鍵をサブジェクトの秘密資格証明に格納するには、trueに設定します。 keyTab。プリンシパルの秘密鍵を取得するには、keyTabのファイル名を設定します。 doNotPrompt。資格証明をキャッシュまたはkeyTabから取得できないときに、パスワードを要求するプロンプトを表示しない場合は、trueに設定します（デフォルト値はFalse）。trueに設定すると、資格証明をキャッシュまたはkeyTabから取得できない場合、認証は失敗します。 |
ログイン・モジュールを構成するには、次の手順を実行します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ログイン・モジュールのリストから、ログイン・モジュールを選択し、「編集」をクリックします。
ログイン・モジュールの特定の属性またはカスタム・プロパティを構成します。
SAML標準では、Web上のソフトウェア・エンティティ間のセキュリティ・アサーションを作成、要求および交換するための共通のXMLフレームワークが定義されています。SAMLトークン・プロファイルは、WS-Security標準のコア・セットの一部であり、WebサービスのセキュリティのためにSAMLアサーションを使用する方法が指定されています。SAMLでは、ビジネス・プロセスまたはトランザクションの複数のステップ間で、ブラウザからポータル、Webサービスのネットワークへと渡すことのできるセキュリティ・トークンを表す標準的な方法も提供されます。
次の事前定義済ポリシーを使用する場合は、SAMLを構成する必要があります。
oracle/wss_saml_token_bearer_over_ssl_service_policy
oracle/wss_saml_token_bearer_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss10_saml_token_service_policy
oracle/wss10_saml_token_client_policy
oracle/wss10_saml_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_protection_service_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy
oracle/wss10_saml_hok_token_with_message_protection_service_policy
oracle/wss10_saml_hok_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_integrity_service_policy
oracle/wss10_saml_token_with_message_integrity_client_policy
oracle/wss11_saml_token_with_message_protection_service_policy
oracle/wss11_saml_token_with_message_protection_client_policy
SAMLログイン・モジュールは、Webサービスに代わってSAMLトークンを検証します。次に、SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、NameCallbackを介してOracle Platform Security Services（OPSS）に（間接的に）渡します。
設計時にSAML Webサービス・クライアントを構成するには、この項で説明する手順を実行します（デプロイ時にWebサービス・クライアントにSAMLポリシーを添付する場合、これらのプロパティは構成が不要で、Fusion Middleware Controlに表示されることもありません）。
これ以降の項で説明するように、ユーザー・ロールをアサーションに含め、SAMLアサーション発行者名を変更することもできます。
JSEクライアント・アプリケーションの場合、次のようにユーザー名をBindingProviderプロパティとして構成します。
Map<String,Object> reqContext = ((BindingProvider) proxy).getRequestContext() reqContext.put( BindingProvider.USERNAME_PROPERTY, "jdoe")
ここで、proxyは、実際のWebサービスの起動に使用されるWebサービス・プロキシを示します。
JEEクライアントの場合は、ユーザーが認証済で、サブジェクトがコンテナ内で確立されていれば、ユーザー名はサブジェクトから自動的に取得されるため、追加の構成は必要ありません。
たとえば、ユーザーjdoeがすでにJEEアプリケーションに対して認証され、JEEアプリケーションからWebサービス・コールを行う場合、ユーザー名jdoeは自動的に伝播されます。
ただし、ユーザーが認証されていない場合、JSEと同様にBindingProviderにユーザー名を構成する必要があります。
ユーザーのロールをSAMLアサーションの属性文として渡すことができます。デプロイ後にこれを実行するには、user.role.includeプロパティをtrueに構成します。ポリシー内のデフォルト値はfalseです。
設計時にユーザーのロールを構成するには、BindingProviderのuser.role.includeプロパティをtrueに設定します。
Webサービス・クライアントとWebサービス側の両方で事前定義済SAMLポリシー（またはアサーション）を使用している場合、saml.issuer.nameプロパティはwww.oracle.comである必要があります。このため、通常はデフォルト値を使用でき、発行者の構成は不要です。NET/WLSなど、異なるクライアントが、事前定義済SAMLポリシーで保護されているWebサービスと通信する場合は、発行者名プロパティを変更する必要があります。このSAMLアサーション発行者名はSAMLアサーションで渡すことができます。
デプロイ時にこれを実行するには、saml.issuer.nameプロパティを設定します。ポリシーのデフォルト値はwww.oracle.comです。
設計時に発行者を構成するには、BindingProviderのsaml.issuer.nameプロパティを設定します。
事前定義済SAMLポリシーに関してOPSSを構成するには、次の手順を実行します。
「SAMLおよびKerberosログイン・モジュールの構成」の説明に従って、SAMLログイン・モジュールを構成します。
デフォルトでは、SAMLアサーション発行者名はwww.oracle.comです。Webサービス・クライアントとWebサービス側の両方で事前定義済SAMLポリシー（またはアサーション）を使用している場合、saml.issuer.nameプロパティはwww.oracle.comである必要があります。このため、通常はデフォルト値を使用でき、発行者の構成は不要です。
別の発行者名を使用するには、図9-7に示すように、「追加」をクリックして追加の発行者名を追加します。
OAM認証プロバイダやその他のIDアサーション・プロバイダをWebLogic Server管理コンソールで構成します。
SAML鍵所有者ポリシーなど、SAMLアサーションに関連する署名が含まれるポリシー（アサーションから参照される鍵がメッセージの署名に使用される）、または送信者保証ポリシー（送信者の鍵がメッセージの署名に使用される）を使用する場合、「メッセージ保護に関するキーストアの設定」の説明に従って、署名と検証のための鍵と証明書を構成する必要があります。
SSLが必要なポリシーを使用する場合、「SSLに関するキーストアの構成」の説明に従ってSSLを構成する必要があります。
Oracle Fusion Middleware 11gリリース1（11.1.1）では、次に示す事前定義済のポリシーとともに、Kerberosトークンもサポートされています。
oracle/wss11_kerberos_token_client_policy
oracle/wss11_kerberos_token_service_policy
oracle/wss11_kerberos_token_with_message_protection_client_policy
oracle/wss11_kerberos_token_with_message_protection_service_policy
また、次のアサーション・テンプレートを使用して、ポリシーを作成することもできます。
oracle/wss11_kerberos_token_client_template
oracle/wss11_kerberos_token_service_template
oracle/wss11_kerberos_token_with_message_protection_client_template
oracle/wss11_kerberos_token_with_message_protection_service_template
これらのアサーションおよびポリシーの詳細は、付録C「事前定義済アサーション・テンプレート」および付録B「事前定義済ポリシー」を参照してください。
この項に記載されている手順に従って、KDCをWebサービス・クライアントとWebサービスで使用できるように構成します。
KDCデータベースを初期化します。たとえば、UNIXでは次のコマンドをルートとして実行する場合があります。ここで、oracle.comはデフォルトのレルムです。
root# /usr/kerberos/sbin/kdb5_util -r oracle.com -s
kerberosサービス・プロセスを起動します。たとえば、UNIXでは次のコマンドをルートとして実行します。
root# /usr/kerberos/sbin/krb5kdc & root# /usr/kerberos/sbin/kadmind &
KDCユーザー・レジストリに2つのアカウントを作成します。最初のアカウントは、エンド・ユーザー用のもの、つまりWebサービス・クライアント・プリンシパルです。2つ目のアカウントは、Webサービス・プリンシパル用のものです。
これらのアカウントを作成する方法には、kadmin.localツールを使用する方法があります。このツールは通常、MIT KDCの配布に含まれています。たとえば、次のような用途があります。
>sudo su - # become root >cd /usr/kerberos/sbin/kadmin.local >kadmin.local>addprinc fmwadmin -pw welcome1 >kadmin.local> addprinc SOAP/myhost.oracle.com -randkey >kadmin.local>listprincs # to see the added principals
この例のWebサービス・プリンシパル名（SOAP/myhost.oracle.com）は、ランダム・パスワードを使用して作成されています。Webサービス・プリンシパルは、キー表（サービス・プリンシパル名とキーを格納するファイル）を使用して、Kerberosシステムにログインします。ランダム・パスワードを使用することにより、セキュリティが強化されます。
Webサービス・クライアントは、正しいKDCに対して認証するように構成する必要があります。
KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。
例9-1に、サンプルのkrb5.confを示します。次の事項に注意してください。
ファイルは、Kerberosランタイムに対して、操作のレルムと接続先のKDCエンドポイントを通知します。
Kerberosトークン・ポリシーが動作するためには、このファイルのlibdefaultsセクションで、次の3つの追加プロパティが指定されている必要があります。
default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
暗号スイートの順序は重要です。Keberosメッセージ保護が動作するためには、リストの先頭がdes3-cbc-sha1になっている必要があります。これは、Oracle WSMでは暗号化アルゴリズムTripleDESがサポートされていますが、プレーンDESはサポートされていないためです。
例9-1 サンプルのkrb5.confファイル
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = oracle.com
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
[realms]
oracle.com =
{kdc = someadminserver.com:88 admin_server = someadminserver.com:749
default_domain = us.oracle.com }
[domain_realm]
us.oracle.com = oracle.com
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam =
{ debug = false ticket_lifetime = 36000 renew_lifetime = 36000
forwardable = true krb4_convert = false }
Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。サービス・プリンシパル名の設定は、「プリンシパルの作成」で行います。
「構成」ページでservice.principal.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。デフォルト（プレースホルダ）値は、HOST/localhost@oracle.comです。
Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。サービス・プリンシパル名の設定は、「プリンシパルの作成」で行います。
設計時に構成のオーバーライドを使用し、次のようにサービス・プリンシパル名を指定します。
JAX-WS Clients: ((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants. WSSEC_KERBEROS_SERVICE_PRINCIPAL, SOAP/myhost.oracle.com@oracle.com);
正しいKDCに対してWebサービスを認証するように構成します。KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。
例9-1に、Webサービス・クライアント用のサンプルのKDC構成を示します。この例は、WebサービスのKDC構成にも適用されます。
正しいkeytabファイルを使用するには、次の作業を行います。
keytabファイルの抽出とインストール
krb5ログイン・モジュールの変更
これらの作業は、後続の項で説明されています。
KDCからサービス・プリンシパル・アカウントのキー表ファイル（キー・タブとも呼ばれる）を抽出し、Webサービス実装のホストとなるマシンにインストールします。
たとえば、kadmin.localなどのツールを使用し、次のようにサービス・プリンシパル名のキー・タブを抽出できます。
>kadmin.local>ktadd -k /tmp/krb5.keytab SOAP/myhost.oracle.com
keytabファイルを、Webサービスのホストとなるマシンにエクスポートします。キー・タブはバイナリ・ファイルです。これをFTPで転送する場合は、バイナリ・モードを使用してください。
「Configuring the SAML and Kerberos Login Modules」の説明に従って、WebサービスのKDCファイルの場所を識別するようにkrb5ログイン・モジュールを変更します。
たとえば、keytabファイルが/scratch/myhome/krb5.keytabにインストールされているとします。キー・タブとプリンシパルのプロパティを次のように変更します。
principal value=SOAP/myhost.oracle.com@oracle.com
useKeyTab value=true
storeKey value=true
keyTab value=/scratch/myhome/krb5.keytab
doNotPrompt value=true
Webサービス・ランタイムでは、Kerberosトークンの妥当性を確認できる必要があります。
トークンが有効の場合、Oracle Platform Security Services（OPSS）は、サービス・プリンシパルに対応するユーザーを、構成済のWebLogic Server認証プロバイダのいずれかに対して認証できる必要があります（認証プロバイダは、「WebLogic Serverへの認証プロバイダの構成」で説明されています）。
そのため、ユーザーは、認証プロバイダで使用されるアイデンティティ・ストアに存在し、有効になっている必要があります。
たとえば、SOAP/myhost.oracle.com@oracle.comなどのサービス・プリンシパルについて考えます。この例では、SOAP/myhost.oracle.comという名前のユーザーがアイデンティティ・ストアに存在する必要があります。@domainは、ユーザー・エンティティに含めないでください。
Webサービス・クライアントのチケット・キャッシュを作成するには、次の手順を実行します。
クライアント用に作成したユーザー・プリンシパルを使用して、Kerberosシステムにログインします。
>kinit fmwadmin welcome1
これにより、チケット認可チケットを含むファイルシステムにチケット・キャッシュが作成されます。このことを確認するには、次のコマンドを入力します。
>klist -e
次のような情報が表示されます。
Credentials cache: /tmp/krb5cc_36687
Default principal: fmwadmin@oracle.com, 1 entry found.
[1] Service Principal: krbtgt/oracle.com@oracle.com
Valid starting: Sep 28, 2007 17:20
Expires: Sep 29, 2007 17:20
Encryption type: DES3 CBC mode with SHA1-KD
暗号化タイプが前述の情報を反映していることを確認します。
Webサービス・クライアントを実行します。
別の方法として、最初にKerberosシステムにログインすることなく、Webサービス・クライアントを実行することもできます。Kerberosユーザー名とパスワードの入力を求められます。この場合、チケット・キャッシュはファイルシステムに作成されず、メモリーに保持されます。
Webサービス・クライアントとWebサービスにポリシーを添付する方法には、クライアントおよびサービスの設計時に行う方法と、デプロイ後に行う方法の2つがあります。
デプロイ後、Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAコンポジット、ADF、WebCenterアプリケーションにセキュリティ・ポリシーと管理ポリシーを添付します。この方法は、Webサービス・セキュリティをセキュリティ管理者の制御に移行するため、最も強力で柔軟性があります。
設計時は、Oracle JDeveloperにより、ADFおよびSOAクライアント・ポリシー添付が自動化されます。また、プログラムによってOracle WSMセキュリティおよび管理ポリシーをアプリケーションに添付することもできます。これを行うには、通常、Oracle JDeveloperなどの任意のIDEを使用します。
どちらの方法でも、クライアント側ポリシーは、Webサービスに関連付けられたポリシーと同等のものである必要があります。2つのファイルが異なり、各ファイルに含まれるアサーションの競合が発生している場合、Webサービスの操作を起動すると、エラーが返されます。
たとえば、oracle/wss_http_token_over_ssl_service_policyポリシーで相互認証が必要になる場合、クライアント・ポリシーを相互認証用に設定する必要もあります。
事前定義済ポリシーの場合、クライアントとWebサービスの両方が含まれます。新しいポリシーを作成する場合、「Webサービス・ポリシーの作成」の説明に従ってポリシーを生成すると、クライアント・ポリシーがサービス・ポリシーと連携する可能性が高くなります。
「オーバーライド可能なクライアント・ポリシーの添付」では、ポリシー構成のオーバーライド機能について説明しています。この機能では、ポリシーを添付するときに特定のWebサービス・クライアントの構成情報を指定できます。ただし、この構成情報を設計時にプログラムによってオーバーライドすることもできます。この項では、クライアントのプログラムによるオーバーライドについて説明します。
表9-2に、プログラムによる構成のオーバーライドを利用して特定のポリシーに設定できるプロパティを示します。例9-2に、プログラムからこれらのプロパティを設定する例を示します。
表9-2 プログラムによる構成のオーバーライドを利用して設定されるプロパティ
| プロパティのリスト | 説明 | 適用対象のポリシー |
|---|---|---|
|
oracle.wsm.sec |
クライアントで資格証明ストアが使用可能な場合に、資格証明ストアで指定されたcsf-keyに対応するユーザー名とパスワードを取得します。 |
oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss11_username_token_with_message_protection_client_policy oracle/wss_username_token_client_policy oracle/wss_username_token_over_ssl_client_policy oracle/wss_username_token_with_digestpassword_client_policy oracle/wss10_username_id_propagation_with_msg_protection_client_policy oracle/wss_http_token_client_policy oracle/wss_http_token_over_ssl_client_policy |
|
oracle.wsm.security.util.Sec |
このプロパティは、キーストア・ファイルの場所を設定します。この値を指定すると、静的に構成された値がオーバーライドされます。タイプ: java.lang.String |
oracle/wss10_message_protection_client_policy oracle/wss10_saml_hok_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_integrity_client_policy oracle/wss10_saml_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss10_x509_token_with_message_protection_client_policy oracle/wss11_kerberos_token_with_message_protection_client_policy oracle/wss11_message_protection_client_policy oracle/wss11_saml_token_with_message_protection_client_policy oracle/wss11_username_token_with_message_protection_client_policy oracle/wss11_x509_token_with_message_protection_client_policy |
|
oracle.wsm.security.util.Sec |
このプロパティは、キーストア・ファイルのタイプを設定します。この値を指定すると、静的に構成された値がオーバーライドされます。タイプ: java.lang.String デフォルトはJKSです。 |
oracle/wss10_message_protection_client_policy oracle/wss10_saml_hok_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_integrity_client_policy oracle/wss10_saml_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss10_x509_token_with_message_protection_client_policy oracle/wss11_kerberos_token_with_message_protection_client_policy oracle/wss11_message_protection_client_policy oracle/wss11_saml_token_with_message_protection_client_policy oracle/wss11_username_token_with_message_protection_client_policy oracle/wss11_x509_token_with_message_protection_client_policy |
|
oracle.wsm.sec |
このプロパティは、キーストア・ファイルのパスワードを設定します。この値を指定すると、静的に構成された値がオーバーライドされます。タイプ: java.lang.String |
oracle/wss10_message_protection_client_policy oracle/wss10_saml_hok_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_integrity_client_policy oracle/wss10_saml_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss10_x509_token_with_message_protection_client_policy oracle/wss11_kerberos_token_with_message_protection_client_policy oracle/wss11_message_protection_client_policy oracle/wss11_saml_token_with_message_protection_client_policy oracle/wss11_username_token_with_message_protection_client_policy oracle/wss11_x509_token_with_message_protection_client_policy |
|
oracle.wsm.sec |
このプロパティは、デジタル署名に使用されるキーストア内のキーの別名を設定します。この値を指定すると、静的に構成された値がオーバーライドされます。タイプ: java.lang.String WSS11ポリシーの場合、このプロパティは相互認証の場合にのみ使用されます。 |
oracle/wss10_message_protection_client_policy oracle/wss10_saml_hok_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_integrity_client_policy oracle/wss10_saml_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss10_x509_token_with_message_protection_client_policy oracle/wss11_kerberos_token_with_message_protection_client_policy oracle/wss11_message_protection_client_policy oracle/wss11_saml_token_with_message_protection_client_policy oracle/wss11_username_token_with_message_protection_client_policy oracle/wss11_x509_token_with_message_protection_client_policy |
|
oracle.wsm.sec |
このプロパティは、デジタル署名に使用されるキーストア内のキーの別名に対応するパスワードを設定します。この値を指定すると、静的に構成された値がオーバーライドされます。タイプ: java.lang.String WSS11ポリシーの場合、このプロパティは相互認証の場合にのみ使用されます。 |
oracle/wss10_message_protection_client_policy oracle/wss10_saml_hok_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_integrity_client_policy oracle/wss10_saml_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss10_x509_token_with_message_protection_client_policy oracle/wss11_kerberos_token_with_message_protection_client_policy oracle/wss11_message_protection_client_policy oracle/wss11_saml_token_with_message_protection_client_policy oracle/wss11_username_token_with_message_protection_client_policy oracle/wss11_x509_token_with_message_protection_client_policy |
|
oracle.wsm.sec |
このプロパティは、サービスからのレスポンスの復号化に使用されるキーストア内のキーの別名を設定します。この値を指定すると、静的に構成された値がオーバーライドされます。タイプ: java.lang.String WSS11ポリシーでは使用されません。 |
oracle/wss10_message_protection_client_policy oracle/wss10_saml_hok_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_integrity_client_policy oracle/wss10_saml_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss10_x509_token_with_message_protection_client_policy |
|
oracle.wsm.sec |
このプロパティは、復号化に使用されるキーストア内のキーのパスワードを設定します。この値を指定すると、静的に構成された値がオーバーライドされます。タイプ: java.lang.String WSS11ポリシーでは使用されません。 |
oracle/wss10_message_protection_client_policy oracle/wss10_saml_hok_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_integrity_client_policy oracle/wss10_saml_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss10_x509_token_with_message_protection_client_policy |
|
oracle.wsm.sec |
このプロパティは、アウトバウンド・メッセージ・タイプの暗号化に使用される受信者の公開鍵の別名を設定します。この値を指定すると、静的な構成値がオーバーライドされます。タイプ: java.lang.String |
oracle/wss10_message_protection_client_policy oracle/wss10_saml_hok_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_integrity_client_policy oracle/wss10_saml_token_with_message_protection_client_policy oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy oracle/wss10_username_token_with_message_protection_client_policy oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy oracle/wss10_x509_token_with_message_protection_client_policy oracle/wss11_kerberos_token_with_message_protection_client_policy oracle/wss11_message_protection_client_policy oracle/wss11_saml_token_with_message_protection_client_policy oracle/wss11_username_token_with_message_protection_client_policy oracle/wss11_x509_token_with_message_protection_client_policy |
|
oracle.wsm.sec |
SAMLクライアント・ポリシーの場合、サブジェクトではなく、クライアント指定のユーザー名を使用する必要があるときは、このプロパティをfalseに設定します。 |
「SAMLの構成」に示されているすべてのSAMLクライアント・ポリシーに適用されます。 |
|
oracle.wsm.sec |
このプロパティは、SAMLメカニズムを使用して保護されているサービスにアクセスしようとする場合に、SAML発行者名を設定します。この値を指定すると、静的な構成値がオーバーライドされます。タイプ: java.lang.String |
「SAMLの構成」に示されているすべてのSAMLクライアント・ポリシーに適用されます。 |
|
oracle.wsm.sec |
このプロパティは、SAMLアサーションのユーザー・ロールを設定します。 |
「SAMLの構成」に示されているすべてのSAMLクライアント・ポリシーに適用されます。 |
|
oracle.wsm.sec |
SAML HOKポリシーの場合、このファイルにはアサーションが含まれます。 |
「SAMLの構成」に示されているすべてのSAMLクライアント・ポリシーに適用されます。 |
|
oracle.wsm.sec |
このプロパティは、Kerberosメカニズムを使用して保護されているサービスにアクセスしようとする場合の、サービス・プリンシパル名を設定します。この値を指定すると、静的な構成値がオーバーライドされます。タイプ: java.lang.String |
oracle/wss11_kerberos_token_with_message_protection_client_policy |
例9-2に、キーストアとユーザー名またはパスワードをオーバーライドするWebサービス・クライアントの例を示します。
オーバーライドした構成プロパティをクリアするには、空の文字列を設定します。
クリアする前に、他のポリシーで同じプロパティを使用している可能性がないかを確認します。プロパティはクライアント固有ですが、同じプロパティを使用する同一クライアントに複数のポリシーが添付されている場合があります。
例9-2 キーストアとユーザー名またはパスワードのオーバーライド
package example;
import oracle.wsm.security.utils.SecurityConstants;
public class MyClientJaxWs {
public static void main(String[] args) {
try {
URL serviceWsdl = new URL("http://localhost/myApp/myPort?WSDL");
QName serviceName = new QName("MyNamespace", "MyService");
Service service = Service.create(serviceWsdl, serviceName);
MyInterface proxy = service.getPort(MyInterface.class);
RequestContext context = ((BindingProvider)proxy).getRequestContext();
context.put(oracle.webservices.ClientConstants.CLIENT_CONFIG, new File( "c:/dat/client-pdd.xml" ) );
context.put(BindingProvider.USERNAME_PROPERTY, getCurrentUsername() );
context.put(BindingProvider.PASSWORD_PROPERTY, getCurrentPassword() );
context.put(SecurityConstants.ClientConstants.WSS_KEYSTORE_LOCATION, "c:/mykeystore.jks");
context.put(SecurityConstants.ClientConstants.WSS_KEYSTORE_PASSWORD, "keystorepassword" );
context.put(SecurityConstants.ClientConstants.WSS_KEYSTORE_TYPE, "JKS" );
context.put(SecurityConstants.ClientConstants.WSS_SIG_KEY_ALIAS, "your signature alias" );
context.put(SecurityConstants.ClientConstants.WSS_SIG_KEY_PASSWORD, "your signature password" );
context.put(SecurityConstants.ClientConstants.WSS_ENC_KEY_ALIAS, "your encryption alias" );
context.put(SecurityConstants.ClientConstants.WSS_ENC_KEY_PASSWORD, "your encryption password" );
System.out.println(proxy.myOperation("MyInput"));
} catch (Exception e) {
e.printStackTrace();
}
}
}
例9-2では、参照されているc:/dat/client-pdd.xmlの内容は次のようになる場合があります。
! -- The contents of c:/dat/client-pdd.xml file mentioned above -- >
<oracle-webservice-clients>
<webservice-client>
<port-info>
<policy-references>
<policy-reference uri="management/Log_Msg_Policy" category="management"/>
<policy-reference uri="oracle/wss10_username_token_with_message_
protection_client_policy" category="security"/>
</policy-references>
</port-info>
</webservice-client>
</oracle-webservice-clients>
Oracle WSMでは、コンポジットからコンポジットを起動できるようにするSOAのローカルの最適化機能がサポートされています。この機能では、一方のコンポジットの参照でもう一方のコンポジットにバインディングするWebサービスを指定します。両方のコンポジットが同じコンテナで動作している必要があります。
図9-8に示されているように、ポリシーを作成または編集するときは、最適化コントロールを使用できます。また、このコントロールは次の場合に対応しています。
HTTPが呼び出されない
SOAPと正規化されたメッセージの変換が必要ない
Webサービスに添付されたポリシーがある場合、この最適化を使用すると、そのポリシーは起動されないことがあります。そのため、ポリシーごとに、ローカルの最適化を使用するかどうかを決定する必要があります。
「ローカルの最適化」コントロールには、「オン」、「オフ」、「アイデンティティの確認」の3つの設定があります。
オン: 最適化がオンになります。
オフ: 最適化がオフになります。リクエストは通常のWS/SOAP/HTTPプロセスに従って処理されます。
アイデンティティの確認: JAASサブジェクトが現在のスレッドにすでに存在し、認証がすでに成功したことを示している場合にのみ最適化します。存在しない場合は、通常のWS/SOAP/HTTPプロセスが実行されます。
表9-3に、事前定義済ポリシーを示し、各ポリシーがローカルの最適化機能を実装する方法について説明します。
表9-3 事前定義済ポリシーのデフォルトの最適化設定
| ポリシー名 | デフォルトの最適化設定 |
|---|---|
|
oracle/wsaddr_policy |
オン |
|
oracle/binding_authorization_denyall_policy |
常に「オフ」 |
|
oracle/binding_authorization_permitall_policy |
常に「オフ」 |
|
oracle/binding_permission_authorization_policy |
オフ |
|
oracle/component_authorization_denyall_policy |
常に「オフ」（バインディングには適用されません） |
|
oracle/component_authorization_permitall_policy |
常に「オフ」（バインディングには適用されません） |
|
oracle/component_permission_authorization_policy |
オフ |
|
oracle/log_policy |
オン |
|
oracle/wsmtom_policy |
オン |
|
oracle/wss_oam_token_client_policy |
常に「オフ」 |
|
oracle/wss_oam_token_service_policy |
常に「オフ」 |
|
oracle/wss_http_token_client_policy |
アイデンティティの確認 |
|
oracle/wss_http_token_service_policy |
アイデンティティの確認 |
|
oracle/wss_http_token_over_ssl_client_policy |
アイデンティティの確認 |
|
oracle/wss_http_token_over_ssl_service_policy |
アイデンティティの確認 |
|
oracle/wss11_kerberos_token_client_policy |
アイデンティティの確認 |
|
oracle/wss11_kerberos_token_service_policy |
アイデンティティの確認 |
|
oracle/wss_username_token_client_policy |
アイデンティティの確認 |
|
oracle/wss_username_token_service_policy |
アイデンティティの確認 |
|
oracle/wss_username_token_over_ssl_client_policy |
アイデンティティの確認 |
|
oracle/wss_username_token_over_ssl_service_policy |
アイデンティティの確認 |
|
oracle/wss10_message_protection_client_policy |
オン |
|
oracle/wss10_message_protection_service_policy |
オン |
|
oracle/wss10_username_token_with_message_protection_client_policy |
アイデンティティの確認 |
|
oracle/wss10_username_token_with_message_protection_service_policy |
アイデンティティの確認 |
|
oracle/wss10_x509_token_with_message_protection_client_policy |
アイデンティティの確認 |
|
oracle/wss10_x509_token_with_message_protection_service_policy |
アイデンティティの確認 |
|
oracle/wss10_saml_token_with_message_protection_client_policy |
アイデンティティの確認 |
|
oracle/wss10_saml_token_with_message_protection_service_policy |
アイデンティティの確認 |
|
oracle/wss10_saml_token_client_policy |
アイデンティティの確認 |
|
oracle/wss10_saml_token_service_policy |
アイデンティティの確認 |
|
oracle/wss10_username_id_propagation_with_msg_protection_client_policy |
アイデンティティの確認 |
|
oracle/wss10_username_id_propagation_with_msg_protection_service_policy |
アイデンティティの確認 |
|
oracle/wss11_message_protection_client_policy |
オン |
|
oracle/wss11_message_protection_service_policy |
オン |
|
oracle/wss11_username_token_with_message_protection_client_policy |
アイデンティティの確認 |
|
oracle/wss11_username_token_with_message_protection_service_policy |
アイデンティティの確認 |
|
oracle/wss11_x509_token_with_message_protection_client_policy |
アイデンティティの確認 |
|
oracle/wss11_x509_token_with_message_protection_service_policy |
アイデンティティの確認 |
|
oracle/wsrm10_policy |
オン |
|
oracle/wsrm11_policy |
オン |
付録B「事前定義済ポリシー」の表B-1に、認証のみを実行するセキュリティ・ポリシーをまとめ、トークンがトランスポート・レイヤーまたはSOAPヘッダーに組み込まれるかどうかを示します。
この項では、認証のみの事前定義済ポリシー、ポリシーが適用されるWebサービスのタイプ、およびポリシーを使用するために実行する必要がある構成手順へのリンクを示します。
oracle/wss_http_token_client_policyポリシーは、アウトバウンド・クライアント・リクエストのHTTPヘッダーに資格証明を含めます。このポリシーは、oracle/wss_http_token_service_policyサービス・エンドポイント・ポリシーに類似したクライアント・ポリシーです。
このポリシーには、oracle/wss_http_token_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_http_token_client_template」を参照してください。
「構成」ページでcsf-keyの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
この値は、ユーザー名/パスワードにマッピングされているキーを表しています。キーを資格証明ストアに追加する方法については、「資格証明ストア・プロバイダの構成」を参照してください。
「相互認証が必要」コントロールを設定しない場合、SSLは含まれません。「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
クライアントは、HTTPヘッダーに資格証明を渡す必要があります。
「相互認証が必要」コントロールを設定しない場合、SSLは含まれません。「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
このwss_http_token_service_policyでは、HTTPヘッダーの資格証明を使用して、ユーザーを認証します。
このポリシーには、oracle/wss_http_token_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_http_token_service_template」を参照してください。
Webサービスは、提供されたユーザー名とパスワードの資格証明を、構成済の認証ソースに対して認証する必要があります。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
相互SSL認証の場合、WebLogic Serverを構成する必要があります。「WebLogic ServerへのSSLの構成（双方向）」を参照してください。
oracle/wss_oam_token_client_policyポリシーは、バイナリ・セキュリティ・トークンの一部として、Oracle Access Managerの資格証明をWS-Securityヘッダーに挿入します。このポリシーは、oracle/wss_oam_token_service_policyサービス・エンドポイント・ポリシーに類似したクライアント・ポリシーです。
このポリシーには、oracle/wss_oam_token_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_oam_token_client_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、Webサーバーは、Webサービスへのすべてのリクエストに対するリバース・プロキシとして使用されます。リバース・プロキシWebサーバーのWebGateは、すべてのリクエストをインターセプトし、（OAMで構成された認証スキームに応じて）Webサービス・クライアント・ユーザーの資格証明を要求し、ユーザーを認証します。推奨される認証スキームは、FORMログインです。
そのため、Webサービス・クライアントは、要求に応じてユーザー名とパスワードの資格証明を提供する必要があります。
このポリシーは、WS-Securityヘッダーのバイナリ・セキュリティ・トークンの資格証明を使用して、Oracle Access Managerアイデンティティ・ストアに対してユーザーを認証します。このポリシーは、SOAPベースのエンドポイントで実行できます。
このポリシーには、oracle/wss_oam_token_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_oam_token_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAMIdentityAsserterタイプのプロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
OAM IDアサーション・プロバイダは、提供されたObssoCookieトークンを検証します。
このプロバイダをIDアサーション用に構成する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証およびIDアサーション・プロバイダの構成に関する項を参照してください。
このポリシーは、すべてのアウトバウンドSOAPリクエスト・メッセージにWS-Security UsernameTokenヘッダーの資格証明を含めます。プレーン・テキスト・メカニズムがサポートされています。また、パスワードは必要ありません。このポリシーは、oracle/wss_username_token_service_policyサービス・エンドポイント・ポリシーに類似したクライアント・ポリシーです。
このポリシーには、oracle/wss_username_token_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_username_token_client_template」を参照してください。
「構成」ページでcsf-keyの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
この値は、ユーザー名/パスワードにマッピングされているキーを表しています。キーを資格証明ストアに追加する方法については、「資格証明ストア・プロバイダの構成」を参照してください。
「設定」ページでパスワード・タイプを「なし」に指定した場合、キーにパスワードを含める必要はありません。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
クライアントは、SOAPリクエスト・メッセージにWS-Security UsernameToken要素（<wsse:UsernameToken/>）を含める必要があります。また、クライアントは、認証用にユーザー名とパスワードを提供します。
このポリシーは、UsernameToken WS-Security SOAPヘッダーの資格証明を使用してユーザーを認証します。プレーン・テキスト・メカニズムがサポートされています。
このポリシーには、oracle/wss_username_token_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_username_token_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
このポリシーには、アウトバウンドSOAPリクエスト・メッセージのSAMLトークンが含まれます。
このポリシーには、oracle/wss10_saml_token_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_token_client_template」を参照してください。
「SAMLの構成」を参照してください。
オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。saml.issuer.nameプロパティのデフォルトは、www.oracle.comという値です。詳細は、「SAMLアサーション発行者名の変更」を参照してください。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
アウトバウンドSOAPメッセージに、SAMLトークンを挿入するWS-Securityヘッダー要素（<saml:Assertion>）を含めます。確認タイプは、常にsender-vouchesです。
このポリシーは、WS-Security SOAPヘッダーのSAMLトークンに含まれる資格証明を使用してユーザーを認証します。
このポリシーには、oracle/wss10_saml_token_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_token_service_template」を参照してください。
saml.loginmoduleログイン・モジュールを構成します。詳細は、「SAMLおよびKerberosログイン・モジュールの構成」を参照してください。
Oracle Platform Security Services（OPSS）の設定方法
「SAMLの構成」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
このポリシーでは、WS-Security Kerberos Token Profile v1.1標準に従い、WS-SecurityヘッダーにKerberosトークンが含まれます。
サービス・プリンシパル名（SPN）は、Kerberos認証のキー・コンポーネントです。SPNは、サーバー上で動作するサービスの一意の識別子です。Kerberos認証を使用するすべてのサービスにSPNを設定し、クライアントがネットワーク上のサービスを識別できるようにする必要があります。サービスにSPNが設定されていない場合、クライアントではそのサービスを特定できないため、Kerberos認証を使用できなくなります。
このポリシーには、oracle/wss11_kerberos_token_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_kerberos_token_with_message_protection_client_template」を参照してください。
Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。「構成」ページでservice.principal.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。デフォルト値（プレースホルダ）は、HOST/localhost@oracle.comです。
このポリシーは、WS-Security Kerberos Token Profile v1.1標準に従って実行されます。
サービス・プリンシパル名（SPN）は、Kerberos認証のキー・コンポーネントです。SPNは、サーバー上で動作するサービスの一意の識別子です。Kerberos認証を使用するすべてのサービスにSPNを設定し、クライアントがネットワーク上のサービスを識別できるようにする必要があります。サービスにSPNが設定されていない場合、クライアントではそのサービスを特定できないため、Kerberos認証を使用できなくなります。
このポリシーには、oracle/wss11_kerberos_token_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_kerberos_token_with_message_protection_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
事前定義済ポリシーによるメッセージ保護の実装方法については、「メッセージの保護」を参照してください。
表B-2に、メッセージ保護のみを実行するポリシーをまとめ、ポリシーがトランスポート・レイヤーまたはSOAPヘッダーで実行されるかどうかを示します。
メッセージ保護のみのポリシーは、リクエスタの認証または認可を行いません。
ポリシー・サブジェクトに添付されるセキュリティ・ポリシーは1つまたは2つです。セキュリティ・ポリシーに含めることができるのは、（このケースでは）認証またはメッセージ保護のサブタイプ・カテゴリに属するアサーションか、両方のサブタイプ・カテゴリに属する1つのアサーションです。また、認可サブタイプに属するアサーションを使用して、リクエスタを認可できます。
このポリシーは、WS-Security 1.0標準に従って、アウトバウンドSOAPリクエストのメッセージ保護（整合性と機密保護）を行います。
このポリシーには、oracle/wss10_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_message_protection_client_policy」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-3 SOAPメッセージのWS-Security 1.0メッセージ整合性
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI="#Timestamp-...">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>...</dsig:DigestValue>
</dsig:Reference>
<dsig:Reference URI="#Body-...">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>...</dsig:DigestValue>
</dsig:Reference>
<dsig:Reference URI="#KeyInfo-...">
<dsig:Transforms>
<dsig:Transform
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-se
curity-1.0#STR-Transform">
<TransformationParameters
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1
.0.xsd">
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
xmlns="http://www.w3.org/2000/09/xmldsig#"/>
</TransformationParameters>
</dsig:Transform>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>...</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>....</dsig:SignatureValue>
<dsig:KeyInfo Id="KeyInfo-...">
<wsse:SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1
.0.xsd">
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-prof
ile-1.0#X509SubjectKeyIdentifier"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-
security-1.0#Base64Binary">
...</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
例9-4 SOAPメッセージのWS-Security 1.0メッセージ機密保護
<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-util
ity-1.0.xsd" wsu:Id="Body-JA9fsCRnqbFJ0ocBAMKb7g22">
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Content" Id="...">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>...</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</env:Body>
このポリシーは、WS-Security 1.0標準に従って、インバウンドSOAPリクエストのメッセージ保護（整合性と機密保護）を実行します。
メッセージは、WS-Securityの非対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、メッセージ機密保護にはRSA鍵メカニズム、メッセージ整合性にはSHA-1ハッシュ・アルゴリズムが使用され、AES-128ビット暗号化も使用されます。このポリシーは、リクエスタの認証または認可を行いません。
このポリシーには、oracle/wss10_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_message_protection_service_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
このポリシーは、WS-Security 1.1標準に従って、アウトバウンドSOAPリクエストのメッセージの整合性と機密保護を提供します。
このポリシーには、oracle/wss11_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_message_protection_client_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
このポリシーは対称鍵テクノロジを使用します。このテクノロジは、データの暗号化と復号化に同じ共有鍵を使用する暗号化メソッドです。対称鍵は、メッセージへの署名に使用されます。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-5に、WS-Security 1.1標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
例9-5 SOAPメッセージのWS-Security 1.1メッセージ機密保護
<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="EK-...">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" />
</xenc:EncryptionMethod>
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.
0.xsd">
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#Thum
bprintSHA1"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-
security-1.0#Base64Binary">...</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>...</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#_..." />
</xenc:ReferenceList>
</xenc:EncryptedKey>
<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Body-...">
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Content" Id="...">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd"
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:Reference URI="#EK-..." ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-
security-1.1#EncryptedKey" />
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>...</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</env:Body>
このポリシーは、WS-Security 1.1標準に従って、インバウンドSOAPリクエストのメッセージの整合性と機密保護を保証します。
このポリシーには、oracle/wss11_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_message_protection_service_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
表B-3に、メッセージ保護および認証の両方を実行するポリシーをまとめ、ポリシーがトランスポート・レイヤーまたはSOAPヘッダーで実行されるかどうかを示します。これらのポリシーは、後続の項で説明されています。
事前定義済ポリシーによるメッセージ保護の実装方法については、「メッセージの保護」を参照してください。
このポリシーは、アウトバウンド・クライアント・リクエストのHTTPヘッダーに資格証明を含めます。
また、このポリシーは、トランスポート・プロトコルがHTTPSであることを検証します。HTTPS以外のトランスポート・プロトコルを介するリクエストは拒否されます。このポリシーは、HTTPベースのすべてのエンドポイントに適用できます。
|
注意: 現在サポートされているのはHTTP Basic認証のみです。 |
このポリシーには、oracle/wss_http_token_over_ssl_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_http_token_over_ssl_client_template」を参照してください。
「構成」ページでcsf-keyの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
この値は、ユーザー名/パスワードにマッピングされているキーを表しています。キーを資格証明ストアに追加する方法については、「資格証明ストア・プロバイダの構成」を参照してください。
「相互認証が必要」コントロールを設定しない場合、一方向SSLが含まれます。「Webサービス・クライアントに関するSSLの構成」を参照してください。
「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
クライアントは、HTTPヘッダーに資格証明を渡す必要があります。
「相互認証が必要」コントロールを設定しない場合、一方向SSLが含まれます。「Webサービス・クライアントに関するSSLの構成」を参照してください。
「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
このポリシーは、HTTPヘッダーの資格証明を抽出し、ユーザーを認証します。
このポリシーは、トランスポート・プロトコルがHTTPSであることを検証します。HTTPS以外のトランスポート・プロトコルを介するリクエストは拒否されます。このポリシーは、HTTPベースのすべてのエンドポイントに適用できます。
|
注意: 現在サポートされているのはHTTP Basic認証のみです。 |
このポリシーには、oracle/wss_http_token_over_ssl_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_http_token_over_ssl_service_template」を参照してください。
「WebLogic ServerへのSSLの構成（一方向）」の説明に従ってSSLを構成します。ただし、「相互認証を許可」がオンの場合は、「WebLogic ServerへのSSLの構成（双方向）」の説明に従ってSSLを構成します。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
このポリシーには、アウトバウンドSOAPリクエスト・メッセージのSAMLトークンが含まれます。確認方法がBearerのSAMLトークンが自動的に作成されます。
このポリシーには、oracle/wss_saml_token_bearer_over_ssl_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_saml_token_bearer_over_ssl_client_template」を参照してください。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
「Webサービス・クライアントに関するSSLの構成」で説明されているように、「相互認証が必要」コントロールを設定しない場合、一方向SSLが含まれます。
「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
「Webサービス・クライアントに関するSSLの構成」で説明されているように、「相互認証が必要」コントロールを設定しない場合、一方向SSLが含まれます。
「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
このポリシーは、WS-Security SOAPヘッダーの、確認方法がBearerのSAMLトークンに含まれる資格証明を使用してユーザーを認証します。
このポリシーには、oracle/wss_saml_token_bearer_over_ssl_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_saml_token_bearer_over_ssl_service_template」を参照してください。
「SAMLの構成」を参照してください。
WebLogic Serverの設定方法
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
SSLを構成するには、「WebLogic ServerへのSSLの構成（一方向）」を参照してください。ただし、「相互認証が必要」がオンの場合は、「WebLogic ServerへのSSLの構成（双方向）」を参照してください。
このポリシーは、WS-Security SOAPヘッダーのSAMLトークンに含まれる資格証明の認証を可能にします。
このポリシーには、oracle/wss_saml_token_over_ssl_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_saml_token_over_ssl_client_template」を参照してください。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
「Webサービス・クライアントに関するSSLの構成」で説明されているように、「相互認証が必要」コントロールを設定しない場合、一方向SSLが含まれます。
「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
「Webサービス・クライアントに関するSSLの構成」で説明されているように、「相互認証が必要」コントロールを設定しない場合、一方向SSLが含まれます。
「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
このポリシーは、WS-Security SOAPヘッダーのSAMLトークンに含まれる資格証明の認証を実行します。
このポリシーには、oracle/wss_saml_token_over_ssl_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_saml_token_over_ssl_service_template」を参照してください。
saml.loginmoduleログイン・モジュールを構成します。詳細は、「SAMLおよびKerberosログイン・モジュールの構成」を参照してください。
Oracle Platform Security Services（OPSS）の設定方法
「SAMLの構成」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
SSLを構成するには、「WebLogic ServerへのSSLの構成（一方向）」を参照してください。ただし、「相互認証が必要」がオンの場合は、「WebLogic ServerへのSSLの構成（双方向）」を参照してください。
このポリシーは、アウトバウンドSOAPリクエスト・メッセージにWS-Security UsernameTokenヘッダーの資格証明を含めます。プレーン・テキスト・メカニズムがサポートされています。また、このポリシーは、トランスポート・レイヤー・セキュリティを実現するためにSSLを使用します。
このポリシーには、oracle/wss_username_token_over_ssl_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_username_token_over_ssl_client_template」を参照してください。
「Webサービス・クライアントに関するSSLの構成」で説明されているように、「相互認証が必要」コントロールを設定しない場合、一方向SSLが含まれます。
「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
「構成」ページでcsf-keyの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
この値は、ユーザー名/パスワードにマッピングされているキーを表しています。キーを資格証明ストアに追加する方法については、「資格証明ストア・プロバイダの構成」を参照してください。
「設定」ページでパスワード・タイプを「なし」に指定した場合、キーにパスワードを含める必要はありません。
クライアントは、SOAPリクエスト・メッセージにWS-Security UsernameToken要素（<wsse:UsernameToken/>）を含める必要があります。また、クライアントは、認証用にユーザー名とパスワードを提供します。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
「相互認証が必要」コントロールを設定しない場合、一方向SSLが含まれます。「Webサービス・クライアントに関するSSLの構成」を参照してください。
「相互認証が必要」コントロールを設定しない場合、クライアントは資格証明を提供し、Webサービスから返される資格証明を受信する必要があります。「Webサービス・クライアントに関する双方向SSLの構成」を参照してください。
このポリシーは、UsernameToken WS-Security SOAPヘッダーの資格証明を使用してユーザーを認証します。プレーン・テキスト・メカニズムがサポートされています。
このポリシーには、oracle/wss_username_token_over_ssl_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss_username_token_over_ssl_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
ユーザー名とパスワードが存在し、有効になっている必要があります。
SSLを構成するには、「WebLogic ServerへのSSLの構成（一方向）」を参照してください。ただし、「相互認証が必要」がオンの場合は、「WebLogic ServerへのSSLの構成（双方向）」を参照してください。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.0標準に従ったアウトバウンドSOAPメッセージのSAML鍵所有者ベースの認証を行います。
このポリシーには、oracle/wss10_saml_hok_with_message_integrity_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_hok_with_message_protection_service_template」を参照してください。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
鍵所有者アサーションを含むファイルを指し示すように、saml.assertion.filenameプロパティをオーバーライドします。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
鍵所有者アサーションを含むファイルを指し示すように、saml.assertion.filenameプロパティをオーバーライドします。オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.0標準に従ったインバウンドSOAPリクエストのSAML鍵所有者ベースの認証を行います。
このポリシーには、oracle/wss10_saml_hok_with_message_integrity_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_hok_with_message_protection_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
Oracle Platform Security Services（OPSS）の設定方法
「SAMLの構成」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
SAML認証局の信頼できる証明書をキーストアに格納します。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
このポリシーは、メッセージ・レベルの整合性と、WS-Security 1.0標準に従ったアウトバウンドSOAPメッセージのSAMLベースの認証を実現します。
このポリシーには、oracle/wss10_saml_token_with_message_integrity_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_token_with_message_protection_client_template」を参照してください。
「SAMLの構成」を参照してください。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。saml.issuer.nameプロパティのデフォルトは、www.oracle.comという値です。詳細は、「SAMLアサーション発行者名の変更」を参照してください。
「構成」ページでuser.roles.includeの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
アウトバウンドSOAPメッセージに、SAMLトークンを挿入するWS-Securityヘッダー要素（<saml:Assertion>）を含めます。確認タイプは、常にsender-vouchesです。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの整合性の保護と、WS-Security 1.0標準に従ったインバウンドSOAPリクエストのSAMLベースの認証を行います。
このポリシーには、oracle/wss10_saml_token_with_message_integrity_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_token_with_message_protection_service_template」を参照してください。
saml.loginmoduleログイン・モジュールを構成します。詳細は、「SAMLおよびKerberosログイン・モジュールの構成」を参照してください。
Oracle Platform Security Services（OPSS）の設定方法
「SAMLの構成」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.0標準に従ったアウトバウンドSOAPメッセージのSAMLベースの認証を行います。
このポリシーには、oracle/wss10_saml_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_token_with_message_protection_client_template」を参照してください。
「SAMLの構成」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。
オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。saml.issuer.nameプロパティのデフォルトは、www.oracle.comという値です。詳細は、「SAMLアサーション発行者名の変更」を参照してください。
「構成」ページでuser.roles.includeの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.0標準に従ったインバウンドSOAPリクエストのSAMLベースの認証を行います。
このポリシーには、oracle/wss10_saml_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_token_with_message_protection_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
Oracle Platform Security Services（OPSS）の設定方法
「SAMLの構成」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.0標準に従ったアウトバウンドSOAPメッセージのSAMLベースの認証を行います。
このポリシーは、リクエスト内の暗号化キーと、レスポンス内の署名と暗号化キーの両方に対して、サブジェクト・キー識別子（ski）参照メカニズムを使用します。
このポリシーには、oracle/wss10_saml_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_token_with_message_protection_client_template」を参照してください。
「SAMLの構成」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。
オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。saml.issuer.nameプロパティのデフォルトは、www.oracle.comという値です。詳細は、「SAMLアサーション発行者名の変更」を参照してください。
「構成」ページでuser.roles.includeの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.0標準に従ったインバウンドSOAPリクエストのSAMLベースの認証を行います。
このポリシーは、リクエスト内の暗号化キーと、レスポンス内の署名と暗号化キーの両方に対して、サブジェクト・キー識別子（ski）参照メカニズムを使用します。
このポリシーには、oracle/wss10_saml_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_saml_token_with_message_protection_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
Oracle Platform Security Services（OPSS）の設定方法
「SAMLの構成」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、キーストアを設定する必要があります。ski参照メカニズムを使用するときは、OpenSSLなどのユーティリティを使用して証明書を作成します。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
このポリシーは、メッセージ・レベルの保護（整合性と機密保護）、およびWS-Security 1.0標準に従ったアウトバウンドSOAPリクエストのアイデンティティ伝播を行います。
このポリシーには、oracle/wss10_username_id_propagation_with_msg_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_username_token_with_message_protection_client_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
クライアントは、SOAPリクエスト・メッセージにWS-Security UsernameToken要素（<wsse:UsernameToken/>）を含める必要があります。また、クライアントは、認証用にユーザー名とパスワードを提供します。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護（整合性と機密保護）、およびWS-Security 1.0で記述されるメカニズムを使用してインバウンドSOAPリクエストへのアイデンティティ伝播を行います。
このポリシーには、oracle/wss10_username_id_propagation_with_msg_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_username_token_with_message_protection_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
Oracle Platform Security Services（OPSS）の設定方法
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
このポリシーは、メッセージ・レベルの保護（メッセージの整合性と機密保護）、およびWS-Security 1.0標準に従ったアウトバウンドSOAPリクエストの認証を行います。
このポリシーには、oracle/wss10_username_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_username_token_with_message_protection_client_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。
「構成」ページでcsf-keyの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
この値は、ユーザー名/パスワードにマッピングされているキーを表しています。キーを資格証明ストアに追加する方法については、「資格証明ストア・プロバイダの構成」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護（メッセージの整合性と機密保護）、およびWS-Security 1.0標準に従ったインバウンドSOAPリクエストの認証を行います。
このポリシーには、oracle/wss10_username_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_username_token_with_message_protection_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
Oracle Platform Security Services（OPSS）の設定方法
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
このポリシーは、メッセージ・レベルの保護（メッセージの整合性と機密保護）、およびWS-Security 1.0標準に従ったアウトバウンドSOAPリクエストの認証を行います。
このポリシーは、リクエスト内の暗号化キーと、レスポンス内の署名と暗号化キーの両方に対して、サブジェクト・キー識別子（ski）参照メカニズムを使用します。
このポリシーには、oracle/wss10_username_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_username_token_with_message_protection_client_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。
「構成」ページでcsf-keyの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
この値は、ユーザー名/パスワードにマッピングされているキーを表しています。キーを資格証明ストアに追加する方法については、「資格証明ストア・プロバイダの構成」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護（メッセージの整合性と機密保護）、およびWS-Security 1.0標準に従ったインバウンドSOAPリクエストの認証を行います。
このポリシーは、リクエスト内の暗号化キーと、レスポンス内の署名と暗号化キーの両方に対して、サブジェクト・キー識別子（ski）参照メカニズムを使用します。
このポリシーには、oracle/wss10_username_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_username_token_with_message_protection_service_template」を参照してください。
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
Oracle Platform Security Services（OPSS）の設定方法
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、キーストアを設定する必要があります。ski参照メカニズムを使用するときは、OpenSSLなどのユーティリティを使用して証明書を作成します。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.0標準に従ったアウトバウンドSOAPリクエストへの資格証明移入の認証を行います。
このポリシーには、oracle/wss10_x509_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_x509_token_with_message_protection_client_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
Webサービス・クライアントは、WS-Securityバイナリ・セキュリティ・トークンを介してSOAPメッセージに有効なX.509認証資格証明を提供する必要があります。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-3に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている署名の一般的な構造を示します。この例では、SOAPメッセージの本体要素が署名されています。
例9-4に、WS-Security 1.0標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.0標準に従ったインバウンドSOAPリクエストへの証明書ベースの認証を行います。
このポリシーには、oracle/wss10_x509_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss10_x509_token_with_message_protection_service_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
WebLogic Serverの設定方法
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、OAM認証プロバイダまたは他の認証プロバイダを構成し、このプロバイダにX.509コールバック情報を確実に提供する必要があります。
このポリシーにはWS-SecurityヘッダーのKerberosトークンが含まれ、WS-Security Kerberos Token Profile v1.1標準に従い、Kerberosキーを使用してメッセージの整合性と機密保護を保証します。
このポリシーには、oracle/wss11_kerberos_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_kerberos_token_with_message_protection_client_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「Kerberosトークンの使用」も参照してください。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。
「Kerberosトークンの使用」も参照してください。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-5に、WS-Security 1.1標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、WS-Security Kerberos Token Profile v1.1標準に従って実行されます。
このポリシーには、oracle/wss11_kerberos_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_kerberos_token_with_message_protection_service_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
「Kerberosトークンの使用」の説明に従って、Kerberosを構成します。
WebLogic Serverの設定方法
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.1で記述されたメカニズムを使用したアウトバウンドSOAPリクエストへのSAMLトークンの移入を行います。
このポリシーには、oracle/wss11_saml_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_saml_token_with_message_protection_client_template」を参照してください。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。
オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。saml.issuer.nameプロパティのデフォルトは、www.oracle.comという値です。詳細は、「SAMLアサーション発行者名の変更」を参照してください。
「構成」ページでuser.roles.includeの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
「設計時のSAML Webサービス・クライアントの設定」を参照してください。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-5に、WS-Security 1.1標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの整合性の保護と、WS-Security 1.0標準に従ったインバウンドSOAPリクエストのSAMLベースの認証を行います。
このポリシーには、oracle/wss11_saml_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_saml_token_with_message_protection_service_template」を参照してください。
「SAMLの構成」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
WebLogic Serverの設定方法
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
SAMLログイン・モジュールは、検証されたトークンからユーザー名を抽出し、（NameCallbackを介して）OAM認証プロバイダまたは他のプロバイダに渡します。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.1標準に従ったアウトバウンドSOAPリクエストの認証を行います。
このポリシーには、oracle/wss11_username_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_username_token_with_message_protection_client_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
このポリシーは対称鍵テクノロジを使用します。このテクノロジは、データの暗号化と復号化に同じ共有鍵を使用する暗号化メソッドです。対称鍵は、メッセージへの署名に使用されます。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
例9-5に、WS-Security 1.1標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護（メッセージ整合性とメッセージ機密保護）、およびWS-Security 1.1標準に従ったインバウンドSOAPリクエストの認証を行います。
このポリシーには、oracle/wss11_username_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_username_token_with_message_protection_service_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
WebLogic Serverの設定方法
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、WebLogic Server管理コンソールを使用して、OAM認証プロバイダ・タイプの認証プロバイダや他の認証プロバイダを、WebサービスがデプロイされているWebLogicドメインのアクティブなセキュリティ・レルムに追加します。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.1標準に従ったアウトバウンドSOAPリクエストの証明書ベースの認証を行います。
このポリシーには、oracle/wss11_x509_token_with_message_protection_client_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_x509_token_with_message_protection_client_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、Webサービス・キーストアを設定する必要があります。
このポリシーでは、「設計時のWebサービス・クライアント・キーストアの設定」で説明されているように、Webサービス・クライアント・キーストアを設定する必要があります。このポリシーでは特に、クライアントとWebサービスそれぞれのキーストアに、お互いの公開鍵を含むデジタル証明書がすでに含まれている必要があります。
Webサービス・クライアントは、WS-Securityバイナリ・セキュリティ・トークンを介してSOAPメッセージに有効なX.509認証資格証明を提供する必要があります。
オーバーライド可能な構成設定については、「クライアントのプログラムによる構成のオーバーライド」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
例9-5に、WS-Security 1.1標準に準拠し、セキュリティ・ヘッダーに含まれている暗号化要素の一般的な構造の例を示します。この例では、本体要素が暗号化されています。
このポリシーは、メッセージ・レベルの保護と、WS-Security 1.1標準に従ったインバウンドSOAPリクエストへの証明書ベースの認証を行います。
このポリシーには、oracle/wss11_x509_token_with_message_protection_service_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/wss11_x509_token_with_message_protection_service_template」を参照してください。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
このポリシーでは、「メッセージ保護に関するキーストアの設定」で説明されているように、キーストアを設定する必要があります。
（メッセージへの署名に使用される）クライアントの公開鍵に対応する信頼できる証明書をキーストアに格納します。また、メッセージを復号化するためにキーストアにサービスの公開鍵を格納し、さらにCAルート証明書も格納する必要があります。
「資格証明ストア・プロバイダの構成」で説明されているように、資格証明ストアには復号化キーのパスワードを格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
WebLogic Serverの設定方法
「WebLogic Serverへの認証プロバイダの構成」で説明されているように、OAM認証プロバイダまたは他の認証プロバイダを構成し、このプロバイダにX.509コールバック情報を確実に提供する必要があります。
多くの場合、ユーザーにWebサービスへのアクセスを許可するかどうかを決定する最初の手順は認証です。ユーザーが認証されたら、2番目の手順は、ユーザーがWebサービスへのアクセスを認可されていることを検証することです。これは、認可ポリシーを使用して実行されます。binding_authorization_templateまたはcomponent_authorization_templateアサーション・テンプレートを使用して、認可ポリシーを作成できます。
これらのテンプレートを使用して作成されたポリシーでは、ロール・ベースまたは権限ベースのアクセス制御（RBAC）が実行され、認証されたユーザーにWebサービスへのアクセスが許可されたいずれかのロールまたは権限が付与されていることが確認されます。
「事前定義済ポリシー」に、認可を実行するセキュリティ・ポリシーをまとめ、ポリシーがトランスポート・レイヤーまたはSOAPヘッダーで実行されるかどうかを示します。
|
注意: 認可ポリシーは、サブジェクトが作成されている任意の認証ポリシーの後に続けることができます。permitallおよびdenyallポリシーの両方を同じWebサービスに添付することはできません。 |
認可ポリシーには、ポリシーで保護するリソースを指定するために使用できる次のプロパティがあります。すべての事前定義済ポリシーにすべてのプロパティを設定できるとはかぎりません。
制約パターン: 今後の使用のために予約済。
アクション・パターン: 権限ベースの確認が実行されるWebサービス操作。この値は、値のカンマ区切りのリストにすることもできます。このフィールドではワイルドカードを使用できます。*は、すべてのWebサービス操作を意味します。
「アクション・パターン」の有効な値は、Webサービス・メソッドで決まります。たとえば、Webサービス・メソッドがvalidate(amountAvailable)の場合は、アクション・パターンをvalidate,amountAvailableと入力します。
リソース・パターン: 権限ベースの確認が実行されるリソースの名前。このフィールドではワイルドカードを使用できます。デフォルトは*で、ポリシーによって保護されるWebサービスのすべてのリソースに対応します。
表記規則により、リソース・パターンを（Webサービスの名前空間+ Webサービス名）として入力します。
たとえば、Webサービスの名前空間がhttp://project11で、Webサービス名がCreditValidationの場合、リソース名をhttp://project11/CreditValidationと入力します。
特定のリソース・パターンを指定した場合、ポリシーは、基準と一致するWebサービスに対してのみ実行されます。つまり、特定のリソース・パターンを入力すると、認可ポリシーのスコープが制限されます。この条件は、この認可ポリシーを複数のサブジェクトに一括添付した場合にも適用されます。デフォルトの*により、一括添付されたWebサービスのすべてのリソース（Webサービスの名前空間+ Webサービス名）が保護されます。
権限チェック・クラス: デフォルトでは、oracle.wsm.security.WSFunctionPermissionになっています。クラスは、クラスパスに存在する必要があります。
認証設定: 使用可能な値は、「すべてを許可」、「すべてを拒否」および「選択したロール」です。「選択したロール」を選択した場合、WebLogic Serverで定義されたエンタープライズ（グローバル）ロールのいずれかを選択する必要があります。このロールには、次のものがあります。
AdminChannelUser
Anonymous
AppTester
CrossDomainConnector
Deployer
Monitor
Operator
OracleSystemRole
このポリシーは、認証されたサブジェクトに基づき、簡単なロールベースの認可ポリシーを提供します。
このポリシーは、ロールを持つすべてのユーザーを拒否します。
このポリシーは、サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダの構成に関する項で説明されているように、WebLogic認証プロバイダがすでに構成されている必要があります。
このポリシーには、oracle/binding_authorization_templateポリシー・アサーションが含まれています。
このアサーションの詳細は、「oracle/binding_authorization_template」を参照してください。
表C-57を参照してください。
ロールを追加するには、次のようにします。
「追加」をクリックします。
ロールを追加するには、「使用可能なロール」列の追加する各ロールの隣にあるチェック・ボックスをクリックし、「移動」をクリックします。すべてのロールを追加するには、「すべて移動」をクリックします。
ロールを削除するには、「追加対象として選択したロール」列の削除する各ロールの隣にあるチェック・ボックスをクリックし、「削除」をクリックします。すべてのロールを削除するには、「すべて削除」をクリックします。
ロールを検索するには、「ロール名」検索ボックスに検索文字列を入力して、実行の矢印をクリックします。検索文字列に一致するロールのみが含まれるように、「使用可能なロール」列が更新されます。
「OK」をクリックします。
ロールを削除するには、次のようにします。
「選択したロール」リストで削除するロールを選択します。
「削除」をクリックします。
1つ以上のWebLogic Serverエンタープライズ・ロールを指定する場合、認証されたサブジェクトにそのロールがすでに付与されている必要があります。Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプで説明されているように、WebLogic Server管理コンソールを使用して、ロールをユーザーまたはグループに付与します。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダの構成に関する項で説明されているように、WebLogic認証プロバイダを構成する必要があります。
このポリシーは、認証されたサブジェクトに基づき、簡単なロールベースの認可ポリシーを提供します。
このポリシーは、ロールを持つすべてのユーザーを許可します。
このポリシーは、サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダの構成に関する項で説明されているように、WebLogic認証プロバイダがすでに構成されている必要があります。
このポリシーには、oracle/binding_authorization_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/binding_authorization_template」を参照してください。
表C-57を参照してください。
ロールを追加するには、次のようにします。
「追加」をクリックします。
ロールを追加するには、「使用可能なロール」列の追加する各ロールの隣にあるチェック・ボックスをクリックし、「移動」をクリックします。すべてのロールを追加するには、「すべて移動」をクリックします。
ロールを削除するには、「追加対象として選択したロール」列の削除する各ロールの隣にあるチェック・ボックスをクリックし、「削除」をクリックします。すべてのロールを削除するには、「すべて削除」をクリックします。
ロールを検索するには、「ロール名」検索ボックスに検索文字列を入力して、実行の矢印をクリックします。検索文字列に一致するロールのみが含まれるように、「使用可能なロール」列が更新されます。
「OK」をクリックします。
ロールを削除するには、次のようにします。
「選択したロール」リストで削除するロールを選択します。
「削除」をクリックします。
1つ以上のWebLogic Serverエンタープライズ・ロールを指定する場合、認証されたサブジェクトにそのロールがすでに付与されている必要があります。Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプで説明されているように、WebLogic Server管理コンソールを使用して、ロールをユーザーまたはグループに付与します。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダの構成に関する項で説明されているように、WebLogic認証プロバイダを構成する必要があります。
このポリシーは、認証されたサブジェクトに基づき、権限ベースの認可ポリシーを提供します。
このポリシーは、サブジェクトに操作を実行する権限があることを保証します。このため、認可ポリシー・エグゼキュータはOPSSを利用し、認証されたサブジェクトに、パラメータとして「リソース・パターン」と「アクション・パターン」を使用してoracle.wsm.security.WSFunctionPermission（または「権限チェック・クラス」で指定された任意の権限クラス）が付与されているかどうかを確認します。「リソース・パターン」と「アクション・パターン」は、認可アサーションがこの特定のリクエストに対して実行されるかどうかを識別するために使用されます。認証されたサブジェクトにWSFunctionPermissionが付与されている場合、アクセスは許可されます。
WSFunctionPermission権限を、ユーザー、グループまたはアプリケーション・ロールに付与できます。WSFunctionPermissionをユーザーまたはグループに付与した場合、この権限は、ドメインにデプロイされているすべてのアプリケーションに適用されます。
このポリシーは、サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SOAPベースの任意のエンドポイントに添付できます。
このポリシーには、oracle/binding_permission_authorization_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/binding_permission_authorization_template」を参照してください。
このポリシーは、認証されたサブジェクトに基づき、簡単なロールベースの認可ポリシーを提供します。
このポリシーは、ロールを持つすべてのユーザーを拒否します。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダの構成に関する項で説明されているように、WebLogic認証プロバイダがすでに構成されている必要があります。
このポリシーは、サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SCAベースの任意のエンドポイントに添付できます。
このポリシーには、oracle/component_authorization_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/component_authorization_template」を参照してください。
表C-59を参照してください。
ロールを追加するには、次のようにします。
「追加」をクリックします。
ロールを追加するには、「使用可能なロール」列の追加する各ロールの隣にあるチェック・ボックスをクリックし、「移動」をクリックします。すべてのロールを追加するには、「すべて移動」をクリックします。
ロールを削除するには、「追加対象として選択したロール」列の削除する各ロールの隣にあるチェック・ボックスをクリックし、「削除」をクリックします。すべてのロールを削除するには、「すべて削除」をクリックします。
ロールを検索するには、「ロール名」検索ボックスに検索文字列を入力して、実行の矢印をクリックします。検索文字列に一致するロールのみが含まれるように、「使用可能なロール」列が更新されます。
「OK」をクリックします。
ロールを削除するには、次のようにします。
「選択したロール」リストで削除するロールを選択します。
「削除」をクリックします。
1つ以上のWebLogic Serverエンタープライズ・ロールを指定する場合、認証されたサブジェクトにそのロールがすでに付与されている必要があります。Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプで説明されているように、WebLogic Server管理コンソールを使用して、ロールをユーザーまたはグループに付与します。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダの構成に関する項で説明されているように、WebLogic認証プロバイダを構成する必要があります。
このポリシーは、認証されたサブジェクトに基づき、簡単なロールベースの認可ポリシーを提供します。
このポリシーは、ロールを持つすべてのユーザーを許可します。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダの構成に関する項で説明されているように、WebLogic認証プロバイダがすでに構成されている必要があります。
サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SCAベースの任意のエンドポイントに添付できます。
このポリシーには、oracle/component_authorization_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/component_authorization_template」を参照してください。
表C-59を参照してください。
ロールを追加するには、次のようにします。
「追加」をクリックします。
ロールを追加するには、「使用可能なロール」列の追加する各ロールの隣にあるチェック・ボックスをクリックし、「移動」をクリックします。すべてのロールを追加するには、「すべて移動」をクリックします。
ロールを削除するには、「追加対象として選択したロール」列の削除する各ロールの隣にあるチェック・ボックスをクリックし、「削除」をクリックします。すべてのロールを削除するには、「すべて削除」をクリックします。
ロールを検索するには、「ロール名」検索ボックスに検索文字列を入力して、実行の矢印をクリックします。検索文字列に一致するロールのみが含まれるように、「使用可能なロール」列が更新されます。
「OK」をクリックします。
ロールを削除するには、次のようにします。
「選択したロール」リストで削除するロールを選択します。
「削除」をクリックします。
1つ以上のWebLogic Serverエンタープライズ・ロールを指定する場合、認証されたサブジェクトにそのロールがすでに付与されている必要があります。Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプで説明されているように、WebLogic Server管理コンソールを使用して、ロールをユーザーまたはグループに付与します。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプの認証プロバイダの構成に関する項で説明されているように、WebLogic認証プロバイダを構成する必要があります。
このポリシーは、認証されたサブジェクトに基づき、権限ベースの認可ポリシーを提供します。
このポリシーは、サブジェクトに操作を実行する権限があることを保証します。このため、認可ポリシー・エグゼキュータはOPSSを利用し、認証されたサブジェクトに、パラメータとして「リソース・パターン」と「アクション・パターン」を使用してoracle.wsm.security.WSFunctionPermission（または「権限チェック・クラス」で指定された任意の権限クラス）が付与されているかどうかを確認します。「リソース・パターン」と「アクション・パターン」は、認可アサーションがこの特定のリクエストに対して実行されるかどうかを識別するために使用されます。認証されたサブジェクトにWSFunctionPermissionが付与されている場合、アクセスは許可されます。
WSFunctionPermission権限を、ユーザー、グループまたはアプリケーション・ロールに付与できます。WSFunctionPermissionをユーザーまたはグループに付与した場合、この権限は、ドメインにデプロイされているすべてのアプリケーションに適用されます。
このポリシーは、サブジェクトが作成されている認証ポリシーの後に続ける必要があり、SCAベースの任意のエンドポイントに添付できます。
このポリシーには、oracle/component_permission_authorization_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/component_permission_authorization_template」を参照してください。
Webサービス・アドレス（WS-Addressing）の仕様（http://www.w3.org/TR/ws-addr-core/）は、Webサービスおよびメッセージに対応する、特定のトランスポートに依存しないメカニズムを提供します。特に、仕様では、Webサービス・エンドポイントの識別とメッセージ内のエンドツーエンドのエンドポイント・アイデンティティの保護に使用されるXML要素の数が定義されます。
この項では、事前定義済のWS-Addressingポリシーについて説明します。
このポリシーを使用すると、プラットフォームにより、W3C 2005の最終版のWS-Addressingポリシー標準に準拠したWS-Addressingヘッダーがインバウンド・メッセージに存在するかどうかが確認されます。また、プラットフォームにより、WS-AddressingヘッダーがアウトバウンドSOAPメッセージに組み込まれます。
Web Services Addressing 1.0 - SOAP Bindingの仕様（http://www.w3.org/TR/ws-addr-soap/）で説明されているように、Webサービス・クライアントのWS-Addressingを構成します。
この項では、事前定義済のMTOMポリシーについて説明します。
SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging（MTOM/XOP）は、SOAPメッセージ内のxs:base64Binaryまたはxs:hexBinaryタイプのXMLデータの転送を最適化するためのメソッドを定義します。
Message Transmission Optimization Mechanism（MTOM）ポリシーは、MTOM形式ではないインバウンド・メッセージを拒否し、アウトバウンド・メッセージがMTOM形式であるかどうかを検証します。
MTOMはhttp://www.w3.org/TR/2005/REC-soap12-mtom-20050125の仕様書と、SOAP 1.2およびSOAP1.1バインディングに関してはhttp://www.w3.org/Submission/2006/SUBM-soap11mtom10-20060405を参照します。
WebサービスのクライアントでMTOMを有効にするには、次の例に示されているように、Webサービス・プロキシまたはディスパッチの作成時にパラメータとしてjavax.xml.ws.soap.MTOMFeatureを渡します。
package examples.webservices.mtom.client;
import javax.xml.ws.soap.MTOMFeature;
public class Main {
public static void main(String[] args) {
String FOO = "FOO";
MtomService service = new MtomService()
MtomPortType port = service.getMtomPortTypePort(new MTOMFeature());
String result = null;
result = port.echoBinaryAsString(FOO.getBytes());
System.out.println( "Got result: " + result );
}
}
WS-ReliableMessagingは、メッセージ交換を信頼できるものにします。また、ソフトウェア・コンポーネント、システムまたはネットワークの障害には関係なく、分散アプリケーション間でメッセージが確実に送信されることを保証します。順序付き配信が保証されているため、クライアント・アプリケーションごとに、失敗したメッセージの自動再送信をコーディングする必要はありません。
Webサービスで次の問題が発生している場合は、信頼できるメッセージングの使用を検討してください。
ネットワーク障害や接続の切断
メッセージの転送中の消失
メッセージの順不同での宛先への到着
WS-ReliableMessagingでは、メッセージの送信元と宛先はクライアント・サーバー・モデルに依存しないものとみなされます。つまり、クライアントとサーバーはそれぞれ、通信パスでメッセージの送信元および宛先の両方として同時に機能できます。
この項では、事前定義済の信頼できるメッセージング・ポリシーについて説明します。
表9-4に、WS-RMポリシーに設定できるプロパティをリストします。
表9-4 WS-RMポリシーのプロパティ
| プロパティ名 | ポリシーで使用されるデフォルト値 | 使用可能な値 |
|---|---|---|
|
DeliveryAssurance |
inorder |
InOrder AtLeastOnce AtLeastOnceInOrder ExactlyOnce ExactlyOnceInOrder AtMostOnce AtMostOnceInOrder |
|
StoreType |
inmemory |
InMemory FileSystem（完全にはサポートされていません） JDBC |
|
jdbc-connection-name JDBCタイプのメッセージ・ストアの接続情報を提供します。JDBCデータ・ソースへのJNDI参照は、jdbc-connection-urlよりも優先されます。ユーザー名とパスワードは、両方存在する場合に使用されます。 |
||
|
StoreName |
oracle |
文字列値 |
|
InactivityTimeout 特定のWS-RMシーケンスに関連付けられたメッセージ交換の間隔の許容時間（ミリ秒単位）であり、この時間を経過するとシーケンスが自動的に終了し、破棄されます。 |
600000 |
時間（ミリ秒単位） |
|
BaseRetransmissionInterval |
3000 |
このポリシーは、Web Servicesの信頼できるメッセージング・プロトコルのバージョン1.0のサポートを提供します。このポリシーは、SOAPベースのすべてのクライアントまたはエンドポイントに添付できます。
マルチメッセージ・シーケンスの場合、クライアント・コードには、シーケンス境界を区切るメソッドの明示的な呼び出しが含まれている必要があります。含まれていない場合、各メッセージは独自のシーケンスでラップされます。
クライアントを編集して、サービスに送信されるメッセージの信頼できるメッセージング・セッションを有効にします。oracle.webservices.rm.client.RMSessionLifecycleインタフェースは、WS-RMシーケンス境界を区切るメカニズムをクライアントに提供します。
例9-6に、サンプルのWS-RMクライアント・コードを示します。このコードでは、新しいTestServiceが作成されます。クライアントがサービスと通信するときに使用されるTestPortが取得されます。ポート・オブジェクトがRMSessionLifecycleオブジェクトにキャストされ、信頼できるメッセージング・セッションがそのオブジェクト上で開かれます（openSession）。メッセージがサービスに送信されると、セッションは終了します（closeSession）。
例9-6 サンプルのWS-Rmクライアント・コード
public class ClientServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
int num1 = Integer.parseInt(request.getParameter("num1"));
int num2 = Integer.parseInt(request.getParameter("num2"));
String outputStr = null;
TestService service = new TestService();
Test port = service.getTestPort();
try {
((RMSessionLifecycle) port).openSession();
outputStr = port.hello(inputStr);
} catch (Exception e) {
e.printStackTrace();
outputStr = e.getMessage();
} finally {
((RMSessionLifecycle) port).closeSession();
response.getOutputStream().write(outputStr.getBytes());
}
}
}
このポリシーは、Web Servicesの信頼できるメッセージング・プロトコルのバージョン1.1のサポートを提供します。このポリシーは、SOAPベースのすべてのクライアントまたはエンドポイントに添付できます。
マルチメッセージ・シーケンスの場合、クライアント・コードには、シーケンス境界を区切るメソッドの明示的な呼び出しが含まれている必要があります。含まれていない場合、各メッセージは独自のシーケンスでラップされます。
クライアントを編集して、サービスに送信されるメッセージの信頼できるメッセージング・セッションを有効にします。oracle.webservices.rm.client.RMSessionLifecycleインタフェースは、WS-RMシーケンス境界を区切るメカニズムをクライアントに提供します。
例9-6に、サーブレット・クライアントを示します。このコードでは、新しいTestServiceが作成されます。クライアントがサービスと通信するときに使用されるTestPortが取得されます。ポート・オブジェクトがRMSessionLifecycleオブジェクトにキャストされ、信頼できるメッセージング・セッションがそのオブジェクト上で開かれます（openSession）。メッセージがサービスに送信されると、セッションは終了します（closeSession）。
この項では、事前定義済の管理ポリシーについて説明します。
このポリシーを使用すると、メッセージ・ログにリクエスト、レスポンスおよびフォルト・メッセージが送信されます。
このポリシーには、oracle/log_templateポリシー・アサーションが含まれています。このアサーションの詳細は、「oracle/security_log_template」を参照してください。
