| Oracle® Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護 11g リリース1(10.3.3) B61620-01 |
|
 前 |
| Oracle® Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護 11g リリース1(10.3.3) B61620-01 |
|
前 |
この付録では、WebLogic ServerでOracle Web Services Manager (WSM) WS-Securityポリシーを使用する方法について説明します。この付録の内容は次のとおりです。
Oracle Fusion Middleware 11g リリース1(10.3.3)製品は、WebLogic Server上にポータビリティ層をインストールします。これにより、Oracle Web Services Manager WS-SecurityポリシーがWebLogic Server環境と統合されます。このポータビリティ層は、WebLogic Server JAX-WS WebサービスとWebサービス・クライアントを保護するのに使用できるOracle WSM WS-Securityポリシーを提供します。
Webサービスのセキュリティを提供するためのWebLogic Server WS-Securityポリシーのかわりに、Oracle WSMポリシーを使用できます。また、カスタムのOracle WSM WS-Securityポリシーを作成して、WebLogic Webサービスで使用することもできます。
環境内の他の場所ですでにSOA、ADF、WebCenterなどのアプリケーションを使用しており、一貫したセキュリティ環境を構築する必要がある場合は、Oracle WSM WS-Securityポリシーを使用してJAX-WS Webサービスを保護することができます。
WebLogic Server JAX-WS WebサービスをOracle Fusion Middlewareアプリケーションと併用する場合は、これらのWebサービスをOracle WSM WS-Securityポリシーで保護し、一貫性と相互運用性を備えたWebサービス・セキュリティを確立する必要があります。
すなわち、スタンドアロンのWebLogic Server Webサービス・アプリケーションではなく、Oracle Fusion Middlewareアプリケーションと相互作用するアプリケーションで使用するWebLogic Server JAX-WS Webサービスは、Oracle WSM WS-Securityポリシーで保護する必要があります。
次のシナリオを参考にしてください。
SOAコンポジット・サービス、ADFコンポーネント、WebCenterサービスなどと相互作用するWebLogic Server JAX-WS Webサービスまたはクライアントを開発する場合は、Oracle WSM WS-Securityポリシーを使用します。
WebLogic ServerネイティブのJava JAX-WS Webサービスのみを開発する場合は、WebLogic ServerのWS-Securityポリシーを使用します。
表A-1は、Oracle WSMポリシーを使用する際のポリシー選択のガイドラインをまとめたものです。
表の@PolicyアノテーションはWebLogic Webポリシーに適用され、@SecurityPolicyアノテーションはOracle WSMポリシーに適用されます。
表A-1 ポリシー選択のガイドライン
| @Policy | @SecurityPolicy | 実装する機能 | 使用するポリシー |
|---|---|---|---|
|
はい |
いいえ |
複数あるWSS1.0は、キー参照メソッドをサポートする必要があります。 |
Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml |
|
はい |
いいえ |
ユーザー名トークン・ダイジェスト認証 |
Wssp1.2-2007-Https-UsernameToken-Digest.xml Wssp1.2-2007-Wss1.0-UsernameToken-Digest-X509-Basic256.xml Wssp1.2-2007-Wss1.1-UsernameToken-Digest-X509-Basic256.xml |
|
いいえ |
はい |
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 |
|
はい |
いいえ |
WSS 1.1派生キー |
Wssp1.2-2007-Wss1.1-DK-X509-SignedEndorsing.xml Wssp1.2-2007-Wss1.1-UsernameToken-Plain-DK.xml |
|
はい |
いいえ |
すべてのセキュアな会話 |
Wssp1.2-2007-Wssc1.3-Bootstrap-Https.xml Wssp1.2-2007-Wssc1.3-Bootstrap-Https-BasicAuth.xml Wssp1.2-2007-Wssc1.3-Bootstrap-Https-ClientCertReq.xml Wssp1.2-2007-Wssc1.3-Bootstrap-Https-UNT.xml Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xml |
|
はい |
いいえ |
すべてのSAML 2.0シナリオ |
Wssp1.2-2007-Saml2.0-Bearer-Https.xml Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml Wssp1.2-2007-Saml2.0-HolderOfKey-Wss1.1-Asymmetric.xml Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Asymmetric.xm |
|
いいえ |
はい |
HTTPS用のSAML 1.1 Bearer確認 |
oracle/wss_saml_token_bearer_over_ssl_client_policy oracle/wss_saml_token_bearer_over_ssl_service_policy |
|
はい |
いいえ |
署名する前の暗号化 |
WSS10、WSS11両方の対称バインディングまたは非対称バインディングにおける、次のようなポリシー・アサーション<sp:EncryptBeforeSigning/>。
<wsp:Policy xmlns:wsp="..." >
<sp:SymmetricBinding>
<wsp:Policy>
.. .
<sp:EncryptBeforeSigning/>
. . .
</wsp:Policy>
</sp:SymmetricBinding>
. . .
</wsp:Policy>
|
|
はい |
いいえ |
複数のポリシー選択肢 |
次のようなポリシー・アサーション。
<wsp:Policy xmlns:wsp="..." >
<wsp:ExactlyOne>
<wsp:All>
... ALternative 1 ...
</wsp:All>
<wsp:All>
... ALternative 2 ...
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
|
WS-RMやMTOMなどの非セキュリティ機能には、WebLogic Webサービスを使用します。
特定のポリシー・インスタンスでは、Webサービス・クライアントまたはサービスにOracle WSMポリシーをアタッチし、WebLogic Java EE WebサービスまたはクライアントにOracle WebLogic Serverポリシーをアタッチして、2種類のポリシーを相互運用することができます。具体的な相互運用性シナリオについては、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』のOracle WebLogic Server 11gのWebサービス・セキュリティ環境との相互運用性に関する項で説明しています。
これらの相互運用性シナリオについては、次の点を考慮した上でOracle WSMポリシーとWebLogicポリシーのいずれかを使用してください。
Oracle WSMポリシーにおけるその他の非標準のポリシー・アサーションが構成で必要とされる場合は、@SecurityPolicyアノテーションを使用します。
このような非標準のアサーションの例としては、次のものがあります。
<oralgp:Logging xmlns:oralgp="http://schemas.oracle.com/ws/2006/01/loggingpolicy" . . .
orawsp:category="security/logging">
. . .
</oralgp:Logging>
または
<orawsp:Config xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" . . .>
<orawsp:PropertySet . . .>
. . .
</orawsp:PropertySet>
</orawsp:Config>
アプリケーションが、既存のWebLogic WebサービスまたはMicrosoft Windows Communication Foundation (WCF)/.NET 3.5 Frameworkサービスとの相互運用に使用され、前述した非標準のポリシー・アサーションが必要でない場合、WebLogicポリシーを持つ@Policyアノテーションを使用します。
使用可能なOracle WSMポリシーを表A-2に示します。
表A-2 使用可能なOracle WSM WS-Securityポリシー
| サービス・ポリシー名 | クライアント・ポリシー名 | 説明 |
|---|---|---|
|
oracle/binding_authorization_ denyall_policy |
なし |
このポリシーは、認証されたサブジェクトに基づく単純なロール・ベースの認可ポリシーの特別なケースです。このポリシーは、任意のロールを持つすべてのユーザーを拒否します。このポリシーは、サブジェクトが確立される認証ポリシーに従う必要があります。このポリシーは、どのようなSOAPベースのエンドポイントにもアタッチできます。 |
|
oracle/binding_authorization_ permitall_policy |
なし |
このポリシーは、認証されたサブジェクトに基づく単純なロール・ベースの認可ポリシーの特別なケースです。このポリシーは、任意のロールを持つすべてのユーザーを許可します。このポリシーは、サブジェクトが確立される認証ポリシーに従う必要があります。このポリシーは、どのようなSOAPベースのエンドポイントにもアタッチできます。 |
|
oracle/binding_permission_ authorization_policy |
なし |
このポリシーは、認証されたサブジェクトに基づく単純なパーミッション・ベースの認可ポリシーの特別なケースです。このポリシーは、サブジェクトがWebサービスに対する操作を呼び出すパーミッションを持っているかどうかチェックします。このポリシーは、サブジェクトが確立される認証ポリシーに従う必要があります。このポリシーは、どのようなSOAPベースのエンドポイントにもアタッチできます。 |
|
oracle/wss10_message_ protection_service_policy |
oracle/wss10_message_ protection_client_policy |
このポリシーはWS-Security v1.0標準に従って、着信SOAPリクエストに対するメッセージの整合性と機密性を適用します。メッセージは、WS-Securityの非対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化が使用されます。キーストアはセキュリティ構成を通して構成されます。このポリシーは、リクエスト元に対する認証も認可も行いません。 |
|
oracle/wss10_saml_token_ service_policy |
oracle/wss10_saml_token_ client_policy |
このポリシーはセキュアではなく、デモの目的でのみ提供されています。SAML発行者名は存在しますが、SAMLトークンが承認されていません。したがって、メッセージの偽装が可能です。 このポリシーは、WS-Security SOAPヘッダーでSAMLトークンに提供された資格証明を使用することでユーザーを認証します。SAMLトークンの資格証明はSAMLログイン・モジュールに対して認証されます。このポリシーは、どのようなSOAPベースのエンドポイントにも適用できます。 |
|
oracle/wss10_saml_token_ with_message_integrity_ service_policy |
oracle/wss10_saml_token_ with_message_integrity_ client_policy |
このポリシーはWS-Security 1.0標準に従って、着信SOAPリクエストに対するメッセージ・レベルの整合性保護とSAMLベースの認証を行います。WS-Securityの非対称鍵テクノロジのBasic 128スイート(メッセージの整合性のためにはSHA-1ハッシュ・アルゴリズム)を使用します。キーストアはセキュリティ構成を通して構成されます。WS-Securityのバイナリ・セキュリティ・トークンからSAMLトークンを抽出し、それらの資格証明を使用して、構成済のアイデンティティ・ストアに対してユーザーが検証されます。 |
|
oracle/wss10_saml_token_ with_message_protection_ service_policy |
oracle/wss10_saml_token_ with_message_protection_ client_policy |
このポリシーはWS-Security 1.0標準に従って、着信SOAPリクエストに対するメッセージ・レベルの保護とSAMLベースの認証を行います。WS-Securityの非対称鍵テクノロジのBasic 128スイートを使用します。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化を使用します。このポリシーでは、リクエストでの暗号化鍵、およびレスポンスでの署名と暗号化鍵の両方に、サブジェクト・キー識別子(ski)参照メカニズムが使用されます。キーストアはセキュリティ構成を通して構成されます。WS-Securityのバイナリ・セキュリティ・トークンからSAMLトークンを抽出し、それらの資格証明を使用して、構成済のアイデンティティ・ストアに対してユーザーが検証されます。 |
|
oracle/wss10_ username_id_propagation_with_msg_ protection_service_policy |
oracle/wss10_ username_id_propagation_with_msg_ protection_client_policy |
このポリシーはWS-Security 1.0に記述されたメカニズムを使用して、着信SOAPリクエストに対するメッセージ・レベルの保護(すなわち、整合性と秘密性)とアイデンティティ伝播を実施します。メッセージ保護は、WS-Security 1.0 Basic128スイートの非対称鍵テクノロジを使用することで提供されます。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化が使用されます。キーストアはセキュリティ構成を通して構成されます。アイデンティティはUsernameToken WS-Security SOAPヘッダーによって提供されたユーザー名を使用して設定されます。サブジェクトは現在構成されているアイデンティティ・ストアに対して確立されます。このポリシーは、どのようなSOAPベースのエンドポイントにも適用できます。 |
|
oracle/wss10_ username_token_with_message_ protection_service_policy |
oracle/wss10_ username_token_with_message_ protection_client_policy |
このポリシーはWS-Security v1.0標準に従って、着信SOAPリクエストに対するメッセージ・レベルの保護(メッセージの整合性と機密性)と認証を実施します。WS-Securityの非対称鍵テクノロジのBasic 128スイートを使用します。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化を使用します。キーストアはセキュリティ構成を通して構成されます。認証は、WS-Security UsernameToken SOAPヘッダーの資格証明を使用して行われます。プレーン・テキストとダイジェストの両方のメカニズムがサポートされます。資格証明は構成された資格証明ストアに対して認証されます。このポリシーは、どのようなSOAPベースのエンドポイントにもアタッチできます。 |
|
oracle/wss10_ x509_token_with_message_ protection_service_policy |
oracle/wss10_ x509_token_with_message_ protection_client_policy |
このポリシーはWS-Security 1.0標準に従って、着信SOAPリクエストに対するメッセージ・レベルの保護と証明書ベースの認証を行います。WS-Securityの非対称鍵テクノロジのBasic 128スイートを使用します。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化を使用します。キーストアはセキュリティ構成を通して構成されます。WS-Securityのバイナリ・セキュリティ・トークンから証明書を抽出し、それらの資格証明を構成済のアイデンティティ・ストアに対して検証することでユーザーが認証されます。 |
|
oracle/wss11_ kerberos_token_service_ policy |
oracle/wss11_ kerberos_token_client_ policy |
このポリシーは、WS-Security Kerberos Token Profile v1.1標準に従って適用されます。SOAPヘッダーからKerberosトークンを抽出してユーザーを認証します。コンテナでKerberosのセキュリティ・インフラストラクチャが構成されている必要があります。このポリシーは、どのようなSOAPエンドポイントにもアタッチできます。このポリシーはMITとActive Directory KDCと互換性があります。 |
|
oracle/wss11_ kerberos_token_with_message_ protection_service_policy |
oracle/wss11_ kerberos_token_with_message_ protection_client_policy |
このポリシーは、WS-Security Kerberos Token Profile v1.1標準に従って適用されます。SOAPヘッダーからKerberosトークンを抽出してユーザーを認証し、Kerberosの鍵を使用してメッセージの整合性と秘密性が適用されます。コンテナでKerberosのセキュリティ・インフラストラクチャが構成されている必要があります。このポリシーは、どのようなSOAPエンドポイントにもアタッチできます。このポリシーはMIT KDCとのみ互換性があります。 |
|
oracle/wss11_ message_protection_ service_policy |
oracle/wss11_ message_protection_ client_policy |
このポリシーはWs-security v 1.1標準に従って、着信SOAPリクエストに対するメッセージの整合性と機密性を適用します。メッセージは、WS-Securityの対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化が使用されます。キーストアはセキュリティ構成を通して構成されます。 |
|
oracle/wss11_ saml_token_with_message_ protection_service_policy |
oracle/wss11_ saml_token_with_message_ protection_client_policy |
このポリシーはWS-Security 1.1標準に従って、着信SOAPリクエストに対するメッセージ・レベルの保護(メッセージの整合性とメッセージの機密性)とSAMLベースの認証を行います。メッセージは、WS-Securityの対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化が使用されます。キーストアはセキュリティ構成を通して構成されます。WS-Securityのバイナリ・セキュリティ・トークンからSAMLトークンを抽出し、それらの資格証明を使用して、構成済のアイデンティティ・ストアに対してユーザーが検証されます。このポリシーは、どのようなSOAPベースのエンドポイントにもアタッチできます。 |
|
oracle/wss11_ username_token_with_message_ protection_service_policy |
oracle/wss11_ username_token_with_message_ protection_client_policy |
このポリシーはWS-Security 1.1標準に従って、着信SOAPリクエストに対するメッセージ・レベルの保護(メッセージの整合性とメッセージの機密性)と認証を行います。メッセージは、WS-Securityの対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化が使用されます。キーストアはセキュリティ構成を通して構成されます。資格証明は、UsernameToken WS-Security SOAPヘッダーを介して提供されます。プレーン・テキストとダイジェストの両方のメカニズムがサポートされます。資格証明は、構成済のアイデンティティ・ストアに対して認証されます。このポリシーは、どのようなSOAPベースのエンドポイントにもアタッチできます。 |
|
oracle/wss11_ x509_token_with_message_ protection_service_policy |
oracle/wss11_ x509_token_with_message_ protection_client_policy |
このポリシーはWS-Security 1.1標準に従って、着信SOAPリクエストに対するメッセージ・レベルの保護と証明書ベースの認証を行います。メッセージは、WS-Securityの非対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化が使用されます。キーストアはセキュリティ構成を通して構成されます。WS-Securityのバイナリ・セキュリティ・トークン・ヘッダーから証明書が抽出され、証明書の資格証明が構成済のアイデンティティ・ストアに対して検証されます。 |
|
oracle/wss_ oam_token_service_policy |
oracle/wss_ oam_token_client_policy |
このポリシーは、WS-Securityヘッダーのバイナリ・セキュリティ・トークンに含まれる資格証明を使用して、Oracle Access Managerアイデンティティ・ストアに対してユーザーを認証します。このポリシーは、どのようなSOAPエンドポイントにもアタッチできます。 |
|
oracle/wss_ saml_token_bearer_over_ _policy |
oracle/wss_ saml_token_bearer_over_ ssl_client_policy |
このポリシーは、WS-Security SOAPヘッダーのBearer確認メソッドを使用して、SAMLトークンで提供される資格証明でユーザーを認証します。SAMLトークンに含まれる資格証明は、SAMLログイン・モジュールに対して認証されます。ポリシーは、トランスポート・プロトコルでSSLメッセージの保護が提供されていることを検証します。このポリシーは、どのようなSOAPベースのエンドポイントにも適用できます。 |
|
oracle/wss_ saml_token_over_ssl_ service_policy |
oracle/wss_ saml_token_over_ssl_ client_policy |
このポリシーは、WS-Security SOAPヘッダーのSAMLトークンで提供される資格証明を使用してユーザーを認証します。SAMLトークンに含まれる資格証明は、SAMLログイン・モジュールに対して認証されます。ポリシーは、トランスポート・プロトコルでSSLメッセージの保護が提供されていることを検証します。このポリシーは、どのようなSOAPベースのエンドポイントにも適用できます。 |
|
oracle/wss_ username_token_over_ssl_ service_policy |
oracle/wss_ username_token_over_ssl_ client_policy |
このポリシーは、UsernameToken WS-Security SOAPヘッダーの資格証明を使用して、構成済のアイデンティティ・ストアに対してユーザーを認証します。プレーン・テキストとダイジェストの両方のメカニズムがサポートされます。このポリシーは、トランスポート・プロトコルでSSLメッセージの保護が提供されていることを検証します。このポリシーは、どのようなSOAPベースのエンドポイントにもアタッチできます。 |
|
oracle/wss_ username_token_service_ policy |
oracle/wss_ username_token_client_ policy |
このポリシーはセキュアではなく、デモの目的でのみ提供されています。パスワードがクリア・テキストで送信されます。 このポリシーは、UsernameToken WS-Security SOAPヘッダーの資格証明を使用して、構成済のアイデンティティ・ストアに対してユーザーを認証します。プレーン・テキストとダイジェストの両方のメカニズムがサポートされます。このポリシーは、トランスポート・プロトコルでSSLメッセージの保護が提供されていることを検証します。このポリシーは、どのようなSOAPベースのエンドポイントにもアタッチできます。 |
|
oracle/wss10_ saml_hok_token_with_message_ protection_service_policy |
oracle/wss10_ saml_hok_token_with_message_ protection_client_policy |
このポリシーはWS-Security 1.0標準に従って、着信SOAPリクエストに対するメッセージ・レベルの保護と、鍵ベース認証のSAMホルダーを実施します。WS-Securityの非対称鍵テクノロジのBasic 128スイートが使用されます。具体的には、RSA鍵メカニズム(メッセージの機密性)、SHA-1ハッシュ・アルゴリズム(メッセージの整合性)、およびAES-128ビットの暗号化が使用されます。キーストアはセキュリティ構成を通して構成されます。WS-Securityのバイナリ・セキュリティ・トークンからSAMLトークンを抽出し、それらの資格証明を使用して、構成済のアイデンティティ・ストアに対してユーザーが検証されます。 |
WebLogic Webサービス・ポリシーの一部をOracle WSMポリシーと相互運用できます。
つまり、特定のポリシー・インスタンスについて、Oracle WSMポリシーをWebサービス・クライアントまたはサービスにアタッチしたり、Oracle WebLogic ServerポリシーをWebLogic Java EE Webサービスまたはクライアントにアタッチすることができるので、Oracle WSMポリシーとOracle WebLogic Serverポリシーは相互運用が可能です。
個々の相互運用性シナリオについては、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』のOracle WebLogic Server 11g Webサービス・セキュリティ環境との相互運用性に関する項で説明しています。
このリリースのWebLogic Serverには、Oracle WSMとの相互運用性のためのポリシー(表A-3を参照)が用意されています。
表A-3 相互運用性WS-Securityポリシー
| ポリシー名 | 説明 |
|---|---|
|
Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.0-Basic128.xml |
このポリシーは、holder-of-key確認メソッド(SAMLトークン内の鍵が署名に使用される)による認証のためのSAMLトークンを含む、Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.0.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。 |
|
Wssp1.2-wss11_saml_token_with_message_protection_owsm_policy.xml |
このポリシーは、sender-vouches確認メソッドによる認証のためのSAMLトークン(リクエストとレスポンスの両方でWSS1.1 X509の対称バインディングにより署名および暗号化される)を含む、Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xmlと同様のセキュリティ機能を提供します。 送信側のX509証明書によって承認が行われ、メッセージの署名は保護されます。Basic256アルゴリズム・スイート(暗号化にはAES256)ではなく、Basic128アルゴリズム・スイート(AES128)を使用する必要があります。 |
|
Wssp1.2-wss10_saml_token_with_message_protection_owsm_policy.xml |
このポリシーは、sender-vouches確認メソッドによる認証のためのSAMLトークン(クライアントの秘密鍵で署名される)を含む、Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。また、公開証明書を含む直接キー参照が使用されます。 |
|
Wssp1.2-2007-Saml1.1-SenderVouches-Https.xml |
sender-vouches確認メソッドによって認証を行うSAML 1.1トークンを使用する、双方向SSL。クライアント証明書が必要であり、受信側で発信元の公開証明書の有無をチェックします。 |
|
Wssp1.2-wss10_x509_token_with_message_protection_owsm_policy.xml |
このポリシーは、X.509証明書による相互認証用に、Wssp1.2-2007-Wss1.0-X509-Basic256.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(AES128の暗号化)の使用が必要になります。また、公開証明書を含む直接キー参照が使用されます。 |
|
Wssp1.2-2007-Wss1.1-EncryptedKey-Basic128.xml |
このポリシーは、Wssp1.2-Wss1.1-EncryptedKey.xmlと同様のセキュリティ機能を提供します。このポリシーでは、メッセージがクライアント側からのX509証明書なしに暗号化および署名される必要があります。これは、匿名認証に使用されます。 |
|
Wssp1.2-wss11_x509_token_with_message_protection_owsm_policy.xml |
このポリシーは、Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xmlと同様のセキュリティ機能を提供します。送信側のX509証明書によって承認が行われ、メッセージの署名は保護されます。Basic256アルゴリズム・スイート(暗号化にはAES256)ではなく、Basic128アルゴリズム・スイート(AES128)の使用が必要になります。 |
|
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml |
このポリシーは、Wssp1.2-Wss1.1-UsernameToken-Plain-X509-Basic256.xmlと同様のセキュリティ機能を提供します。非対称バインディングによるWSS 1.1 X509およびプレーン・テキスト・ユーザー名トークンによる認証が提供されます。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。 |
|
Wssp1.2-wss10_username_token_with_message_protection_owsm_policy.xml |
このポリシーは、クライアントの秘密鍵で署名された、認証用の暗号化されたプレーン・テキスト・パスワードを含む、Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic256.xmlと同様のセキュリティ機能を提供します。Basic256アルゴリズム・スイート(AES256)ではなく、Basic128アルゴリズム・スイート(暗号化にはAES128)の使用が必要になります。また、公開証明書を含む直接キー参照が使用されます。 |
Oracle Fusion Middleware 11g リリース1(10.3.3)製品に含まれている幅広いOracle WSM WS-Securityポリシーに慣れ親しんでいる場合、次のOracle WSM WS-Securityポリシーが現在WebLogic Server JAX-WSでサポートされていないことに注意してください。
ログ・ポリシー
WS-Addressingポリシー
MTOMポリシー
信頼性のあるメッセージ・ポリシー
HTTPベースの認証
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 WSMポリシーは、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』で解説されています。
読者の便宜のため、各ポリシーの説明を表A-2に再録しいますが、これらのポリシーの完全な情報については『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
Oracle WSM WS-Securityポリシーのアタッチメント・モデルは、WebLogic Webサービス・ポリシーのものと同様です。
設計時にポリシー・アノテーションを使用
実行時に管理コンソールを使用
Fusion Middleware Controlを使用。方法については、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
Webサービスには、1種類のセキュリティ・ポリシー(WebLogic Serverセキュリティ・ポリシーまたはOracle WSMポリシー)のみをアタッチできます。アノテーション・メカニズム、管理コンソール、Fusion Middleware Controlのいずれか、またはこの3つの組合せを使用して、WebLogic ServerポリシーとOracle WSMポリシーの両方を同じWebサービスにアタッチすることはできません。
Oracle WSM WS-SecurityポリシーはJAX-WS Webサービスにのみアタッチできます。このタイプのポリシーをJAX-RPC Webサービスにアタッチすることはできません。
Oracle WSMポリシーは、WebLogic Server WS-Securityポリシーで使用される既存の@Policiesおよび@Policyアノテーションと同様の構文およびセマンティクスを持つ、固有の@SecurityPolicy (単一ポリシー)および@SecurityPolicies (複数のポリシー)アノテーションを使用します(ただし、次の例外があります)。
@SecurityPolicyと@SecurityPoliciesはクラス・レベルでのみ適用できます。
Directionは@SecurityPolicyアノテーションでは使用されません。
例:
例A-1 SecurityPolicyアノテーションを使用したポリシーのアタッチ
@SecurityPolicies({
@SecurityPolicy(uri=
"policy:oracle/wss10_username_token_with_message_protection_server_policy"),
@SecurityPolicy(uri=
"policy:oracle/authorization_policy")})
設計時にJWSアノテーションを介してOracle OWSM WS-Securityポリシーを追加するには、次の手順に従います。
@SecurityPolicyおよび@SecurityPolicies JWSアノテーションを追加して、Webサービス全体にアタッチされる事前定義済のOracle OWSM WS-Securityポリシー・ファイルを指定し、JWSファイルを更新します。
通常の反復的な開発プロセスの一部として、Webサービスを再コンパイルして再デプロイします。
JAX-WSを使用したWebLogic Webサービス・スタート・ガイドのWebLogic Webサービスの開発に関する項を参照してください。
管理コンソールを使用して、セキュリティ・レルムに認証用のユーザーを作成します。
ロールおよびポリシーによるWebLogicリソースの保護を参照してください。
「クライアントへのOracle WSM WS-Securityポリシーの追加」の説明に従って、メッセージ保護されたWebサービスを起動するJavaコードを追加して、クライアント・アプリケーションを更新します。
クライアント・アプリケーションを再コンパイルします。
JAX-WSを使用したWebLogic Webサービス・スタート・ガイドを参照してください。
管理コンソールで実行時にデプロイ済WebサービスにOracle WSMポリシーの1つをアタッチするのは、「メッセージ・レベルのセキュリティの構成」で説明しているように、WebLogic Serverポリシーのアタッチするのと同様です。
JWSファイルで@SecurityPolicyアノテーションも@SecurityPolicies アノテーションを使用せず、管理コンソールを使用して実行時にポリシー・ファイルを関連付けることができます。あるいは、アノテーションを使用して一部のポリシー・ファイルを指定しておき、実行時に追加のポリシー・ファイルを関連付けることもできます。
JWSアノテーションを使用してポリシー・ファイルを関連付けた場合は、実行時に管理コンソールを使用してこの関連付けを削除できます。
実行時、管理コンソールでは、ファイル内のポリシー・アサーションが互いに矛盾している場合や、JWSアノテーションに関連付けられたポリシー・ファイルのアサーションと矛盾している場合でも、必要な数のポリシー・ファイルをWebサービスとその操作に関連付けることができます。ただし、関連付けられた複数のポリシー・ファイルの連携は、管理者が管理する必要があります。何らかの矛盾がある場合、クライアント・アプリケーションがWebサービスの操作を呼び出すときに、WebLogic Serverから実行時エラーが返されます。
ポリシーの検証は行われません。次の組合せのみが有効です。
ポリシー・サブジェクトには、管理ポリシーを1つのみアタッチできます。
サブジェクトには、サブタイプの認証を行うセキュリティ・ポリシーを1つのみアタッチできます。
サブジェクトには、サブタイプのメッセージ保護を行うセキュリティ・ポリシーを1つのみアタッチできます。
サブジェクトには、サブタイプの認可を行うセキュリティ・ポリシーを1つのみアタッチできます。
|
注意: 1つのポリシー・サブジェクトに1つまたは2つのセキュリティ・ポリシーがアタッチされていることがあります。セキュリティ・ポリシーには、認証とメッセージ保護のいずれかのサブタイプ・カテゴリに属するアサーション、または両方のサブタイプ・カテゴリに属するアサーションを含めることができます。2つ目のセキュリティ・ポリシーには、認可サブタイプに属するアサーションが含まれています。 |
認証ポリシーと認可ポリシーを両方ともポリシー・サブジェクトにアタッチする場合は、認証ポリシーを認可ポリシーより前に置く必要があります。
管理コンソールでOracle WSM WS-Securityポリシーをアタッチするには、次の手順を実行します。
管理コンソールを使用して、デフォルトのWebサービス・セキュリティ構成を作成します。必ずdefault_wssと命名してください。デフォルトのWebサービス・セキュリティ構成は、別の構成を使用するよう明示的にプログラムされていないかぎり、ドメイン内のすべてのWebサービスで使用されます。
WebLogic Server管理コンソール・オンライン・ヘルプのWebサービス・セキュリティ構成の作成に関する項を参照してください。
「デプロイメントのサマリー」ページから、Webサービスを保護するアプリケーションを選択します。
プラス記号(+)をクリックしてアプリケーションを展開します。保護するWebサービスを選択します。
「構成」ページを選択します。
「WS-Policy」ページを選択します。
図A-1に示すように、Webサービス・エンドポイントを選択してください。Oracle WSM WS-Securityポリシーは、クラス/ポート・レベルでのみアタッチすることができます。
図A-2に示すように、OWSMを選択します。
図A-3に示すように、誤って特定のWebサービス操作を選択した場合、ポリシー選択画面は表示されません。最初からやり直すには、「取消」をクリックします。
このWebサービスにアタッチしたいOracle WSM WS-Securityポリシーを選択し、図A-4に示すように、コントロールを使用して、それらを「選択されたエンドポイント・ポリシー」ボックスの中に移動してください。完了したら、「終了」をクリックします。
デプロイメント・プランを保存します。
WebLogic Server変更メッセージで示されたとおりに変更が自動的にアクティブにならない場合は、デプロイ済のアプリケーションを再起動して、新しいデプロイメント・プランを反映させます。
1つのポリシーをアタッチするにはweblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeatureクラスを、複数のポリシーをアタッチするにはweblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeatureクラスを使用します。使用可能なクライアント・ポリシーは表A-2に示されています。
次の例を参考にしてください。
|
注意: この例に示したoracle/wss_username_token_clientポリシーはセキュアではなく、デモの目的でのみ提供されています。パスワードはクリア・テキストで送信されます。 |
例A-2 SecurityPolicyFeatureの使用
JAXWSService jaxWsService = new JAXWSService ();
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature securityFeature = new
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature {
new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/wss_username_token_client_policy") };
JAXWSServicePort port = jaxWsService.getJaxWsServicePort(securityFeature);
例A-3 SecurityPoliciesFeatureの使用
weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature
securityFeature = new weblogic.wsee.jws.jaxws.owsm.SecurityPoliciesFeature
{
new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/wss_username_token_client_policy") ,
new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/log_policy")};
次の手順は、Webサービス・オペレーションを呼び出すクライアント・アプリケーションにOracle WSM WS-Policyファイルを関連付けるためのステップを大まかに説明したものです。
デプロイ済のWebサービスを呼び出すクライアント・アプリケーションを作成してあり、クライアント側のポリシー・ファイルを関連付けることでそのクライアント・アプリケーションを更新するものとします。また、Antベースの開発環境を設定済で、clientgen Antタスクを実行するためのターゲットを含む、作業用のbuild.xmlファイルがあることを前提としています。
JAX-WSを使用したWebLogic Webサービス・スタート・ガイドのWebサービスの呼出しに関する項を参照してください。
表A-2から、アタッチしたいクライアント側Securityポリシー・ファイルを選択します。
クライアント・アプリケーションのビルドに使用するbuild.xmlファイルを更新します。
Javaクライアント・アプリケーションを更新します。
適切なタスクを実行して、クライアント・アプリケーションを再ビルドします。例:
prompt> ant build-client
次回クライアント・アプリケーションを実行したときには、ポリシー・ファイルがロードされ、Webサービス・クライアント・ランタイムはこれを使用してSOAPリクエスト・メッセージのセキュリティを有効にします。
パーミッション・ベースのポリシーoracle/binding_permission_authorization_policyは、認証済のサブジェクトに基づくパーミッション・ベースの認可ポリシーを提供します。
ポリシーは、サブジェクトが操作を実行するパーミッションを持つことを保証します。これを行うため、Oracle WSM認可ポリシーのエグゼキュータは、Oracle Platform Security Services (OPSS)を使用し、リソース・パターンとアクション・パターンをパラメータとして使用することで、認証済サブジェクトにoracle.wsm.security.WSFunctionPermissionが付与されているか(または、パーミッション・チェック・クラスで何らかのパーミッション・クラスが指定されているか)をチェックします。
リソース・パターンとアクション・パターンは、認可アサーションがこの特定のリクエストに適用されるかどうかを判定するために使用されます。認証済のサブジェクトがWSFunctionPermissionを付与されていれば、アクセスが許可されます。
WSFunctionPermissionパーミッションは、ユーザー、グループまたはアプリケーション・ロールに付与できます。ユーザーまたはグループにWSFunctionPermissionを付与すると、ドメインにデプロイされたすべてのアプリケーションに適用されます。
これを行うには、例A-4に示すように、WSFunctionPermissionパーミッションをユーザー、グループ、またはWebサービスへの認証を試行するアプリケーションに与えるために、<domain-home>/config/fmwconfigにあるsystem-jazn-data.xmlファイルを編集します。
この例では、ApplicationRoleを持っているユーザーは、有効なWebLogic Serverユーザーである必要があります。
例A-4 パーミッションを付与するためのsystem-jazn-data.xmlファイルの編集
:
<jazn-policy>
<grant>
<grantee>
<display-name>myPolicy</display-name>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>testapp</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.wsm.security.WSFunctionPermission</class>
<name>*</name>
<actions>echo1</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
:
SOAPメッセージの署名と暗号化を行うには、まずWebLogicドメインのWebサービス・マネージャ・キーストアを作成して構成する必要があります。このキーストアは、WebLogicドメイン内のSOAPメッセージの公開鍵と秘密鍵を保存するために使用されます。
|
注意: Webサービス・マネージャ・ランタイムはSSLに使用されるWebLogic Serverキーストアを使用しません。 |
署名と暗号化キーは、SOAPメッセージの署名、確認、暗号化および復号化に使用されます。
キーストア構成はドメイン全体に適用されるため、ドメイン内のすべてのWebサービスおよびWebサービス・クライアントがこのキーストアを使用します。
Web Services Managerで使用されるキーストアを設定するには、次の手順に従います。
「Javaキーストアの作成方法および使用方法」の説明に従って、キーストアを作成します。
WLSTを使用して資格証明ストアを構成します。
Java Keystore (JKS)は、Sun Microsystemsによって定義されたプロプライエタリのキーストア書式です。JKSのキーと証明書を作成して、管理するには、keytoolユーティリティを使用してください。以下のタスクを実行するのにkeytoolユーティリティを使用できます。
公開鍵と秘密鍵のペアを作成し、他のパーティに属する公開鍵を信頼性できるものとして指定し、キーストアを管理します。
適切な認証局(CA)への証明書リクエストを発行して、戻された証明書をインポートします。
固有の公開鍵と秘密鍵のペア、および関連の証明書を管理します。これにより、他のユーザーやサービスに対して自身を認証する際に、自身に固有の鍵と証明書を使用できます。このプロセスは自己認証と呼ばれます。デジタル署名を使用したデータ整合性および認証サービスにも固有の鍵と証明書を使用できます。
通信相手の公開鍵をキャッシュします。キーは証明書の形でキャッシュされます。
次の項では、keytoolユーティリティを使用してJKSを作成し管理する方法について概説します。キーストアを作成し、秘密鍵と信頼性のあるCA証明書をロードする方法について説明します。keytoolユーティリティのコマンドと引数の詳細は、次のURLを参照してください。
http://java.sun.com/javase/6/docs/tooldocs/windows/keytool.html
新しい秘密鍵と自己署名証明書を作成します。
秘密鍵を作成するには、genKeyコマンドを使用します。秘密鍵が存在しない場合は、新しい秘密鍵が作成されます。次のコマンドでは、署名アルゴリズムとしてRSA-SHA1を使用してRSA鍵が生成され、test.jksキーストアに別名testが格納されます。
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がパスワードの入力を要求できるようにしてください。
keytool -certreq -alias test -sigalg "RSAwithSHA1" -file certreq_file -storetype jks -keystore test.jks
自己署名証明書を信頼性のあるCA証明書に置き換えます。
既存の自己署名証明書をCAからの証明書に置き換える必要があります。そのためには、-importコマンドを使用します。次のコマンドは、test.jksキーストアの信頼性のあるCA証明書を置き換えます。
keytool -import -alias test -file trustedcafilename -keystore test.jks
Oracle WSMは、安全なフォームで資格証明を管理するため、資格証明ストア・フレームワーク(CSF)を使用します。CSF構成は<domain-home>/config/fmwconfigの下のjps-config.xmlファイルに保持されます。
CSFはWebサービスと他のアプリケーションのために資格証明を保存、検索、および削除する方法を提供します。たとえば、oracle/wss_username_token_client_policyポリシーはbasic.credentialsのデフォルト値があるcsf-keyプロパティを含んでいます。この資格証明はCSFに格納されます。
パスワード資格証明はユーザー名とパスワードを保存できます。汎用的な資格証明はどのような資格証明オブジェクトも保存できます。
別名とキーのペアを使用することで各資格証明はストアに保存されます。マップ名と呼ばれている別名は、様々なキーのグループとそのキーに関連している1つの資格証明を定義する論理名です。すなわち、マップ名とキー名は、ストアで主キーを作るために結合されます。
マップ名は通常、指定しやすくするアプリケーションまたはコンポーネントの名前です。慣例として、Webサービスではoracle.wsm.securityを使用します。
例A-5に示したキーストアの例を考えてみましょう。
例A-5 jps-config.xmlからのキーストアの例
serviceInstance name="keystore" provider="keystore.provider" location="./default-keystore.jks">
<description>Default JPS Keystore Service</description>
<property name="keystore.type" value="JKS"/>
<property name="keystore.csf.map" value="oracle.wsm.security"/>
<property name="keystore.pass.csf.key" value="keystore-csf-key"/>
<property name="keystore.sig.csf.key" value="sign-csf-key"/>
<property name="keystore.enc.csf.key" value="enc-csf-key"/>
</serviceInstance>
キーストア・プロバイダ位置は「秘密鍵の作成、信頼性のある証明書のロード方法」で作成したキーストアの位置を識別する必要があります。
keystore.csf.mapプロパティはCSF別名を含むCSFマップを示します。この場合、keystore.csf.mapは、oracle.wsm.securityの推奨される名前として指定されますが、任意の値をとることができます。
keystore.pass.csf.keyプロパティは、キーストアのユーザー名とパスワードにマップされるCSF別名を示します。パスワードのみが使用されます。キーストアの場合、ユーザー名は冗長です。
keystore.sig.csf.keyプロパティは、署名に使用される、秘密鍵のユーザー名とパスワードにマップされるCSF別名を示します。
keystore.enc.csf.keyプロパティは、復号化に使用される、秘密鍵のユーザー名とパスワードにマップされるCSF別名を示します。
資格証明ストアを更新するには、次の手順に従います。
WLSTを起動します。
実行中のサーバーに接続します。
wls:/offline> connect() Please enter your username [weblogic] :weblogic Please enter your password [...] : Please enter your server URL [t3://localhost:7001] :t3://localhost:7101 Connecting to t3://localhost:7101 with userid weblogic ... Successfully connected to Admin Server 'DefaultServer' that belongs to domain 'DefaultDomain'. Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead. wls:/DefaultDomain/serverConfig>
資格証明ストアにエントリを作成します。
wls:/DefaultDomain/serverConfig> createCred(map="oracle.wsm.security", key="basic.credentials", user="john", desc="test-key")
これにより、キーbasic.credentialsがユーザー名johnでマップoracle.wsm.securityに追加されます。このエントリは、<your domain>/config/fmwconfig/cwallet.sso内に格納されます。
(オプション)キーの値をリストします。
wls:/DefaultDomain/serverConfig> listCred(map="oracle.wsm.security", key="basic.credentials")
Oracle WSM WS-Securityポリシーのデフォルト設定を設計時にプログラム的にオーバーライドすることも可能です(『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照)。
|
注意: アノテーション、Fusion Middleware Control、管理コンソールのいずれかを使用してサーバー側ポリシーをオーバーライドすることはできません。 |
たとえば、csf keyの設定や受信側のキー別名の指定などを行うことができます。その場合は、例A-6に示すように、標準のJAX-WS RequestContextを使用します。
例A-6 Webサービス・クライアントのプログラムによるオーバーライド
import oracle.wsm.security.util.SecurityConstants.ClientConstants;
...
public class MyClientJaxWs {
public void doWork(String[] args) {
try {
RequestContext context = …
// the user code does this for passing the Policy Names that are used for the call
JAXWSService jaxWsService = new JAXWSService ();
weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature []
securityFeature = new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature [] {
new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/wss_
username_token_client_policy") };
JAXWSServicePort port = jaxWsService.getJaxWsServicePort(securityFeature);
context.put(BindingProvider.USERNAME_PROPERTY, getCurrentUsername() );
context.put(BindingProvider.PASSWORD_PROPERTY, getCurrentPassword() );
context.put(ClientConstants.WSSEC_KEYSTORE_LOCATION, "c:/mykeystore.jks");
context.put(ClientConstants.WSSEC_KEYSTORE_PASSWORD, "keystorepassword" );
context.put(ClientConstants.WSSEC_KEYSTORE_TYPE, "JKS" );
context.put(ClientConstants.WSSEC_SIG_KEY_ALIAS, "your signature alias" );
context.put(ClientConstants.WSSEC_SIG_KEY_PASSWORD, "your signature password" );
context.put(ClientConstants.WSSEC_ENC_KEY_ALIAS, "your encryption alias" );
context.put(ClientConstants.WSSEC_ENC_KEY_PASSWORD, "your encryption password" );
System.out.println(proxy.myOperation("MyInput"));
…
} catch (Exception e) {
e.printStackTrace();
}
}
}
この項では、カスタム・アサーションの作成方法について説明します。内容は次のとおりです。
事前定義済のアサーション・テンプレート(『Webサービスのためのセキュリティおよび管理者ガイド』の事前定義済アサーション・テンプレートに関する項を参照)がニーズに合わない場合は、固有のカスタム・アサーションを作成できます。
カスタム・アサーションを作成するには、次のファイルを作成する必要があります。
カスタム・アサーション・クラス: Javaクラスとその解析および適用のロジックを実装します。
カスタム・ポリシー・ファイル: カスタム・アサーションのバインディングの定義とカスタム・アサーションの構成が可能です。
カスタム・アサーション・クラスとポリシー・ファイルをJARファイルとしてパッケージ化し、そのJARファイルをドメインのCLASSPATHで使用できるようにします。次に、必要に応じてカスタム・ポリシー・ファイルをインポートし、Webサービスまたはクライアントにアタッチします。
以降の項では、このプロセスの各手順について説明します。
カスタム・ポリシー・ファイルを作成し、カスタム・アサーションのバインディングの定義とカスタム・アサーションの構成を行います。カスタム・ポリシー・ファイルとカスタム・アサーションの作成に使用できるスキーマについては、『Webサービスのためのセキュリティおよび管理者ガイド』のカスタム・アサーションのスキーマ参照に関する項を参照してください。
次の例では、oracle/ip_assertion_policyカスタム・ポリシー・ファイルが定義されます。アサーションは、リクエストに対して有効なIPアドレスのカンマ区切りリストを定義します。
エグゼキュータ・クラスは、<orawsp:Implementation>sampleassertion.IpAssertionExecutor</orawsp:Implementation>と指定されています。
例A-7 カスタム・ポリシー・ファイルの例
<?xml version = '1.0' encoding = 'UTF-8'?>
<wsp:Policy xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:orasp="http://schemas.oracle.com/ws/2006/01/securitypolicy"
orawsp:status="enabled"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" orawsp:category="security"
orawsp:attachTo="binding.server" wsu:Id="ip_assertion_policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
wsp:Name="oracle/ip_assertion_policy">
<orasp:ipAssertion orawsp:Silent="true" orawsp:Enforced="true"
orawsp:name="WSSecurity IpAssertion Validator" orawsp:category="security/authentication">
<orawsp:bindings>
<orawsp:Implementation>sampleassertion.IpAssertionExecutor</orawsp:Implementation>
<orawsp:Config orawsp:name="ipassertion" orawsp:configType="declarative">
<orawsp:PropertySet orawsp:name="valid_ips">
<orawsp:Property orawsp:name="valid_ips" orawsp:type="string"
orawsp:contentType="constant">
<orawsp:Value>127.0.0.1,192.168.1.1</orawsp:Value>
</orawsp:Property>
</orawsp:PropertySet>
</orawsp:Config>
</orawsp:bindings>
</orasp:ipAssertion>
</wsp:Policy>
カスタム・ポリシー・ファイルを作成したら(ステップ1)、それをポリシー・ストアに追加する必要があります。Fusion Middleware Controlを使用してポリシーをインポートできます(『Webサービスのためのセキュリティおよび管理者ガイド』のWebサービス・ポリシーのインポートに関する項を参照)。
カスタム・アサーション・クラスを作成し、ポリシー・アサーションのロジックを実行および検証します。カスタム・アサーション・クラスはoracle.wsm.policyengine.impl.AssertionExecutorを拡張している必要があります。
カスタム・アサーション・クラスを作成する際に、wsm-policy-core.jarとwsm-agent-core.jarのJARファイルがCLASSPATHに含まれていることを確認します。
次の例は、リクエストのIPアドレスを検証するために使用できるカスタム・アサーション・エグゼキュータを示しています。リクエストのIPアドレスが無効の場合は、FAULT_FAILED_CHECK例外がスローされます。
固有のカスタム・アサーション・クラスの開発に使用できるAPIの詳細は、Oracle Web Services ManagerのJava APIリファレンスを参照してください。
例A-8 カスタム・アサーション・クラスの例
package sampleassertion;
import oracle.wsm.common.sdk.IContext;
import oracle.wsm.common.sdk.IMessageContext;
import oracle.wsm.common.sdk.IResult;
import oracle.wsm.common.sdk.Result;
import oracle.wsm.common.sdk.WSMException;
import oracle.wsm.policy.model.IAssertionBindings;
import oracle.wsm.policy.model.IConfig;
import oracle.wsm.policy.model.IPropertySet;
import oracle.wsm.policy.model.ISimpleOracleAssertion;
import oracle.wsm.policy.model.impl.SimpleAssertion;
import oracle.wsm.policyengine.impl.AssertionExecutor;
public class IpAssertionExecutor extends AssertionExecutor {
public IpAssertionExecutor() {
}
public void destroy() {
}
public void init(oracle.wsm.policy.model.IAssertion assertion,
oracle.wsm.policyengine.IExecutionContext econtext,
oracle.wsm.common.sdk.IContext context) {
this.assertion = assertion;
this.econtext = econtext;
}
public oracle.wsm.policyengine.IExecutionContext getExecutionContext() {
return this.econtext;
}
public boolean isAssertionEnabled() {
return ((ISimpleOracleAssertion)this.assertion).isEnforced();
}
public String getAssertionName() {
return this.assertion.getQName().toString();
}
/**
* @param context
* @return
*/
public IResult execute(IContext context) throws WSMException {
try {
IAssertionBindings bindings =
((SimpleAssertion)(this.assertion)).getBindings();
IConfig config = bindings.getConfigs().get(0);
IPropertySet propertyset = config.getPropertySets().get(0);
String valid_ips =
propertyset.getPropertyByName("valid_ips").getValue();
String ipAddr = ((IMessageContext)context).getRemoteAddr();
IResult result = new Result();
if (valid_ips != null && valid_ips.trim().length() > 0) {
String[] valid_ips_array = valid_ips.split(",");
boolean isPresent = false;
for (String valid_ip : valid_ips_array) {
if (ipAddr.equals(valid_ip.trim())) {
isPresent = true;
}
}
if (isPresent) {
result.setStatus(IResult.SUCCEEDED);
} else {
result.setStatus(IResult.FAILED);
result.setFault(new WSMException(WSMException.FAULT_FAILED_CHECK));
}
} else {
result.setStatus(IResult.SUCCEEDED);
}
return result;
} catch (Exception e) {
throw new WSMException(WSMException.FAULT_FAILED_CHECK, e);
}
}
public oracle.wsm.common.sdk.IResult postExecute(oracle.wsm.common.sdk.IContext p1) {
IResult result = new Result();
result.setStatus(IResult.SUCCEEDED);
return result;
}
}
ステップ3で作成したカスタム・アサーション・クラス・ファイルを含むJARファイルを作成します。JARファイルの生成には、Oracle JDeveloper、別のIDE、またはjarツールを使用できます。
JARファイルにはクラス・ファイルとマニフェスト・ファイルが含まれている必要があります。例:
$ jar -tvf assertionjar.jar
25 Tue Oct 06 14:40:10 PDT 2009 META-INF/MANIFEST.MF
3558 Tue Oct 06 14:40:10 PDT 2009 sampleassertion/IpAssertionExecutor.class
次のファイルをCLASSPATHに追加する必要があります。
ステップ2で作成したカスタム・ポリシーJARファイル。
ステップ4で作成したカスタム・アサーションJARファイル(カスタム・アサーション実行クラスをサーバー環境で使用できるようにするため)。
JARファイルをCLASSPATHに追加するには、次の手順を実行します。
WebLogic Serverを停止します。
WebLogic Serverの停止の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。
ステップ2および4で作成したカスタム・ポリシーJARファイルとカスタム・アサーションJARファイルを$DOMAIN_HOME/libディレクトリにコピーします。
WebLogic Serverを再起動します。
WebLogic Serverの再起動の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。
JAX-WS Webサービスを開発してデプロイします。次に示すのは、JAX-WS Webサービスのごく単純な例です。
package project1;
import javax.jws.WebService;
@WebService
public class Class1 {
public Class1() {
super();
}
public String echo1() {
return "one";
}
}
JAX-WS Webサービスの開発およびデプロイの詳細は、次のドキュメントを参照してください。
Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド
Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング
Oracle JDeveloperオンライン・ヘルプのWebサービスを使用した開発に関する項
Oracle WebLogic管理コンソールを使用して、カスタム・ポリシーをJAX-WS Webサービスにアタッチします。詳しい手順は、Oracle WebLogic Server Webサービスの保護の管理コンソールを使用した実行時のポリシー・ファイルの関連付けに関する項を参照してください。
管理コンソールまたはFusion Middleware Controlを使用して、Oracle WSM WS-Securityポリシーで保護されるWebLogic JAX-WS Webサービスをモニターおよびテストできます。
管理コンソールからWebサービスをテストするか、またはモニターするには、次の手順に従います。
「デプロイメントのサマリー」ページから、Webサービスをテストするアプリケーションを選択します。
設定ページから、「テスト」タブを選択してWebサービスをテストするか、「監視」タブを選択してWebサービスをモニターします。
Fusion Middleware ControlからWebサービスをテストまたはモニターする場合は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
