| Oracle® Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護 12c (12.2.1.2.0) E82854-02 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護 12c (12.2.1.2.0) E82854-02 |
|
|
前へ |
次へ |
この章の内容は次のとおりです:
メッセージ・レベルのセキュリティでは、クライアント・アプリケーションと、そのクライアントによって呼び出されるWebサービスとの間のSOAPメッセージに、デジタル署名または暗号化(あるいはその両方)を施すかどうかを指定します。複数のSOAPメッセージを交換するイベントにおいて、Webサービスとクライアント間の共有セキュリティ・コンテキストを指定することもできます。メッセージ・レベルのセキュリティは次のことを実現します。
メッセージ部分の暗号化による機密性
デジタル署名による整合性
ユーザー名トークン、X.509トークンまたはSAMLトークンを要求することによる認証
簡易なメッセージ・レベルのセキュリティを構成する場合に実行する基本的な手順については、「簡易なメッセージ・レベルのセキュリティの構成」を参照してください。この項では、Webサービス実行時環境の構成、特定のWebサービスに対するメッセージ・レベルのセキュリティの構成、およびそのサービスを呼び出すクライアント・アプリケーションのコーディング方法について説明します。
また、Webサービスをデプロイした後、実行時にWebサービスのメッセージ・レベルのセキュリティを構成することもできます。詳細は、「管理コンソールを使用した実行時のポリシー・ファイルの関連付け」を参照してください。
注意:
SOAP添付ファイルに対しては、デジタル署名も暗号化も行えません。
注意:
「WebLogic Webサービスでサポートされる標準」には、このリリースでサポートされるWebサービス標準が明確に記載されています。
WebLogic Webサービスは、次のOASIS Standard 1.1 Web Services Security (WS-Security 1.1 (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss)仕様(2006年2月1日付)を実装しています。
WS-Security 1.0および1.1
Username Token Profile 1.0および1.1
X.509 Token Profile 1.0および1.1
SAML Token Profile 1.0および1.1
これらの仕様は、セキュリティ・トークンの伝播、メッセージの整合性、およびメッセージの機密性を提供します。これらのメカニズムは、個別に使用する(たとえば、ユーザー認証のためにユーザー名トークンを渡す)か、または組み合せて使用する(たとえば、SOAPメッセージのデジタル署名と暗号化を行い、認証のためにユーザーがX.509証明書を使用すべきことを指定する)ことができます。
WebLogic Webサービスは、Web Services Trust (WS-Trust 1.3)仕様とWeb Services Secure Conversation (WS-SecureConversation 1.3)仕様を実装しており、これらが連携して、Webサービスとそのクライアント(別のWebサービスやスタンドアロンのJavaクライアント・アプリケーション)との間のセキュアな通信を提供します。
WS-Trust仕様には、セキュリティ・トークンのリクエストと発行や信頼関係の仲介を行うためのフレームワークとなる拡張機能が定義されています。
WS-SecureConversation仕様には、複数のメッセージの交換を可能にする、セキュリティ・コンテキストの確立と共有のメカニズムや、セキュリティ・コンテキストからキーを派生するためのメカニズムが定義されています。セキュリティ・コンテキストと派生キーを併用すると、交換のパフォーマンスとセキュリティが全体的に向上します。
WS-Policy仕様では、Webサービスの制約や要件を表現するためのフレームワークが定義されています。これらの制約や要件は、ポリシー・アサーションとして表現されます。
WS-SecurityPolicyでは、WS-Policyフレームワークで使用する一連のセキュリティ・ポリシー・アサーションが定義され、WSSのコンテキストでメッセージを保護する方法(SOAPメッセージ・セキュリティ、WS-TrustおよびWS-SecureConversation)が記述されています。
Webサービスに対してメッセージ・レベルのセキュリティを構成するには、WS-SecurityPolicy仕様に従って、セキュリティ・ポリシー文を格納した1つ以上のポリシー・ファイルをWebサービスにアタッチします。Webサービス実行時環境におけるセキュリティ・ポリシー・ファイルの使用方法の詳細は、「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」を参照してください。
このリリースのWebLogic ServerでサポートされないWeb Services SecurityPolicy 1.2の要素については、「サポートされないWS-SecurityPolicy 1.2アサーション」を参照してください。
Web Services Security: SOAP Message Security仕様の実装では、次の使用例がサポートされます。
SOAPメッセージの署名と暗号化にX.509証明書を使用する場合、SOAPメッセージは、メッセージ保護されたWebサービスを呼び出すクライアント・アプリケーションを起点に、WebサービスのホストであるWebLogic Serverインスタンスへ送られ、またクライアント・アプリケーションに戻ります。
署名または暗号化される、あるいは要求されるSOAPメッセージ・ターゲット(本文、特定のSOAPヘッダー、または特定の要素)を指定します。
認証のためにSOAPメッセージにトークン(ユーザー名、SAML、またはX.509)を含めます。
Webサービスとそのクライアント(別のWebサービスやスタンドアロンのアプリケーション)が、WS-SecureConversation (WSSC)を使用して複数のメッセージを交換するときに、セキュリティ・コンテキストを確立して共有することを指定します。
コンテキストが確立され、Webサービスとそのクライアントの間で共有された時点で、セキュリティ・コンテキストにおける各キー用途に応じてキーを派生します。つまり、個々のSOAPメッセージで2つの派生キー(署名用に1つ、暗号用に1つ)を使用し、各SOAPメッセージが他のSOAPメッセージとは別の派生キーのペアを使用することになります。各SOAPメッセージで派生キーの独自のペアを使用することから、クライアントとWebサービスの間のメッセージ交換はきわめてセキュアなものになります。
1つ以上のセキュリティ・ポリシー・ファイルを使用して、WebLogic Webサービスに対するメッセージ・レベルのセキュリティの詳細を指定します。WS-SecurityPolicy仕様には、Webサービスのセキュリティ・ポリシーを記述して通信するための汎用モデルとXML構文があります。
注意:
WS-SecurityPolicy仕様が規定される以前の旧リリースのWebLogic Serverでは、WS-Policy仕様に基づき、プロプライエタリのセキュリティ・ポリシー・スキーマを使用して記述されたセキュリティ・ポリシー・ファイルを使用していました。このプロプライエタリのセキュリティ・ポリシー・スキーマは非推奨となりましたので、WS-SecurityPolicy1.2形式を使用してください。
このリリースのWebLogic Serverでは、WS-SecurityPolicy 1.2仕様に準拠するセキュリティ・ポリシー・ファイル、またはWebサービス・セキュリティ・ポリシー・スキーマ(WebLogic Server 9で導入)に準拠するセキュリティ・ポリシー・ファイルのいずれかがサポートされますが、同じWebサービスで両方を使用することはできません。これらのフォーマットは互換性がありません。
事前定義済のWS-SecurityPolicy 1.2セキュリティ・ポリシー・ファイルについては、「WS-SecurityPolicy 1.2ポリシー・ファイルの使用」を参照してください。
メッセージ・レベルのセキュリティに使用されるセキュリティ・ポリシー・ファイルは、操作を呼び出した結果として生成されるSOAPメッセージに対してデジタル署名または暗号化を行うかどうかとその方法が記述されたXMLファイルです。この中では、クライアント・アプリケーションがユーザー名トークン、SAMLトークンまたはX.509トークンを使用して自身を認証することの指定もできます。
ポリシー・ファイルをWebサービスと関連付けるには、JWSファイル内で@Policyおよび@Policies JWSアノテーションを使用します。Webサービスに関連付けることのできるポリシー・ファイルの数に制限はありませんが、アサーションが互いに矛盾しないようにする必要があります。ポリシー・ファイルは、JWSファイルのクラス・レベルでも、メソッド・レベルでも指定できます。
注意:
Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。
また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。
この項では、次のトピックについて説明します。
移植性を最大限に高めるため、JAX-WSではWS-Policy 1.2およびOASIS WS-SecurityPolicy 1.2を使用することをお薦めします。
WebLogic Serverは、次のネームスペースを使用するWS-Policy 1.2をサポートしています。
http://schemas.xmlsoap.org/ws/2004/09/policy
注意:
WebLogic Serverは、ネームスペースhttp://www.w3.org/ns/ws-policyを使用するWS-Policy 1.5 (現在のW3C規格)もサポートしています。
次のOASIS WS-SX TC Web Services SecurityPolicyネームスペースがサポートされます。
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
この新しいバージョンのネームスペースに加えて、WebLogic Serverは次のWeb Services SecurityPolicyネームスペースも引き続きサポートします。
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
ほとんどの場合、ポリシー・アサーションはどちらのネームスペースでも同じですが、次の例外があります。
Trust10およびTrust13のアサーション。Trust10とTrust13両方のアサーションがサポートされます。
SC10SecurityContextTokenおよびSC13SecurityContextToken (「仕様の後方互換性」を参照)。
異なるWSSCバージョンを使用した派生キー(200502、1.3)。
このバージョンのWebLogic Serverでは、バージョンに依存しないポリシーがサポートされます。異なるバージョンのWS-Policy仕様に基づいたWS-SecurityPolicyやWS-ReliableMessagingポリシーなどのプロトコル固有のポリシーを組み合せることができます。実行時に、結合されたポリシー・ファイルには複数の異なるネームスペースが含まれます。
このリリースのWebLogic Serverでは、次の3つのバージョンのWS-SecurityPolicyが用意されています。
(1) WS-SecurityPolicy 1.2 OASIS標準。
(2) WS-SecurityPolicy 1.2 (WebLogic Server 10.0に含まれます)。
(3) 独自形式のWebLogic Server 9.xスタイルのポリシー(非推奨)。
(1)、(2)、または(1)と(2)の組合せと任意のバージョンのWS-Policyを組み合せることができます。しかし、(1)または(2)や異なるバージョンのWS-Policyと(3)を組み合せることはできません。
考えられるバージョンの組合せを表2-1に示します。
表2-1 バージョンに依存しないポリシーの対応表
| セキュリティ・ポリシーのバージョン | WS-Policy 1.5 | WS-Policy 1.2 | WS-Policy 1.5とWS-Policy 1.2 |
|---|---|---|---|
WS-SecurityPolicy 1.2 OASIS標準 |
可 |
可 |
可 |
WS-SecurityPolicy 1.2 (WebLogic Server 10.0) |
可 |
可 |
可 |
WS-SecurityPolicy 1.2 OASIS標準とWS-SecurityPolicy 1.2 (WebLogic Server 10.0) |
可 |
可 |
可 |
WebLogic Server 9.xスタイル |
可 |
可 |
不可 |
WebLogic Server 9.xスタイルとWS-SecurityPolicy 1.2 OASIS標準またはWS-SecurityPolicy 1.2 (WebLogic Server 10.0) |
不可 |
不可 |
不可 |
使用されているポリシーまたはセキュリティ・ポリシーのバージョンをクライアント・プログラムが認識する必要がある場合は、ネームスペースとバージョニングの情報を戻すバージョニングAPIを使用してください。
WebLogic Server Webサービス・セキュリティ・ポリシーでは、デジタル署名のハッシュのためにSHA-1およびより強固なSHA-2 (SHA-256)セキュア・ハッシュ・アルゴリズムの両方がサポートされています。FIPS 140-2モードには、SHA-2セキュア・ハッシュ・アルゴリズムに加え、拡張アルゴリズム・スイート・ポリシーでサポートされる、さらに強固なデジタル署名メソッド・アルゴリズムが必要です。詳細は、「拡張アルゴリズム・スイートの使用」を参照してください。FIPS-140モードのデジタル署名がご使用の環境で必須でない場合、SHA-256ポリシーを使用できます。
注意:
SHA-1セキュア・ハッシュ・アルゴリズムは、FIPSモードではサポートされません。詳細は、Oracle WebLogic Serverセキュリティの管理のFIPSモードの有効化を参照してください。
事前定義済のWebサービス・セキュリティ・ポリシーは、<sp:AlgorithmSuite>要素で使用する特定のアルゴリズムを選択します。
WebLogic Serverには、特にSHA-256セキュア・ハッシュ・アルゴリズムを使用するWssp1.2-2007-Wss1.1-X509-Basic256Sha256.xmlのようなポリシーが含まれています。表2-2を参照してください。
使用するポリシーのSHA-256バージョンが存在する場合、古いSHA-1バージョンよりもSHA-250のご使用をお薦めします。
注意:
セキュリティを最大限に強化するため、可能であればSHA-1のかわりにSHA-256を使用することをお薦めします。
使用しているポリシーが古いバージョンのSHA-1の場合は、SHA-256を使用するようWebサービスを更新することをお薦めします。
表2-2 SHA-256ポリシーの使用
| このSHA-1ポリシーのかわりに | ...このSHA-256ポリシーを使用します |
|---|---|
Wssp1.2-2007-Https-UsernameToken-Plain.xml |
Wssp1.2-2007-Https-UsernameToken-Plain-Basic256Sha256.xml |
Wssp1.2-2007-Wss1.1-X509-Basic256.xml |
Wssp1.2-2007-Wss1.1-X509-Basic256Sha256.xml |
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xml |
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256Sha256.xml |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xml |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256Sha256.xml |
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xml |
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1-Basic256Sha256.xml |
Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml |
Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Basic256Sha256.xml |
Wssp1.2-2007-Saml2.0-Bearer-Https.xml |
Wssp1.2-2007-Saml2.0-Bearer-Https-Basic256Sha256.xml |
この項にリストされている事前定義済のポリシーでは、デジタル署名にSHA-1が使用されます。『NIST Special Publication 800-131A』の「Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths」に記載されているように、このハッシュ・アルゴリズムでは、セキュリティに関するお客様の現在または将来の要求に応えられない可能性があります。
現在、このポリシーをひとつでも使用しているお客様には次のことをお薦めします。
次の事前定義済のポリシーでは、SHA-1アルゴリズムが使用されています。この項での説明に従って、SHA-256を使用するようにポリシーを編集します。
Wssp1.2-2007-Saml1.1-Bearer-Wss1.1.xml
Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.0.xml
Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.1-Asymmetric.xml
Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.1-IssuedToken.xml
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xml
Wssp1.2-2007-Saml2.0-Bearer-Wss1.1.xml
Wssp1.2-2007-Saml2.0-HolderOfKey-Wss1.1-Asymmetric.xml
Wssp1.2-2007-Saml2.0-HolderOfKey-Wss1.1-IssuedToken.xml
Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml
Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Asymmetric.xml
次の事前定義済のポリシーでは、SHA-1アルゴリズムが使用されています。この項での説明に従って、SHA-256を使用するようにポリシーを編集します。
Wssp1.2-2007-Wss1.0-UsernameToken-Digest-X509-Basic256.xml
Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml
Wssp1.2-2007-Wss1.0-X509-Basic256.xml
Wssp1.2-Wss1.0-UsernameToken-Digest-X509-Basic256.xml
Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic256.xml
Wssp1.2-Wss1.0-X509-Basic256.xml
Wssp1.2-Wss1.0-X509-EncryptRequest-SignResponse.xml
Wssp1.2-Wss1.0-X509-SignRequest-EncryptResponse.xml
次の事前定義済のポリシーでは、SHA-1アルゴリズムが使用されています。この項での説明に従って、SHA-256を使用するようにポリシーを編集します。
Wssp1.2-2007-Wss1.1-DK-X509-SignedEndorsing.xml
Wssp1.2-2007-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml
Wssp1.2-2007-Wss1.1-UsernameToken-Digest-DK.xml
Wssp1.2-2007-Wss1.1-UsernameToken-Digest-EncryptedKey.xml
Wssp1.2-2007-Wss1.1-UsernameToken-Digest-X509-Basic256.xml
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-DK.xml
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xml
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xml
Wssp1.2-2007-Wss1.1-X509-Basic256.xml
Wssp1.2-Wss1.1-DK.xml
Wssp1.2-Wss1.1-DK-X509-Endorsing.xml
Wssp1.2-Wss1.1-EncryptedKey.xml
Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml
Wssp1.2-Wss1.1-UsernameToken-DK.xml
Wssp1.2-Wss1.1-X509-Basic256.xml
Wssp1.2-Wss1.1-X509-EncryptRequest-SignResponse.xml
Wssp1.2-Wss1.1-X509-SignRequest-EncryptResponse.xml
次の事前定義済のポリシーでは、SHA-1アルゴリズムが使用されています。この項での説明に従って、SHA-256を使用するようにポリシーを編集します。
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-Saml1.1-Bearer.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
Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1-Saml1.1-Bearer.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-Saml1.1-SenderVouches.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml1.1-SenderVouches.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml2.0-Bearer.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-UsernameToken-Plain-EncryptedKey.xml
Wssp1.2-Wssc200502-Bootstrap-Wss1.1.xml
デジタル署名を使用している場合、WebLogic ServerのWebサービス・セキュリティ・ポリシーには、FIPS-140-2認定に必要な拡張アルゴリズム・スイート(EAS)をサポートする一連のポリシーが含まれます。FIPS 140-2認定が必要な場合は、これらのEASポリシーのいずれかをWebサービスにアタッチできます。または、ポリシーのいずれも環境要件を満たさない場合は、既存のポリシーのアルゴリズム・スイートを編集してそれをかわりに使用できます。
WebLogic ServerのWebサービス・ポリシーでサポートされる標準アルゴリズム・スイートと、アルゴリズム・スイート表で使用される省略名はWS-SecurityPolicy 1.3仕様で定義されています。この仕様はhttp://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/errata01/os/ws-securitypolicy-1.3-errata01-os-complete.html#_Toc325573605で参照できます。
Wssp1.2-2007-Wss1.1-X509-Eas256.xmlなどの拡張アルゴリズム・スイート・ポリシーでは、より強力なSHA-256ハッシュ・アルゴリズムと署名メソッド・アルゴリズムを使用します。
表2-3に、拡張アルゴリズム・スイート・ポリシーの対称署名(Sym Sig)と非対称署名(Asym Sig)の値および関連付けられたアルゴリズムのURIを示します。
表2-3 拡張アルゴリズム・スイートの署名値
| プロパティ・アルゴリズム | 値/省略値 | アルゴリズムURI |
|---|---|---|
| [Sym Sig] | HmacSha256 | http://www.w3.org/2000/09/xmldsig#hmac-sha256 |
| [Asym Sig] | RsaSha256 | http://www.w3.org/2000/09/xmldsig#rsa-sha256 |
RSA-SHA256およびHMAC-SHA256のXML署名は、次のサイトで入手可能なw3c XMLセキュリティ・アルゴリズム・クロスリファレンス仕様で定義されています。
http://www.w3.org/TR/xmlsec-algorithms/表2-4に、拡張アルゴリズム・スイート・ポリシーのアルゴリズム・スイートを示します。
表2-4 拡張アルゴリズム・スイート・ポリシーのアルゴリズム・スイート
| アルゴリズム・スイート | ダイジェスト | 暗号化 | 対称鍵のラップ | 非対称鍵のラップ | 暗号化鍵の導出 | 対称署名 | 非対称署名 | 署名キーの導出 | 署名キーの最小長 |
|---|---|---|---|---|---|---|---|---|---|
Basic256Exn256 |
Sha256 |
Aes256 |
KwAes256 |
KwRsaOaep |
PSha1L256 |
HmacSha256 |
RsaSha256 |
PSha1L192 |
256 |
Basic192Exn256 |
Sha256 |
Aes192 |
KwAes192 |
KwRsaOaep |
PSha1L192 |
HmacSha256 |
RsaSha256 |
PSha1L192 |
192 |
Basic128Exn256 |
Sha256 |
Aes128 |
KwAes128 |
KwRsaOaep |
PSha1L128 |
HmacSha256 |
RsaSha256 |
PSha1L128 |
128 |
TripleDesExn256 |
Sha256 |
TripleDes |
KwTripleDes |
KwRsaOaep |
PSha1L192 |
HmacSha256 |
RsaSha256 |
PSha1L192 |
192 |
Basic256Exn256Rsa15 |
Sha256 |
Aes256 |
KwAes256 |
KwRsa15 |
PSha1L256 |
HmacSha256 |
RsaSha256 |
PSha1L192 |
256 |
Basic192Exn256Rsa15 |
Sha256 |
Aes192 |
KwAes192 |
KwRsa15 |
PSha1L192 |
HmacSha256 |
RsaSha256 |
PSha1L192 |
192 |
Basic128Exn256Rsa15 |
Sha256 |
Aes128 |
KwAes128 |
KwRsa15 |
PSha1L128 |
HmacSha256 |
RsaSha256 |
PSha1L128 |
128 |
TripleDesExn256Rsa15 |
Sha256 |
TripleDes |
KwTripleDes |
KwRsa15 |
PSha1L192 |
HmacSha256 |
RsaSha256 |
PSha1L192 |
192 |
<sp:AlgorithmSuite>要素で使用する特定のアルゴリズムを選択します。 注意:
セキュリティを強化するために、拡張アルゴリズム・スイート・ポリシーを非FIPSモードで使用することもできます。ただし、これらのポリシーではアルゴリズム・スイートに対して独自のネームスペースを使用しているため、ターゲット・プラットフォームが拡張アルゴリズム・スイートのアサーションをサポートしていない場合、他のプラットフォームとの相互運用性の問題が生じる場合があります。拡張アルゴリズム・スイート・ポリシーを使用する前に、次の点を考慮してください。FIPS 140-2認証を必要とするWebサービスがある場合、EASポリシーを使用します。
他のプラットフォームと相互運用する必要はないがセキュリティを強化する必要のある新しいWebサービスがある場合は、EASポリシーを使用できます。
この項では、Webサービス・セキュリティ・ランタイム、特定のWebLogic Webサービス、およびWebサービスの操作を呼び出すクライアント・アプリケーションに、簡易なメッセージ・レベルのセキュリティを構成する手順について説明します。このドキュメントでは、簡易なメッセージ・レベルのセキュリティを次のように定義します。
メッセージ保護されたWebサービスは、ユーザーが作成したWS-SecurityPolicyファイルではなく、事前定義済のWS-SecurityPolicyファイルを使用してセキュリティ要件を指定します。これらのファイルについては、「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」で説明しています。
Webサービスは、関連付けられたセキュリティ・ポリシー・ファイルを、公開されているデプロイ済WSDLにアタッチして公開します。
Webサービス・ランタイムは、暗号化とデジタル署名に、固有のキー・ペアではなく、デフォルトのキーストアに用意されている、すぐに使用可能な秘密鍵とX.509証明書のペアを使用します。これらのすぐに使用できるペアは、WebLogic Serverコア・セキュリティ・サブシステムでSSLにも使用されるもので、デモやテストの目的で提供されています。このため、本番では独自のキーストアおよびキー・ペアを使用することを強くお薦めします。すぐに使用できるペア以外のキー・ペアを使用する場合は、「すぐに使用できるSSLペア以外のキー・ペアの使用」を参照してください。
注意:
それぞれのWebLogic Serverインスタンスが別々のコンピュータ上で実行されているクラスタにWebサービスをデプロイする場合は、テスト目的であっても、すぐに使用できるもの以外のキーストアおよびキー・ペアを使用する必要があります。これは、デフォルトのWebLogic ServerキーストアDemoIdentity.jks内のキー・ペアが、異なるマシン上で動作しているWebLogic Server間で同じになるという保証がないためです。
デフォルトのキーストアを使用する場合は、デプロイされているWebサービスのWSDLで、これらのキーストアの1つから公開鍵が指定されますが、実際にはサービスの呼出しは、別のコンピュータ上で実行されているサーバーによって処理される可能性があり、この場合、サーバーの秘密鍵は、公開されている公開鍵に一致せず、呼出しが失敗してしまいます。この問題は、クラスタ内でデフォルトのキーストアとキー・ペアを使用した場合に発生するものであり、独自のキーストアとキー・ペアを使用することで簡単に解決されます。
Webサービスを呼び出すクライアントは、X.509トークンではなく、ユーザー名トークンを使用して自身を認証します。
Webサービスを呼び出すクライアントは、WebLogic Serverで実行されているモジュールではなく、スタンドアロンのJavaアプリケーションです。
後半の項では、前述の一部シナリオの詳細と、簡易なメッセージ・レベルのセキュリティの使用例に基づいたWebサービス・セキュリティのその他の使用例について説明します。
次の手順では、WebLogic Webサービスを実装するJWSファイルがすでに作成されており、SOAPメッセージにデジタル署名と暗号化が行われるようにそのファイルを更新することを前提としています。また、Antビルド・スクリプトを使用してWebサービスを反復的に開発することと、新しい情報で更新できる有効なbuild.xmlファイルがあることも前提となっています。さらに、保護されていないWebサービスを呼び出すクライアント・アプリケーションも用意されているものとします。これらの前提条件が満たされていない場合は、次のドキュメントを参照してください。
Oracle WebLogic Server JAX-WS Webサービスの開発
Oracle WebLogic Server JAX-RPC Webサービスの開発
WebLogic Webサービスに対して簡易なメッセージ・レベルのセキュリティを構成するには:
簡易なメッセージ・レベルのセキュリティの使用例に基づいたWebサービス・セキュリティのその他の使用例については、次の項を参照してください。
メッセージ保護されたWebサービスの問題をデバッグする方法については、「システム・プロパティを使用したメッセージ・レベルのセキュリティのデバッグ」を参照してください。
クライアントがSOAPリクエストのデジタル署名に使用し、WebLogic ServerがクライアントへのSOAPレスポンスの暗号化に使用するX.509証明書をWebLogic Serverで検証できることを確認しておく必要があります。以下のいずれかを実行します。
信頼性のある認証局で発行されているためにWebLogic Serverが自動的に信頼するデジタル証明書をクライアント・アプリケーションが取得することを確認します。
WebLogic Serverによって信頼される個々の証明書をすべて登録する証明書レジストリを作成し、登録された証明書のいずれかをクライアントが使用することを確認します。
詳細は、Oracle WebLogic Serverセキュリティの管理のSSL証明書の検証を参照してください。
JWSファイルで@Policyアノテーションおよび@Policiesアノテーションを使用して、Webサービスに1つ以上のポリシー・ファイルがアタッチされるように指定できます。これらのアノテーションは、クラス・レベルまたはメソッド・レベルのいずれかで使用できます。
注意:
Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。
また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。
追加のポリシー・オプションについては、「CLASSPATHからのポリシーのロード」を参照してください。
@Policiesアノテーションは、複数の@Policyアノテーションをグループ化するものです。複数のポリシー・ファイルをクラスまたはメソッドにアタッチする場合は、@Policiesアノテーションを使用してください。ポリシー・ファイルを1つのみアタッチする場合は、@Policyを単独で使用できます。
@Policyアノテーションでは、1つのポリシー・ファイル、その場所、ポリシーがSOAPのリクエスト・メッセージ、レスポンス・メッセージ、またはその両方のいずれに適用されるか、およびそのポリシー・ファイルをサービスの公開WSDLにアタッチするかどうかを指定します。
uri属性の設定ポリシー・ファイルの場所は、uri属性を使用して次のように指定します。
WebLogic Serverとともにインストールされる事前定義済のセキュリティ・ポリシー・ファイルを指定するには、次の例に示すように、policy:接頭辞とポリシー・ファイルの名前を使用します。
@Policy(uri="policy:Wssp1.2-2007-Https-BasicAuth.xml")
事前定義済のポリシー・ファイルを使用する場合は、自分でファイルを作成したり、アクセス可能な場所にファイルをパッケージ化したりする必要はありません。このため、できるだけ事前定義済のポリシー・ファイルを使用することをお薦めします。
事前定義済のポリシー・ファイルで提供されるメッセージ・レベルの各種セキュリティについては、「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」を参照してください。
ユーザーが作成したポリシー・ファイルを指定するには、次の例に示すように、JWSファイルの場所を基準とした相対パスと名前を指定します。
@Policy(uri="../policies/MyPolicy.xml")
この例では、MyPolicy.xmlファイルは、JWSファイルを格納するディレクトリのpolicies兄弟ディレクトリにあります。
共有Java EEライブラリにあるポリシー・ファイルも指定できます。この方法は、別々のJava EEアーカイブにパッケージ化された複数のWebサービス間でファイルを共有する場合に便利です。
注意:
この場合、ポリシー・ファイルが共有Java EEライブラリのMETA-INF/policiesディレクトリまたはWEB-INF/policiesディレクトリにあることを前提としています。ライブラリをパッケージ化する際には、必ずこのディレクトリにポリシー・ファイルを入れてください。
共有Java EEライブラリにあるポリシー・ファイルを指定するには、次の例に示すように、policy接頭辞とポリシー・ファイルの名前を使用します。
@Policy(uri="policy:MySharedPolicy.xml")
共有ライブラリの作成、およびWebサービスが共有のポリシー・ファイルを検出できるようにするための環境設定については、Oracle WebLogic Serverアプリケーションの開発の共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。
@Policyアノテーションでは次の属性も設定できます。
direction: ポリシー・ファイルがリクエスト(着信) SOAPメッセージ、レスポンス(発信) SOAPメッセージ、またはその両方のいずれに適用されるかを指定します。この属性を指定しない場合のデフォルト値は、bothです。direction属性には、以下の値を指定できます。
Policy.Direction.both
Policy.Direction.inbound
Policy.Direction.outbound
attachToWsdl: ポリシー・ファイルを、Webサービスのパブリック規約を記述したWSDLファイルにアタッチするかどうかを指定します。この属性のデフォルト値はfalseです。
@Policyおよび@Policies JWSアノテーションの使用例次の例では、@Policyおよび@Policies JWSアノテーションの使用方法を示します(該当する個所は太字で示しています)。
例2-1 @Policyおよび@Policiesアノテーションの使用
package wssp12.wss10; import weblogic.jws.WLHttpTransport; import weblogic.jws.Policy; import weblogic.jws.Policies; import javax.jws.WebService; import javax.jws.WebMethod; import javax.jws.Oneway; /** * This web service demonstrates how to use WS-SecurityPolicy 1.2 * to enable message-level security specified in WS-Security 1.0. * * The service authenticates the client with a username token. * Both the request and response messages are signed and encrypted with X509 certificates. * */ @WebService(name="Simple", targetNamespace="http://example.org") @WLHttpTransport(contextPath="/wssp12/wss10", serviceUri="UsernameTokenPlainX509SignAndEncrypt") @Policy(uri="policy:Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml") public class UsernameTokenPlainX509SignAndEncrypt { @WebMethod @Policies({ @Policy(uri="policy:Wssp1.2-2007-SignBody.xml"), @Policy(uri="policy:Wssp1.2-2007-EncryptBody.xml")}) public String echo(String s) { return s; } @WebMethod @Policies({ @Policy(uri="policy:Wssp1.2-2007-SignBody.xml"), @Policy(uri="policy:Wssp1.2-2007-Sign-Wsa-Headers.xml")}) public String echoWithWsa(String s) { return s; } @WebMethod @Policy(uri="policy:Wssp1.2-2007-SignBody.xml", direction=Policy.Direction.inbound) @Oneway public void echoOneway(String s) { System.out.println("s = " + s); } @WebMethod @Policies({ @Policy(uri="policy:Wssp1.2-2007-Wss1.0-X509-Basic256.xml", direction=Policy.Direction.inbound), @Policy(uri="policy:Wssp1.2-2007-SignBody.xml", direction=Policy.Direction.inbound) }) @Oneway public void echoOnewayX509(String s) { System.out.println("X509SignEncrypt.echoOneway: " + s); } }
この例の次の部分は、Webサービスのバインディング・ポリシーであり、対象となるポリシーが指定されています。
@WebService(name="Simple", targetNamespace="http://example.org") @WLHttpTransport(contextPath="/wssp12/wss10", serviceUri="UsernameTokenPlainX509SignAndEncrypt") @Policy(uri="policy:Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml")
この例では、メソッド・レベルでWebサービスにセキュリティ・ポリシー・ファイルがアタッチされています。指定されたポリシー・ファイルは、WebLogic Serverで事前に定義されているファイルです。つまり、開発者が独自のファイルを作成したり、対応するアーカイブにファイルをパッケージ化したりする必要はありません。
Wssp1.2-2007-SignBody.xmlポリシー・ファイルは、SOAPのリクエスト・メッセージおよびレスポンス・メッセージの両方の本文とWebLogicシステム・ヘッダーにデジタル署名が行われることを指定しています。Wssp1.2-2007-EncryptBody.xmlポリシー・ファイルは、SOAPのリクエスト・メッセージおよびレスポンス・メッセージの両方の本文が暗号化されることを指定しています。
このリリースのWebLogic Serverには、ポリシーをCLASSPATHからリソースとしてロードする機能があります。この機能を使用すると、ポリシー・ファイルをWebアプリケーションのルート・ディレクトリにコピーし、JWSファイルの@POLICYアノテーションから名前(mypolicy.xmlなど)で直接参照することができます。
この機能を有効にするには、-Dweblogic.wsee.policy.LoadFromClassPathEnabled=trueを指定してWebLogic Serverを起動します。
この機能を有効にした場合は、ポリシー・ファイルをWEB-INF/policiesディレクトリに移動すると、@POLICYアノテーションの同じmypolicy.xml参照が機能しなくなりますので注意してください。policy:mypolicy.xmlのように、@POLICYアノテーションにポリシー接頭辞を追加する必要が生じます。
「簡易なメッセージ・レベルのセキュリティの構成」で説明した、簡易なメッセージ・レベルの構成手順では、Webサービス・ランタイムが、WebLogic Serverにすぐに使用できる状態で用意されている秘密鍵とX.509証明書のペアを使用することが前提となっています。SSL用のコア・セキュリティ・サブシステムでも同じキー・ペアが使用されますが、このキー・ペアはデモやテストを主目的として用意されています。本番環境では、Webサービス・ランタイムで、独自の秘密鍵とデジタル証明書のペアを2つ使用するのが一般的で、1つはSOAPメッセージの署名用、もう1つはSOAPメッセージの暗号化用です。
次の手順は、これらを使用できるようにするための追加のステップを説明したものです。
メッセージ保護されたWebサービスを呼び出すようにJavaコードを更新する場合には、クライアントのキーストアから秘密鍵とデジタル証明書のペアをロードし、その情報を、セキュリティ・ポリシーで必要とされている場合はユーザー認証用のユーザー名およびパスワードとともに、呼び出されるセキュアなWebLogic Webサービスに渡す必要があります。
Webサービスのセキュリティ・ポリシー・ファイルにSOAPリクエストの暗号化が指定されている場合、Webサービス・クライアント・ランタイムはサービスのWSDLにアタッチされているポリシー・ファイルからサーバーの証明書を自動的に取得し、それを暗号化に使用します。ただし、ポリシー・ファイルがWSDLにアタッチされていない場合や、WSDL自体を使用できない場合には、クライアント・アプリケーションはポリシー・ファイルのクライアント・サイドのコピーを使用する必要があります。詳細については、「クライアント側のセキュリティ・ポリシー・ファイルの使用」を参照してください。
例2-2は、メッセージ保護されたWebLogic Webサービス(「セキュリティ関連アノテーションでのJWSファイルの更新」のJWSファイルを参照)を呼び出すJAX-RPCのJavaクライアント・アプリケーションを示しています。このクライアント・アプリケーションは、次の5つの引数を取ります。
クライアント認証用のクライアント・ユーザー名
クライアント認証用のクライアント・パスワード
クライアントの秘密鍵ファイル
クライアントのデジタル証明書
デプロイされたWebサービスのWSDL
サンプル・クライアント・アプリケーションのセキュリティ固有のコードは太字で示し、サンプルの後で説明します。
例2-2 メッセージ保護されたWebサービスを呼び出す、JAX-RPCを使用したクライアント・アプリケーション
package examples.webservices.security_jws.client; import weblogic.security.SSL.TrustManager; import weblogic.xml.crypto.wss.provider.CredentialProvider; import weblogic.xml.crypto.wss.WSSecurityContext; import weblogic.wsee.security.bst.ClientBSTCredentialProvider; import weblogic.wsee.security.unt.ClientUNTCredentialProvider; import javax.xml.rpc.Stub; import java.util.List; import java.util.ArrayList; import java.security.cert.X509Certificate; /** * Copyright © 1996, 2008, Oracle and/or its affiliates. * All rights reserved. */ public class SecureHelloWorldClient { public static void main(String[] args) throws Throwable { //username or password for the UsernameToken String username = args[0]; String password = args[1]; //client private key file String keyFile = args[2]; //client certificate String clientCertFile = args[3]; String wsdl = args[4]; SecureHelloWorldService service = new SecureHelloWorldService_Impl(wsdl + "?WSDL" ); SecureHelloWorldPortType port = service.getSecureHelloWorldServicePort(); //create credential provider and set it to the Stub List credProviders = new ArrayList(); //client side BinarySecurityToken credential provider -- x509 CredentialProvider cp = new ClientBSTCredentialProvider(clientCertFile, keyFile); credProviders.add(cp); //client side UsernameToken credential provider cp = new ClientUNTCredentialProvider(username, password); credProviders.add(cp); Stub stub = (Stub)port; stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders); stub._setProperty(WSSecurityContext.TRUST_MANAGER, new TrustManager(){ public boolean certificateCallback(X509Certificate[] chain, int validateErr){ return true; } } ); String response = port.sayHello("World"); System.out.println("response = " + response); } }
このコードで注目すべき主な点は次のとおりです。
WebLogicセキュリティTrustManager APIをインポートします。
import weblogic.security.SSL.TrustManager;
次のWebLogic Webサービス・セキュリティAPIをインポートし、Webサービスに関連付けられたポリシー・ファイルで指定されているように、必要なクライアント側の資格証明プロバイダを作成します。
import weblogic.xml.crypto.wss.provider.CredentialProvider; import weblogic.xml.crypto.wss.WSSecurityContext; import weblogic.wsee.security.bst.ClientBSTCredentialProvider; import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
ClientBSTCredentialProvider WebLogic APIを使用して、クライアントの証明書と秘密鍵からバイナリ・セキュリティ・トークン資格証明プロバイダを作成します。
CredentialProvider cp =
new ClientBSTCredentialProvider(clientCertFile, keyFile);
ClientUNTCredentialProvider WebLogic APIを使用して、クライアントのユーザー名とパスワードからユーザー名トークンを作成します。ユーザー名とパスワードはWebLogic Serverによっても認識されます。
cp = new ClientUNTCredentialProvider(username, password);
WSSecurityContext.CREDENTIAL_PROVIDER_LISTプロパティを使用して、バイナリ・セキュリティ・トークンおよびユーザー名トークンを含むListオブジェクトをJAX-RPCスタブに渡します。
stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders)
JAX-WSの場合は、これを次のようにコーディングできます。
import javax.xml.ws.BindingProvider; : Map<String, Object> requestContext = ((BindingProvider) port).getRequestContext(); requestContext.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
weblogic.security.SSL.TrustManager WebLogicセキュリティAPIを使用して、SOAPリクエストの暗号化に使用される証明書が有効かどうかを確認します。Webサービス・クライアント・ランタイムはWebサービスのデプロイされたWSDLからこの証明書を取得しますが、本番の状況では、この証明書は自動的には信頼されないので、クライアント・アプリケーションでは、その証明書を使用してSOAPリクエストを暗号化する前に、証明書が有効であることを確認する必要があります。
stub._setProperty(WSSecurityContext.TRUST_MANAGER,
new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int validateErr){
return true;
}
} );
JAX-WSの場合は、これを次のようにコーディングできます。
requestContext.put(WSSecurityContext.TRUST_MANAGER,
new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain,
int validateErr) {
return true;
}
});
この例は、クライアント側のTrustManager APIを示しています。Webサービス・アプリケーションには、セキュリティを確保するため、適切な検証コードを実装する必要があります。
例2-3は、メッセージ保護されたWebサービスを呼び出す、同じJAX-WSのJavaクライアント・アプリケーションを示しています。このサンプル・クライアント・アプリケーションの中で、JAX-WS固有のコードは太字で表されています。
例2-3 メッセージ保護されたWebサービスを呼び出すJAX-WSのクライアント・アプリケーション
package examples.webservices.security_jaxws.client;
import weblogic.security.SSL.TrustManager;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import javax.xml.ws.BindingProvider;
import java.util.List;
import java.util.Map;
import java.util.ArrayList;
import java.security.cert.X509Certificate;/**
* Copyright © 1996, 2010, Oracle and/or its affiliates.
* All rights reserved.
*/
public class SecureHelloWorldJaxwsClient {
public static void main(String[] args) throws Throwable {
//username or password for the UsernameToken
String username = args[0];
String password = args[1];
//client private key file
String keyFile = args[2];
//client certificate
String clientCertFile = args[3];
String wsdl = args[4];
SecureHelloWorldService service = new SecureHelloWorldService_Impl(wsdl + "?WSDL" );
SecureHelloWorldPortType port = service.getSecureHelloWorldServicePort();
//create credential provider and set it to the request context
List credProviders = new ArrayList();
//client side BinarySecurityToken credential provider -- x509
CredentialProvider cp = new ClientBSTCredentialProvider(clientCertFile, keyFile);
credProviders.add(cp);
//client side UsernameToken credential provider
cp = new ClientUNTCredentialProvider(username, password);
credProviders.add(cp);
Map<String, Object> requestContext = ((BindingProvider) port).getRequestContext();
requestContext.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
requestContext.put(WSSecurityContext.TRUST_MANAGER, new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain,
int validateErr) {
// need to validate if the server cert can be trusted
return true;
}
});
String response = port.sayHello("World");
System.out.println("response = " + response);
}
}
「簡易なメッセージ・レベルのセキュリティの構成」で説明した、簡易なWebサービスの構成手順では、スタンドアロンのクライアント・アプリケーションがメッセージ保護されたWebサービスを呼び出すことが前提となっています。ただし、クライアント自体がEJB、サーブレット、または別のWebサービスの一部として、WebLogic Serverインスタンスで実行されている場合もあります。この場合には、WebLogic Serverコア・セキュリティ・フレームワークを使用して資格証明プロバイダと信頼マネージャを構成して、EJB、サーブレット、またはJWSコードには保護された操作の単純な呼出しのみが含まれ、他のセキュリティ関連のAPIの使用は含まれないようにできます。
次の手順は、この使用例でWebLogic Serverコア・セキュリティ・フレームワークを利用するためのステップを大まかに説明したものです。
すぐに使用できる資格証明プロバイダと信頼マネージャをクライアント・アプリケーションで使用しない場合は、この手順で説明したようにWebLogic Serverコア・セキュリティ・フレームワークを構成する必要はありません。「クライアント側のセキュリティ・ポリシー・ファイルの使用」で説明されているスタンドアロンのJavaコードと同じAPIをEJB、サーブレットおよびJWSコードで使用することで、その構成をすべてオーバーライドできます。ただし、コア・セキュリティ・フレームワークを使用することで、WebLogic Serverの構成が標準化され、Webサービスを呼び出すクライアント・アプリケーションのJavaコードが簡略化されます。
この項では、JAX-WS Webサービスにセキュリティを追加する単純な例を示します。例の中では、次の4つのポリシーをアタッチしています。
Wssp1.2-2007-SignBody.xml
Wssp1.2-2007-EncryptBody.xml
Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml
Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic128.xml
例のコードには大量のインライン・コメントが含まれています。
例2-4は、Webサービス・コードを示しています。
注意:
このWebサービスはattachToWsdl=falseを実装するため、Webサービス・クライアントは、例2-5に示すように、クライアント側バージョンのポリシーをロードする必要があります。
例2-4 WebサービスSignEncrypt.java
package signencrypt;
import java.io.File;
import weblogic.jws.Policies;
import weblogic.jws.Policy;
import weblogic.jws.security.WssConfiguration;
import javax.activation.DataHandler;
import javax.activation.FileDataSource;
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.xml.ws.BindingType;
import javax.xml.ws.soap.MTOM;
import com.sun.xml.ws.developer.SchemaValidation;
/**
*
* Webservice which accepts a SOAP Message which is Signed And
* Encrypted Uses the WS-Policy 1.2
*/
@WebService(name = "SignEncrypt", portName = "SignEncryptPort", serviceName =
"SignEncrypt", targetNamespace = "http://signencrypt")
@BindingType(value = "http://schemas.xmlsoap.org/wsdl/soap/http")
// Domain Level WebserviceSecurity Configuration
@WssConfiguration(value = "Basic-UNT")
@MTOM()
//@SchemaValidation
public class SignEncrypt {
@Policies( {
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml", attachToWsdl=false),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml", attachToWsdl=false),
/*
* WSS 1.1 X509 with symmetric binding and authentication with plain-text
* Username Token which is encrypted and signed using the Symmetric key
*/
/* Use Basic-UNT WssConfiguration */
@Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml",
attachToWsdl=false)
/*
* The client side public certificate and private key is not required in
* this scenario. Username token with plain text password is sent in the
* request for authentication, and signed and encrypted with the symmetric
* key. The symmetric key is encrypted by the server's public key. The client
* also signs and encrypts the request header elements and body with the
* symmetric key. The server signs and encrypts the response body with the
* symmetric key. Both request and response messages include the signed time
* stamps. The encryption method is Basic128.
*/
/* Use untx509webservicesecurity WssConfiguration */
/*
* @Policy(uri =
* "policy:Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic128.xml")
*/})
@WebMethod()
public String echoString(String input) {
String result = "[SignEncrypt.echoString]: " + input;
System.out.println(result);
return result;
}
@WebMethod()
public String echoStringWithoutSecurity(String input) {
String result = "[SignEncrypt.echoString]: " + input;
System.out.println(result);
return result;
}
@WebMethod()
public byte[] echoStringAsByteArray(String data) {
System.out.println("echoByteArray data: " + data);
byte[] output = data.getBytes();
System.out.println("Output Length : " + output.length + " Output: " + output.toString());
return data.getBytes();
}
@Policies( {
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml", attachToWsdl=false),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml", attachToWsdl=false),
/*
* WSS 1.1 X509 with symmetric binding and authentication with plain-text
* Username Token which is encrypted and signed using the Symmetric key
*/
/* Use Basic-UNT WssConfiguration */
@Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml",
attachToWsdl=false)
/*
* The client side public certificate and private key is not required in
* this scenario. Username token with plain text password is sent in the
* request for authentication, and signed and encrypted with the symmetric
* key. The symmetric key is encrypted by the server's public key. The client
* also signs and encrypts the request header elements and body with the
* symmetric key. The server signs and encrypts the response body with the
* symmetric key. Both request and response messages include the signed time
* stamps. The encryption method is Basic128.
*/
/* Use untx509webservicesecurity WssConfiguration */
/*
* @Policy(uri =
* "policy:Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic128.xml")
*/})
@WebMethod()
public byte[] echoByteArrayWithSecurity(byte[] inputData) {
System.out.println("echoByteArrayWithSecurity data: " + inputData.length + " bytes");
return inputData;
}
@WebMethod()
public byte[] echoByteArray(byte[] inputData) {
System.out.println("echoByteArray data: " + inputData);
return inputData;
}
@WebMethod()
public DataHandler getDataHandler(String fileName) {
DataHandler handler = null;
try {
File file = new File(fileName);
System.out.println("file: " + file.getCanonicalPath() + ", " + file.getPath());
FileDataSource fileDataSource = new FileDataSource(file);
handler = new DataHandler(fileDataSource);
} catch(Exception e) {
System.out.println("Error Creating Data Handelr: " + e.getMessage());
}
return handler;
}
@WebMethod()
@Policies( {
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml", attachToWsdl=false),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml", attachToWsdl=false),
/*
* WSS 1.1 X509 with symmetric binding and authentication with plain-text
* Username Token which is encrypted and signed using the Symmetric key
*/
/* Use Basic-UNT WssConfiguration */
@Policy(uri = "policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml", attachToWsdl=false)
/*
* The client side public certificate and private key is not required in
* this scenario. Username token with plain text password is sent in the
* request for authentication, and signed and encrypted with the symmetric
* key. The symmetric key is encrypted by the server's public key. The client
* also signs and encrypts the request header elements and body with the
* symmetric key. The server signs and encrypts the response body with the
* symmetric key. Both request and response messages include the signed time
* stamps. The encryption method is Basic128.
*/
/* Use untx509webservicesecurity WssConfiguration */
/*
* @Policy(uri =
* "policy:Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic128.xml")
*/})
public DataHandler getDataHandlerWithSecurity(String fileName) {
DataHandler handler = null;
try {
File file = new File(fileName);
System.out.println("file: " + file.getCanonicalPath() + ", " + file.getPath());
FileDataSource fileDataSource = new FileDataSource(file);
handler = new DataHandler(fileDataSource);
} catch(Exception e) {
System.out.println("Error Creating Data Handelr: " + e.getMessage());
}
return handler;
}
}
前述のとおり、WebサービスでattachToWsdl=falseが実装されるため、Webサービス・クライアントではクライアント側バージョンのポリシーをロードする必要があります。例2-5に、weblogic.jws.jaxws.ClientPolicyFeatureクラスを使用してクライアント側のポリシーをロードする例を示します。
この例には大量のインライン・コメントが含まれています。
例2-5 SOAClient.java
package signencrypt.client;
import weblogic.jws.jaxws.ClientPolicyFeature;
import weblogic.jws.jaxws.policy.InputStreamPolicySource;
import weblogic.security.SSL.TrustManager;
import weblogic.wsee.policy.runtime.BuiltinPolicyFinder;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.bst.StubPropertyBSTCredProv;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import weblogic.wsee.security.util.CertUtils;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import soa.client.Bpelprocess1ClientEp;
import soa.client.BPELProcess1;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.URL;
import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import javax.activation.DataHandler;
import javax.activation.FileDataSource;
import javax.xml.namespace.QName;
import javax.xml.ws.BindingProvider;
import javax.xml.ws.WebServiceFeature;
import javax.xml.ws.soap.MTOMFeature;
public class SOAClient {
private final static boolean debug = true;
private final static String endpointURL =
"http://....com:8001/soa-infra/services/default/soa/bpelprocess1_client_ep";
private final static String certsDir = "C:/webservices/server/keystores";
private final static String serverKeyStoreName = "default-keystore.jks";
private final static String serverKeyStorePass = "...";
private final static String serverCertAlias = "alice";
private final static String serverKeyPass = "...";
private final static String username = "weblogic";
private final static String password = "...";
private final static String fileName =
"C:/webservices/farallon/owsm-interop/mtom.JPG";
private final static String outputFileName =
"C:/webservices/farallon/owsm-interop/output.jpg";
private final static String[] clientPolicyFileNames =
{
"./policy/Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml",
"./policy/Wssp1.2-2007-SignBody.xml",
"./policy/Wssp1.2-2007-EncryptBody.xml" };
private BPELProcess1 port = null;
/**
* Create the Stub/Port and set the Stub/Port with Client Side Security Policy
* Feature and MTOM Feature.
* @throws Exception
*/
private void createStubWithClientPolicy() throws Exception {
URL url = new URL(endpointURL + "?WSDL");
QName serviceName =
new QName("http://xmlns.oracle.com/SOASecurity/soa/BPELProcess1",
"bpelprocess1_client_ep");
Bpelprocess1ClientEp service = new Bpelprocess1ClientEp(url, serviceName);
QName operationName =
new QName("http://xmlns.oracle.com/SOASecurity/soa/BPELProcess1", "process");
ClientPolicyFeature policyFeature = new ClientPolicyFeature();
// Set the Client Side Policy on the operation with QName <operationName>
policyFeature.setEffectivePolicyForOperation(operationName, new
InputStreamPolicySource(getPolicyInputStreamArray(clientPolicyFileNames)
));
MTOMFeature mtomFeature = new MTOMFeature();
WebServiceFeature[] features = { policyFeature, mtomFeature };
// WebServiceFeature[] features = { mtomFeature };
//WebServiceFeature[] features = {policyFeature};
port = service.getBPELProcess1Pt(features);
}
/**
* Setup the Client Port/Stub used to invoke the webservice with Security
*
* @throws Exception
*/
private void setUp() throws Exception {
createStubWithClientPolicy();
/**
* Get the Server Public Certificate to Encrypt the Symmetric Key or the
* SOAP Message
*/
/**
* Get the Server Public Certificate to Verify the Signature of the
* Symmetric Key or the SOAP Message
*/
X509Certificate serverCert =
(X509Certificate) CertUtils.getCertificate(
certsDir + "/" + serverKeyStoreName, serverKeyStorePass,
serverCertAlias, "JKS").get(0);
List<CredentialProvider> credProviders =
new ArrayList<CredentialProvider>();
/*
* Set up UserNameToken
*/
credProviders.add(new ClientUNTCredentialProvider(username.getBytes(),
password.getBytes()));
Map<String, Object> rc = ((BindingProvider) port).getRequestContext();
/*
* For Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml
* there is no need to specify the client side public certificate and
* private key as this is a symmetric key use case. serverCert is used to
* encrypt the Symmetric Key/Keys
*/
rc.put(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, serverCert);
rc.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
rc.put(WSSecurityContext.TRUST_MANAGER, new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain,
int validateErr) {
// need to validate if the server cert can be trusted
System.out.println("Validating Server Certificate");
return true;
}
});
}
/**
* Returns an array of InputStreams of the policy files
*
* @param policyNames
* @return array of InputStreams of Policy's
* @throws FileNotFoundException
*/
private InputStream[] getPolicyInputStreamArray(String[] policyNames)
throws FileNotFoundException {
InputStream[] inpStreams = new InputStream[policyNames.length];
for (int k = 0; k < policyNames.length; k++) {
System.out.println("policy name: " + policyNames[k]);
inpStreams[k] = getPolicyInputStream(policyNames[k]);
}
return inpStreams;
}
/**
* Returns an InputStream of the policy file
*
* @param myPolicyName
* @return
* @throws FileNotFoundException
*/
private InputStream getPolicyInputStream(String myPolicyName)
throws FileNotFoundException {
return new FileInputStream(myPolicyName);
}
/**
* Invoke the webservice at endpointURL
*
(http://....:9003/soa-infra/services/default/soa/bpelprocess1_client_ep)
*
* @throws Exception
*/
private void invokeProcess() throws Exception {
InputStream inputstream = null;
OutputStream outputstream = null;
try {
File file = new File(fileName);
File outputFile = new File(outputFileName);
inputstream = new BufferedInputStream(new FileInputStream(file));
int bytesAvailable = -1;
int counter = 0;
int bytesRead = 0;
int fileSize = (int) file.length();
byte[] fileInBytes = new byte[fileSize];
bytesRead = inputstream.read(fileInBytes);
System.out.println("bytesRead: " + bytesRead + ", fileSize: " + fileSize + "
fileInBytes: " + fileInBytes.length);
byte[] result = port.process(fileInBytes);
/*byte[] input = "Hello".getBytes();
System.out.println("input length : "+ input.length);
byte[] result = port.process(input);*/
if (!outputFile.exists()) {
outputFile.createNewFile();
}
outputstream = new BufferedOutputStream(new FileOutputStream(outputFile));
if (result != null) {
System.out.println("Result Length: " + result.length);
} else {
System.out.println("result is null");
}
outputstream.write(result);
// System.out.println(result);
} catch (Exception e) {
System.out.println("Error Creating Data Handler: " + e.getMessage());
} finally {
if (inputstream != null) {
inputstream.close();
}
if (outputstream != null) {
outputstream.close();
}
}
}
public static void main(String[] args) {
try {
SOAClient client = new SOAClient();
client.setUp();
//client.createStubWithClientPolicy();
client.invokeProcess();
} catch (Exception e) {
System.out.println("Error calling SOA Webservice: " + e.getMessage());
if (debug) {
e.printStackTrace();
}
}
}
}
WebLogic Serverには、プログラミングを行う上で一般的に必要となるセキュリティ機能に対応する事前定義済のWebサービス・セキュリティ・ポリシー・ファイルが多数用意されていますが、追加の構成が必要な場合は、独自のWS-SecurityPolicyファイルを作成して使用することもできます。セキュリティ・ポリシー・ファイルについての全般的な情報、およびメッセージ・レベルのセキュリティ構成でセキュリティ・ポリシー・ファイルを使用する方法については、「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」を参照してください。
注意:
要素レベルのセキュリティを使用する場合は常に、1つ以上のカスタム・ポリシー・ファイルで、保護の対象となる特定の要素のパスと名前を指定する必要があります。
カスタム・ポリシー・ファイルを作成する場合には、事前定義済のファイルと同じように、3つの主なセキュリティ・カテゴリ(認証、暗号化および署名)を3つの別々のポリシー・ファイルに分割するか、3つのカテゴリすべてを含む1つのポリシー・ファイルを作成することができます。1つのカテゴリ(認証など)のみを変更したカスタム・ポリシー・ファイルを作成し、他のカテゴリについては事前定義済のファイル(Wssp1.2-2007-SignBody.xml、Wssp1.2-SignBody.xmlおよびWssp1.2-2007-EncryptBody、Wssp1.2-EncryptBody)を使用することもできます。つまり、Webサービスに関連付けるポリシー・ファイルの数および内容は、適宜組み合せることができます。ただしこの場合は、組み合せた複数のファイルが互いに矛盾していないことを常に確認する必要があります。
カスタム・ポリシー・ファイルは、WS-SecurityPolicy1.2で定義された標準の形式とアサーションに準拠している必要があります。ただし、このリリースのWebLogic ServerはWS-SecurityPolicy 1.2を完全に実装していませんので注意してください。詳細は、「サポートされないWS-SecurityPolicy 1.2アサーション」を参照してください。WS-SecurityPolicyファイルのルート要素は<Policy>とする必要があります。
このリリースでは、次のネームスペース宣言を使用してください。
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" > . . . </wsp:Policy>
WLSは、セキュリティ・ポリシーの他のネームスペースもサポートしています。たとえば、次の2つのネームスペースもサポートされます。
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512" > . . . </wsp:Policy>
または
<wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" > . . . </wsp:Policy>
事前定義済のWS-SecurityPolicyファイルをテンプレートとして使用して、自分のカスタム・ファイルを作成することもできます。
WebLogic Serverでは、Webサービス・セキュリティで使用するためにセキュリティ・トークン・サービス(STS)からセキュリティ・トークンを取得するWS-Trustクライアントを実装しています。WS-Trustクライアントはクライアント側のWebLogic Server Webサービス・ランタイムによって内部的に使用されます。
WS-Trustクライアントは次のようにして構成できます:
スタンドアロンのWebサービス・クライアントの場合は、Webサービス・クライアント・スタブのプロパティを使用。
サーバー上で実行されるWebサービス・クライアントの場合は、MBeanプロパティを使用。
WebLogic Serverの10gリリース3 (10.3)より前のリリースでは、WS-Trustクライアントは、Webサービスと共存しており、かつWebLogic ServerにホストされているSTSのセキュリティ・トークンしか使用できませんでした。しかし、現在STSに求められるのはWS-Trustクライアントからアクセスできることのみで、共存の必要はなくなりました。
旧リリースのWS-Trustクライアントは、WS-SecureConversationトークンのみをサポートしていました。現在はSAMLトークンもサポートしています。
Web Service Secure Conversation Language (WS-SecureConversation)とSAMLのトークンがサポートされます。各トークンには次のネームスペースとURIがあります。
WS-SecureConversation 1.3
http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct
WS-SecureConversation 1.2
http://schemas.xmlsoap.org/ws/2005/02/sc http://schemas.xmlsoap.org/ws/2005/02/sc/sct
SAML 1.1
urn:oasis:names:tc:SAML:1.0:assertion
サポートされる確認メソッドは、Sender-Vouches、Holder-of-KeyおよびBearerです。対称型のHolder-of-Keyはサポートされません。
SAML 2.0
urn:oasis:names:tc:SAML:2.0:assertion
サポートされる確認メソッドは、Sender-Vouches、Holder-of-KeyおよびBearerです。対称型のHolder-of-Keyはサポートされません。
WS-Trustクライアントに固有の一部の構成プロパティを設定します。それ以外のプロパティについては、Webサービス・クライアントに通常存在する構成情報によって決定されます。たとえば、取得するトークンのタイプは、Webサービス・クライアントが呼び出しているWebサービスのセキュリティ・ポリシーによって決定されます。
明示的に設定できるプロパティと適用されるトークン・タイプは次のとおりです。
STS URI (WS-SecureConversationおよびSAML)
STSセキュリティ・ポリシー(SAML)
STS SOAPバージョン(SAML)
STS WS-Trustバージョン(SAML)
STSサーバー証明書(SAML)
この項では、次のトピックについて説明します。
WS-Trustクライアントがセキュア・トークン・サービス(STS)のURIを取得できるソースは3つあります。優先順位は次のとおりです。
Webサービスのセキュリティ・ポリシーにおけるトークン・アサーションのsp:Issuer/wsa:Address要素で指定されたSTSのURI。
構成済のSTSのURI。
同じ場所にあるSTSのURI。他のソースがない場合はこれがデフォルトです(WS-SecureConversationのみ)。
注意:
Webサービスのセキュリティ・ポリシーにおけるトークン・アサーションのsp:IssuedToken/sp:Issuer/wsa:Address要素で指定されたSTSのURIは、このリリースでは、SAMLトークンを取得する目的でのみサポートされ、Secure Conversationトークンを取得する目的ではサポートされません。
たとえば、STS URIに対する次のアサーションは、Secure Conversationトークン(SCT)を取得する目的ではサポートされません。
<sp:IssuedToken IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <sp:Issuer> <a:Address>http://example.com/STS</a:Address> </sp:Issuer> . . . </sp:IssuedToken>
WS-SecureConversationの場合、STSがサービスと共存していれば、STS URIの構成は不要です。ただし、STSとサービスが同じポートを共有しないときは(サービスがHTTPポートを使用し、STSがHTTPsポートを使用する場合など)、STS URIを構成する必要があります。
次のコード例は、JAX-RPCでクライアント・スタブにSTS URIを設定する方法を示しています。この例では、STS URIの場所をクライアントがすでに認識していることを前提としています。
String wsdl = "http://myserver/wsscsecuredservice?wsdl";
WsscSecuredService service = new WsscSecuredService_Impl(wsdl);
WsscSecured port = service.getWsscSecuredSoapPort();
Stub stub = (Stub) port;
String sts = "https://myserver/wsscsecuredservice";
stub._setProperty(weblogic.wsee.jaxrpc.WLStub.WST_STS_ENDPOINT_ON_WSSC, sts);
次のコード例は、JAX-WSでクライアント・スタブにSTS URIを設定する方法を示しています。
String wsdl = "http://myserver/wsscsecuredservice?wsdl";
WsscSecuredService service = new WsscSecuredService_Impl(wsdl);
String sts = "https://myserver/wsscsecuredservice";
WsscSecured port = service.getWsscSecuredSoapPort();
BindingProvider provider = (BindingProvider) port;
Map context = provider.getRequestContext();
context.put(weblogic.wsee.jaxrpc.WLStub.WST_STS_ENDPOINT_ON_WSSC, sts)
STSを使用してSAMLトークンを取得する場合、STSはサービスと共存しておらず、デフォルトのSTS URIはありません。この場合は、STS URIを構成する必要があります。
次のコード例は、JAX-RPCでクライアント・スタブにSAML用のSTS URIを設定する方法を示しています。この例では、STS URIの場所をクライアントがすでに認識していることを前提としています。
String wsdl = "http://myserver/wssecuredservice?wsdl";
WssecuredService service = new WsSecuredService_Impl(wsdl);
WsSecured port = service.getWsSecuredSoapPort();
Stub stub = (Stub) port;
String sts = "https://stsserver/standaloneSTS/saml/STS";
stub._setProperty(weblogic.wsee.jaxrpc.WLStub.WST_STS_ENDPOINT_ON_SAML, sts);
次のコード例は、JAX-WSでクライアント・スタブにSAML用のSTS URIを設定する方法を示しています。
String wsdl = "http://myserver/wsssecuredservice?wsdl";
WsSecuredService service = new WsSecuredService_Impl(wsdl);
String sts = "https://stsserver/standaloneSTS/saml/STS";
WsscSecured port = service.getWsSecuredSoapPort();
BindingProvider provider = (BindingProvider) port;
Map context = provider.getRequestContext();
context.put(weblogic.wsee.jaxrpc.WLStub.WST_STS_ENDPOINT_ON_SAML, sts)
例2-6では、WebLogic Scripting Tool (WLST)を使用してWS-Trustクライアントの資格証明プロバイダを作成し、STS URIを構成する方法を太字で示しています。
プロバイダ・クラス名は次のいずれかです。
weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider
weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider
weblogic.wsee.security.saml.SAMLTrustCredentialProvider
例2-6 WLSTを使用したSTS URIの構成
userName = sys.argv[1]
passWord = sys.argv[2]
host = sys.argv[3]+":"+sys.argv[4]
sslhost = sys.argv[3]+":"+sys.argv[5]
url="t3://"+ host connect(userName, passWord, url)
edit()
startEdit()
defaultWss = cmo.lookupWebserviceSecurity('default_wss')
#Create credential provider for SCT Trust Client
wtm = defaultWss.createWebserviceCredentialProvider('trust_client_sct_cp')
wtm.setClassName('weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider')
wtm.setTokenType('sct_trust')
cpm = wtm.createConfigurationProperty('StsUri')
cpm.setValue("https://" + sslhost + "/standaloneSTS/wssc13/STS")
save()
activate(block="true")
disconnect()
exit()
WebLogic Server管理コンソールからSTS URIを構成すると、使用するURIをWebLogicサービスの開発段階ではなく実行時に決定できます。
管理コンソールからSTS URIを構成するには、次の手順に従います。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービスのセキュリティ構成を作成します。空の構成が作成されます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービスのセキュリティ構成を編集し、資格証明プロバイダを作成します。
「資格証明プロバイダの作成」タブで、以下のように入力します。
プロバイダ名(このMBeanインスタンスの名前)。
プロバイダ・クラス名(次のいずれか)
weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider
または
weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider
または
weblogic.wsee.security.saml.SAMLTrustCredentialProvider
トークン・タイプ(トークンを識別する短い名前)。sctやsamlなどです。
「次へ」を選択します。
STS URIの名前と値のペアを入力します。
「終了」を選択します。
「セキュリティ構成: 全般」タブで、「デフォルト資格証明プロバイダSTS URI」の値を設定します。
デフォルト資格証明プロバイダSTS URLは、このWebサービス・セキュリティ構成のすべてのWS-Trust対応資格証明プロバイダにおける、デフォルトのSTSエンドポイントURLです。
次のコード例では、JAX-RPCでクライアント・スタブにSTSセキュリティ・ポリシーを設定する方法を太字で示しています。
import weblogic.wsee.message.WlMessageContext;
. . .
String wsdl = "http://myserver/samlsecuredservice?wsdl";
SamlSecuredService service = new SamlSecuredService_Impl(wsdl);
SamlSecured port = service.getSamlSecuredSoapPort();
Stub stub = (Stub) port;
InputStream policy = loadPolicy();
stub._setProperty(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
次のコード例では、JAX-WSでクライアント・スタブにSTSセキュリティ・ポリシーを設定する方法を太字で示しています。
import weblogic.wsee.message.WlMessageContext;
. . .
String wsdl = "http://myserver/wsssecuredservice?wsdl";
WsSecuredService service = new WsSecuredService_Impl(wsdl);
WsscSecured port = service.getWsSecuredSoapPort();
BindingProvider provider = (BindingProvider) port;
Map context = provider.getRequestContext();
InputStream policy = loadPolicy();
context._setProperty(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
例2-7では、WLSTを使用してデフォルトのWebサービス・セキュリティ構成の資格証明プロバイダを作成し、STSセキュリティ・ポリシーを構成する方法を太字で示しています。StsPolicyのプロパティの値は、WebLogic Serverに含まれるポリシー(「WS-SecurityPolicy 1.2ポリシー・ファイルの使用」を参照)、またはJava EEライブラリのカスタム・ポリシー・ファイル(「カスタム・ポリシー・ファイルの作成と使用」を参照)のどちらかである必要があります。
例2-7 WLSTを使用したSTSセキュリティ・ポリシーの構成
userName = sys.argv[1]
passWord = sys.argv[2]
host = sys.argv[3]+":"+sys.argv[4]
sslhost = sys.argv[3]+":"+sys.argv[5]
samlstsurl = sys.argv[6]
url="t3://"+ host
print "Connect to the running adminSever"
connect(userName, passWord, url)
edit()
startEdit()
defaultWss = cmo.lookupWebserviceSecurity('default_wss')
#Create credential provider for SAML Trust Client
wtm = defaultWss.createWebserviceCredentialProvider('trust_client_saml_cp')
wtm.setClassName('weblogic.wsee.security.saml.SAMLTrustCredentialProvider')
wtm.setTokenType('saml_trust')
cpm = wtm.createConfigurationProperty('StsUri')
cpm.setValue(samlstsurl)
cpm = wtm.createConfigurationProperty('StsPolicy')
cpm.setValue("Wssp1.2-2007-Https-UsernameToken-Plain")
save()
activate(block="true")
disconnect()
exit()
コンソールを使用してSTSセキュリティ・ポリシーを構成するには、次の手順に従います。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービスのセキュリティ構成を作成します。空の構成が作成されます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの説明に従って、Webサービスのセキュリティ構成を編集し、資格証明プロバイダを作成します。
「資格証明プロバイダの作成」タブで、以下のように入力します。
プロバイダ名(このMBeanインスタンスの名前)。
プロバイダ・クラス名(次のいずれか)
weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider
または
weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider
または
weblogic.wsee.security.saml.SAMLTrustCredentialProvider
トークン・タイプ(トークンを識別する短い名前)。sctやsamlなどです。
「次へ」を選択します。
STSポリシーの名前と値のペアを入力します。
「終了」を選択します。
SAML STSでは、デフォルト(WS-Trust 1.3)でない場合にのみ、WS-Trustのバージョンを構成する必要があります。WSEESecurityConstants.TRUST_VERSIONでサポートされる値は次のとおりです。
http://docs.oasis-open.org/ws-sx/ws-trust/200512 (WS-Trust 1.3)
SOAPバージョンが、スタンドアロン・クライアントを生成したターゲットWebサービスのSOAPバージョンと異なる場合は、SOAPバージョンも構成する必要があります。(定数の定義については、インタフェースSOAPConstants(http://docs.oracle.com/javase/8/docs/api/javax/xml/soap/SOAPConstants.html)を参照してください。)WSEESecurityConstants.TRUST_SOAP_VERSIONでサポートされる値は次のとおりです。
javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE (http://schemas.xmlsoap.org/soap/envelope/による)
javax.xml.soap.SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE (http://www.w3.org/2003/05/soap-envelopeによる)
例2-8は、WS-TrustとSOAPのバージョンを設定する例を示しています。
例2-8 WS-TrustおよびSOAPバージョンの設定
// set WS-Trust version stub._setProperty(WSEESecurityConstants.TRUST_VERSION, "http://docs.oasis-open.org/ws-sx/ws-trust/200512"); // set SOAP version stub._setProperty(WSEESecurityConstants.TRUST_SOAP_VERSION, SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE);
SAML STSの場合、メッセージ・レベルのポリシーを使用してSTSサーバーとWS-Trustクライアントの間のリクエストおよびレスポンスを保護するには、STSサーバーのX.509証明書を構成する必要があります。(トランスポート・レベルのポリシーを使用する場合は、STSサーバー証明書の構成は不要です。)
例2-9は、JAX-RPCでSTSサーバー証明書を設定する方法の例を示しています。この例では、STSサーバー証明書の場所がわかっていることを前提としています。
例2-9 JAX-RPCによるSTSサーバー証明書の設定
// import import weblogic.wsee.security.util.CertUtils; import java.security.cert.X509Certificate; import weblogic.wsee.jaxrpc.WLStub; . . . // get X509 Certificate String stsCertLocation = "../../cert/WssIP.cer"; X509Certificate stsCert = CertUtils.getCertificate(stsCertLocation); // set STS Server Cert stub._setProperty(WLStub.STS_ENCRYPT_CERT,stsCert);
例2-10は、JAX-WSでSTSサーバー証明書を設定する方法の例を示しています。この例の中で、JAX-WS固有のコードは太字で表されています。
例2-10 JAX-WSによるSTSサーバー証明書の設定
// import
import weblogic.wsee.security.util.CertUtils;
import java.security.cert.X509Certificate;
import weblogic.wsee.jaxrpc.WLStub;
. . .
// get X509 Certificate
String stsCertLocation = "../../cert/WssIP.cer";
X509Certificate stsCert = CertUtils.getCertificate(stsCertLocation);
// set STS Server Cert
context.put(WLStub.STS_ENCRYPT_CERT,stsCert);
WS-Trustを使用してSAML 2.0 BearerトークンをSTSから取得し、そのSAMLトークンをセキュアな会話でのブートストラップ・メッセージに対する認証に使用するよう、クライアント・アプリケーションを構成できます。
このシナリオでは、クライアントとSAML STSの間のWS-Trustメッセージ交換、およびセキュアな会話でのブートストラップ・メッセージには、トランスポート・レベルのメッセージ保護が使用されます。このスタンドアロン・クライアントには公開鍵と秘密鍵は不要です。
サービス側のポリシーは、事前定義済のWS-PolicyファイルWssp1.2-2007-Wssc1.3-Bootstrap-Https-UNT.xmlとほぼ同じです。ただし、次の<sp:SupportingTokens>がポリシーで使用されています。
<sp:SupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SupportingTokens>
WS-TrustクライアントとリモートSTSサーバーの間のWS-Trustメッセージの保護に使用されるポリシーは、パッケージ化されたセキュリティ・ポリシー・ファイルWssp1.2-2007-Https-UsernameToken-Plain.xmlのコピーです。このファイルでは、トランスポート・レベルのメッセージ保護における認証にユーザー名トークンが使用されます。
注意:
トランスポート・レベルのセキュリティ・ポリシーを使用してセキュアな会話のブートストラップ・メッセージを保護する場合、WS-TrustクライアントとリモートSTSの間で交換されるWS-Trustメッセージもトランスポート・レベルのセキュリティ・ポリシーを使用して保護する必要があります。
Webサービスをクライアントから呼び出すとき、そのサービスはメッセージ保護されたWebサービスを呼び出す標準的なクライアント・アプリケーションに似ています(「クライアント側のセキュリティ・ポリシー・ファイルの使用」を参照)。主な違いは、2つのSTSエンドポイントを構成する必要がある点です。1つは取得したSAMLトークンに使用され、もう1つは安全な通信のためのセキュリティ・コンテキスト・トークン(SCT)に使用されます。
例2-11は、クライアント・アプリケーションから、WS-Trust経由でSAMLトークンを取得するJAX-WSのWebサービスを呼び出す、単純な例を示しています。それは、HTTPSによるトランスポート・レベルの保護を使用してセキュアな会話を可能にするセキュリティ・ポリシーに関連付けられています。セキュリティ・コンテキストに関連する太字のセクションについては、例の後で説明します。
例2-11 WS-TrustとWS-SecureConversationをHTTPSとともに使用するクライアント・アプリケーション
package examples.webservices.samlwsschttps.client;
import weblogic.security.SSL.TrustManager;
import weblogic.wsee.message.WlMessageContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.saml.SAMLTrustCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.wsee.jaxrpc.WLStub;
import weblogic.wsee.security.util.CertUtils;
import com.sun.xml.ws.developer.MemberSubmissionAddressingFeature;
import java.security.cert.X509Certificate;
import javax.xml.ws.*;
import javax.xml.namespace.*;
import javax.net.ssl.HttpsURLConnection;
import java.net.URL;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
public class TravelAgencyClient {
public static final String STS_POLICY = "StsHttpsUntPolicy.xml";
static {
HttpsURLConnection.setDefaultHostnameVerifier(new MyHostnameVerifier());
try {
String defaultTrustStore = new File(TravelAgencyClient.class.getResource("/cacerts").getFile()).getCanonicalPath();
System.out.println("Default trustStore:\t" + defaultTrustStore);
System.setProperty("javax.net.ssl.trustStore", defaultTrustStore);
} catch (IOException e) {
System.out.printf("can't find default trusted keystore");
}
}
public static void main(String[] args) throws Exception {
TravelAgencyClient client = new TravelAgencyClient();
String wsscStsURL = System.getProperty("wsscStsURL");
System.out.println("WSSC StS URL \t" + wsscStsURL);
String samlStsURL = System.getProperty("samlStsURL");
System.out.println("StS URL \t" + samlStsURL);
String hotelWsdlURL = System.getProperty("hotelWsdlURL");
System.out.println("Hotel Service WSDL URL \t" + hotelWsdlURL);
String hotelResult = client.callWsscHotelService("Travel Agency client to Hotel Service", wsscStsURL,hotelWsdlURL, samlStsURL);
System.out.println("Hotel Service return value: -->"+hotelResult);
}
public String callWsscHotelService(String hello,
String wsscStsURL,
String hotelWsdlURL,
String samlStsURL) throws Exception{
HotelService service = new HotelService(new URL(hotelWsdlURL),
new QName("http://wsinterop.org/samples", "HotelService"));
IHotelService port = service.getIHotelServicePort(new MemberSubmissionAddressingFeature());
BindingProvider provider = (BindingProvider)port;
this.configurePort(provider, wsscStsURL, samlStsURL);
try {
// for securie conversation, it can call twice
String s1 = port.getName(hello);
String s2 = port.getName(hello + " --- " + s1) ;
WSSCClientUtil.terminateWssc((BindingProvider)port);
return s2;
} catch (Exception ex) {
ex.printStackTrace();
throw new RuntimeException("fail to call the remote hotel service!", ex);
}
}
private void configurePort(BindingProvider provider, String wsscStsURL, String samlStsURL) throws Exception {
Map context = provider.getRequestContext();
InputStream policy = getPolicy(STS_POLICY);
context.put(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
if (null != wsscStsURL) {
context.put(WLStub.WST_STS_ENDPOINT_ON_WSSC, wsscStsURL);
}
context.put(WLStub.WST_STS_ENDPOINT_ON_SAML, samlStsURL);
context.put(WSSecurityContext.TRUST_MANAGER,
new TrustManager() {
public boolean certificateCallback(X509Certificate[] chain,
int validateErr) {
// need to validate if the server cert can be trusted
return true;
}
});
List credProviders = buildCredentialProviderList();
context.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
context.put(com.sun.xml.ws.developer.JAXWSProperties.HOSTNAME_VERIFIER, new MyHostnameVerifier());
}
private static List buildCredentialProviderList() throws Exception {
List credProviders = new ArrayList();
credProviders.add(new SAMLTrustCredentialProvider());
credProviders.add(getClientUNTCredentialProvider());
return credProviders;
}
private static CredentialProvider getClientUNTCredentialProvider() throws Exception {
String username = System.getProperty("target.username", "Alice");
String password = System.getProperty("target.password", "Password1");
return new ClientUNTCredentialProvider(username.getBytes(),
password.getBytes());
}
private InputStream getPolicy(String policyName) {
String resName = '/' + this.getClass().getPackage().getName().replace('.', '/') + '/' + policyName;
InputStream stsPolicy = this.getClass().getResourceAsStream(resName);
if(stsPolicy == null) {
throw new RuntimeException("STS policy is not correctly set!");
}
return stsPolicy;
}
public static class MyHostnameVerifier implements javax.net.ssl.HostnameVerifier {
public boolean verify(String hostname, javax.net.ssl.SSLSession session) {
return(true);
}
}
}
この例では、次の点に注意してください。
リモートSTSとWS-Trustクライアントとの間のメッセージ保護のポリシーを構成します。
context.put(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
ブートストラップはトランスポート・レベルのポリシーで保護されるため、セキュアな会話のためのSTSエンドポイント・アドレスを設定する必要があります。
context.put(WLStub.WST_STS_ENDPOINT_ON_WSSC, wsscStsURL);
SAML STSのSTSエンドポイント・アドレスを設定します。
context.put(WLStub.WST_STS_ENDPOINT_ON_SAML, samlStsURL);
トランスポート・レベルの保護のために、ホスト名検証を構成する必要があります。
context.put(com.sun.xml.ws.developer.JAXWSProperties.HOSTNAME_VERIFIER, new MyHostnameVerifier());
SAMLトークンのリモート取得を処理するようにSAML信頼資格証明プロバイダを設定します。
credProviders.add(new SAMLTrustCredentialProvider());
クライアントのユーザー名とパスワードを使用してWS-Trust呼出し経由でSAMLトークンを交換するように、クライアント・ユーザー名トークン・プロバイダを設定します。
credProviders.add(getClientUNTCredentialProvider());
例2-11と同様に、WS-Trustを使用してSAML 2.0 BearerトークンをSTSから取得し、そのSAMLトークンをセキュアな会話でのブートストラップ・メッセージに対する認証に使用するよう、クライアント・アプリケーションを構成できます。ただし、HTTPSによるトランスポート・レベルのメッセージ保護ではなく、WS-Security 1.1によるメッセージ・レベルの保護を使用するため、HTTPSの構成は不要です。
このシナリオでは、クライアントとSAML STSの間のWS-Trustメッセージ交換の保護にはSTSサーバーのX.509証明書が使用され、セキュアな会話でのブートストラップ・メッセージの保護にはサーバーのX.509証明書が使用されます。このスタンドアロン・クライアントには公開鍵と秘密鍵は不要です。
サービス側のポリシーは、パッケージ化されたWS-PolicyファイルWssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xmlに類似しています。ただし、Bootstrapメッセージにおける認証で、クライアントのX.509証明書のかわりにSAML 2.0トークンを使用する点が異なります。つまり、<sp:SignedEndorsingSupportingTokens>アサーションではなく、ポリシー内で<sp:SignedSupportingTokens>アサーションをSAMLトークンと共に使用します。
セキュアな会話のポリシー全体を次に示します。
<?xml version="1.0"?>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:SecureConversationToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:RequireDerivedKeys/>
<sp:BootstrapPolicy>
<wsp:Policy>
<sp:SignedParts>
<sp:Body/>
<sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>
<sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<sp:RequireDerivedKeys/>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>
</sp:BootstrapPolicy>
</wsp:Policy>
</sp:SecureConversationToken>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:ProtectTokens/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
<sp:Trust13>
<wsp:Policy>
<sp:MustSupportIssuedTokens/>
<sp:RequireClientEntropy/>
<sp:RequireServerEntropy/>
</wsp:Policy>
</sp:Trust13>
</wsp:Policy>
WS-TrustクライアントとリモートSTSサーバーの間のWS-Trustメッセージの保護に使用されるポリシーは、パッケージ化されたセキュリティ・ポリシーWssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xmlのコピーです。このファイルでは、認証およびWS-Security 1.1によるメッセージ・レベルのセキュリティにユーザー名トークンが使用されます。
セキュリティ・ポリシー全体を次に示します。
<?xml version="1.0"?>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
<sp:SignedParts>
<sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>
<sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:Policy>
注意:
メッセージ・レベルのセキュリティ・ポリシーを使用してセキュアな会話のブートストラップ・メッセージを保護する場合、WS-TrustクライアントとリモートSTSの間で交換されるWS-Trustメッセージもメッセージ・レベルのセキュリティ・ポリシーを使用して保護する必要があります。トランスポート・レベルのセキュリティ・ポリシーとメッセージ・レベルのセキュリティ・ポリシーを併用することはできません。
WS-TrustクライアントからWebサービスを呼び出す場合、構成は前の例とほぼ同じです。主な違いとしては、次の点があげられます。
暗号化証明書を2つ構成する必要があります。1つはSAMLトークンを取得するためのSTSの証明書、もう1つはサーバー用の証明書です。
セキュアな会話のためのサービスSTSエンドポイント・アドレスを構成する必要はありません。ブートストラップ・メッセージがトランスポート・レベルのセキュリティで保護されていない場合、STSエンドポイント・アドレスはデフォルトで、セキュアな会話のサービス・エンドポイント・アドレスと同じです。
SSLの構成は不要です。
例2-12は、クライアント・アプリケーションから、WS-Trust経由でSAMLトークンを取得するJAX-WSのWebサービスを呼び出す、単純な例を示しています。それは、WS-Security 1.1によるメッセージ・レベルのセキュリティを使用してセキュアな会話を可能にするセキュリティ・ポリシーに関連付けられています。セキュリティ・コンテキストに関連する太字のセクションについては、例の後で説明します。
例2-12 WS-TrustとWS-SecureConversationを使用し、HTTPSを使用しないクライアント・アプリケーション
package examples.webservices.samlwssc.client;
import weblogic.security.SSL.TrustManager;
import weblogic.wsee.message.WlMessageContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.saml.SAMLTrustCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.wsee.jaxrpc.WLStub;
import weblogic.wsee.security.util.CertUtils;
import weblogic.wsee.security.wssc.utils.WSSCClientUtil;
import com.sun.xml.ws.developer.MemberSubmissionAddressingFeature;
. . .
public class TravelAgency1Client {
public static final String STS_POLICY = "StsWss11UntPolicy.xml";
public static void main(String[] args) throws Exception {
TravelAgencyClient client = new TravelAgencyClient();
String stsURL = System.getProperty("stsURL");
System.out.println("StS URL \t" + stsURL);
String hotelWsdlURL = System.getProperty("hotelWsdlURL");
System.out.println("Hotel Service WSDL URL \t" + hotelWsdlURL);
String hotelResult = client.callWsscHotelService("Travel Agency client to Hotel Service", stsURL, hotelWsdlURL);
System.out.println("Hotel Service return value: -->" + hotelResult);
}
public String callWsscHotelService(String hello,
String stsurl,
String hotelWsdlURL) throws Exception {
HotelService service = new HotelService(new URL(hotelWsdlURL),
new QName("http://wsinterop.org/samples", "HotelService"));
IHotelService port = service.getIHotelServicePort(new MemberSubmissionAddressingFeature());
BindingProvider provider = (BindingProvider) port;
this.configurePort(provider, stsurl);
try {
// for secure conversation, it can call twice
String s1 = port.getName(hello);
String s2 = port.getName(hello + " --- " + s1);
WSSCClientUtil.terminateWssc((BindingProvider)port);
return s2;
} catch (Exception ex) {
ex.printStackTrace();
throw new RuntimeException("fail to call the remote hotel service!", ex);
}
}
private void configurePort(BindingProvider provider, String stsurl) throws Exception {
Map context = provider.getRequestContext();
InputStream policy = getPolicy(STS_POLICY);
context.put(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
context.put(WLStub.WST_STS_ENDPOINT_ON_SAML, stsurl);
context.put(WLStub.STS_ENCRYPT_CERT, getStsCert());
context.put(WLStub.SERVER_ENCRYPT_CERT, getServerCert());
List credProviders = buildCredentialProviderList();
context.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
context.put(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT);
}
private static List buildCredentialProviderList() throws Exception {
List credProviders = new ArrayList();
credProviders.add(new SAMLTrustCredentialProvider());
credProviders.add(getClientUNTCredentialProvider());
return credProviders;
}
. . .
private static X509Certificate getServerCert() throws Exception {
String defaultServerCert = new File(
TravelAgency1Client.class.getResource("/Bob.cer").getFile()).getCanonicalPath();
String certName = System.getProperty("target.serverCert",
defaultServerCert);
X509Certificate cert = CertUtils.getCertificate(certName);
return cert;
}
}
この例では、次の点に注意してください。
リモートSTSとWS-Trustクライアントとの間のメッセージ保護を目的としたSTSサーバー証明書を構成します。
context.put(WLStub.STS_ENCRYPT_CERT, getStsCert());
セキュアな会話のブートストラップ・メッセージのメッセージ保護を目的としたSTSサーバー証明書を構成します。
context.put(WLStub.SERVER_ENCRYPT_CERT, getServerCert());
(オプション)サービスがMicrosoft .NET WCFサービスの場合は、WLStub.POLICY_COMPATIBILITY_PREFERENCEフラグをWLStub.POLICY_COMPATIBILITY_MSFTに設定して相互運用性を確保します。
context.put(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT);
セキュリティ・コンテキストと派生キーを構成するために、次のような事前定義済のWS-SecurityPolicyファイルが提供されています。
WS-SecureConversation 1.2 (2005/2)仕様
Wssp1.2-Wssc200502-Bootstrap-Https.xml
Wssp1.2-Wssc200502-Bootstrap-Wss1.0.xml
Wssp1.2-Wssc200502-Bootstrap-Wss1.1.xml
WS-SecureConversation 1.3バージョンのWS-SecureConversation 1.2 (2005/2)ポリシー・ファイル
Wssp1.2-Wssc1.3-Bootstrap-Https.xml
Wssp1.2-Wssc1.3-Bootstrap-Wss1.0.xml
Wssp1.2-Wssc1.3-Bootstrap-Wss1.1.xml
追加のWS-SecureConversation 1.3ポリシー・ファイル
Wssp1.2-Wssc1.3-Bootstrap-Https-BasicAuth.xml
Wssp1.2-Wssc1.3-Bootstrap-Https-ClientCertReq.xml
WS-SecureConversation 1.4ポリシー
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256Sha256.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-Saml1.1-SenderVouches.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml1.1-SenderVouches.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml2.0-Bearer.xml
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-UsernameToken-Plain-EncryptedKey.xml
必要な機能と一般的なデフォルト値のほとんどが、これらのセキュリティ・ポリシー・ファイルで提供されるので、セキュリティ・コンテキストを構成する場合には、これらの事前定義済ファイルを使用することをお薦めします。これらのファイルの詳細は、「WS-SecureConversationポリシー」を参照してください。
注意:
クラスタに対して共有のセキュリティ・コンテキストを使用するWebサービスをデプロイする場合は、クラスタ間のセッション状態レプリケーションも構成する必要があります。詳細は、Oracle WebLogic Serverクラスタの管理のクラスタのフェイルオーバーとレプリケーションを参照してください。
ポリシー・アノテーション、アプリケーションのWSDLにアタッチされたポリシー、または実行時のポリシー構成を通じてポリシーを使用するように、アプリケーションをコーディングまたは構成します。
WebLogic Webサービスでは、Web Services Trust (WS-Trust 1.3)およびWeb Services Secure Conversation (WS-SecureConversation 1.3)仕様を実装しています。02/2005バージョンのWS-SecureConversationとは次の点で異なりますので注意してください。
Web Services Secure Conversation (WS-SecureConversation 1.3)仕様では、トークン・サービスはwst:RequestSecurityTokenに応答して、開始側パーティにwst:RequestedSecurityTokenを戻す必要があります。1つのwst:RequestSecurityTokenResponseCollectionの中に1つ以上のwst:RequestSecurityTokenResponse要素が含まれています。
これは、トークン・サービスがwst:RequestSecurityTokenResponseを戻していた旧バージョンの仕様とは異なります。
次のようにサービス・ポリシーでSC10SecurityContextTokenが指定されている場合、トークン・サービスはwst:RequestSecurityTokenResponseを戻すことができます。
WS-SecurityPolicy 1.2 Errataドキュメントには、SecureConversationToken Assertionに関する次の変更が記述されています:
<sp:SC10SecurityContextToken />
これを次のように変更します。
<sp:SC13SecurityContextToken />
sp:SC10SecurityContextTokenは、02/2005バージョンのWS-SecureConversationで使用する場合にのみ、引き続きサポートされます。
WS-SecureConversationは、クラスタ内の特定のWebLogic Serverインスタンスに固定されています。SecureConversationリクエストが間違ったサーバーに届くと、自動的に正しいサーバーに転送されます。WS-SecureConversationをホストするサーバー・インスタンスに障害が発生した場合は、そのサーバー・インスタンスが回復するまでSecureConversationを使用できなくなります。
Webサービスの呼出し時にセキュリティ・コンテキストのネゴシエーションを行うクライアント・アプリケーションは、メッセージ保護されたWebサービスを呼び出す標準的なクライアント・アプリケーションに似ています(「クライアント側のセキュリティ・ポリシー・ファイルの使用」を参照)。本質的には、セキュアなコンテキスト・トークンを明示的に取り消すために、weblogic.wsee.security.wssc.utils.WSSCClientUtil APIを使用できるという点のみが異なっています。
SCT存続期間プロパティを設定して、SCT有効期限値を構成できます。このSCT有効期限値は、SCTのタイムアウト処理に使用されます。タイムアウトに達すると、クライアント側のWebサービス・ランタイムによって、SCTが自動的に更新されます。未使用のセキュアなコンテキスト・トークンは、タイムアウトに達すると自動的に取り消されます。
注意:
WebLogic Serverには、ユーザーの利便性だけを目的としてWSSCCLientUtil APIが用意されています。このWebサービス・ランタイムでは、構成されたタイムアウトに到達するとセキュアなコンテキスト・トークンが自動的に取り消されます。このAPIは、トークンを取消す時期をより厳密に制御する必要がある場合にのみ使用します。
例2-13は、クライアント・アプリケーションから、セキュアな通信を可能にする事前定義済のセキュリティ・ポリシー・ファイルに関連付けられたJAX-RPCのWebサービスを呼び出す、単純な例を示しています。セキュリティ・コンテキストに関連する太字のセクションについては、例の後で説明します。
例2-13 WS-SecureConversationを使用するクライアント・アプリケーション
package examples.webservices.wssc.client; import weblogic.security.SSL.TrustManager; import weblogic.xml.crypto.wss.provider.CredentialProvider; import weblogic.xml.crypto.wss.WSSecurityContext; import weblogic.wsee.security.bst.ClientBSTCredentialProvider; import weblogic.wsee.security.bst.StubPropertyBSTCredProv; import weblogic.wsee.security.wssc.utils.WSSCClientUtil; import weblogic.wsee.security.util.CertUtils; import javax.xml.rpc.Stub; import java.util.List; import java.util.ArrayList; import java.security.cert.X509Certificate; /** * Copyright © 1996, 2008, Oracle and/or its affiliates. * All rights reserved. */ public class WSSecureConvClient { public static void main(String[] args) throws Throwable { String clientKeyStore = args[0]; String clientKeyStorePass = args[1]; String clientKeyAlias = args[2]; String clientKeyPass = args[3]; String serverCert = args[4]; String wsdl = args[5]; WSSecureConvService service = new WSSecureConvService_Impl(wsdl); WSSecureConvPortType port = service.getWSSecureConvServicePort(); //create credential provider and set it to the Stub List credProviders = new ArrayList(); //use x509 to secure wssc handshake credProviders.add(new ClientBSTCredentialProvider(clientKeyStore, clientKeyStorePass, clientKeyAlias, clientKeyPass)); Stub stub = (Stub)port; stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders); stub._setProperty(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, CertUtils.getCertificate(serverCert)); stub._setProperty(WlMessageContext.SCT_LIFETIME_PROPERTY, new Long( 2 * 60 * 60 * 1000L)); // set to 2 hrs (Default is 30 minutes.) stub._setProperty(WSSecurityContext.TRUST_MANAGER, new TrustManager(){ public boolean certificateCallback(X509Certificate[] chain, int validateErr){ //need to validate if the server cert can be trusted return true; } } ); System.out.println (port.sayHelloWithWSSC("Hello World, once")); System.out.println (port.sayHelloWithWSSC("Hello World, twice")); System.out.println (port.sayHelloWithWSSC("Hello World, thrice")); //cancel SecureContextToken after done with invocation WSSCClientUtil.terminateWssc(stub); System.out.println("WSSC terminated!"); } }
この例で注目すべき点は次のとおりです。
セキュアなコンテキスト・トークンを明示的に終了するために使用されるWebLogic APIをインポートします。
import weblogic.wsee.security.wssc.utils.WSSCClientUtil;
JAX-RPCスタブに次のプロパティを設定します。このプロパティは、クライアント・アプリケーションが指定のWebLogic Server公開鍵でWebLogic Serverへのリクエストを暗号化する必要があることを示しています。
stub._setProperty(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, CertUtils.getCertificate(serverCert));
JAX-RPCスタブに次のプロパティを設定します。このプロパティは、セキュリティ・コンテキスト・トークン(SCT)のタイムアウト値を示しています。
stub._setProperty(WlMessageContext.SCT_LIFETIME_PROPERTY, new Long( 2 * 60 * 60 * 1000L));
注意:
SCT存続期間値の設定はオプションです。デフォルト値は30分に設定されています。SCT存続期間値を短くするとセキュリティは向上しますが、SCTを頻繁に更新する必要が生じます。SCT存続期間値を長くすると、SCT更新の頻度が低くなるので、明示的に終了しないかぎり、SCTはメモリー内に長期間保持されます。
WSSClientUtilクラスのterminateWssc()メソッドを使用して、セキュアなコンテキスト・トークンを終了します。
WSSCClientUtil.terminateWssc(stub);
簡易なメッセージ・レベルの構成手順(「簡易なメッセージ・レベルのセキュリティの構成」を参照)では、Webサービスを実装するJWSファイルで@Policyおよび@Policies JWSアノテーションを使用して、サービスに関連付けられた1つ以上のポリシー・ファイルを指定する方法について説明しています。つまり、これはWebサービスのプログラミング時にはWebサービスとその操作に関連付けるポリシー・ファイルをあらかじめ認識しておく必要があることを示します。これは必ずしも可能ではないため、Webサービスをデプロイした後、WebLogic Server管理コンソールを使用して実行時にポリシー・ファイルを関連付けることも可能です。
JWSファイルで@Policyおよび@Policies JWSアノテーションを使用せず、WebLogic Server管理コンソールを使用して実行時にポリシー・ファイルを関連付けるか、アノテーションを使用して一部のポリシー・ファイルを指定しておき、実行時に追加のポリシー・ファイルを関連付けることができます。
実行時、WebLogic Server管理コンソールでは、ファイル内のポリシー・アサーションが互いに矛盾している場合や、JWSアノテーションに関連付けられたポリシー・ファイルのアサーションと矛盾している場合でも、必要な数のポリシー・ファイルをWebサービスとその操作に関連付けることができます。ただし、関連付けられた複数のポリシー・ファイルが連携して機能するかどうかは、ユーザー次第です。なんらかの矛盾がある場合、クライアント・アプリケーションがWebサービスの操作を呼び出すときに、WebLogic Serverから実行時エラーが返されます。
コンソールを使用して1つ以上のWS-PolicyファイルをWebサービスに関連付けるには、EJB JARファイル(EJB実装のWebサービスの場合)、またはWARファイル(Javaクラス実装のWebサービスの場合)のMETA-INF/policiesまたはWEB-INF/policiesディレクトリにWS-Policy XMLファイルを格納する必要があります。
WebLogic Server管理コンソールを使用してポリシー・ファイルを実行時に関連付ける手順の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWS-PolicyファイルのWebサービスへのアタッチを参照してください。
この項では、アイデンティティとしてのSAMLトークンの使用について説明します。次の内容で構成されています。
SAML Token Profile 1.1 (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf)はWS-Security標準のコア・セットの一部であり、Webサービス・セキュリティにSAMLアサーションをどのように使用するかを指定します。WebLogic Serverでは、SAML 2.0およびSAML 1.1アサーションのサポートを含めて、SAML Token Profile 1.1をサポートしています。SAML Token Profile 1.1はSAML Token Profile 1.0と後方互換性があります。
注意:
SAML Token Profile 1.1はWS-SecurityPolicyを通じてのみサポートされます。
WS-SecurityPolicy仕様が規定される以前の旧リリースのWebLogic Serverでは、WS-Policy仕様に基づき、プロプライエタリのセキュリティ・ポリシー・スキーマを使用して記述されたセキュリティ・ポリシー・ファイルを使用していました。これらの初期のセキュリティ・ポリシー・ファイルはSAML Token Profile 1.0とSAML 1.1のみをサポートします。
「簡易なメッセージ・レベルのセキュリティの構成」に記載された簡易なWebサービスの構成手順では、ユーザーがユーザー名トークンを使用して自身を認証することが前提となっています。WebLogic ServerにはWebサービス・セキュリティ仕様のSAML Token Profile 1.1 (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf)が実装されているので、この項で説明するように、ユーザーはWebサービス操作の呼出しの際にSOAPメッセージでSAMLトークンを使用して自身を認証できます。
SAMLトークンの使用はサーバー間で機能します。つまり、あるWebLogic Serverインスタンスで実行されているクライアント・アプリケーションが、アイデンティティとしてSAMLを使用して別のWebLogic Serverインスタンスで実行されているWebサービスを呼び出します。クライアント・アプリケーション自体がWebサービスであるため、Webサービス・セキュリティ・ランタイムによってすべてのSAML処理が行われます。
このサーバー間での使用に加えて、「WS-Trustクライアントの構成」で説明するように、WS-Trustを通じてスタンドアロン・クライアントからSAMLトークンを使用することもできます。
注意:
この項では、読者がSAMLの基礎、およびWebLogic Serverのコア・セキュリティとSAMLとの関連について理解していることを前提としています。一般情報については、Oracle WebLogic Serverセキュリティの理解のSecurity Assertion Markup Language (SAML)を参照してください。
また、次の手順では、「簡易なメッセージ・レベルのセキュリティの構成」の手順がすでに実行されていることを前提として、ユーザー名トークンではなく、SAMLトークンをアイデンティティとして使用できるようにします。
SAMLトークンをアイデンティティとして使用するには、次のようにします。
必要なSAMLプロバイダが構成されていることを確認し、適切なパートナ・エントリを追加します。この手順により、WebLogic Serverコア・セキュリティ・サブシステムが構成されます。詳細は、『Oracle WebLogic Serverセキュリティの管理』の次の各項を参照してください。
SAMLアイデンティティ・アサーション・プロバイダの構成
SAML資格証明マッピング・プロバイダの構成
注意:
SAMLトークン・プロファイルで両方のバージョンのSAMLを使用する場合は、SAML 1.1とSAML 2.0の両方のセキュリティ・プロバイダを構成する必要があります。
SAML 2.0パートナ・エントリを構成する場合は、WSSIdPPartnerとWSSSPPartnerの両方のエントリで、パートナの名前として対象のWebサービスのエンドポイントURLを使用する必要があります。SSLを使用する場合は、URLをHTTPSとして指定します。
SAML Holder-of-KeyポリシーのようなSAMLアサーションに関連した署名を呼び出すポリシー(アサーションによって参照されているキーを使用してメッセージが署名されます)、またはSender-Vouchesポリシー(送信側のキーを使用してメッセージが署名されます)を使用する場合は、署名および検証用のキーと証明書を構成する必要があります。
Holder-of-Keyシナリオの場合、クライアント証明書の署名は、SAMLトークンの参照する秘密鍵をクライアントが持っていることを証明します。Sender Vouchesシナリオの場合、クライアント証明書の署名は、SAMLトークンを含むメッセージが送信側で生成されることを保証します。
注意:
これらのキーと証明書は、アサーション自体には署名の作成または認証として使用されることはありません。アサーションに対する署名の作成と検証には、SAMLセキュリティ・プロバイダで構成されているキーと証明書が使用されます。
SAML Bearerポリシーを使用する場合は、保護はSSLによって提供され、PKI資格証明マッピング・プロバイダは必要ありません。
WS-TRUSTを介してスタンドアロン・クライアントのSAMLトークンを使用する場合、トークンはPKI資格証明マッピング・プロバイダではなくWebサービス・クライアント・スタブを通じて渡されます。
送信側でPKI資格証明マッピング・プロバイダを構成し、署名に使用される鍵と証明書を設定します。setKeypairCredentialはprincipalName、resourceid、資格証明アクション、キーストア別名、対応するパスワードの間の鍵ペア・マッピングを作成します。
pkiCM.setKeypairCredential(
type=<remote>, protocol=http,
remoteHost=hostname, remotePort=portnumber, path=/ContextPath/ServicePath,
username, Boolean('true'), None,
alias, passphrase)
最初の(String)パラメータを使用して、ターゲットWebサービスのエンドポイントを表すリソース・オブジェクトが作成されます。userNameパラメータは、署名済Webサービス・メッセージを生成する際のユーザーです。aliasおよびpassphraseパラメータは、PKI資格証明マッピング・プロバイダで構成されているキーストアから鍵と証明書を取得するときに使用される別名とパスフレーズです。KeypairCredentialを作成する前に、実際の鍵と証明書をキーストアにロードしておく必要があります。
Webサービス・セキュリティ・ランタイムが検証できるように、同じ証明書を受信側の証明書レジストリに追加します。
reg.registerCertificate(certalias, certfile)
WS-SecurityPolicyでは、SAMLアサーションに対する確認メソッドは明示的に規定されていませんが、暗黙的に定義されています。次の一般的なガイドラインを考慮してください。
WSS1.0非対称バインディングにおいて、SamlTokenアサーションが<sp:AsymmerticBinding>アサーションの内部にある場合は、Holder of Key確認メソッドを使用します。
WSS1.1対称バインディングにおいて、SamlTokenアサーションが<sp:EndorsingSupportingTokens>アサーションの内部にある場合は、Holder of Key確認メソッドを使用します。
Holder of Key確認を使用する事前定義済ポリシーの例については、表2-13を参照してください。
WSS1.0非対称バインディングにおいて、SamlTokenアサーションが<sp:SignedSupportingTokens>の内部にある場合は、Sender Vouches確認メソッドを使用します。
WSS1.1対称バインディングにおいて、SamlTokenアサーションが<sp:SignedSupportingTokens>アサーションの内部にあり、<sp:X509Token>が<sp:EndorsingSupportingTokens>アサーション内で使用されている場合は、Sender Vouches確認メソッドを使用します。
トランスポート・バインディングにおいて、Sender Vouches確認メソッドを使用するには、クライアント認証による双方向SSLが必要です。この場合、トランスポート・レベルのセキュリティの構成の説明に従って、トランスポート・レベルのセキュリティを使用してください。
Sender Vouches確認を使用する事前定義済ポリシーの例については、表2-13を参照してください。
トランスポート・レベルのセキュリティにおいて、SamlTokenアサーションが<sp:SupportingTokens>の内部にある場合は、Bearer確認メソッドを使用します。この場合、トランスポート・レベルのセキュリティの構成の説明に従って、トランスポート・レベルのセキュリティを使用してください。
WSS1.1対称バインディングにおいて、SamlTokenアサーションが<sp:SignedSupportingTokens>アサーションの内部にあり、<sp:EndorsingSupportingTokens>アサーションが存在しない場合は、Bearer確認メソッドを使用します。
Bearer確認を使用する事前定義済ポリシーの例については、表2-13を参照してください。
この項では、プロプライエタリのセキュリティ・ポリシー・スキーマを使用するポリシー・ファイル内にSAML確認メソッドを指定する方法について説明します。
注意:
SAML V1.1とSAML V2.0のアサーションでは、それぞれ<saml: SubjectConfirmation>要素と<saml2: SubjectConfimation>要素を使用して確認メソッドを指定します。確認メソッドはポリシー・ファイルに直接指定しません。
アイデンティティとしてSAMLトークンを要求するようにWebサービスを構成する場合には、次のいずれかの確認メソッドを指定できます。
sender-vouches
holder-of-key
bearer
これらの確認メソッドの詳細は、SAML WebLogic WebサービスでのSAMLトークン・プロファイルのサポート、およびWeb Services Security: SAML Token Profile (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf)仕様を参照してください。
アイデンティティとしてSAMLを使用することを指定したセキュリティ・ポリシー・ファイルを使用します。正確な構文は、構成する確認メソッドのタイプ(sender-vouches、holder-of-key)によって異なります。
sender-vouches確認メソッドを指定するには、次の手順に従います。
<Identity><SupportedTokens>要素の<SecurityToken>子要素を作成し、TokenType属性をSAMLトークンの使用を示す値に設定します。
<SecurityToken>要素の<Claims><Confirmationmethod>子要素を追加し、sender-vouchesを指定します。
次に例を示します。
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Identity>
<wssp:SupportedTokens>
<wssp:SecurityToken
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>sender-vouches</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
</wsp:Policy>
holder-of-key確認メソッドを指定するには、次の手順に従います。
<Integrity><SupportedTokens>要素の<SecurityToken>子要素を作成し、TokenType属性をSAMLトークンの使用を示す値に設定します。
holder-of-key確認メソッドの<Integrity>アサーションにSAMLトークンを含めるのは、Webサービス・ランタイムがメッセージの整合性を証明する必要があるためで、sender-vouchesの場合、メッセージの整合性を証明する必要はありません。
<SecurityToken>要素の<Claims><Confirmationmethod>子要素を追加し、holder-of-keyを指定します。
次に例を示します。
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part">
<wssp:Integrity>
<wssp:SignatureAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm
URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken
IncludeInMessage="true"
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
<wssp:Claims>
<wssp:ConfirmationMethod>holder-of-key</wssp:ConfirmationMethod>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
</wsp:Policy>
デフォルトでは、WebLogic Webサービス・ランタイムは常に、関連付けられたすべてのWS-Policyファイルの<KeyInfo>アサーションで指定されているX.509証明書を検証します。SAML holder-of-keyアサーションの使用時にこの検証を無効化するには、SAMLトークン・ハンドラにプロパティを設定することで、Webサービスと関連付けられたWebサービス・セキュリティを構成する必要があります。この構成をWebLogic Server管理コンソールで行う方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML holder_of_keyアサーション使用時のX.509証明書の検証の無効化を参照してください。
固有のセキュリティ・ポリシー・ファイルの作成の詳細は、「カスタム・ポリシー・ファイルの作成と使用」を参照してください。アサーションのリファレンス情報は、Oracle WebLogic Server WebLogic Webサービス・リファレンスのWebサービス・セキュリティ・ポリシー・アサーションのリファレンスを参照してください。
Webサービスを実装するJWSファイルの該当する@Policyアノテーションを更新して、前の手順で作成したセキュリティ・ポリシー・ファイルを指定します。たとえば、Webサービスのすべての操作の呼出しでSAMLをアイデンティティとして使用する場合は、@Policyアノテーションをクラス・レベルで指定します。
Webサービスに関連付けるポリシー・ファイルは、互いに矛盾しないかぎり、適宜組み合せることができますが、OASIS WS-SecurityPolicy 1.2ファイルと、Oracleのセキュリティ・ポリシー・スキーマに従って記述されたセキュリティ・ポリシー・ファイルを組み合せることはできません。
たとえば、<Identity>セキュリティ・アサーションのみが含まれるシンプルなMyAuth.xmlファイルを作成し、アイデンティティにSAMLの使用を指定してから、これを事前定義済のWssp1.2-2007-EncryptBody.xmlおよびWssp1.2-2007-SignBody.xmlファイルとともにWebサービスに関連付けます。ただし、関連付けられた複数のポリシー・ファイルが互いに矛盾しないようにする必要があります。なんらかの矛盾がある場合は、実行時エラーが発生するか、またはWebサービスが想定どおりに動作しなくなるおそれがあります。
通常の反復的な開発プロセスの一部として、Webサービスを再コンパイルして再デプロイします。
Oracle WebLogic Server JAX-RPC Webサービスの開発のWebLogic Webサービスの開発を参照してください。
SAMLをアイデンティティとして使用してメインWebサービスを呼び出すように、WebLogic Serverインスタンスで実行されるクライアント・アプリケーションを作成します。詳細は、「WebLogic Serverインスタンスで実行中のクライアントからのWebサービスの呼出し」を参照してください。
このリリースのWebLogic Serverには、スタンドアロン・クライアントによるSAML 1.1 Bearerの例が含まれています。この例は、WebLogic ServerインストールのWLS_HOME\samples\server\examples\src\examples\webservices\saml\bearer11sslにあります。
これはスタンドアロン・クライアントによるSAML 1.1 Bearerの例です。WS-TrustによるSAMLアサーションを使用したWebサービス・アプリケーションの認証に必要な最小限の構成および設定を示しています。この例には、FlightService Webサービス、およびセキュリティ・トークン・サービス(STS)として使用するSTSHttpsUNT.javaをホストする2つのWebLogic Serverインスタンスが含まれています。
TravelAgencyClientは公開鍵/秘密鍵の組合せを保持せず、トランスポート・レベルのメッセージ保護を使用して、STSからSAMLトークンを取得して認証を行います。
SAMLアサーションは、サブジェクトに対する認証動作の実行、サブジェクトの属性に関する情報、または特定のリソースに関する認可データのサブジェクトへの適用について、SAML権限が作成するデータです。
SAMLの仕様(http://www.oasis-open.orgを参照)では、特定のサブジェクトに関する不特定の追加情報をSAMLパートナ間でアサーション内の属性文としてやり取りすることが許可されています。したがって、SAML属性アサーションは、サブジェクトの属性に関してサイトで決定される情報を伝達する、特定のタイプのSAMLアサーションです。
属性のデータ型はStringです。
属性は、多くの場合、名前/値の組合せであり(たとえば、name=position, value=team lead)、複数の値を指定できます。ただし、必ずしもこのモデルに従う必要はありません。
SAML属性はターゲット・パートナ・サービスで確認でき、認証または認可の際の追加情報として使用できます。
SAML属性の使用はサーバー間で機能します。つまり、あるWebLogic Serverインスタンスで、属性を提供するクライアント・アプリケーションが実行されています。このアプリケーションは、同じまたは別のWebLogic Serverインスタンスで実行されているWebサービスを呼び出して属性を使用します。クライアント・アプリケーション自体がWebサービスであるため、Webサービス・セキュリティ・ランタイムによってすべてのSAML処理が行われます。
表2-5に示すクラスおよびインタフェースを使用してSAMLの属性を実装できます。詳細は、Oracle WebLogic Server Java APIリファレンスを参照してください。
表2-5 SAML属性のクラスおよびインタフェース
| インタフェースまたはクラス | 説明 |
|---|---|
|
SAML 2.0アサーションの資格証明プロバイダ。 |
|
SAML 1.1アサーションの資格証明プロバイダ。 |
|
このインタフェースは、1つの属性文中の属性を表します。SAML 1.1および2.0に対応しています。 |
|
このクラスは、1つの属性文中の属性を表します。SAML 1.1および2.0に対応しています。 |
|
SAML 1.1またはSAML 2.0属性のいずれかのSAML属性情報インタフェース。 |
|
weblogic.wsee.security.saml.SAMLAttributeDataを実装するクラス。 |
|
SAMLAttributeStatementDataオブジェクトを取得するヘルパー関数 |
表2-5に記載されたクラスとインタフェースの中で、SAMLAttributeDataインタフェースについて追加の説明を行います。SAMLAttributeDataインタフェースは、SAML 1.1およびSAML 2.0の属性をサポートします。表2-6に示すメソッドがあります。
表2-6 SAMLAttributeDataのメソッド
| メソッド | 説明 |
|---|---|
|
属性名を取得します。 |
|
属性名の書式を取得します(SAML 2.0専用)。 |
|
属性のわかりやすい名前を取得します。 |
|
属性値の集合を取得します。 |
|
SAML 2.0の属性かどうかをチェックします。SAML 2.0属性の場合はtrue、それ以外の場合はfalseを返します |
|
属性名を設定します。 |
|
属性名の書式を設定します。 |
|
わかりやすい属性名を設定します。 |
|
属性値の集合を設定します。 |
|
属性値を1つ追加します。 |
|
属性のネームスペースを取得します。SAML 1.1専用です。 |
|
属性のネームスペースを設定します。SAML 1.1専用です。 |
|
このオブジェクトからSAML 2.0属性情報オブジェクトを取得します。 |
|
このオブジェクトからSAML 1.1属性情報オブジェクトを取得します。 |
|
この属性データ要素の値がないかどうかをチェックします。 |
SAML2CredentialProviderクラスおよびSAMLCredentialProviderクラスは、Webサービス・コンテキストを介してSAMLアサーションに属性を追加するメカニズムを提供します。
SAMLパートナで、SAMLAttributeStatementDataHelper.getSAMLAttributeStatementDataメソッドを使用して、Webサービス・コンテキストに基づいて受信SAMLアサーションから属性をマップします。
次の手順に従います。
SAML2CredentialProviderまたはSAMLCredentialProvider (SAMLアイデンティティ・プロバイダ・サイト)によって、使用する属性およびパッケージの方法が決定されます。
属性をパッケージするには、SAMLAttributeStatementDataインタフェースおよびSAMLAttributeDataインタフェースを実装します。
SAMLパートナは、WebServiceContextを使用して属性を取得し、属性に対する処理を決定します。
SAMLAttributeStatementDataHelperクラスを使用してSAMLAttributeStatementDataオブジェクトを取得し、このオブジェクトからSAMLAttributeDataオブジェクトを取得します。
この項では、SAML 2.0のSAML属性を実装する単純なアプリケーションについて説明します。この例は、WebLogic ServerインストールのWLS_HOME\samples\server\examples\src\examples\webservices\saml\saml20svにあります。
例2-14に、WebLogic Serverインスタンスで実行されているWebサービス(クライアント)の例を示します。
このWebサービスは、WebServiceContextに4つの属性を追加します。最初の属性は値を保持せず、2番目の属性は静的値を使用します。3番目および4番目の属性の値は、サブジェクトの認証に基づいて計算されます。
例2-14 WebServiceContextに属性を追加するWebサービス
@WebService(serviceName = "ProxyService", name = "IProxy", targetNamespace = "http://www.oracle.com/2008/12/interop")
public class ProxyService{
@WebMethod(operationName = "Echo")
@WebResult(name = "EchoResponse")
public String echo(@WebParam(name = "EchoRequest")String hello,
@WebParam(name = "partenerWsdlURL") String partenerWsdlURL){
try{
PartnerService service =
new PartnerService(new URL(partenerWsdlURL),
new QName("http://www.oracle.com/2008/12/interop", "PartnerService"));
IPartner port = service.getIPartnerPort();
BindingProvider provider = (BindingProvider) port;
Map context = provider.getRequestContext();
context.put(WLStub.SAML_ATTRIBUTE_ONLY, "True");
List credProviders = buildCredentialProviderList();
context.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
String result = port.echo(hello);
return result+" I'm ProxyService Echo!\n";
} catch(Exception ex ){
throw new RuntimeException(ex);
}
}
private static List buildCredentialProviderList() throws Exception {
List credProviders = new ArrayList();
credProviders.add(new MySAMLCredentialProvider1());
return credProviders;
}
/**
* This Credential Provider is for SAML 2.0 Sender Vouches
*/
private static class MySAMLCredentialProvider1 extends SAML2CredentialProvider {
public SAMLAttributeStatementData getSAMLAttributeData(Subject subject) {
System.out.println(" Providing SAML Attributes from MySAMLCredentialProvider1 for Subject =" + subject);
// There are four types of attributes in this test
SAMLAttributeStatementData attributes = new SAMLAttributeStatementDataImpl();
String xmlns = "www.oracle.com/webservices/saml/test";
// 1. The attribute without value
SAMLAttributeData attribute1 = new SAMLAttributeDataImpl();
attribute1.setAttributeName("test.no.value.attribute");
// Friendly name is optional. It is set in this example.
attribute1.setAttributeFriendlyName("Type 1 - No Value");
attribute1.setAttributeNameSpace(xmlns);
attributes.addAttributeInfo(attribute1);
// 2. Static attribute that has static value
SAMLAttributeData attribute2 = new SAMLAttributeDataImpl();
attribute2.setAttributeName("test.static.attribute");
attribute2.setAttributeFriendlyName("Type 2 - Static Attribute");
attribute2.setAttributeNameSpace(xmlns);
attribute2.addAttributeValue("static.attribute.value");
attributes.addAttributeInfo(attribute2);
// 3. Subjust dependent attributes
SAMLAttributeData attribute3 = new SAMLAttributeDataImpl();
attribute3.setAttributeName("test.subject.dependent.attribute");
attribute3.setAttributeFriendlyName("Type 3 - Subject Dependent Attribute");
attribute3.setAttributeNameSpace(xmlns);
if (hasUser("Alice", subject)) {
attribute3.addAttributeValue("Alice A");
} else if (hasUser("Bob", subject)) {
attribute3.addAttributeValue("Bob B");
} else {
attribute3.addAttributeValue("Hacker X");
}
attributes.addAttributeInfo(attribute3);
// 4. Multiple value attributes
SAMLAttributeData attribute4 = new SAMLAttributeDataImpl();
attribute4.setAttributeName("test.multi.value.attribute");
attribute4.setAttributeFriendlyName("Type 4 - Multi-Value Attribute");
attribute4.setAttributeNameSpace(xmlns);
if (hasUser("Alice", subject)) {
attribute4.addAttributeValue("Team Lead");
attribute4.addAttributeValue("Programmer");
} else if (hasUser("Bob", subject)) {
attribute4.addAttributeValue("System Admin");
attribute4.addAttributeValue("QA");
} else {
attribute4.addAttributeValue("Hacker");
attribute4.addAttributeValue("meber of unkown");
}
attributes.addAttributeInfo(attribute4);
return attributes;
}
private static boolean hasUser(String user, Subject subject) {
if (null == user || null == subject) {
return false;
}
Set principals = subject.getPrincipals();
if (null == principals || principals.isEmpty()) {
return false;
}
for (Iterator it = principals.iterator(); it.hasNext(); ) {
Object obj = it.next();
if (obj instanceof Principal) {
Principal p = (Principal) obj;
// System.out.println("principal =[" + p + "]");
if (user.equals(p.getName())) {
return true;
}
} else if (obj instanceof WLSPrincipal) {
WLSPrincipal principal = (WLSPrincipal) obj;
// System.out.println("principal =[" + principal + "]");
if (user.equals(principal.getName())) {
return true;
}
}
}
return false;
}
}
}
この例では、SAMLAttributeStatementDataImpl()クラスを呼び出してSAMLAttributeStatementDataオブジェクトを取得し、SAMLAttributeDataImpl()を呼び出してSAML2AttributeStatementInfoオブジェクトを取得します。
SAMLAttributeDataクラスはSAML 2.0および1.1をサポートし、この例ではSAML 2.0を使用します。例2-15に、SAMLAttributeDataImpl()を示します。
例2-15 SAMLAttributeDataImplの実装
package weblogic.wsee.security.saml;
import com.bea.security.saml2.providers.SAML2AttributeInfo;
import weblogic.security.providers.saml.SAMLAttributeInfo;
import java.util.Collection;
import java.util.ArrayList;
import java.util.List;
import java.util.Iterator;
/**
*
*/
public class SAMLAttributeDataImpl implements SAMLAttributeData {
public static final String SAML_2_0_ATTRNAME_FORMAT_BASIC = SAML2AttributeInfo.ATTR_NAME_FORMAT_BASIC;
/**
* the name of the attribute
*/
private String attributeName;
private String attributeNameSpace;
/**
* the name format of the attribute for SAML 2.0. Defaults to basic.
*/
private String attributeNameFormat = SAML_2_0_ATTRNAME_FORMAT_BASIC;
/**
* the friendly name of the attribute, this is for SAML 2.0 only.
*/
private String attributeFriendlyName;
/**
* the values of the attribute.
*/
private Collection<String> attributeValues;
/**
* is a SAML 2.0 attribute info
*/
private boolean isSAML20;
public SAMLAttributeDataImpl() {
}
public SAMLAttributeDataImpl(String attributeName, Collection<String> attributeValues) {
this.attributeName = attributeName;
this.attributeValues = attributeValues;
}
public SAMLAttributeDataImpl(String attributeName, String
attributeNameFormat, String attributeFriendlyName, String namespace,
Collection<String> attributeValues) {
this.attributeName = attributeName;
this.attributeNameFormat = attributeNameFormat;
this.attributeFriendlyName = attributeFriendlyName;
this.attributeValues = attributeValues;
this.attributeNameSpace = namespace;
}
public SAMLAttributeDataImpl(SAML2AttributeInfo saml2AttributeInfo) {
if (null == saml2AttributeInfo) {
throw new IllegalArgumentException("Null SAML2AttributeInfo found ");
}
this.attributeName = saml2AttributeInfo.getAttributeName();
this.attributeNameFormat = saml2AttributeInfo.getAttributeNameFormat();
this.attributeFriendlyName = saml2AttributeInfo.getAttributeFriendlyName();
this.attributeValues = saml2AttributeInfo.getAttributeValues();
this.isSAML20 = true;
}
public SAMLAttributeDataImpl(SAMLAttributeInfo samlAttributeInfo) {
if (null == samlAttributeInfo) {
throw new IllegalArgumentException("Null SAMLAttributeInfo found ");
}
this.attributeName = samlAttributeInfo.getAttributeName();
this.attributeNameSpace = samlAttributeInfo.getAttributeNamespace();
this.attributeValues = samlAttributeInfo.getAttributeValues();
this.isSAML20 = false;
}
/**
* get the attribute name
*
* @return string of the attribute name
*/
public String getAttributeName() {
return attributeName;
}
/**
* set the attribute name
*
* @param attributeName string of the attribute name
*/
public void setAttributeName(String attributeName) {
if (null == attributeName) {
throw new IllegalArgumentException("attributeName cannot be null");
}
this.attributeName = attributeName;
}
/**
* get the attribute name format for SAML 2.0 only
*
* @return String of the attribute name format,
default is SAML_2_0_ATTRNAME_FORMAT_BASIC for SAML 2.0. Null for SAML 1.1.
*/
public String getAttributeNameFormat() {
return attributeNameFormat;
}
/**
* set et the attribute name format
*
* @param attributeNameFormat String of the attribute name format
*/
public void setAttributeNameFormat(String attributeNameFormat) {
this.attributeNameFormat = attributeNameFormat;
}
/**
* get the Attribute Friendly Name
*
* @return String of the Attribute Friendly Name
*/
public String getAttributeFriendlyName() {
return attributeFriendlyName;
}
/**
* set the Attribute Friendly Name
*
* @param attributeFriendlyName the Attribute Friendly Name
*/
public void setAttributeFriendlyName(String attributeFriendlyName) {
this.attributeFriendlyName = attributeFriendlyName;
}
/**
* get the Attribute Value
*
* @return collection of attribute values
*/
public Collection<String> getAttributeValues() {
return attributeValues;
}
/**
* set collection of attribute values
*
* @param attributeValues collection of attribute values to be set
*/
public void setAttributeValues(Collection<String> attributeValues) {
this.attributeValues = attributeValues;
}
/**
* add one attribute value
*
* @param attributeValue String of attribute value to be added
*/
public void addAttributeValue(String attributeValue) {
if (this.attributeValues == null) {
this.attributeValues = new ArrayList();
}
if (null == attributeValue) {
this.attributeValues.add("");
} else {
this.attributeValues.add(attributeValue);
}
}
/**
* add attribute values
*
* @param newAttributeValues collection of attribute values to be added
*/
public void addAttributeValues(Collection<String> newAttributeValues) {
if (this.attributeValues == null || this.attributeValues.isEmpty()) {
this.setAttributeValues(newAttributeValues);
return;
}
if (null == newAttributeValues || newAttributeValues.isEmpty()) {
this.attributeValues.add("");
return;
}
Iterator iter = newAttributeValues.iterator();
while (iter.hasNext()) {
this.attributeValues.add((String) iter.next());
}
}
/**
* get the namespace of the Attribute. This is for SAML 1.1 only.
*
* @return string of attribute namespace
*/
public String getAttributeNameSpace() {
return attributeNameSpace;
}
/**
* set attributeNameSpace. This is for SAML 1.1 only.
*
* @param attributeNameSpace attributeNameSpace to be set
*/
public void setAttributeNameSpace(String attributeNameSpace) {
this.attributeNameSpace = attributeNameSpace;
}
/**
* set this data object to SAML 2.0 attribute object
* @param saml20 true if it is a SAML 2.0 attribute data
*/
public void setSAML20(boolean saml20) {
this.isSAML20 = saml20;
}
/**
* check if this is a SAML 2.0 Attributes
*
* @return true if it is a SAML 2.0 attribute, false otherwise
*/
public boolean isSAML20() {
return isSAML20;
}
/**
* get a SAML2AttributeInfo object from this object
*
* @return SAML2AttributeInfo for SAML 2.0
*/
public SAML2AttributeInfo getSAML2AttributeInfo() {
SAML2AttributeInfo sai = new SAML2AttributeInfo();
sai.setAttributeFriendlyName(this.attributeFriendlyName);
sai.setAttributeName(this.attributeName);
if (null == this.attributeNameFormat || this.attributeNameFormat.length() ==0 ) {
sai.setAttributeNameFormat(SAML_2_0_ATTRNAME_FORMAT_BASIC);
} else {
sai.setAttributeNameFormat(this.attributeNameFormat);
}
sai.addAttributeValues(this.attributeValues);
return sai;
}
/**
* get a SAMLAttributeInfo object from this object
*
* @return SAMLAttributeInfo for SAML 1.1
*/
public SAMLAttributeInfo getSAMLAttributeInfo() {
SAMLAttributeInfo sai = new SAMLAttributeInfo();
if (null == this.attributeNameSpace) {
sai.setAttributeName(this.attributeName, "");
} else {
sai.setAttributeName(this.attributeName, this.attributeNameSpace);
}
sai.setAttributeValues(this.attributeValues);
return sai;
}
/**
* This method will add all attribute values into the first SAMLAttributeData
object, and return a single SAMLAttributeData object.
* Please note that the attribute name will not be verified in this method.
*
* @param attributeList SAMLAttributeData objects to be merged
* @return a single SAMLAttributeData object
*/
static public SAMLAttributeData consolation(List<SAMLAttributeData>
attributeList) {
if (null == attributeList || attributeList.size() == 0 ) {
return null;
}
if (attributeList.size() == 1) {
attributeList.get(0);
}
SAMLAttributeData data = attributeList.get(0);
for (int i=1; i < attributeList.size(); i++ ) {
data.addAttributeValues(attributeList.get(i).getAttributeValues());
}
return data;
}
/**
* Check if this attribute data element does not have vlaues
* @return true if the data is empty, no values; false otherwise
*/
public boolean isEmpty() {
if ((null == this.attributeValues) || (this.attributeValues.isEmpty())) {
return true;
}
if (this.attributeValues.size() == 1) {
Object a[] = this.attributeValues.toArray();
if ("".equals(a[0])) {
return true;
}
}
return false;
}
/**
* Return a String for the array of value String, concatenated with "; "
* @return a string for all values
*/
public String valuesToString(String existing) {
if ((null == this.attributeValues) || (this.attributeValues.isEmpty())) {
return existing;
}
Object a[] = this.attributeValues.toArray();
if (this.attributeValues.size() == 1) {
if (a[0] == null) {
return existing;
}
if (existing == null) {
return (String) a[0];
} else {
return existing + "; " + (String) a[0];
}
}
StringBuffer sb = new StringBuffer();
if (existing != null) {
sb.append(existing);
}
for (int i=0; i < a.length; i++) {
sb.append("; ");
if (a[i] != null) {
sb.append((String) a[i]);
}
}
return sb.toString();
}
public String toString() {
StringBuffer sb = new StringBuffer();
sb.append("Name=" + this.attributeName);
if (isSAML20()) {
if (null != this.attributeFriendlyName) {
sb.append(" FriendlyName=" + this.attributeFriendlyName);
}
} else {
if (null != this.attributeNameSpace) {
sb.append(" Namespace=" + this.attributeNameSpace);
}
}
String value = this.valuesToString(null);
if (null != value) {
sb.append(" Value=" + value);
}
return sb.toString();
}
}
例2-16に示すPartnerServiceコードは、Webサービス・コンテキストの属性の有無を判定し、それらを取得します。この例は、例2-17に示すSAMLAttributeStatementDataHelperクラスに依存します。
この例で使用される事前定義済のポリシー、Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xmlについては、表2-13で説明します。
例2-16 WebServiceContextから属性を取得するWebサービス
package jaxws.interop.saml;
import weblogic.jws.Policies;
import weblogic.jws.Policy;
import weblogic.wsee.util.AccessException;
import weblogic.wsee.security.saml.SAMLAttributeStatementData;
import weblogic.wsee.security.saml.SAMLAttributeStatementDataHelper;
import weblogic.wsee.security.saml.SAMLAttributeData;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.annotation.Resource;
import javax.xml.ws.WebServiceContext;
/**
* ID Propagation using SAML 2.0 token [sender-vouches] with message protection (WSS 11) .
*
* This example will work for canned policy like:
* - Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml
*/
@Policies(
{
@Policy(uri = "policy:Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml"),
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml"),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml")
}
)
@WebService(serviceName = "PartnerService", name = "IPartner", targetNamespace = "http://www.oracle.com/2008/12/interop")
public class PartnerService{
@Resource
WebServiceContext ctx;
@WebMethod(operationName = "Echo")
@WebResult(name = "EchoResponse")
public String echo(@WebParam(name = "EchoRequest")String hello){
try {
this.checkSamlAttributesFromRequestMesasge();
return hello+"! I'm PartnerService for SAML 2.0 SenderVouches WSS1.1!\n";
}catch(Exception ex ){
throw new RuntimeException(ex);
}
}
private void checkSamlAttributesFromRequestMesasge() throws AccessException {
SAMLAttributeStatementData attributes = SAMLAttributeStatementDataHelper.getSAMLAttributeStatementData(ctx);
if (null == attributes) {
throw new AccessException("No SAML Attributes Data found");
}
SAMLAttributeData testData = attributes.getAttributeInfo("test.no.value.attribute");
if (null == testData) {
throw new AccessException("Missing SAML Attribute Data of \"test.no.value.attribute\"");
}
if (!attributes.hasAttributeInfo("test.no.value.attribute")) {
throw new AccessException("Missing SAML Attribute Data of \"test.no.value.attribute\"");
}
if (!attributes.hasAttributeInfo("test.static.attribute")) {
throw new AccessException("Missing SAML Attribute Data of \"test.static.attribute\"");
}
if (!attributes.hasAttributeValue("test.static.attribute","static.attribute.value")) {
throw new AccessException("Missing or wrong SAML Attribute Value of \"static.attribute.value\" for attribute \"test.static.attribute\" ");
}
if (!attributes.hasAttributeValue("test.subject.dependent.attribute","Alice A")) {
throw new AccessException("Missing or wrong SAML Attribute Value of \"Alice A\" for attribute - \"test.multi.value.attribute\" ");
}
if (!attributes.hasAttributeValue("test.multi.value.attribute","Programmer")) {
throw new AccessException("Missing or wrong SAML Attribute Value on \"Programmer\" for attribute \"test.multi.value.attribute\" ");
}
if (!attributes.hasAttributeValue("test.multi.value.attribute","Team Lead")) {
throw new AccessException("Missing or wrong SAML Attribute Value on \"Team Lead\" for attribute \"test.multi.value.attribute\" ");
}
}
}
例2-17に、SAMLAttributeStatementDataHelperクラスを示します。これはSAMLAttributeStatementDataオブジェクトを取得するヘルパー関数です。
例2-17 SAMLAttributeStatementDataHelperヘルパー関数
package weblogic.wsee.security.saml;
import weblogic.wsee.jaxws.framework.jaxrpc.SOAPMessageContext;
import weblogic.wsee.jaxrpc.WLStub;
import weblogic.wsee.jws.JwsContext;
import weblogic.xml.crypto.wss.WSSecurityContext;
import com.sun.xml.ws.api.message.Message;
import com.sun.xml.ws.api.message.Packet;
import com.sun.xml.ws.api.server.WSWebServiceContext;
import javax.xml.ws.WebServiceContext;
import javax.xml.rpc.handler.MessageContext;
/**
* Helper function to get the SAMLAttributeStatementData object
*/
public class SAMLAttributeStatementDataHelper {
public static SAMLAttributeStatementData getSAMLAttributeStatementData(WebServiceContext context) {
final Packet request = ((WSWebServiceContext) context).getRequestPacket();
WSSecurityContext securityCtx = (WSSecurityContext) request.invocationProperties
.get(WSSecurityContext.WS_SECURITY_CONTEXT);
SAMLAttributeStatementData samlAttributes = null;
if ((securityCtx != null) && (securityCtx.getMessageContext() != null)) {
samlAttributes = (SAMLAttributeStatementData) securityCtx.getMessageContext().getProperty(WLStub.SAML_ATTRIBUTES);
}
return samlAttributes;
}
public static SAMLAttributeStatementData getSAMLAttributeStatementData(JwsContext context) {
MessageContext msgCtx = context.getMessageContext(); // this is for JAX-RPC
SAMLAttributeStatementData attributes = (SAMLAttributeStatementData) msgCtx.getProperty(WLStub.SAML_ATTRIBUTES);
return attributes;
}
}
これまでに説明した多くの使用例では、WebLogic Server管理コンソールを使用してデフォルトのWebサービス・セキュリティ構成(default_wss)を作成する必要があります。この構成の作成後は、@weblogic.jws.security.WssConfiguration JWSアノテーションを使用しなくても、属性のない状態でこのアノテーションを指定しても、すべてのWebサービスにこの構成が適用されます。
ただし、指定するタイムスタンプ値をサービス間で変える場合など、Webサービスをデフォルト以外のセキュリティ構成に関連付ける必要が生じる場合もあります。
Webサービスをデフォルト以外のセキュリティ構成に関連付けるには、次の手順に従います。
セキュリティ構成を作成するときに、その構成の資格証明プロバイダのクラス名を指定する必要があります。使用できる有効なクラス名とトークン・タイプは以下のとおりです。
weblogic.wsee.security.bst.ClientBSTCredentialProvider。トークン・タイプはx509です。
weblogic.wsee.security.unt.ClientUNTCredentialProvider。トークン・タイプはutです。
weblogic.wsee.security.wssc.v13.sct.ClientSCCredentialProvider。トークン・タイプはsctです。
weblogic.wsee.security.wssc.v200502.sct.ClientSCCredentialProvider。トークン・タイプはsctです。
weblogic.wsee.security.saml.SAMLTrustCredentialProvider。トークン・タイプはsamlです。
次の表に、メッセージ保護されたWebサービスの問題をデバッグするために設定できるシステム・プロパティをまとめます。
表2-7 メッセージ・レベルのセキュリティをデバッグするためのシステム・プロパティ
| システム・プロパティ | データ型 | 説明 |
|---|---|---|
weblogic.xml.crypto.dsig.verbose |
ブール |
デジタル署名の処理に関する情報を出力します。 |
weblogic.xml.crypto.encrypt.verbose |
ブール |
暗号化処理に関する情報を出力します。 |
weblogic.xml.crypto.keyinfo.verbose |
ブール |
キーの解決処理に関する情報を出力します。 |
weblogic.xml.crypto.wss.verbose |
ブール |
Webサービス・セキュリティ・トークンおよびトークンの参照処理に関する情報を出力します。 |
「メッセージ・レベルのセキュリティ構成でのポリシー・ファイルの使用」では、Webサービスのメッセージ・レベルのセキュリティを記述する1つまたは複数のセキュリティ・ポリシー・ファイルに、WebLogic Webサービスを関連付ける方法について説明しています。これらのポリシー・ファイルは、SOAPメッセージのデジタル署名や暗号化の方法と、Webサービスを呼び出すクライアントで必要になるユーザー認証の種類を記述するXMLファイルです。通常、Webサービスに関連付けられたポリシー・ファイルはそのWSDLにアタッチされ、Webサービス・クライアント・ランタイムはこれを読み取り、クライアント・アプリケーションから呼び出された操作からのSOAPメッセージ・リクエストのデジタル署名や暗号化を行うかどうかを判別したり、行う場合はその方法を判別したりします。
しかし、Webサービスがデプロイ済のWSDLにポリシー・ファイルをアタッチしない場合や、WebサービスがWSDLを公開しないように構成されている場合もあります。これらの場合、Webサービス・クライアント・ランタイムは、SOAPメッセージ・リクエスト用に有効化する必要があるセキュリティをサービス自体から判別できません。かわりに、ポリシー・ファイルのクライアント側のコピーをロードする必要があります。この項では、クライアント・アプリケーションを更新して、ポリシー・ファイルのローカル・コピーがロードされるようにする方法について説明します。
例2-5は、JAX-WS Webサービスのクライアント側ポリシー・ファイルを使用する例を示しています。
通常、クライアント側のポリシー・ファイルは、デプロイ済のWebサービスに関連付けられているポリシー・ファイルとまったく同じものです。これら2つのファイルが異なり、ファイルに含まれるセキュリティ・アサーションに競合がある場合は、Webサービスの操作を呼び出すとエラーが返されます。
クライアント側のポリシー・ファイルは、SOAPメッセージのリクエストまたはレスポンス、あるいはその両方に関連付けることができます。また、ポリシー・ファイルをWebサービス全体と関連付けるか、Webサービスの操作の1つのみと関連付けるかを指定できます。
次の手順は、Webサービスの操作を呼び出すクライアント・アプリケーションにセキュリティ・ポリシー・ファイルを関連付けるためのステップを大まかに説明したものです。
デプロイ済のWebサービスを呼び出すクライアント・アプリケーションを作成してあり、クライアント側のポリシー・ファイルを関連付けることでそのクライアント・アプリケーションを更新するものとします。また、Antベースの開発環境を設定済であり、かつclientgen Antタスクを実行するためのターゲットを含む、作業用のbuild.xmlファイルがあることが前提となっています。
Oracle WebLogic Server JAX-WS Webサービスの開発のWebサービスの呼出しおよびOracle WebLogic Server JAX-RPC Webサービスの開発のスタンドアロン・クライアントからのWebサービスの呼出し: 主な手順を参照してください。
次回クライアント・アプリケーションを実行するときには、ポリシー・ファイルのローカル・コピーがロードされ、Webサービス・クライアント・ランタイムはこれを使用してSOAPリクエスト・メッセージのセキュリティを有効にします。
注意:
すでにセキュリティ・ポリシーが設定されているWebサービスの操作(たとえば、サーバー・ポリシーからクライアントを生成する際に格納されたWSDLファイル内で設定されたWebサービス操作)が存在する場合、この手順に従ってクライアント側のセキュリティ・ポリシーをプログラムで設定すると、それ以前に存在していたポリシーはすべて削除されます。
JAX-RPCの場合は、clientgen AntタスクのgeneratePolicyMethods属性をtrueに設定して、Antタスクが追加のgetXXX()メソッドをJAX-RPC Serviceインタフェースの実装内に生成するように指定し、ポートの取得時にポリシー・ファイルのクライアント側コピーがロードされるようにします。例:
<clientgen
wsdl="http://ariel:7001/policy/ClientPolicyService?WSDL"
destDir="${clientclass-dir}"
generatePolicyMethods="true"
packageName="examples.webservices.client_policy.client"/>
追加で生成されるメソッドとそれらをクライアント・アプリケーションで使用する方法の説明は、「ポリシー・ファイルをロードするためのクライアント・アプリケーションの更新(JAX-RPCのみ)」を参照してください。
JAX-WSの使用
JAX-WSの場合は、weblogic.jws.jaxws.ClientPolicyFeatureクラスを使用して、サービスに定義されている有効なポリシーをオーバーライドします。weblogic.jws.jaxws.ClientPolicyFeatureはjavax.xml.ws.WebServiceFeatureを拡張したものです。
clientgenでgeneratePolicyMethods="true"と設定すると、Antタスクはポリシー・ファイルのロードに使用できるJAX-RPC Serviceインタフェースの実装内に追加メソッドを生成します(XXXはWebサービスの名前です)。
ポリシー・ファイルの配列または集合を、Webサービスへの複数ファイルの関連付けに使用できます。単一のポリシー・ファイルのみを関連付ける場合は、単一メンバーの配列または集合を作成します。
getXXXPort(String operationName, java.util.Set<java.io.InputStream> inbound, java.util.Set<java.io.InputStream> outbound)
クライアント側のポリシー・ファイルの別個の2つの集合を、InputStreamsからロードし、1つ目の集合をSOAPリクエストに関連付け、2つ目をSOAPレスポンスに関連付けます。最初のパラメータで指定されているように、特定の操作に適用されます。
getXXXPort(String operationName, java.io.InputStream[] inbound, java.io.InputStream[] outbound)
クライアント側のポリシー・ファイルの別個の2つの配列を、InputStreamsからロードし、1つ目の配列をSOAPリクエストに関連付け、2つ目をSOAPレスポンスに関連付けます。最初のパラメータで指定されているように、特定の操作に適用されます。
getXXXPort(java.util.Set<java.io.InputStream> inbound, java.util.Set<java.io.InputStream> outbound)
クライアント側のポリシー・ファイルの別個の2つの集合を、InputStreamsからロードし、1つ目の集合をSOAPリクエストに関連付け、2つ目をSOAPレスポンスに関連付けます。Webサービスのすべての操作に適用されます。
getXXXPort(java.io.InputStream[] inbound, java.io.InputStream[] outbound)
クライアント側のポリシー・ファイルの別個の2つの配列を、InputStreamsからロードし、1つ目の配列をSOAPリクエストに関連付け、2つ目をSOAPレスポンスに関連付けます。Webサービスのすべての操作に適用されます。
Webサービスのポートを取得すると同時に、そのポートを使用するすべての操作または指定された操作の呼出しに対してポリシー・ファイルが関連付けられるようにするには、パラメータのない通常のgetXXXPort()メソッドではなく、これらのメソッドを使用します。
注意:
前のリリースのWebLogic Serverからの以下のメソッドは、非推奨となっています。単一のクライアント側ポリシー・ファイルの関連付けを行う場合は、単一メンバーの配列または集合を指定し、上述の対応するメソッドを使用します。
getXXXPort(java.io.InputStream policyInputStream);
単一のクライアント側ポリシー・ファイルをInputStreamからロードし、SOAPリクエスト(着信)メッセージおよびSOAPレスポンス(発信)メッセージの両方に追加します。
getXXXPort(java.io.InputStream policyInputStream, boolean inbound, boolean outbound);
単一のクライアント側ポリシー・ファイルをInputStreamからロードし、2番目および3番目のパラメータのブール値に応じて、SOAPリクエスト・メッセージまたはSOAPレスポンス・メッセージのどちらかに適用します。
例2-18に、これらのポリシー・メソッドの簡易なクライアント・アプリケーションでの使用例を示します。太字で示されたコードは、例の後に説明します。
例2-18 クライアント・アプリケーションでのポリシーのロード
package examples.webservices.client_policy.client;
import java.rmi.RemoteException;
import javax.xml.rpc.ServiceException;
import javax.xml.rpc.Stub;
import java.io.FileInputStream;
import java.io.IOException;
/**
* This is a simple standalone client application that invokes the
* the <code>sayHello</code> operation of the ClientPolicyService web service.
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class Main {
public static void main(String[] args)
throws ServiceException, RemoteException, IOException {
FileInputStream [] inbound_policy_array = new FileInputStream[2];
inbound_policy_array[0] = new FileInputStream(args[1]);
inbound_policy_array[1] = new FileInputStream(args[2]);
FileInputStream [] outbound_policy_array = new FileInputStream[2];
outbound_policy_array[0] = new FileInputStream(args[1]);
outbound_policy_array[1] = new FileInputStream(args[2]);
ClientPolicyService service = new ClientPolicyService_Impl(args[0] + "?WSDL");
// standard way to get the web service port
ClientPolicyPortType normal_port = service.getClientPolicyPort();
// specify an array of policy files for the request and response
// of a particular operation
ClientPolicyPortType array_of_policy_port = service.getClientPolicyPort("sayHello",
inbound_policy_array, outbound_policy_array);
try {
String result = null;
result = normal_port.sayHello("Hi there!");
result = array_of_policy_port.sayHello("Hi there!");
System.out.println( "Got result: " + result );
} catch (RemoteException e) {
throw e;
}
}
}
クライアント・アプリケーションに対する2つ目と3つ目の引数は、アプリケーションがFileInputStreamsの配列(inbound_policy_arrayおよびoutbound_policy_array)を作成する元となる2つのポリシー・ファイルです。normal_portはポートの取得にパラメータのない標準的なメソッドを使用します。一方、array_of_policy_portはポリシー・メソッドの1つを使用します。このポリシー・メソッドで、ポートを使用するsayHello操作の呼出しでは複数のポリシー・ファイル(FileInputStreamの配列で指定)が、着信および発信のSOAPリクエストおよびレスポンスと関連付けられていることを指定します。
ClientPolicyPortType array_of_policy_port =
service.getClientPolicyPort("sayHello", inbound_policy_array, outbound_policy_array);
WebLogic Serverには、ほとんどのWebサービス・アプリケーションで使用できるWS-SecurityPolicyファイルが多数用意されています。ポリシー・ファイルはORACLE_HOMEoracle_common/modules/com.oracle.webservices.wls.wls-soap-stack-impl.jarにあります。com.oracle.webservices.wls.wls-soap-stack-impl.jar内では、ポリシー・ファイルは/weblogic/wsee/policy/runtimeにあります。
これらのポリシーは2つのグループに分けられます。ほとんどの場合、実行する機能はどちらも同じですが、使用するネームスペースが異なります。
1つ目のグループは、Wssp1.2-2007-という接頭辞が付いています。これらのセキュリティ・ポリシー・ファイルは、OASIS WS-SecurityPolicy 1.2仕様に準拠しており、次のネームスペースを備えています。
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" >
2番目のグループは、WebLogic Serverバージョン10.0から引き継いだもので、接頭辞Wssp1.2-が付いています。
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512" >
OASIS標準の公式のネームスペースであり、他のベンダーと相互運用するときに適しているため、新しいポリシー・ネームスペースを使用することをお薦めします。「Wssp1.2」の接頭辞を持っている古いポリシーは、主に、ポリシーのこのバージョンをすでに使用している既存のアプリケーションと相互運用したいユーザー用です。
次の項では、使用可能なWS-SecurityPolicy 1.2ポリシー・ファイルについて説明します。
さらに、Webサービス実装に最も適したセキュリティ・ポリシー・アプローチの選択方法と、このリリースのWebLogic ServerでサポートされていないWS-SecurityPolicy 1.2の要素については、「ポリシーの選択」および「適切なポリシー選択の構成」を参照してください。
これらのポリシーでは、WSDLへのアクセスおよびWebサービス操作の呼出しに、httpsプロトコルを使用する必要があります。
注意:
Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。
また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。
表2-8 トランスポート・レベルのポリシー
| ポリシー・ファイル | 説明 |
|---|---|
Wssp1.2-2007-Https.xml |
一方向SSL。 |
Wssp1.2-2007-Https-BasicAuth.xml |
基本認証による一方向SSL。リクエストに認可ヘッダーが含まれていない場合は401チャレンジが発生します。 |
Wssp1.2-2007-Https-UsernameToken-Digest.xml |
ダイジェスト・ユーザー名トークンによる一方向SSL。 |
Wssp1.2-2007-Https-UsernameToken-Plain.xml |
プレーン・テキスト・ユーザー名トークンによる一方向SSL。 |
Wssp1.2-2007-Https-UsernameToken-Plain-Basic256Sha256.xml |
Wssp1.2-2007-Https-UsernameToken-Plain.xmlと同じですが、Sha-256のより強力なハッシュ・アルゴリズムを使用します。 |
Wssp1.2-Https.xml |
一方向SSL。 |
Wssp1.2-Https-BasicAuth.xml |
基本認証による一方向SSL。リクエストに認可ヘッダーが含まれていない場合は401チャレンジが発生します。 |
Wssp1.2-Https-UsernameToken-Digest.xml |
ダイジェスト・ユーザー名トークンによる一方向SSL。 |
Wssp1.2-Https-UsernameToken-Plain.xml |
プレーン・テキスト・ユーザー名トークンによる一方向SSL。 |
Wssp1.2-Https-ClientCertReq.xml |
双方向SSL。受信側で、発信元のパブリック証明書をチェックします。認証にクライアント証明書を使用することも可能です。 |
保護アサーションは、保護の対象とレベルを特定するために使用します。保護アサーション・ポリシーは単独では使用できず、X.509トークン・ポリシーと組み合せることによってのみ使用できます。たとえば、Wssp1.2-2007-Wss1.1-X509-Basic256.xmlとWssp1.2-2007-SignBody.xmlを組み合せて使用します。以下のポリシー・ファイルは、署名および暗号化によって、メッセージ部分の保護を提供します。
表2-9 保護アサーション・ポリシー
| ポリシー・ファイル | 説明 |
|---|---|
Wssp1.2-2007-SignBody.xml |
すべてのメッセージ本文部分が署名されます。 |
Wssp1.2-2007-EncryptBody.xml |
すべてのメッセージ本文部分が暗号化されます。 |
Wssp1.2-2007-Sign-Wsa-Headers.xml |
WS-Addressingヘッダーが署名されます。 |
Wssp1.2-SignBody.xml |
すべてのメッセージ本文部分が署名されます。 |
Wssp1.2-EncryptBody.xml |
すべてのメッセージ本文部分が暗号化されます。 |
Wssp1.2-Sign-Wsa-Headers.xml |
WS-Addressingヘッダーが署名されます。 |
Wssp1.2-2007-SignAndEncryptWSATHeaders.xml |
WS-AtomicTransactionヘッダーが署名および暗号化されます。 |
Wssp1.2-2007-Wsp1.5-SignAndEncryptWSATHeaders.xml |
WS-AtomicTransactionヘッダーが署名および暗号化されます。Web Services Policy 1.5が使用されます。 |
次のポリシーは、WS-Security 1.0のユーザー名トークン仕様またはX.509トークン仕様をサポートしています。
表2-10 WS-Security 1.0ポリシー
| ポリシー・ファイル | 説明 |
|---|---|
Wssp1.2-2007-Wss1.0-X509-Basic256.xml |
X.509証明書による相互認証。メッセージは、リクエスト側とレスポンス側の両方で署名および暗号化されます。アルゴリズムとしては、両側でBasic256を使用する必要があります。 |
Wssp1.2-2007-Wss1.0-UsernameToken-Digest-X509-Basic256.xml |
認証のリクエストでは、ユーザー名トークンとパスワード・ダイジェストが送信されます。暗号化方式はBasic256です。 |
Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml |
認証のリクエストでは、ユーザー名トークンとプレーン・テキスト・パスワードが送信されます。これらは、クライアントの秘密鍵で署名され、サーバーの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護されたパブリック証明書を含めます。サーバーは、その秘密鍵でレスポンスの本文に署名し、そのパブリック証明書をメッセージの一部として送信します。リクエスト・メッセージとレスポンス・メッセージの両方に、署名されたタイム・スタンプが含まれます。暗号化方式はBasic256です。 |
Wssp1.2-Wss1.0-UsernameToken-Plain-X509-Basic256.xml |
認証のリクエストでは、ユーザー名トークンとプレーン・テキスト・パスワードが送信されます。これらは、クライアントの秘密鍵で署名され、サーバーの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護されたパブリック証明書を含めます。サーバーは、その秘密鍵でレスポンスの本文に署名し、そのパブリック証明書をメッセージの一部として送信します。リクエスト・メッセージとレスポンス・メッセージの両方に、署名されたタイム・スタンプが含まれます。暗号化方式はBasic256です。 |
Wssp1.2-Wss1.0-UsernameToken-Plain-X509-TripleDesRsa15.xml |
認証のリクエストでは、ユーザー名トークンとプレーン・テキスト・パスワードが送信されます。これらは、クライアントの秘密鍵で署名され、サーバーの公開鍵で暗号化されます。クライアントは、リクエストの本文にも署名し、メッセージ内の署名によって保護されたパブリック証明書を含めます。サーバーは、その秘密鍵でレスポンスの本文に署名し、そのパブリック証明書をメッセージの一部として送信します。リクエスト・メッセージとレスポンス・メッセージの両方に、署名されたタイム・スタンプが含まれます。暗号化方式はTripleDesです。 |
Wssp1.2-Wss1.0-UsernameToken-Digest-X509-Basic256.xml |
認証のリクエストでは、ユーザー名トークンとパスワード・ダイジェストが送信されます。暗号化方式はBasic256です。 |
Wssp1.2-Wss1.0-UsernameToken-Digest-X509-TripleDesRsa15.xml |
認証のリクエストでは、ユーザー名トークンとパスワード・ダイジェストが送信されます。暗号化方式はTripleDesです。 |
Wssp1.2-Wss1.0-X509-Basic256.xml |
X.509証明書による相互認証。メッセージは、リクエスト側とレスポンス側の両方で署名および暗号化されます。アルゴリズムとしては、両側でBasic256を使用する必要があります。 |
Wssp1.2-Wss1.0-X509-TripleDesRsa15.xml |
X.509証明書による相互認証。メッセージは、リクエスト側とレスポンス側の両方で署名および暗号化されます。アルゴリズムとしては、両側でTripleDesを使用する必要があります |
Wssp1.2-Wss1.0-X509-EncryptRequest-SignResponse.xml |
このポリシーは、X.509v3証明書(および公開鍵/秘密鍵の組合せ)を保持するサーバーでのみ使用します。リクエストが暗号化され、レスポンスが署名されます。 |
| Wssp1.2-wss10_x509_token_with_message_protection_owsm_policy.xml | このポリシーは、Wssp1.2-wss11_x509_token_with_message_protection_owsm_policyと同様ですが、WSS1.1のかわりにWSS 1.0をサポートします。 |
| Wssp1.2-wss10_x509_token_with_message_protection_owsm_policy_eas256.xml | このポリシーはWssp1.2-wss10_x509_token_with_message_protection_owsm_policy.xmlと同様です。Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
| Wssp1.2-wss10_username_token_with_message_protection_owsm_policy.xml | このポリシーはWssp1.2-wss10_x509_token_with_message_protection_owsm_policy.xmlと同様ですが、認証にX509トークンではなくユーザー名トークンを必要とします。 |
| Wssp1.2-wss10_username_token_with_message_protection_owsm_policy_eas256.xml | このポリシーはWssp1.2-wss10_username_token_with_message_protection_owsm_policyと同様です。Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
次のポリシーは、WS-Security 1.1のユーザー名トークン仕様またはX.509トークン仕様をサポートしています。
表2-11 WS-Security 1.1のユーザー名およびX509トークン・ポリシー
| ポリシー・ファイル | 説明 |
|---|---|
Wssp1.2-2007-Wss1.1-X509-Basic256.xml |
非対称バインディングによるWSS 1.1 X509。 |
Wssp1.2-2007-Wss1.1-X509-Basic256Sha256.xml |
Wssp1.2-2007-Wss1.1-X509-Basic256.xmlと同じですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。 |
Wssp1.2-2007-Wss1.1-UsernameToken-Digest-X509-Basic256.xml |
非対称バインディングによるWSS 1.1 X509、およびダイジェスト・ユーザー名トークンによる認証。 |
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xml |
非対称バインディングによるWSS 1.1 X509、およびプレーン・テキスト・ユーザー名トークンによる認証。 |
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256Sha256.xml |
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xmlと同じですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。 |
| Wssp1.2-2007-Wss1.1-X509-Eas256.xml | このポリシーはポリシーWssp1.2-2007-Wss1.1-X509-Basic256.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
Wssp1.2-2007-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml |
対称バインディングによるWSS 1.1 X509。トークンをサポートする署名付き承認によって保護されます。 |
Wssp1.2-2007-Wss1.1-UsernameToken-Digest-EncryptedKey.xml |
対称バインディングによるWSS 1.1 X509、およびダイジェスト・ユーザー名トークンによる認証。 |
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xml |
対称バインディングによるWSS 1.1 X509、およびプレーン・テキスト・ユーザー名トークンによる認証。 |
Wssp1.2-2007-Wss1.1-DK-X509-SignedEndorsing.xml |
派生キー対称バインディングによるWSS 1.1 X509。トークンをサポートする署名付き承認によって保護されます。 |
Wssp1.2-2007-Wss1.1-UsernameToken-Digest-DK.xml |
派生キー対称バインディングによるWSS 1.1 X509、およびダイジェスト・ユーザー名トークンによる認証。 |
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-DK.xml |
派生キー対称バインディングによるWSS 1.1 X509、およびプレーン・テキスト・ユーザー名トークンによる認証。 |
Wssp1.2-Wss1.1-X509-Basic256.xml |
このポリシーは、署名確認、指紋キー参照といったWS-Security 1.1の追加機能を使用する点以外はWssp1.2-Wss1.0-X509-Basic256.xmlポリシーと同様です。 |
Wssp1.2-Wss1.1-EncryptedKey.xml |
署名と暗号化の両方でWS-Security 1.1の暗号化キー機能を使用する対称バインディング・ポリシー。署名確認、指紋キー参照などのWS-Security 1.1機能も使用します。 |
Wssp1.2-Wss1.1-UsernameToken-DK.xml |
派生キー対称バインディングによるWSS 1.1 X509、およびプレーン・テキスト・ユーザー名トークンによる認証。 |
Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml |
このポリシーは、Wssp1.2-Wss1.1-EncryptedKey.xmlポリシーで定義されているすべての機能を備えるだけでなく、送信側のキーを使用してメッセージ署名を承認します。承認キーも、メッセージ署名で署名されます。 |
Wssp1.2-Wss1.1-DK.xml |
このポリシーは、Wssp1.2-Wss1.1-EncryptedKey.xmlポリシーで定義されているすべての機能を備えているが、暗号化キーは使用しません。代わりに、リクエストをDerivedKeyToken1で署名し、DerivedKeyToken2で暗号化します。また、レスポンスをDerivedKeyToken3で署名し、DerivedKeyToken4で暗号化します。 |
Wssp1.2-Wss1.1-DK-X509-Endorsing.xml |
このポリシーは、Wssp1.2-Wss1.1-DK.xmlポリシーで定義されているすべての機能を備えるだけでなく、送信側のキーを使用してメッセージ署名を承認します。 |
Wssp1.2-Wss1.1-X509-EncryptRequest-SignResponse.xml |
このポリシーは、署名確認、指紋キー参照といったWSS 1.1の追加機能を使用する点以外はWssp1.2-Wss1.0-X509-EncryptRequest-SignResponse.xmlポリシーと同様です。 |
Wssp1.2-Wss1.1-X509-SignRequest-EncryptResponse.xml |
このポリシーは、Wssp1.2-Wss1.1-X509-EncryptRequest-SignResponse.xmlポリシーの反対で、リクエストが署名され、レスポンスが暗号化されます。 |
Wssp1.2-wss11_x509_token_with_message_protection_owsm_policy.xml |
このポリシーでは、送信側のX509証明書によって承認が行われ、メッセージの署名は保護されます。Basic256アルゴリズム・スイート(暗号化にはAES256)ではなく、Basic128アルゴリズム・スイート(AES128)を使用する必要があります。 |
| Wssp1.2-wss11_x509_token_with_message_protection_owsm_policy_eas256.xml | このポリシーはWssp1.2-wss11_x509_token_with_message_protection_owsm_policy.xmlと同様です。Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持ちます。このポリシーはFIPS-140モードでサポートされています。 |
表2-12に示すポリシーは、WS-SecureConversation 1.3、1.4およびWS-SecureConversation 2005/2を実装しています。
注意:
『Oracle WebLogic Server JAX-WS Webサービスの開発』に記載されているように、テンプレートを使用してドメインを構成する場合には、WS-SecureConversationを使用するJAX-WS WebサービスでJAX-WS拡張テンプレート(wls_webservice_jaxws)が必要になります。
WebサービスにWS-SecureConversationポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。
表2-12 WS-SecureConversationポリシー
| ポリシー・ファイル | 説明 |
|---|---|
Wssp1.2-2007-Wssc1.3-Bootstrap-Https-BasicAuth.xml |
基本認証による一方向SSL。タイムスタンプが含まれます。アルゴリズム・スイートはBasic256です。署名は暗号化されます。 |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256Sha256.xml |
このポリシーはポリシーWssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xmlと同様ですが、Sha-256の強力ハッシュ・アルゴリズムを使用します。 |
Wssp1.2-2007-Wssc1.3-Bootstrap-Https-ClientCertReq.xml |
双方向SSL。受信側で、発信元のパブリック証明書をチェックします。認証にクライアント証明書を使用することも可能です。 |
Wssp1.2-2007-Wssc1.3-Bootstrap-Https-UNT.xml |
SSLユーザー名トークン認証。 |
Wssp1.2-2007-Wssc1.3-Bootstrap-Https.xml |
WS-SecureConversationハンドシェイク(RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージ)がhttpsトランスポートで発生します。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。署名も暗号化されます。 |
Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml |
WS-SecureConversationハンドシェイクがWS-Security 1.0によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。タイムスタンプは、格納されて署名されます。署名は暗号化されます。アルゴリズム・スイートはBasic256です。 |
Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xml |
WS-SecureConversationハンドシェイクがWS-Security 1.1によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。署名と暗号化には、暗号化キーからの派生キーが使用されます。 |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xml |
Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xm.ポリシーと同様に、WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.0 X509とプレーン・テキスト・ユーザー名トークンによる認証によって保護されます ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。 |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Eas256.xml |
このポリシーはポリシーWssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-UsernameToken-Plain-X509-Basic256.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.0-Saml1.1-SenderVouches.xml |
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xmlポリシーと同様に、WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.0 X509とSAML 1.1 Sender Vouchesトークンによる認証によって保護されます。 ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。 |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml1.1-SenderVouches.xml |
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xmlポリシーと同様に、WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.1 X509とSAML 1.1 Sender Vouchesトークンによる認証によって保護されます。 ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。 |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-Saml2.0-Bearer.xml |
WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.1 X509とSAML 2.0 Bearerトークンによる認証によって保護されます。 ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。 |
Wssp1.2-2007-Wssc1.4-Bootstrap-Wss1.1-UsernameToken-Plain-EncryptedKey.xml |
Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xmlポリシーと同様に、WS-SecureConversationハンドシェイクは非対称バインディングのWS-Security 1.1 X509とプレーン・テキスト・ユーザー名トークンによる認証によって保護されます。 ハンドシェイクのRequestSecurityTokenメッセージおよびRequestSecurityTokenResponseCollectionメッセージのSOAP本文は署名および暗号化されます。アプリケーション・メッセージは、セキュアな会話トークン暗号化キーから導出されたキーで署名および暗号化されます。WS-Addressingヘッダーは署名されます。ポリシーでは、WS-Policy 1.5ネームスペース「http://www.w3.org/ns/ws-policy」が使用されます。 |
Wssp1.2-Wssc1.3-Bootstrap-Https-BasicAuth.xml |
基本認証による一方向SSL。タイムスタンプが含まれます。アルゴリズム・スイートはBasic256です。署名は暗号化されます。 |
Wssp1.2-Wssc1.3-Bootstrap-Https-ClientCertReq.xml |
双方向SSL。受信側で、発信元のパブリック証明書をチェックします。認証にクライアント証明書を使用することも可能です。 |
Wssp1.2-Wssc1.3-Bootstrap-Https.xml |
WS-SecureConversationハンドシェイク(RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージ)がhttpsトランスポートで発生します。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。署名も暗号化されます。 |
Wssp1.2-Wssc1.3-Bootstrap-Wss1.0.xml |
WS-SecureConversationハンドシェイクがWS-Security 1.0によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。タイムスタンプは、格納されて署名されます。署名は暗号化されます。アルゴリズム・スイートはBasic256です。 |
Wssp1.2-Wssc1.3-Bootstrap-Wss1.1.xml |
WS-SecureConversationハンドシェイクがWS-Security 1.1によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。署名と暗号化には、暗号化キーからの派生キーが使用されます。 |
Wssp1.2-Wssc200502-Bootstrap-Https.xml |
WS-SecureConversationハンドシェイク(RequestSecurityTokenおよびRequestSecurityTokenResponseメッセージ)がhttpsトランスポートで発生します。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。 |
Wssp1.2-Wssc200502-Bootstrap-Wss1.0.xml |
WS-SecureConversationハンドシェイクがWS-Security 1.0によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。タイムスタンプは、格納されて署名されます。アルゴリズム・スイートはBasic128です。 |
Wssp1.2-Wssc200502-Bootstrap-Wss1.1.xml |
WS-SecureConversationハンドシェイクがWS-Security 1.1によって保護されます。アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。RequestSecurityTokenおよびRequestSecurityTokenResponseメッセージのsoap:Bodyは署名および暗号化されます。WS-Addressingヘッダーは署名されます。署名と暗号化には、暗号化キーからの派生キーが使用されます。 |
表2-13に示すポリシーは、WS-Security SAML Token Profile 1.0および1.1を実装しています。
注意:
WebLogic Serverバージョン10.3は受信リクエストに対してのみSAML Holder of keyをサポートしていました。WebLogic Serverバージョン10.3MP1以降現在、リクエストとレスポンス・メッセージの両方が保護されます。
表2-13 WS-Security SAML Token Profileポリシー
| ポリシー・ファイル | 説明 |
|---|---|
Wssp1.2-2007-Saml1.1-Bearer-Https.xml |
一方向SSLでは、SAML 1.1トークンを使用し、Bearer確認メソッドによって認証を行います。 WebLogic Serverは、Wssp1.2-2007-Saml2.0-Bearer-Https.xmlを使用して、トランスポート・レベルでのSAML 1.1 Bearer確認メソッドをサポートします。 Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。 |
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml |
メッセージは、WSS1.0非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。SAML 1.1トークンはSender Vouches確認メソッドによる認証用にリクエスト内で送信され、X509トークンにより署名されます。 |
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xml |
メッセージは、WSS1.1 X509対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。SAML 1.1トークンはSender Vouches確認メソッドによる認証用にリクエスト内で送信され、X509トークンにより署名されます。 |
Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1-Basic256Sha256.xml |
このポリシーはWssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムを使用します。 |
| Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.1-Eas256.xml | このポリシーはポリシーWssp1.2-2007-Saml1.1-SenderVouches-Wss1.1.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xml |
メッセージは、WSS1.1 X509対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。SAML 2.0トークンはSender Vouches確認メソッドによる認証用にリクエスト内で送信され、X509トークンにより署名されます。 |
Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Basic256Sha256.xml |
このポリシーはポリシーWssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムを使用します。 |
Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Asymmetric.xml |
メッセージは、WSS1.1非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。署名確認、指紋キー参照などの追加のWS-Security 1.1機能も使用します。SAML 2.0トークンはSender Vouches確認メソッドによる認証用にリクエスト内で送信され、X509トークンにより署名されます。 |
| Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Eas256.xml | このポリシーはポリシーWssp1.2-2007-Saml2.0-SenderVouches-Wss1.1.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.0.xml |
メッセージは、WSS1.0非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。SAML 1.1トークンはHolder of Key確認メソッドによる認証用にリクエスト内で送信されます。SAMLトークン内のキーが署名に使用されます。 |
Wssp1.2-2007-Saml1.1-HolderOfKey-Wss1.1-Asymmetric.xml |
メッセージは、WSS1.1非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。署名確認、指紋キー参照などの追加のWS-Security 1.1機能も使用します。SAML 1.1トークンはHolder of Key確認メソッドによる認証用にリクエスト内で送信されます。SAMLトークン内のキーが署名に使用されます。 |
Wssp1.2-2007-Saml2.0-HolderOfKey-Wss1.1-Asymmetric.xml |
メッセージは、WSS1.1非対称バインディングによりリクエスト側とレスポンス側の両方で署名および暗号化されます。署名確認、指紋キー参照などの追加のWS-Security 1.1機能も使用します。SAML 2.0トークンはHolder of Key確認メソッドによる認証用にリクエスト内で送信されます。SAMLトークン内のキーが署名に使用されます。 |
Wssp1.2-2007-Saml2.0-Bearer-Https.xml |
一方向SSLは、認証用にBearer確認メソッドがあるSAML 2.0トークンを使用します。 WebLogic Serverは、Wssp1.2-2007-Saml2.0-Bearer-Https.xmlを使用して、トランスポート・レベルでのSAML 2.0 Bearer確認メソッドをサポートします。 SAML 2.0をサポートしない他の製品と相互運用するために、SAML-over-HTTPSシナリオについてはsender-vouches確認メソッドの使用をお薦めします。 SAML1.1 Bearerを使用するかわりに Wssp1.2-2007-Saml1.1-SenderVouches-Https.xmlポリシーを使用してください。 Webサービスにトランスポート・レベルのセキュリティ・ポリシーを指定する場合、ポリシーの指定はクラス・レベルで行う必要があります。また、トランスポート・レベルのセキュリティ・ポリシーは着信方向と発信方向の両方に適用する必要があります。つまり、着信にHTTPSを使用し、発信にHTTPを使用することはできません。 |
Wssp1.2-2007-Saml2.0-Bearer-Https-Basic256Sha256.xml |
Wssp1.2-2007-Saml2.0-Bearer-Https.xmlと同じですが、Sha-256のより強力なハッシュ・アルゴリズムを使用します。 |
| Wssp1.2-wss10_saml_token_with_message_protection_owsm_policy.xml | このポリシーはWssp1.2-wss10_x509_token_with_message_protection_owsm_policy.xmlと同様ですが、認証用にSAMLトークンを必要とします。 |
| Wssp1.2-wss10_saml_token_with_message_protection_owsm_policy_eas256.xml | このポリシーはWssp1.2-wss10_saml_token_with_message_protection_owsm_policy.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
Wssp1.2-wss11_saml_token_with_message_protection_owsm_policy.xml |
このポリシーでは、送信側のX509証明書によって承認が行われ、メッセージの署名は保護されます。Basic256アルゴリズム・スイート(暗号化にはAES256)ではなく、Basic128アルゴリズム・スイート(AES128)を使用する必要があります。 |
| Wssp1.2-wss11_saml_token_with_message_protection_owsm_policy_eas256.xml | このポリシーはWssp1.2-wss11_saml_token_with_message_protection_owsm_policy.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
| Wssp1.2-wss11_saml20_token_with_message_protection_owsm_policy.xml | このポリシーはWssp1.2-wss11_saml_token_with_message_protection_owsm_policyと同様ですが、SAML 2.0トークンを使用します。 |
| Wssp1.2-wss11_saml20_token_with_message_protection_owsm_policy_eas256.xml | このポリシーはWssp1.2-wss11_saml20_token_with_message_protection_owsm_policy.xmlと同様ですが、Sha-256のより強力なハッシュ・アルゴリズムおよびより強力な署名方法アルゴリズムを持つ拡張アルゴリズム・スイートを使用します。このポリシーはFIPS-140モードでサポートされています。 |
WebLogic Serverは、WS-SecurityPolicy 1.2を実装したことで、セキュリティ・ポリシーの幅広い選択肢を提供できるようになりました。Webサービスのセキュリティ・ポリシーを選択する際は、次の面での要件を考慮する必要があります。
パフォーマンス
セキュリティ
相互運用性
資格証明可用性(X.509証明書、ユーザー名トークン、クリア・パスワードまたはダイジェスト・パスワード)
可能なかぎり、次のガイドラインに従ってください。
カスタム・ポリシーを作成せず、WebLogic Serverにパッケージ化されたポリシーを使用します。
WS-SecurityPolicy 1.2ポリシーでまだサポートされていない機能が必要な場合を除き、WebLogic Server 9.xスタイルのポリシーではなくWS-SecurityPolicy 1.2ポリシーを使用します。
トランスポート・レベルのポリシー(Wssp1.2-2007-Https-*.xml)は、メッセージ・レベルのセキュリティが必要ない場所にのみ使用します。
仕様との相互運用性を確保する必要がある場合はWS-Security 1.0ポリシーを使用します。認証要件および資格証明可用性に応じて、以下のいずれかを使用してください。
Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml
Wssp1.2-2007-Wss1.0-UsernameToken-Digest-X509-Basic256.xml
Wssp1.2-2007-Wss1.0-X509-Basic256.xml
強固なセキュリティの要件を満たす必要がある場合はWS-Security 1.1ポリシーを使用します。以下のいずれかを使用してください。
Wssp1.2-2007-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml
Wssp1.2-2007-Wss1.1-DK-X509-SignedEndorsing.xml
Wssp1.2-Wss1.1-EncryptedKey-X509-SignedEndorsing.xml
Wssp1.2-Wss1.1-DK-X509-Endorsing.xml
WS-ReliableMessagingに加えてセキュリティが必要な場合はWS-SecureConversationポリシーを使用します。
Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml
Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xml
Wssp1.2-Wssc1.3-Bootstrap-Wss1.0.xml
Wssp1.2-Wssc1.3-Bootstrap-Wss1.1.xml
Wssp1.2-Wssc200502-Bootstrap-Wss1.0.xml
Wssp1.2-Wssc200502-Bootstrap-Wss1.1.xml
「バージョンに依存しないポリシーのサポート」でのWS-SecurityPolicy 1.2アサーションはWebLogic Serverのこのリリースではサポートされません。
注意:
新しいWS-SecurityPolicy1.3アサーションもこのリリースではサポートされません。
表2-14 サポートされないWeb Services SecurityPolicy 1.2アサーション
| 仕様 | アサーション | 備考 |
|---|---|---|
5.1.1 |
TokenInclusion |
includeTokenPolicy=Onceはサポートされません。 |
5.4.1 |
UsernameToken |
このリリースでは<sp:UsernameToken11>とパスワード派生キーのみがサポートされていません。その他のユーザー名トークン・アサーションはサポートされます。 |
5.4.2 |
IssuedToken |
WS-Trustポリシー・アサーションはこのリリースではサポートされません。 |
5.4.4 |
KerberosToken |
このリリースではサポートされません。 |
5.4.5 |
SpnegoContextToken |
このリリースではサポートされません。 |
5.4.9 |
RelToken |
このリリースではサポートされません。 |
5.4.11 |
KeyValueToken |
このリリースではサポートされません。 |
6.5 |
トークン保護 |
includeTokenPolicy="Never"の場合や、メッセージにトークンが含まれていない場合、このリリースではトークン保護はサポートされません。 |
7.1 |
AlgorithmSuite |
このリリースでは/sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20アサーション、/sp:AlgorithmSuite/wsp:Policy/sp:XPath10アサーション、および/sp:AlgorithmSuite/wsp:Policy/sp:SoapNormalization10はサポートされません。 |
8.1 |
SupportingTokens |
このリリースでは以下はサポートされません。 ../sp:SignedPartsアサーション、../sp:SignedElementsアサーション、../sp:EncryptedPartsアサーション、../sp:EncryptedElementsアサーション |
8.2 8.3 8.4 8.5 |
SignedSupportingTokens EndorsingSupportingTokens SignedEndorsingSupportingTokens SignedEncryptedSupportingTokens |
このリリースでは以下はサポートされません。 ../sp:SignedPartsアサーション ../sp:SignedElementsアサーション ../sp:EncryptedPartsアサーション ../sp:EncryptedElementsアサーション ../sp:SignedEncryptedSupportingTokensアサーション メッセージにトークンが含まれていない場合(たとえば、includeTokenPolicy=Never/Onceの場合)、ランタイムはサポートするトークンを承認できません。 |
8.6 |
EncryptedSupportingTokens |
このリリースでサポートされるEncryptionSupportingTokensはUserNameトークンのみです。 その他のタイプのトークンはサポートされません。 |
8.7 |
EndorsingEncryptedSupportingTokens |
このリリースではサポートされません。 |
8.8 |
SignedEndorsingEncryptedSupportingTokens |
このリリースではサポートされません。 |
9.1 |
WSS10アサーション |
<sp:MustSupportRefExternalURI>および<sp:MustSupportRefEmbeddedToken>はこのリリースではサポートされません。 |
9.2 |
WSS11アサーション |
<sp:MustSupportRefExternalURI>および<sp:MustSupportRefEmbeddedToken>はこのリリースではサポートされません。 |
10.1 |
Trust13アサーション |
MustSupportClientChallengeおよびMustSupportServerChallengeはこのリリースではサポートされません。このアサーションはWS-SecureConversationポリシーでのみサポートされます。 |
WebLogic Serverは、Optional WS-Policyアサーションをサポートします。次の例でOptionalがどのように使用されているか考えてみましょう。
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="…/IncludeToken/AlwaysToRecipient" wsp:Optional="true" >
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
この例では、認可を行うためのユーザー名トークンの指定はオプションです。ユーザーが匿名である、またはセキュリティ・コンテキストがないという理由でユーザー名トークンを生成できない場合でも、クライアントは処理を続行できます。
セキュリティ・ポリシーの適用プロセスにおいて、欠落した要素にwsp:Optional="true"属性を持つポリシー・アサーションが指定されていれば、メッセージは拒否されません。
現在、次のセキュリティ・ポリシー・アサーションがOptionalポリシー・アサーションでサポートされています。
ユーザー名トークン
SAMLトークン
署名部分または署名要素
暗号化部分または暗号化要素
派生キー・トークン
WebLogic Serverでは、WS-SecurityPolicy 1.2で定義される要素レベルのアサーションがサポートされます。これらのアサーションを使用すると、SOAPリクエストまたはレスポンス・メッセージ内の選択した要素に署名または暗号化を適用することができます。また、セキュリティが必要なメッセージ内の特定のデータのみを対象にできるため、計算要件が緩和されます。
また、RequiredElementsアサーションを使用すると、メッセージに特定のヘッダー要素が必ず含まれるようになります。
次の要素レベルのアサーションを使用できます。
EncryptedElements (http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826516)
ContentEncryptedElements (http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826517)
SignedElements (http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826513)
RequiredElements (http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826518)
要素レベルのアサーションを指定するには、適用するリクエスト要素またはレスポンス要素を特定する必要があります。
これらの要素を特定するには、XPathバージョン1.0 (http://www.w3.org/TR/xpath)またはXPath Filterバージョン2.0 (http://www.w3.org/TR/xmldsig-filter2/)の構文を使用して、ポリシー・ファイルでXPath式を使用します。この項のサンプルでは、デフォルト構文のXPathバージョン1.0を使用しています。
これらの各アサーションではWebサービス・メッセージ内の1つまたは複数の要素を特定するため、すべての要素レベルのセキュリティ・アサーションにカスタム・セキュリティ・ポリシー・ファイルを使用する必要があります。通常、これらのカスタム・ポリシー・ファイルは、事前定義済のセキュリティ・ポリシー・ファイルと併用されます。事前定義済のファイルでは署名や暗号化の実行方法が定義され、カスタム・ポリシー・ファイルでは署名や暗号化の対象となる特定の要素が指定されます。
最初に、ターゲット要素を特定するXPath式を決定します。そのためには、Webサービスで使用されているSOAPメッセージの形式を、直接調べるかサービスのWSDLとXMLスキーマを分析することで理解する必要があります。
SOAPメッセージの形式を確認して必要なXPath式を決定する方法は、使用しているツールに大きく依存するため、このドキュメントの対象外です。たとえば、次のようなことを行います:
要素レベルのセキュリティのないWebサービスを実行します。
SOAPのトレースを有効にします。
ログ内のSOAPメッセージを調べます。
そのSOAPメッセージをもとにXPath式を作成します。
または、特定のWSDLに対するサンプルSOAPリクエストを生成できるソフトウェア・ツールがある場合は、そのツールを使用してXPath式を生成します。
WebサービスのsubmitOrderRequest操作が例2-19に示す形式のSOAPリクエストを受け取る例について検討します。
太字の部分は後で要素レベルのカスタム・ポリシーを作成するときに使用されます。
例2-19 submitOrderRequest SOAPリクエスト
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header/> <env:Body> <ns1:submitOrderRequest xmlns:ns1="http://www.oracle.com/OrderService"> <ns1:OrderRequest> <ns1:orderNumber>4815162342</ns1:orderNumber> <ns1:creditCard> <ns1:cctype>MasterCard</ns1:cctype> <ns1:expires>12-01-2020</ns1:expires> <ns1:ccn>1234-567890-4444</ns1:ccn> </ns1:creditCard> </ns1:OrderRequest> </ns1:submitOrderRequest> </env:Body> </env:Envelope>
<ns1:creditCard>要素とその子要素を暗号化する必要があると仮定します。そのためには、例2-19の太字の箇所から得られた情報を使用して、カスタム・セキュリティ・ポリシー・ファイル(EncryptCreditCard.xmlなど)を作成します。
例2-20に示す例について考えてみましょう。
例2-20 EncryptCreditCard.xmlカスタム・ポリシー・ファイル
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">
<sp:EncryptedElements xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<sp:XPath xmlns:myns="http://www.oracle.com/OrderService">
/soapenv:Envelope/soapenv:Body/myns:submitOrderRequest/myns:OrderRequest/myns:creditCard
</sp:XPath>
</sp:EncryptedElements>
</wsp:Policy>
WS-SecurityPolicy1.2仕様(http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826516)に記載されているように、/sp:EncryptedElements/sp:XPath要素にはXPath式を指定する文字列があり、この文字列によって機密性の保護の対象となるノードを特定します。XPath式はメッセージのS:Envelope要素ノードに対して評価されます。このアサーションには、この要素の複数のインスタンスが出現する可能性もありますが、それぞれを異なる参照として扱う必要があります。
次の点に注意してください。
ルート要素は接頭辞(この場合はwsp)の付いた<wsp:Policy>にし、WS-Policyの完全なネームスペースにマッピングする必要があります。
アサーション(この場合はEncryptedElements)は、spという接頭辞を付けて、WS-SecurityPolicy 1.2の完全なネームスペースで修飾する必要があります。
SOAPメッセージのcreditCard要素はネームスペースで修飾され(ns1接頭辞を使用)、親要素OrderRequest、submitOrderRequest、Body、およびEnvelopeがあります。これらの各要素もネームスペースで修飾されています。
(/soapenv:Envelope…で始まる) XPath問合せはcreditCard要素の場所を一致させます。
/soapenv:Envelope/soapenv:Body/myns:submitOrderRequest/myns:OrderRequest/myns:creditCard
SOAPメッセージのネームスペース接頭辞とカスタム・セキュリティ・ポリシー・ファイルの接頭辞が一致している必要はありません。重要なのは、接頭辞のマップ先の完全なネームスペースがメッセージとポリシー・アサーションで同一であることのみです。
WebLogic ServerはSOAP 1.1とSOAP 1.2のネームスペース、WS-Addressing 2004/08とWS-Addressing 1.0のネームスペースのマッピングを処理します。
カスタム・ポリシーを作成した後、ポリシー・アノテーションをJWSファイルに追加して、ElementEncryptionポリシーがsubmitOrder Webサービス・リクエストに対して使用されるようにします(例2-21を参照)。
例2-21 カスタム・ポリシー・ファイルへのポリシー・アノテーションの追加
@WebMethod
@Policies({
@Policy(uri="policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plan-X509-Basic256.xml"),
@Policy(uri="../policies/EncryptCreditCard.xml",
direction=Policy.Direction.inbound)})
public String submitOrderRequest (OrderRequest orderRequest) {
return orderService.processOrder(orderRequest);
}
creditCard要素がレスポンスではなく、SOAPリクエストに存在しているので、コードの抜粋は単に「着信」の方向によるEncryptedElementsカスタム・ポリシーを構成します。
ユーザーが作成したポリシー・ファイルを指定するには、次の例に示すように、JWSファイルの場所を基準とした相対パスと名前を指定します。
@Policy(uri="../policies/MyPolicy.xml")
この例では、MyPolicy.xmlファイルは、JWSファイルを格納するディレクトリのpolicies兄弟ディレクトリにあります。
共有Java EEライブラリにあるポリシー・ファイルも指定できます。この方法は、別々のJava EEアーカイブにパッケージ化された複数のWebサービス間でファイルを共有する場合に便利です。
注意:
この場合、ポリシー・ファイルが共有Java EEライブラリのMETA-INF/policiesディレクトリまたはWEB-INF/policiesディレクトリにあることを前提としています。ライブラリをパッケージ化する際には、必ずこのディレクトリにポリシー・ファイルを入れてください。
共有Java EEライブラリにあるポリシー・ファイルを指定するには、次の例に示すように、policy接頭辞とポリシー・ファイルの名前を使用します。
@Policy(uri="policy:MySharedPolicy.xml")
共有ライブラリの作成、およびWebサービスが共有のポリシー・ファイルを検出できるようにするための環境設定については、Oracle WebLogic Serverアプリケーションの開発の共有Java EEライブラリおよびオプション・パッケージの作成を参照してください。
要素レベルのセキュリティを実装するときは次の点に注意してください。
1つのポリシーの中に複数の要素レベルのアサーションを含めることができます。すべてのアサーションが実行されます。
1つのアサーションの中に複数の<sp:XPath>式を含めることができます。すべてのアサーションが実行されます。
EncryptedElementsアサーションでは、特定された要素とその子要素がすべて暗号化されます。
ContentEncryptedElementsアサーションでは、特定された要素は暗号化されないが、その子要素はすべて暗号化されます。
RequiredElementsアサーションを使用すると、SOAPヘッダーの最上位要素の存在をテストできます。その要素が見つからない場合はSOAP Faultが生成されます。
RequiredElementsアサーションはSOAP本文内の要素のテストには使用できません。
特定のWebサービスに対して複数のポリシー選択肢を用意することができるため、サービスの柔軟性が大幅に向上します。
Webサービスで次のいずれかをサポートするかどうか検討してください。
様々なバージョンの標準。たとえば、1つのWebサービスでWSRM 1.0とWSRM 1.1、WSS1.0とWSS 1.1、WSSC 1.1とWWSSC 1.2、SAML 1.1またはSAML 2.0に対応可能です。
認証用の様々な資格証明。たとえば、Webサービスで認証用にユーザー名トークン、X509、またはSAMLトークンを使用できます。
内部のクライアントと外部のクライアントで異なるセキュリティ要件。たとえば、外部の認証にはSAMLトークンを要求し、内部の従業員の認証にはユーザー名トークンのみを要求することができます。
Webサービス・クライアントでも複数のポリシー選択肢に対応できます。同じクライアントが多様なポリシーやポリシー選択肢を持つ複数のサービスとやり取りできます。
たとえば、同じクライアントが、SAML 1.1 Token Profile 1.0による認証が必要なサービスとやり取りする一方で、SAML 2.0 Token Profile 1.1による認証が必要な別のサービスともやり取りできます。
例2-22は、WS-Security 1.0とWS-Security 1.1の両方をサポートするセキュリティ・ポリシーの例です。
注意:
<wsp:ExactlyOne>要素の中で、各ポリシー選択肢が<wsp:All>要素内にカプセル化されています。
例2-22 複数の選択肢を定義するポリシー
<?xml version="1.0"?> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"> <wsp:ExactlyOne> <wsp:All> <sp:AsymmetricBinding> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never"> <wsp:Policy> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:ProtectTokens/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:SignedParts> <sp:Body/> </sp:SignedParts> <sp:Wss10> <wsp:Policy> <sp:MustSupportRefKeyIdentifier/> <sp:MustSupportRefIssuerSerial/> </wsp:Policy> </sp:Wss10> </wsp:All> <wsp:All> <sp:AsymmetricBinding> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:RequireThumbprintReference/> <sp:WssX509V3Token11/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never"> <wsp:Policy> <sp:RequireThumbprintReference/> <sp:WssX509V3Token11/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:ProtectTokens/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:SignedParts> <sp:Body/> </sp:SignedParts> <sp:Wss11> <wsp:Policy> <sp:MustSupportRefKeyIdentifier/> <sp:MustSupportRefIssuerSerial/> <sp:MustSupportRefThumbprint/> <sp:MustSupportRefEncryptedKey/> <sp:RequireSignatureConfirmation/> </wsp:Policy> </sp:Wss11> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
例2-22に示すように、カスタム・ポリシーの作成により、1つのWebサービスに対して複数のポリシー選択肢を構成できます。その後、ポリシー選択プリファレンスを作成するようWebサービス・クライアントを構成します。
このリリースのWebLogic Serverでは、WebLogic Server管理コンソールでスタブを使用して、Webサービス・クライアントに対するポリシー選択プリファレンスを構成できます。
次のプリファレンスがサポートされています。
セキュリティ
パフォーマンス
互換性
Webサービス・ランタイムでは、ポリシー選択プリファレンスを使用してポリシー選択肢を調べ、最適なものを選択します。
複数のポリシー選択肢がある場合は、構成済のプリファレンス・リスト、使用可能な資格証明、オプション機能の設定を使用して、最適なポリシーが選択されます。
1つのクライアントに対して複数のポリシー選択肢が存在する場合は、次の選択ルールが使用されます。
プリファレンスが設定されていない場合は、ポリシー選択肢がwsp:optional=trueと定義されている場合を除いて、最初のポリシー選択肢が選択されます。
プリファレンスがセキュリティ優先に設定されている場合は、最大のセキュリティ機能を持つポリシーが選択されます。
プリファレンスが互換性/相互運用性優先に設定されている場合は、バージョンが最小のポリシーが選択されます。
プリファレンスがパフォーマンス優先に設定されている場合は、最小のセキュリティ機能を持つポリシーが選択されます。
オプションのポリシー・アサーションでは、次の選択ルールが使用されます。
デフォルトのポリシー選択プリファレンスが設定されている場合は、アサーションのオプション属性は無視されます。
プリファレンスが互換性またはパフォーマンスに設定されている場合は、オプション属性を持つアサーションは無視されるため、そのアサーションは無視されます。
セキュリティ・ポリシーの選択プリファレンスが設定されている場合、オプションのアサーションが含まれ、選択肢のアサーションは生成されません。
適切なポリシー選択のシナリオにおいて、本文が暗号化される(<sp:EncryptedParts> <sp:Body /></sp:EncryptedParts>など)かどうかは、ポリシー選択プリファレンスのルールによって次のように異なります。
デフォルト -- 最初のポリシー選択肢が決定に使用されます。最初のポリシー選択肢に本文暗号化のアサーションが含まれている場合、本文は暗号化されます。最初のポリシー選択肢に本文暗号化のアサーションが含まれていない場合、本文は暗号化されません。
SCP、SPC -- 暗号化されます
PCS、PSC -- 暗号化されません
CPS -- 暗号化されません
CSP -- 暗号化されます
次の2つの例について考えます。例2-23では、最初のポリシー選択肢に本文暗号化のアサーションが含まれています。したがって、デフォルトのプリファレンスの場合、本文は暗号化されます。デフォルト以外のポリシー選択プリファレンスの場合は、他のプリファレンス・ルールが適用されます。
例2-23 最初のポリシー選択肢に含まれる本文のアサーション
<?xml version="1.0"?> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" > <wsp:ExactlyOne> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> <sp:EncryptedParts/> </wsp:ExactlyOne> </wsp:Policy>
一方、例2-24では、最初のポリシー選択肢に本文暗号化のアサーションが含まれていません。したがって、デフォルトのプリファレンスの場合、本文は暗号化されません。デフォルト以外のポリシー選択プリファレンスの場合は、他のプリファレンス・ルールが適用されます。
例2-24 最初のポリシー選択肢に含まれない本文のアサーション
<?xml version="1.0"?> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" > <wsp:ExactlyOne> <sp:EncryptedParts/> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> </wsp:ExactlyOne> </wsp:Policy>
スタブ・プロパティを通じてポリシー選択プリファレンスを設定できます。
次の例では、JAX-RPCのスタブ・プロパティに「セキュリティ、互換性、パフォーマンスの順」の優先順位を設定しています。
stub._setProperty(WLStub.POLICY_SELECTION_PREFERENCE,
WLStub.PREFERENCE_SECURITY_COMPATIBILITY_PERFORMANCE);
JAX-WSで次の例を考えてみます。
BindingProvider bindingProvider = (BindingProvider) port; Map<String,Object> rc = (Map<String,Object>)bindingProvider.getRequestContext(); rc.put(WLStub.POLICY_SELECTION_PREFERENCE, WLStub.PREFERENCE_COMPATIBILITY_PERFORMANCE_SECURITY);
ポリシー選択プリファレンスが設定されていない場合は、デフォルトのプリファレンス(なし)が使用されます。
注意:
この例は、JAX-RPC Webサービスにセキュリティを追加する方法を示しています。このリリースでは、WS-SecurityによるMTOMはJAX-WSとJAX-RPCの両方に対してサポートされます。
MTOM/XOPを使用したバイナリ・データ転送の最適化に関する項で説明されているように、SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging (MTOM/XOP)では、SOAPメッセージにおけるxs:base64Binary型またはxs:hexBinary型のXMLデータの転送を最適化するための方法が定義されています。
この項では、WebLogic Serverにオプションで含まれている2つのサンプルの組合せについて説明します。
EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wss1.1
EXAMPLES_HOME\wl_server\examples\src\examples\webservices\mtom
これらの既存のサンプルには、実際に機能するコードと、その使用方法や役割、ビルド方法などを説明した詳細なinstructions.htmlファイルが含まれています。この項では、その説明を繰り返すのではなく、これらのサンプルに加える変更と変更の理由に焦点を当てています。WebLogic Serverのコード例の詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。
この例では、**INTERNAL XREF ERROR**に示すファイルを使用します。ソース・ファイルの内容はこの後の項で示します。
表2-15 MTOM/セキュリティの例で使用されるファイル
| ファイル | 説明 |
|---|---|
build.xml |
サンプルをビルドおよび実行するためのターゲットが含まれたビルド・ファイル。 |
configWss.py |
Webサービス・セキュリティ構成を構成するWLSTスクリプト。このファイルは |
MtomClient.java |
MTOM Webサービスを呼び出すスタンドアロンのクライアント・アプリケーション。このファイルでは、WebサービスのWSDLに基づいてclientgenによって生成されたJAX-RPCスタブを使用します。 |
SecurityMtomService.java |
MTOM Webサービスを実装するJWSファイル。このJWSファイルでは、@Policyアノテーションを使用して、Webサービスに関連付けられたWS-Policyファイルを指定します。 |
clientkeyStore.jks |
クライアント側のキーストア。クライアント側のBinarySecurityToken資格証明プロバイダの作成に使用されます。 このファイルは |
serverkeyStore.jks |
サーバー側のキーストア。サーバー側のBinarySecurityToken資格証明プロバイダの作成に使用されます。 このファイルは |
testServerCertTempCert.der |
サーバー側の証明書。サーバー側のBinarySecurityToken資格証明プロバイダの作成に使用されます。 このファイルは |
SecurityMtomService.java JWSファイルは、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\mtom\MtomService.javaのJWSファイルと同じものです(追加のポリシー・アノテーションは太字で示されています)。
例2-25 SecurityMtomService.java
package examples.webservices.security_mtom;
import weblogic.jws.Binding;
import weblogic.jws.Policy;
import weblogic.jws.Policies;
import weblogic.jws.Context;
import weblogic.jws.WLDeployment;
import weblogic.wsee.jws.JwsContext;
import weblogic.wsee.mtom.api.MtomPolicyInfo;
import weblogic.wsee.mtom.api.MtomPolicyInfoFactory;
import weblogic.wsee.policy.framework.PolicyException;
import javax.jws.WebService;
import javax.jws.WebMethod;
import java.rmi.RemoteException;
/**
* Sample to MTOM with JAX-RPC
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
@WebService
@Binding(Binding.Type.SOAP12)
//enable WSS + MTOM for this web service by adding the following canned policy files
@Policies({
@Policy(uri = "policy:Mtom.xml"),
@Policy(uri = "policy:Wssp1.2-2007-SignBody.xml"),
@Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml"),
@Policy(uri = "policy:Wssp1.2-Wss1.1-EncryptedKey.xml")
})
public class SecurityMtomService {
public SecurityMtomService() {
}
/**
* Input is sent as XOP'ed binary octet stream
*
* @param bytes input bytes
* @return A simple String
*/
@WebMethod
public String echoBinaryAsString(byte[] bytes) {
return new String(bytes);
}
/**
* Output is sent as as XOP'ed binary octet stream
*
* @param s a simple String
* @return byte[]
*/
@WebMethod
public byte[] echoStringAsBinary(String s) {
return s.getBytes();
}
/**
* input byte[] is sent as as XOP'ed binary octet stream
*
* @param array input byte[] array
* @return String[]
*/
@WebMethod
public String[] echoBinaryArrayAsStringArray(byte[] array) {
String[] strings = new String[1];
strings[0] = new String(array);
return strings;
}
}
@Policyアノテーションはクラス・レベルでもメソッド・レベルでも指定できます。この例では、アノテーションをクラス・レベルで使用して、事前定義済のWS-Policyファイルを指定しているため、Webサービスのすべてのパブリック操作が指定されたWS-Policyファイルに関連付けられます。
複数の@Policyアノテーションをグループ化するには、@Policiesアノテーションを使用します。このアノテーションはクラス・レベルでもメソッド・レベルでも指定できます。この例では、アノテーションをクラス・レベルで使用して、事前定義済のWS-Policyファイルを指定する4つの@Policyアノテーションをグループ化しています。
事前定義済のWS-PolicyファイルMtom.xmlでは、MTOMエンコーディングを有効にします。
保護アサーション・ポリシーで説明しているように、Wssp1.2-2007-SignBody.xmlポリシー・ファイルは、リクエストとレスポンスSOAPメッセージの両方の本文とWebLogicシステム・ヘッダーがデジタル署名されるよう指定します。
Wssp1.2-2007-EncryptBody.xmlポリシー・ファイルは、SOAPのリクエスト・メッセージおよびレスポンス・メッセージの両方の本文が暗号化されることを指定しています。
Wssp1.2-Wss1.1-EncryptedKey.xml対称バインディング・ポリシーは、WS-Security 1.1 Encrypted Key機能を使用します。Webサービスを呼び出すクライアント・アプリケーションは暗号化キーを使用して暗号化と署名を行い、サーバーは署名確認を送信する必要があります。
MtomClient.javaは、SecurityMtomService Webサービスを呼び出すスタンドアロン・クライアント・アプリケーションです。WebサービスのWSDLに基づいてclientgenによって生成されたJAX-RPCスタブを使用します。MtomClientコードは例2-26に示されています。
例2-26 MtomClient.java
package examples.webservices.security_mtom.client; import java.rmi.RemoteException; import java.security.cert.X509Certificate; import java.util.ArrayList; import java.util.List; import javax.xml.rpc.Stub; import weblogic.security.SSL.TrustManager; // Import classes to create the Binary and Username tokens import weblogic.wsee.security.bst.ClientBSTCredentialProvider; import weblogic.wsee.security.unt.ClientUNTCredentialProvider; // Import classes for creating the client-side credential provider import weblogic.xml.crypto.wss.WSSecurityContext; import weblogic.xml.crypto.wss.provider.CredentialProvider; import weblogic.wsee.security.util.CertUtils; /** * @author Copyright © 1996, 2008, Oracle and/or its affiliates. * All rights reserved. */ public class MtomClient { private static final String FOO = "FOO"; private static SecurityMtomService port; public MtomClient(String args[]) throws Exception { //client keystore file String clientKeyStore = args[0]; String clientKeyStorePass = args[1]; String clientKeyAlias = args[2]; String clientKeyPass = args[3]; //server certificate String serverCertFile = args[4]; String wsdl = args[5]; SecurityMtomServiceService service = new SecurityMtomServiceService_Impl(wsdl); port = service.getSecurityMtomServiceSoapPort(); X509Certificate serverCert = (X509Certificate) CertUtils.getCertificate(serverCertFile); //create emtpy list of credential providers List credProviders = new ArrayList(); //Create client-side BinarySecurityToken credential provider that uses // X.509 for identity, based on certificate and keys parameters CredentialProvider cp = new ClientBSTCredentialProvider(clientKeyStore, clientKeyStorePass, clientKeyAlias, clientKeyPass, "JKS", serverCert); credProviders.add(cp); Stub stub = (Stub) port; // Set stub property to point to list of credential providers stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders); // setup the TrustManager. stub._setProperty(WSSecurityContext.TRUST_MANAGER, new TrustManager() { public boolean certificateCallback(X509Certificate[] chain, int validateErr) { //Typically in a real-life application, Java code that actually //verifies the certificate goes here; for sake of simplicity, this //example assumes the certificate is valid and simply returns true. return true; } }); } public static void main(String[] args) throws Exception { MtomClient client = new MtomClient(args); client.invokeEchoBinaryAsString(); client.invokeEchoStringAsBinary(); client.invokeEchoBinaryArrayAsStringArray(); } public void invokeEchoBinaryArrayAsStringArray() throws RemoteException { System.out.println("sending a String '" + FOO + "' as a byte array."); String result = port.echoBinaryArrayAsStringArray(FOO.getBytes()).getJavaLangstring()[0]; System.out.println("echoing '" + result + "' as a String array."); } public void invokeEchoStringAsBinary() throws RemoteException { System.out.println("sending a String '" + FOO + "'"); String result = new String(port.echoStringAsBinary(FOO)); System.out.println("echoing '" + result + "' as a byte array."); } public void invokeEchoBinaryAsString() throws RemoteException { System.out.println("sending a String '" + FOO + "' as a byte array."); String result = port.echoBinaryAsString(FOO.getBytes()); System.out.println("echoing '" + result + "' as a String."); } }
クライアント・アプリケーションは、次の6つの引数を取ります。
クライアント・キーストア
クライアント・キーストア・パスワード
クライアント・キー別名
クライアント・キー・パスワード
サーバー証明書ファイル
デプロイされたWebサービスのWSDL
クライアント・アプリケーションは、次のWebLogic Webサービス・セキュリティAPIを使用し、Webサービスに関連付けられているWS-Policyファイルでの指定に従って、必要なクライアント側の資格証明プロバイダを作成します。
weblogic.wsee.security.bst.ClientBSTCredentialProvider - 証明書と秘密鍵を使用してバイナリ・セキュリティ・トークン資格証明プロバイダを作成します。
weblogic.xml.crypto.wss.WSSecurityContext - JAX-RPCスタブに資格証明プロバイダのリストを指定します。
weblogic.xml.crypto.wss.provider.CredentialProvider - メインの資格証明プロバイダ・クラス。
このクライアント・アプリケーションを記述するときは、Webサービスに関連付けられているWS-Policyファイルを参照し、JAX-RPCスタブに設定する必要のある資格証明プロバイダのタイプと数を確認する必要があります。通常、WS-PolicyファイルでアイデンティティにX.509を使用してSOAPメッセージを署名または暗号化することが指定されている場合は、ClientBSTCredentialProviderを作成する必要があります。(ユーザーがアイデンティティとしてユーザー名トークンを提示することが指定されている場合は、アプリケーションはClientUNTCredentialProviderを作成する必要があります。)
この例では、指定されたキーストア、証明書別名およびサーバー証明書に対応するクライアントBST資格証明プロバイダを作成します。パラメータserverCertで渡された証明書は、メッセージ本文の内容の暗号化と受信した署名の検証に使用されます。受信した署名の一部として受け取ったKeyInfo (証明書の指紋など)は、同じサーバー証明書を正しく識別するものであることが必要です。
また、Webサービス・クライアント・ランタイムは、操作が呼び出されると、SOAPリクエストのセキュリティ・ヘッダーを正しく作成するために、このWSDLを確認します。
最後に、クライアント・アプリケーションはweblogic.security.SSL.TrustManager WebLogicセキュリティAPIを使用して、SOAPリクエストの暗号化に使用される証明書が有効かどうかを確認する必要があります。クライアント・ランタイムはWebサービスのデプロイされたWSDLからこの証明書(サンプルではserverCert)を取得しますが、実際の状況ではこの証明書は自動的には信頼されないので、クライアント・アプリケーションでは、その証明書を使用してSOAPリクエストを暗号化する前に、証明書が有効であることを確認する必要があります。
注意:
この例で使用されるクライアント側の証明書と秘密鍵は単純なテスト目的で作成されているため、WebLogic Serverから常に信頼されます。このため、この例を実行するためにサーバー側のセキュリティ構成を追加する必要はありません。しかし実際には、クライアント・アプリケーションはVerisignなどの実在の認証局が発行した証明書を使用します。その場合、管理者はWebLogic Server管理コンソールを使用して、WebLogic Serverから信頼されるリストにこの証明書を追加する必要があります。
SecurityMtomService Webサービスが、関連付けられたポリシー・ファイルで課せられている要件に対応するためにWebLogic Server APIを明示的に呼び出すことはなく、セキュリティ・プロバイダ、トークン、その他のメカニズムが存在する場合でも、そのいずれが使用されるかを認識する必要もありません。
スクリプト・ファイルconfigWss.pyでは、WLSTを使用して、アクティブなセキュリティ・レルムのデフォルトのWebサービス・セキュリティ構成default_wssを作成および構成します。(デフォルトのWebサービス・セキュリティ構成は、別の構成を使用するように明示的にプログラミングされていないかぎり、ドメイン内のすべてのWebサービスで使用されます。)さらに、このスクリプトではx509トークンがサポートされるようにし、必要なセキュリティ・プロバイダなどを作成します。
例2-27は、configWss.pyファイルを示しています。build.xmlファイルがコマンド入力を提供します。注目すべき部分は太字で表されています。
注意:
このスクリプト内の長い行は、見やすいように書式を整えてあります。
例2-27 configWss.py
userName = sys.argv[1] passWord = sys.argv[2] url="t3://"+sys.argv[3]+":"+sys.argv[4] print "Connect to the running adminSever" connect(userName, passWord, url) edit() startEdit() #Enable assert x509 in SecurityConfiguration rlm = cmo.getSecurityConfiguration().getDefaultRealm() ia = rlm.lookupAuthenticationProvider("DefaultIdentityAsserter") activeTypesValue = list(ia.getActiveTypes()) existed = "X.509" in activeTypesValue if existed == 1: print 'assert x509 is aleady enabled' else: activeTypesValue.append("X.509") ia.setActiveTypes(array(activeTypesValue,java.lang.String)) ia.setDefaultUserNameMapperAttributeType('CN'); ia.setUseDefaultUserNameMapper(Boolean('true')); #Create default WebServcieSecurity securityName='default_wss' defaultWss=cmo.lookupWebserviceSecurity(securityName) if defaultWss == None: print 'creating new webservice security bean for: ' + securityName defaultWss = cmo.createWebserviceSecurity(securityName) else: print 'found exsiting bean for: ' + securityName #Create credential provider for DK cpName='default_dk_cp' wtm=defaultWss.lookupWebserviceCredentialProvider(cpName) if wtm == None: wtm = defaultWss.createWebserviceCredentialProvider(cpName) wtm.setClassName('weblogic.wsee.security.wssc.v200502.dk. DKCredentialProvider') wtm.setTokenType('dk') cpm = wtm.createConfigurationProperty('Label') cpm.setValue('WS-SecureConversationWS-SecureConversation') cpm = wtm.createConfigurationProperty('Length') cpm.setValue('16') else: print 'found exsiting bean for: DK ' + cpName #Create credential provider for x.509 cpName='default_x509_cp' wtm=defaultWss.lookupWebserviceCredentialProvider(cpName) if wtm == None: wtm = defaultWss.createWebserviceCredentialProvider(cpName) wtm.setClassName('weblogic.wsee.security.bst. ServerBSTCredentialProvider') wtm.setTokenType('x509') else: print 'found exsiting bean for: x.509 ' + cpName #Custom keystore for xml encryption cpName='ConfidentialityKeyStore' cpm=wtm.lookupConfigurationProperty(cpName) if cpm == None: cpm = wtm.createConfigurationProperty(cpName) keyStoreName=sys.argv[5] cpm.setValue(keyStoreName) cpName='ConfidentialityKeyStorePassword' cpm=wtm.lookupConfigurationProperty(cpName) if cpm == None: cpm = wtm.createConfigurationProperty(cpName) cpm.setEncryptValueRequired(Boolean('true')) KeyStorePasswd=sys.argv[6] cpm.setEncryptedValue(KeyStorePasswd) cpName='ConfidentialityKeyAlias' cpm=wtm.lookupConfigurationProperty(cpName) if cpm == None: cpm = wtm.createConfigurationProperty(cpName) keyAlias=sys.argv[7] cpm.setValue(keyAlias) cpName='ConfidentialityKeyPassword' cpm=wtm.lookupConfigurationProperty(cpName) if cpm == None: cpm = wtm.createConfigurationProperty('ConfidentialityKeyPassword') cpm.setEncryptValueRequired(Boolean('true')) keyPass=sys.argv[8] cpm.setEncryptedValue(keyPass) #Custom keystore for xml digital signature cpName='IntegrityKeyStore' cpm=wtm.lookupConfigurationProperty(cpName) if cpm == None: cpm = wtm.createConfigurationProperty(cpName) keyStoreName=sys.argv[5] cpm.setValue(keyStoreName) cpName='IntegrityKeyStorePassword' cpm=wtm.lookupConfigurationProperty(cpName) if cpm == None: cpm = wtm.createConfigurationProperty(cpName) cpm.setEncryptValueRequired(Boolean('true')) KeyStorePasswd=sys.argv[6] cpm.setEncryptedValue(KeyStorePasswd) cpName='IntegrityKeyAlias' cpm=wtm.lookupConfigurationProperty(cpName) if cpm == None: cpm = wtm.createConfigurationProperty(cpName) keyAlias=sys.argv[7] cpm.setValue(keyAlias) cpName='IntegrityKeyPassword' cpm=wtm.lookupConfigurationProperty(cpName) if cpm == None: cpm = wtm.createConfigurationProperty(cpName) cpm.setEncryptValueRequired(Boolean('true')) keyPass=sys.argv[8] cpm.setEncryptedValue(keyPass) #Create token handler for x509 token #cpName='default_x509_handler' th=defaultWss.lookupWebserviceTokenHandler(cpName) if th == None: th = defaultWss.createWebserviceTokenHandler(cpName) th.setClassName('weblogic.xml.crypto.wss.BinarySecurityTokenHandler') th.setTokenType('x509') cpm = th.createConfigurationProperty('UseX509ForIdentity') cpm.setValue('true') save() activate(block="true") disconnect() exit()
build.xmlファイルには、**INTERNAL XREF ERROR**に示したターゲットがあります。
表2-16 build.xmlのターゲット
| ターゲット | 説明 |
|---|---|
client |
セキュリティMTOM Webサービス・クライアントをビルドするターゲット。 |
config.server.security |
Webサービス・セキュリティを構成するターゲット。 |
deploy |
Webサービスをデプロイするターゲット。 |
server |
セキュリティMTOM Webサービスをビルドするターゲット。 |
clean |
一時ディレクトリを削除します。 |
build |
server、client、およびcleanに依存します。 |
run |
セキュリティMTOM Webサービス・クライアントを実行するターゲット。 |
all |
デフォルト・ターゲット。build、deployに依存します。 |
完全なbuild.xmlファイルを例2-28に示します。
例2-28 build.xmlファイル
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="webservices.security_mtom" default="all" basedir=".">
<!-- set global properties for this build -->
<property file="../../../examples.properties"/>
<property name="client.dir" value="${client.classes.dir}/webservicesSecurityMtom_Client" />
<property name="package.dir" value="examples/webservices/security_mtom"/>
<property name="package" value="examples.webservices.security_mtom"/>
<property name="ws.file" value="SecurityMtomService" />
<property name="ear.dir" value="${examples.build.dir}/webservicesSecurityMtomEar" />
<property name="cert.dir" value="${basedir}/certs" />
<property name="certs.dir" value="${basedir}/certs" />
<!--client keystore-->
<property name="client-keystore-name" value="clientKeyStore.jks"/>
<property name="client-keystore-pass" value="keystorepw"/>
<property name="client-cert" value="ClientCert"/>
<property name="client-key" value="ClientKey"/>
<property name="client-key-pass" value="ClientKeyPass"/>
<property name="client-cert-alias" value="testClientCert"/>
<!--server keystore-->
<property name="server-keystore-name" value="serverKeyStore.jks"/>
<property name="server-keystore-pass" value="keystorepw"/>
<property name="server-cert" value="ServerCert"/>
<property name="server-key" value="ServerKey"/>
<property name="server-key-pass" value="ServerKeyPass"/>
<property name="server-cert-alias" value="testServerCert"/>
<path id="client.class.path">
<pathelement path="${client.dir}"/>
<pathelement path="${java.class.path}"/>
</path>
<!-- Web Service WLS Ant task definitions -->
<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />
<taskdef name="clientgen"
classname="weblogic.wsee.tools.anttasks.ClientGenTask" />
<target name="all" depends="build, deploy"/>
<target name="build" depends="clean,server,client"/>
<target name="clean">
<delete dir="${ear.dir}"/>
<delete dir="${client.dir}"/>
</target>
<!-- Target that builds the MTOM Web Service -->
<target name="server" description="Target that builds the MTOM Web Service">
<jwsc
srcdir="${examples.src.dir}/${package.dir}"
sourcepath="${examples.src.dir}"
destdir="${ear.dir}"
classpath="${java.class.path}"
fork="true"
keepGenerated="true"
deprecation="${deprecation}"
debug="${debug}">
<jws file="SecurityMtomService.java" explode="true"/>
</jwsc>
</target>
<!-- Target that builds the MTOM Web Service client -->
<target name="client" description="Target that builds the source Web Service">
<mkdir dir="${client.dir}/${package.dir}/client/"/>
<clientgen
wsdl="${ear.dir}/${ws.file}/WEB-INF/${ws.file}Service.wsdl"
destDir="${client.dir}"
classpath="${java.class.path}"
packageName="${package}.client"/>
<copy file="MtomClient.java" todir="${client.dir}/${package.dir}/client/"/>
<javac
srcdir="${client.dir}" destdir="${client.dir}"
classpath="${java.class.path}"
includes="${package.dir}/client/**/*.java"/>
</target>
<!-- Target that deploys the MTOM Web Service -->
<target name="deploy" description="Target that deploys the reliable destination Web Service">
<wldeploy
action="deploy"
source="${ear.dir}"
user="${wls.username}"
password="${wls.password}"
verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}"
failonerror="${failondeploy}"/>
</target>
<!-- Target that runs the MTOM Web Service client -->
<target name="run" >
<java fork="true"
classname="examples.webservices.security_mtom.client.MtomClient"
failonerror="true" >
<jvmarg line="-Dweblogic.wsee.verbose=*"/>
<classpath refid="client.class.path"/>
<arg line="
${basedir}/certs/${client-keystore-name}
${client-keystore-pass}
${client-cert-alias}
${client-key-pass}
${basedir}/certs/testServerCertTempCert.der
http://${wls.hostname}:${wls.port}/SecurityMtomService/SecurityMtomService?WSDL" />
</java>
</target>
<!-- Target the configure the web service security -->
<target name="config.server.security" description="Target the configure the web service security">
<copy todir="${examples.domain.dir}" overwrite="true">
<fileset dir="${certs.dir}" includes="${server-keystore-name}"/>
</copy>
<java classname="weblogic.WLST" fork="true" failonerror="true">
<arg line="configWss.py ${wls.username} ${wls.password} ${wls.hostname} ${wls.port}
${server-keystore-name} ${server-keystore-pass} ${server-cert-alias} ${server-key-pass}" />
</java>
</target>
</project>
SecurityMtomService Webサービスのデプロイ済WSDLは、次のURLにあります。
http://host:port/SecurityMtomService/SecurityMtomService?WSDL
完全なWSDLを例2-29に示します。
例2-29 SecurityMtomServiceのデプロイ済WSDL
<?xml version="1.0" encoding="UTF-8" ?> <s1:definitions name="SecurityMtomServiceServiceDefinitions" targetNamespace="http://examples/webservices/security_mtom" xmlns="" xmlns:s0="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:s1="http://schemas.xmlsoap.org/wsdl/" xmlns:s2="http://examples/webservices/security_mtom" xmlns:s3="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsp:UsingPolicy s1:Required="true" /> <wsp:Policy s0:Id="Mtom.xml"> <wsoma:OptimizedMimeSerialization xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization" /> </wsp:Policy> <wsp:Policy s0:Id="Wssp1.2-Wss1.1-EncryptedKey.xml"> <sp:SymmetricBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"> <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never"> <wsp:Policy> <sp:RequireThumbprintReference /> <sp:WssX509V3Token11 /> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:ProtectionToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256 /> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax /> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp /> <sp:OnlySignEntireHeadersAndBody /> </wsp:Policy> </sp:SymmetricBinding> <sp:Wss11 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"> <wsp:Policy> <sp:MustSupportRefKeyIdentifier /> <sp:MustSupportRefIssuerSerial /> <sp:MustSupportRefThumbprint /> <sp:MustSupportRefEncryptedKey /> <sp:RequireSignatureConfirmation /> </wsp:Policy> </sp:Wss11> </wsp:Policy> <wsp:Policy s0:Id="Wssp1.2-2007-EncryptBody.xml"> <sp:EncryptedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <sp:Body /> </sp:EncryptedParts> </wsp:Policy> <wsp:Policy s0:Id="Wssp1.2-2007-SignBody.xml"> <sp:SignedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <sp:Body /> </sp:SignedParts> </wsp:Policy> <s1:types> <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="java:examples.webservices.security_mtom" xmlns:s0="http://schemas.xmlsoap.org/wsdl/" xmlns:s1="http://examples/webservices/security_mtom" xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType name="ArrayOfJavaLangstring_literal"> <xs:sequence> <xs:element maxOccurs="unbounded" minOccurs="0" name="JavaLangstring" nillable="true" type="xs:string" /> </xs:sequence> </xs:complexType> <xs:element name="ArrayOfJavaLangstring_literal" type="java:ArrayOfJavaLangstring_literal" xmlns:java="java:examples.webservices.security_mtom" /> <xs:element name="base64Binary_literal" type="xs:base64Binary" /> </xs:schema> <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://examples/webservices/security_mtom" xmlns:s0="http://schemas.xmlsoap.org/wsdl/" xmlns:s1="http://examples/webservices/security_mtom" xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import namespace="java:examples.webservices.security_mtom" /> <xs:element name="echoBinaryAsString"> <xs:complexType> <xs:sequence> <xs:element name="bytes" type="xs:base64Binary" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="echoBinaryAsStringResponse"> <xs:complexType> <xs:sequence> <xs:element name="return" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="echoBinaryArrayAsStringArray"> <xs:complexType> <xs:sequence> <xs:element name="array" type="xs:base64Binary" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="echoBinaryArrayAsStringArrayResponse"> <xs:complexType> <xs:sequence> <xs:element name="return" type="java:ArrayOfJavaLangstring_literal" xmlns:java="java:examples.webservices.security_mtom" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="echoStringAsBinary"> <xs:complexType> <xs:sequence> <xs:element name="s" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="echoStringAsBinaryResponse"> <xs:complexType> <xs:sequence> <xs:element name="return" type="xs:base64Binary" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </s1:types> <s1:message name="echoBinaryAsString"> <s1:part element="s2:echoBinaryAsString" name="parameters" /> </s1:message> <s1:message name="echoBinaryAsStringResponse"> <s1:part element="s2:echoBinaryAsStringResponse" name="parameters" /> </s1:message> <s1:message name="echoBinaryArrayAsStringArray"> <s1:part element="s2:echoBinaryArrayAsStringArray" name="parameters" /> </s1:message> <s1:message name="echoBinaryArrayAsStringArrayResponse"> <s1:part element="s2:echoBinaryArrayAsStringArrayResponse" name="parameters" /> </s1:message> <s1:message name="echoStringAsBinary"> <s1:part element="s2:echoStringAsBinary" name="parameters" /> </s1:message> <s1:message name="echoStringAsBinaryResponse"> <s1:part element="s2:echoStringAsBinaryResponse" name="parameters" /> </s1:message> <s1:portType name="SecurityMtomService" wsp:PolicyURIs="#Wssp1.2-2007-SignBody.xml #Wssp1.2-2007-EncryptBody.xml #Wssp1.2-Wss1.1-EncryptedKey.xml"> <s1:operation name="echoBinaryAsString" parameterOrder="parameters"> <s1:input message="s2:echoBinaryAsString" /> <s1:output message="s2:echoBinaryAsStringResponse" /> </s1:operation> <s1:operation name="echoBinaryArrayAsStringArray" parameterOrder="parameters"> <s1:input message="s2:echoBinaryArrayAsStringArray" /> <s1:output message="s2:echoBinaryArrayAsStringArrayResponse" /> </s1:operation> <s1:operation name="echoStringAsBinary" parameterOrder="parameters"> <s1:input message="s2:echoStringAsBinary" /> <s1:output message="s2:echoStringAsBinaryResponse" /> </s1:operation> </s1:portType> <s1:binding name="SecurityMtomServiceServiceSoapBinding" type="s2:SecurityMtomService"> <s3:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsp:Policy> <wsp:PolicyReference URI="#Mtom.xml" /> </wsp:Policy> <s1:operation name="echoBinaryAsString"> <s3:operation style="document" /> <s1:input> <s3:body parts="parameters" use="literal" /> </s1:input> <s1:output> <s3:body parts="parameters" use="literal" /> </s1:output> </s1:operation> <s1:operation name="echoBinaryArrayAsStringArray"> <s3:operation style="document" /> <s1:input> <s3:body parts="parameters" use="literal" /> </s1:input> <s1:output> <s3:body parts="parameters" use="literal" /> </s1:output> </s1:operation> <s1:operation name="echoStringAsBinary"> <s3:operation style="document" /> <s1:input> <s3:body parts="parameters" use="literal" /> </s1:input> <s1:output> <s3:body parts="parameters" use="literal" /> </s1:output> </s1:operation> </s1:binding> <s1:service name="SecurityMtomServiceService"> <s1:port binding="s2:SecurityMtomServiceServiceSoapBinding" name="SecurityMtomServiceSoapPort"> <s3:address location="http://localhost:7001/SecurityMtomService/SecurityMtomService" /> </s1:port> </s1:service> </s1:definitions>
この項では、WebLogic Serverにオプションで含まれているサンプルの更新方法について説明します。
EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security
この節では、最新バージョンのポリシー・ファイルを使用するようにサンプルを更新する方法を示します。。変更されたサンプルに示すように、新しいポリシー・ネームスペースを使用することをお薦めします。OASIS標準の公式のネームスペースであり、他のベンダーと相互運用するときに適しているためです。
信頼性のあるSOAPメッセージングとは、あるWebLogic Serverインスタンスで実行されているアプリケーションが別のWebLogic Serverインスタンスで実行されているWebサービスを確実に呼び出せるようにするフレームワークです。信頼性のある、とは2つのWebサービス間でのメッセージの配信を保証できるということです。
WebLogic Webサービスは、異なるWebLogic Serverアプリケーション・サーバーで動作する2つのWebサービスが、ソフトウェア・コンポーネント、システムまたはネットワークで障害が発生した場合に確実に通信する方法を規定した、WS-ReliableMessaging 1.1仕様に準拠しています。具体的には、ソース・エンドポイント(クライアントWebサービス)から宛先エンドポイント(操作を確実に呼び出せるWebサービス)へ送信されるメッセージが、1つ以上の配信保証に基づいて確実に配信され、そうでなければ必ずエラーが発生する、相互運用性を備えたプロトコルについて記述されています。WS-ReliableMessaging仕様では、WS-ReliableMessagingにWS-SecureConversationを組み合せて、信頼性のあるシーケンスとセキュアなセッションを関連付けることにより、相互運用可能なセキュリティの提供方法を定義しています。シーケンスの作成時に、送信側は、シーケンスの所有者の識別に使用されるセキュリティ・コンテキスト・トークンを指すセキュリティ・トークン参照を提示する必要があります。以降の両方向のすべてのシーケンス・メッセージとプロトコル・メッセージは、参照されたキーの所有証明を提示する必要があります。
WebLogicの信頼性のあるSOAPメッセージングは、2つのWebサービス間でのみ機能します。つまり、WebLogic Webサービスは別のWebサービスからのみ呼び出すことが可能で、スタンドアロン・クライアント・アプリケーションから呼び出すことはできません。この例では、両方のタイプ(ソースと宛先)のWebサービスの作成方法を示します。WsrmSecurityClient.javaクラスは、ソースWebサービスを呼び出すスタンドアロンのJavaアプリケーションです。
既存のサンプルでは、次の2つのWebLogic Webサービスを作成することで、Webサービス・メッセージングの信頼性に加えてセキュリティ機能を提供する方法を示しています。
信頼性のあるセキュアなSOAPメッセージングを使用して操作を呼び出せるWebサービス(宛先エンドポイント)。宛先ReliableEchoService Webサービスには、信頼性のあるセキュアな方法で呼び出せる2つの操作echoおよびechoOnewayがあります。
1番目のWebサービスの操作を信頼性のあるセキュアな方法で呼び出すクライアントWebサービス(ソース・エンドポイント)。ソースReliableEchoClientService Webサービスには、ReliableEchoService WebサービスのechoおよびechoOneway操作を、1回の通信で信頼性のあるセキュアな方法で呼び出す操作echoがあります。
既存のサンプルには、実際に機能するコードと、その使用方法や役割、ビルド方法などを説明した詳細なinstructions.htmlファイルが含まれています。この項では、その説明を繰り返すのではなく、サンプルに加える変更と変更の理由に焦点を当てています。
configWSS.py WLSTスクリプトはソースおよび宛先WebサービスをホストするWebLogic Serverインスタンスのセキュリティを設定します。セキュリティ要件は、宛先Webサービスに関連付けられたWS-SecurityPolicyファイルによって規定されます。
Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xmlポリシーは次の要件を課しています。
WS-SecureConversationハンドシェイクがWS-Security 1.0によって保護されます。
アプリケーション・メッセージは、DerivedKeyで署名および暗号化されます。
(WS-SecureConversationハンドシェイクの一部の) RequestSecurityTokenおよびRequestSecurityTokenResponseCollectionメッセージのsoap:Bodyは署名および暗号化されます。
WS-Addressingヘッダーは署名されます。
タイムスタンプは、格納されて署名されます。
署名は暗号化されます。
アルゴリズム・スイートはBasic256です。
これを受けて、configWSS.py WLSTスクリプトは次の機能を実行します。
デフォルト・セキュリティ・レルム内のデフォルトIdentityAsserterでX.509トークンを有効にします。
デフォルトのWebサービス・セキュリティ構成を作成します。
セキュリティ・コンテキスト・トークンの資格証明プロバイダを構成します。
派生キーの資格証明プロバイダを構成します。
X.509トークンのBinarySecurityTokenHandlerトークンを構成します。
X.509トークンのServerBSTCredentialProvider資格証明プロバイダを構成します。
機密性と整合性を確保するためにキーストアを構成します。
PKI資格証明マッパーを構成します。これは、イニシエータとターゲット・リソースをキー・ペアまたはパブリック証明書にマップします
さらに、configWSSRuntime.py WLSTスクリプトは次の機能を実行します。
宛先Webサービスを呼び出すように、(configWSS.pyで構成された)PKI資格証明マッパーを設定します。
この例では、**INTERNAL XREF ERROR**に示すファイルを使用します。変更されたソース・ファイルの内容はこの後の項で示します。
表2-17 WSRM/セキュリティの例で使用されるファイル
| ファイル | 説明 |
|---|---|
build.xml |
サンプルをビルドおよび実行するためのターゲットが含まれたビルド・ファイル。 |
ReliableEchoClientServiceImpl.java |
ReliableEchoService WebサービスのechoOneWayおよびecho操作をセキュアな方法で確実に呼び出すソースWebサービスを実装するJWSファイル。このJWSファイルでは、@ServiceClientアノテーションを使用して、確実に呼び出すWebサービスを指定しています。 |
ReliableEchoServiceImpl.java |
信頼性のある宛先Webサービスを実装するJWSファイル。このJWSファイルでは、@Policyアノテーションを使用して、信頼性のあるSOAPメッセージング・アサーションを含むWS-Policyファイルを指定しています。 |
ws_rm_configuration.py |
信頼性のあるSOAPメッセージングに必要なSAFエージェント、ファイル・ストア、JMSサーバー、およびJMSキューを構成するWLSTスクリプト。このスクリプトは、信頼性のある宛先WebサービスをホストするWebLogic Serverインスタンスに対して実行します。すぐに使用できるサンプル・サーバーは、信頼できる方法で操作を呼び出すソースWebサービス向けにすでに構成されています。 |
configWss.py |
セキュアなSOAPメッセージングに必要な、セキュリティ・コンテキスト・トークンの資格証明プロバイダ、派生キーの資格証明プロバイダ、X.509の資格証明プロバイダ、機密性と整合性のためのキーストア、PKI資格証明マッパーなどを構成するWLSTスクリプト。このスクリプトは、ソースおよび宛先WebサービスをホストするWebLogic Serverインスタンスに対して実行します。このスクリプトを実行した後はWebLogic Serverを必ず再起動してください |
configWss_Service.py |
宛先WebサービスをホストするサーバーでセキュアなSOAPメッセージングのために必要となる、セキュリティ・コンテキスト・トークンの資格証明プロバイダ、派生キーの資格証明プロバイダ、X.509の資格証明プロバイダ、機密性と整合性のためのキーストアなどを構成するWLSTスクリプト。このスクリプトは、ソースおよび宛先Webサービスが2つのサーバーでホストされている場合に、宛先WebサービスをホストするWebLogic Serverインスタンスに対して実行します。このスクリプトを実行した後はWebLogic Serverを必ず再起動してください。 |
configWssRuntime.py |
宛先Webサービスを呼び出すための鍵ペア資格証明を構成するWLSTスクリプト。 |
certs/testServerCertTempCert.der |
サーバー側の証明書。サーバー側のBinarySecurityToken資格証明プロバイダの作成に使用されます。 |
certs/clientKeyStore.jks |
クライアント側のキーストア。クライアント側のBinarySecurityToken資格証明プロバイダの作成に使用されます。 |
certs/serverKeyStore.jks |
サーバー側のキーストア。サーバー側のBinarySecurityToken資格証明プロバイダの作成に使用されます。 |
WsrmSecurityClient.java |
信頼性のあるセキュアな方法で、ソースWebLogic Webサービスを呼び出してからReliableEchoService Webサービスの操作を呼び出す、スタンドアロンのJavaクライアント・アプリケーション。 |
ReliableEchoServiceImpl.java JWSファイルは、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security\ReliableEchoServiceImpl.javaのJWSファイルと同じものです(変更されたポリシー・アノテーションは太字で示されています)。
例2-30 ReliableEchoServiceImpl.java
@WebService(name = "ReliableEchoPort",
serviceName = "ReliableEchoService")
@WLHttpTransport(contextPath = "WsrmSecurity", serviceUri = "ReliableEchoService")
@Policies({
@Policy(uri="policy:Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml"),
@Policy(uri="policy:Reliability1.1_SequenceSTR")}
)
@Policyアノテーションはクラス・レベルでもメソッド・レベルでも指定できます。この例では、アノテーションをクラス・レベルで使用して、事前定義済のWS-Policyファイルを指定しているため、Webサービスのすべてのパブリック操作が指定されたWS-Policyファイルに関連付けられます。
ReliableEchoServiceImpl Webサービスが、関連付けられたポリシー・ファイルで課せられている要件に対応するためにWebLogic Server APIを明示的に呼び出すことはなく、セキュリティ・プロバイダ、トークン、その他のメカニズムが存在する場合でも、そのいずれが使用されるかを認識する必要もありません。
スクリプト・ファイルconfigWss.pyでは、WLSTを使用して、アクティブなセキュリティ・レルムのデフォルトのWebサービス・セキュリティ構成default_wssを作成および構成します。(デフォルトのWebサービス・セキュリティ構成は、別の構成を使用するように明示的にプログラミングされていないかぎり、ドメイン内のすべてのWebサービスで使用されます。)さらに、このスクリプトではx509トークンがサポートされるようにし、必要なセキュリティ・プロバイダなどを作成します。
configWss.pyファイルは、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security\configWss.pyのファイルと同じものです(変更点は太字で示されています)。build.xmlファイルがコマンド入力を提供します。
注意:
このスクリプト内の長い行は、見やすいように書式を整えてあります。
例2-31 configWss.py
: #Create credential provider for SCT cpName='default_sct_cp' wtm=defaultWss.lookupWebserviceCredentialProvider(cpName) if wtm == None: print 'creating new webservice credential provider : ' + cpName wtm = defaultWss.createWebserviceCredentialProvider(cpName) wtm.setClassName('weblogic.wsee.security.wssc.v13.sct. ServerSCCredentialProvider') wtm.setTokenType('sct') cpm = wtm.createConfigurationProperty('TokenLifeTime') cpm.setValue('43200000') else: print 'found exsiting bean for: ' + cpName #Create credential provider for DK cpName='default_dk_cp' wtm=defaultWss.lookupWebserviceCredentialProvider(cpName) if wtm == None: wtm = defaultWss.createWebserviceCredentialProvider(cpName) wtm.setClassName('weblogic.wsee.security.wssc.v13. dk.DKCredentialProvider') wtm.setTokenType('dk') cpm = wtm.createConfigurationProperty('Label') cpm.setValue('WS-SecureConversationWS-SecureConversation') cpm = wtm.createConfigurationProperty('Length') cpm.setValue('16') else: print 'found exsiting bean for: DK ' + cpName :
configWss_Service.pyスクリプトはconfigWss.pyと似ていますが、ソースと宛先のWebサービスが2つのサーバーでホストされている場合にのみ使用されます。
configWss_Service.pyファイルは、EXAMPLES_HOME\wl_server\examples\src\examples\webservices\wsrm_security\configWss_Service.pyのファイルと同じものです(変更点は太字で示されています)。build.xmlファイルがコマンド入力を提供します。
注意:
このスクリプト内の長い行は、見やすいように書式を整えてあります。
例2-32 configWss_Service.py
: #Create credential provider for SCT cpName='default_sct_cp' wtm=defaultWss.lookupWebserviceCredentialProvider(cpName) if wtm == None: print 'creating new webservice credential provider : ' + cpName wtm = defaultWss.createWebserviceCredentialProvider(cpName) wtm.setClassName('weblogic.wsee.security.wssc. v13.sct.ServerSCCredentialProvider') wtm.setTokenType('sct') cpm = wtm.createConfigurationProperty('TokenLifeTime') cpm.setValue('43200000') else: print 'found exsiting bean for: ' + cpName #Create credential provider for DK cpName='default_dk_cp' wtm=defaultWss.lookupWebserviceCredentialProvider(cpName) if wtm == None: wtm = defaultWss.createWebserviceCredentialProvider(cpName) wtm.setClassName('weblogic.wsee.security.wssc.v13.dk. DKCredentialProvider') wtm.setTokenType('dk') cpm = wtm.createConfigurationProperty('Label') cpm.setValue('WS-SecureConversationWS-SecureConversation') cpm = wtm.createConfigurationProperty('Length') cpm.setValue('16') else: print 'found existing bean for: DK ' + cpName :
Webサービスの原子性トランザクションを使用する際には(Oracle WebLogic Server JAX-WS Webサービスの開発のWebサービスの原子性トランザクションの使用を参照)、次のいずれかの事前定義済ポリシーを使用して、コーディネーション・コンテキストとIssuedTokensを含むアプリケーション・メッセージ・ヘッダーを保護してください。
Wssp1.2-2007-SignAndEncryptWSATHeaders.xml: WS-AtomicTransactionヘッダーが署名および暗号化されることを指定します。
Wssp1.2-2007-Wsp1.5-SignAndEncryptWSATHeaders.xml: WS-AtomicTransactionヘッダーが署名および暗号化されることを指定します。Web Services Policy 1.5が使用されます。
注意:
ヘッダーの暗号化はWS-Security 1.1標準の一部として提供されているため、アプリケーション・リクエスト・メッセージを保護する際には、前述のポリシーとともにWS-Security 1.1のバインディング・ポリシーのみを使用することを強くお薦めします。WS-Security 1.1のバインディング・ポリシーでは、ポリシーに<sp:Wss11>アサーションが含まれ、事前定義済のポリシー名に-Wss1.1が含まれています。WS-Security 1.0のポリシーを使用すると、ヘッダーがWS-Security 1.0の規格外の形式に暗号化されます。
次のいずれかの方法でポリシーをアタッチします。
設計時には、@Policyおよび@Policiesアノテーションを使用します(「JAX-WS Webサービスにセキュリティを追加する例」を参照)。
デプロイメント時には、WebLogic Server管理コンソールを使用します(「管理コンソールを使用した実行時のポリシー・ファイルの関連付け」を参照)。
次の例は、@Policyおよび@Policiesアノテーションを使用して、Webサービスの原子性トランザクションをプログラムで保護する方法を示しています。関連するコードは太字で示されています。
package jaxws.interop.rsp; ... import javax.jws.WebService; import javax.xml.ws.BindingType; import weblogic.wsee.wstx.wsat.Transactional; import weblogic.wsee.wstx.wsat.Transactional.TransactionalFlowType; import weblogic.wsee.wstx.wsat.Transactional.Version; import weblogic.jws.Policy; import weblogic.jws.Policies; ... @WebService( portName = "FlightServiceBindings_Basic", serviceName = "FlightService", targetNamespace = "http://wsinterop.org/samples", wsdlLocation = "/wsdls/FlightService.wsdl", endpointInterface = "jaxws.interop.rsp.IFlightService" ) @BindingType("http://schemas.xmlsoap.org/wsdl/soap/http") @javax.xml.ws.soap.Addressing public class FlightServiceImpl implements IFlightService { ... @Transactional(value = Transactional.TransactionFlowType.SUPPORTS, version = Transactional.Version.WSAT12) @Policies({ @Policy(uri="policy:Wssp1.2-2007-EncryptBody.xml" @Policy(uri="policy:Wssp1.2-2007-SignAndEncryptWSATHeaders.xml" @Policy(uri="policy:Wssp1.2-2007-SignBody.xml" @Policy(uri="policy:Wssp1.2-2007-Wss1.1-X509-Basic256.xml" }) public FlightReservationResponse reserveFlight(FlightReservationRequest request) { //replace with your impl here FlightReserverationEnitity entity = new FlightReserverationEnitity(); entity.setAirlineID(request.getAirlineID()); entity.setFlightNumber(request.getFlightNumber()); entity.setFlightType(request.getFlightType()); boolean successful = saveRequest(entity); FlightReservationResponse response = new FlightReservationResponse(); if (!successful) { response.setConfirmationNumber("OF" + CONF_NUMBER++ + "-" + request.getAirlineID() + String.valueOf(entity.getId())); } else if (request.getFlightNumber() == null || request.getFlightNumber().trim().endsWith("LAS")) { successful = false; response.setConfirmationNumber("OF" + "- No flight available for " + request.getAirlineID()); } else { response.setConfirmationNumber("OF" + CONF_NUMBER++ + "-" + request.getAirlineID() + String.valueOf(entity.getId())); } response.setSuccess(successful); return response; }
WS-SecurityPolicy仕様が規定される以前の旧リリースのWebLogic Serverでは、WS-Policy仕様に基づき、プロプライエタリのセキュリティ・ポリシー・スキーマを使用して記述されたセキュリティ・ポリシー・ファイルを使用していました。
注意:
Webサービス・セキュリティ・ポリシー・スキーマに基づいて記述されたセキュリティ・ポリシー・ファイルは、このリリースで非推奨になりました。
WS-SecurityPolicy 1.2ポリシー・ファイルと独自のWebサービス・セキュリティ・ポリシー・スキーマ・ファイルには、相互の互換性はありません。したがって、1つのWebサービスに、両方のタイプのポリシー・ファイルを定義することはできません。WS-Security 1.1機能を使用する場合は、WS-SecurityPolicy 1.2ポリシー・ファイル形式を使用する必要があります。
この項では、WebLogic Serverの事前定義済のWebサービス・セキュリティ・ポリシー・スキーマ・ファイルについて説明します。これらは、すべて抽象ポリシー・ファイルです。詳細については、「抽象および具象ポリシー・ファイル」を参照してください。
WebLogic Webサービスのメッセージ・レベルのセキュリティを構成するために、これらのセキュリティ・ポリシー・ファイルで使用されるポリシー・アサーションは、Web Services Security Policy Language(WS-SecurityPolicy)仕様(2002年12月18日付)に記述されているアサーションに基づいています。つまり、WebLogic Serverのアサーションの正確な構文と使用方法は、この仕様で説明されているアサーションとは異なっていますが、意味上の違いはありません。これらのアサーションには、これ以降の仕様の更新は反映されていません。
事前定義済のWebサービス・セキュリティ・ポリシーには次のものがあります。
Auth.xml: クライアントが自身を認証する必要があることを指定します。単独で使用することも、Sign.xmlやEncrypt.xmlと併用することもできます。
Sign.xml: SOAPメッセージがデジタル署名されることを指定します。単独で使用することも、Auth.xmlやEncrypt.xmlと併用することもできます。
Encrypt.xml: SOAPメッセージが暗号化されることを指定します。単独で使用することも、Auth.xmlやSign.xmlと併用することもできます。
Wssc-dk.xml: WS-SecureConversation仕様に従って、複数のメッセージを交換する際にクライアントとサービスがセキュリティ・コンテキストを共有すること、および派生キーが暗号化とデジタル署名に使用されることを指定します。
注意:
この事前定義済のポリシー・ファイルはAuth.xml、Sign.xml、Encrypt.xml、またはWssc-sct.xmlで使用されるのではなく、そのファイル自体で使用されます。また、Oracleは、クライアントとサービスにセキュリティ・コンテキストを共有するためにWssc-sct.xml ( Wssc-sct.xml)よりむしろ高いレベルのセキュリティのためこのポリシー・ファイルを使用することを薦めます。
Wssc-sct.xml: WS-SecureConversation仕様に従って、複数のメッセージを交換する際にクライアントとサービスがセキュリティ・コンテキストを共有することを指定します。
注意:
この事前定義済のポリシー・ファイルはAuth.xml、Sign.xml、Encrypt.xml、またはWssc-dk.xmlで使用されるのではなく、そのファイル自体で使用されます。また、Oracleは、 WS-SecureConversation仕様に関するさまざまなユース・ケースをサポートするためにこのポリシー・ファイルを提供します。 ただし、高いレベルのセキュリティでクライアントとサービスにセキュリティ・コンテキストを共有するためにWssc-sct.xml (Wssc-sct.xml),よりむしろWssc-dk.xml (Wssc-dk.xml)ポリシー・ファイルを使用することを薦めます。
WebLogic Webサービス実行時環境では、抽象と具象という若干異なる2種類のセキュリティ・ポリシー・ファイルが認識されます。
抽象ポリシー・ファイルでは、認証、暗号化、およびデジタル署名に使用されるセキュリティ・トークンは明示的に指定されませんが、Webサービスのデプロイ時にWebサービス実行時環境でセキュリティ・トークンが決定されます。つまり具体的には、ポリシー・ファイルの<Identity>および<Integrity>要素(またはアサーション)には<SupportedTokens><SecurityToken>子要素が含まれず、ポリシー・ファイルの<Confidentiality>要素には<KeyInfo><SecurityToken>子要素が含まれません。
Webサービスが関連付けられているのが事前定義済のポリシー・ファイルのみの場合は、クライアント認証にユーザー名トークンが必要です。Webサービスでは、暗号化とデジタル署名用のトークン・タイプは1つ(X.509)しかサポートされていないため、<Integrity>要素および<Confidentiality>要素が使用される場合でも、抽象ポリシー・ファイルと具象ポリシー・ファイルは結果として本質的には同じになります。
Webサービスが抽象ポリシー・ファイルに関連付けられ、そのファイルがWSDLの添付ファイルとして公開される場合(デフォルトの動作)、Webサービスのアーカイブ・ファイル(JARまたはWAR)にパッケージ化される静的WSDLファイルは、デプロイされたWebサービスの動的WSDLファイルとは若干異なります。抽象的な静的WSDLには特定の<SecurityToken>要素が含まれていないのに対し、動的WSDLにはこうした要素が含まれているのは、サービスがデプロイされるときにWebサービス・ランタイムによってこれらの要素が自動的に設定されるためです。このためクライアント・アプリケーションでJAX-RPCスタブを作成するコードでは、操作を呼び出そうとするとき、ダイナミックなWSDLを確実に指定してください。そうでないとランタイム・エラーが発生します:HelloService service = new HelloService(Dynamic_WSDL);
この場合、clientgen Antタスクには静的WSDLと動的WSDLのどちらでも指定できます。デプロイされたWebサービスの動的WSDLの参照については、Oracle WebLogic Server JAX-RPC Webサービスの開発のWebサービスのWSDLの参照を参照してください。
具象ポリシー・ファイルでは、Webサービスのプログラミング時にセキュリティ・トークンの詳細を明示的に指定します。サービスのプログラミング時に、認証のタイプの詳細(x509トークンまたはSAMLトークンの使用など)や、キーストアの複数の秘密鍵と証明書のペアが暗号化とデジタル署名に使用されるかどうかなどがわかっている場合は、具象セキュリティ・ポリシー・ファイルを作成します。
次に示すWebLogic Server Auth.xmlファイルでは、Webサービスを呼び出すクライアント・アプリケーションが、認証をサポートしているトークンのいずれか(ユーザー名またはX.509)を使用して自身を認証する必要があることを指定します。
事前定義済のWebサービス・セキュリティ・ポリシー・スキーマ・ファイルは抽象ファイルであるため、開発時にはAuth.xmlファイルに特定のユーザー名やX.509トークンのアサーションはありません。セキュリティがWebLogic Serverにどのように構成されたかによって、ユーザー名トークン、X.509トークン、またはその両方が、Webサービスに関連付けられた実際の実行時バージョンのAuth.xmlポリシー・ファイルに示されます。さらに、実行時バージョンのポリシー・ファイルにあるX.509トークンがクライアントの呼出しに適用される場合は、SOAPメッセージの本文全体が署名されます。
アイデンティティとしてX.509のみを使用する(ユーザー名トークンは使用しない)ことを指定する場合、またはアイデンティティとしてX.509を使用しているときにSOAPメッセージの特定の部分のみに署名することを指定する場合は、カスタム・セキュリティ・ポリシー・ファイルを作成する必要があります。
例2-33 Auth.xml
<?xml version="1.0"?> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wssp="http://www.bea.com/wls90/security/policy" > <wssp:Identity/> </wsp:Policy>
WebLogic ServerのSign.xmlファイルでは、SOAPメッセージの本文およびWebLogic固有のシステム・ヘッダーにデジタル署名することを指定します。また、デジタル署名されたタイムスタンプをSOAPメッセージに含めること、および署名に使用するトークンにもデジタル署名することを指定します。署名に使用するトークンはSOAPメッセージに含まれます。
次のヘッダーは、Sign.xmlセキュリティ・ポリシー・ファイルの使用時に署名されます。
SequenceAcknowledgement
AckRequested
Sequence
Action
FaultTo
From
MessageID
RelatesTo
ReplyTo
To
SetCookie
Timestamp
WebLogic ServerのSign.xmlファイルを次に示します。
例2-34 Sign.xml
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity>
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<wssp:CanonicalizationAlgorithm
URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
</wssp:Integrity>
<wssp:MessageAge/>
</wsp:Policy>
WebLogic ServerのEncrypt.xmlファイルでは、SOAPメッセージの本文全体を暗号化することを指定します。デフォルトでは、暗号化トークンはSOAPメッセージに含まれません。
例2-35 Encrypt.xml
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
>
<wssp:Confidentiality>
<wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<wssp:Target>
<wssp:EncryptionAlgorithm
URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo/>
</wssp:Confidentiality>
</wsp:Policy>
WS-SecureConversation仕様のとおりに、クライアントとWebサービスでセキュリティ・コンテキストを共有すること、および派生キー・トークンを使用することを指定します。これにより、最も高度なセキュリティを確保できます。
このポリシー・ファイルでは以下の構成が提供されます。
派生キー・トークンを使用して、すべてのシステムSOAPヘッダー、タイムスタンプ・セキュリティSOAPヘッダー、およびSOAP本文を署名します。
派生キー・トークンを使用して、SOAPメッセージの本文を暗号化します。これは、署名に使用されるものとは別のトークンです。
各SOAPメッセージで派生キーの固有のペアを使用します。
デジタル署名と暗号化の両方において、キー長をデフォルトの32ではなく16とします。
セキュリティ・コンテキストの存続期間を12時間とします。
デフォルトのセキュリティ・コンテキストと派生キーの動作を変更する場合は、後の項で説明するカスタム・セキュリティ・ポリシー・ファイルを作成する必要があります。
注意:
この事前定義済セキュリティ・ポリシー・ファイルを指定する場合、他の事前定義済セキュリティ・ポリシー・ファイルは指定しないでください。
例2-36 Wssc-dk.xml
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity SupportTrust10="true">
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
<wssp:Claims>
<wssp:Label>WS-SecureConversationWS-SecureConversation</wssp:Label>
<wssp:Length>16</wssp:Length>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
<wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
<wssp:Claims>
<wssp:Label>WS-SecureConversationWS-SecureConversation</wssp:Label>
<wssp:Length>16</wssp:Length>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:KeyInfo>
</wssp:Confidentiality>
<wssp:MessageAge/>
</wsp:Policy>
WS-SecureConversation仕様のとおりに、クライアントとWebサービスでセキュリティ・コンテキストを共有することを指定します。この場合、セキュリティ文脈トークンは、SOAPメッセージを暗号化して、署名するのに使用されます(派生している主要なトークンが使用されているWssc-dk.xml (Wssc-dk.xml)と異なっています)。最大のセキュリティのために、Wssc-sct.xmlポリシー・ファイルは仕様に関するすべての使用例がサポートするために提供します。 しかし、Oracleは、より高いレベルのセキュリティのため共有されたセキュリティ文脈を指定するとき、いつもWssc-dk.xml (Wssc-dk.xml)を使用することを薦めます。
このセキュリティ・ポリシー・ファイルでは以下の構成が提供されます。
セキュリティ・コンテキスト・トークンを使用して、すべてのシステムSOAPヘッダー、タイムスタンプ・セキュリティSOAPヘッダー、およびSOAP本文を署名します。
セキュリティ・コンテキスト・トークンを使用して、SOAPメッセージの本文を暗号化します。
セキュリティ・コンテキストの存続期間を12時間とします。
デフォルトのセキュリティ・コンテキストと派生キーの動作を変更する場合は、後の項で説明するカスタム・セキュリティ・ポリシー・ファイルを作成する必要があります。
注意:
この事前定義済セキュリティ・ポリシー・ファイルを指定する場合、他の事前定義済セキュリティ・ポリシー・ファイルは指定しないでください。
例2-37 Wssc-sct.xml
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<wssp:Integrity SupportTrust10="true">
<wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SystemHeaders()
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
wls:SecurityHeader(wsu:Timestamp)
</wssp:MessageParts>
</wssp:Target>
<wssp:Target>
<wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()
</wssp:MessageParts>
</wssp:Target>
<wssp:SupportedTokens>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Integrity>
<wssp:Confidentiality SupportTrust10="true">
<wssp:Target>
<wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
</wssp:Target>
<wssp:KeyInfo>
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
</wssp:SecurityToken>
</wssp:KeyInfo>
</wssp:Confidentiality>
<wssp:MessageAge />
</wsp:Policy>
