この章では、Service BusでWebLogic Serverのセキュリティ・ポリシーを使用する方法について説明します。
注意:
この章は主にWLS 9ポリシーに適用され、Oracle Web Services Manager (OWSM)ポリシーは対象ではありません。WLSポリシーは、このリリースで非推奨になったため、OWSMポリシーで置き換えられます。WLS9ポリシーがアタッチされているサービスをインポートできますが、新しいサービスにはOWSMポリシーのみを使用できます。
Webサービスであるプロキシ・サービスまたはビジネス・サービスのメッセージ・レベルのセキュリティ要件を指定するには、Webサービス・ポリシー(WS-Policy)フレームワークを使用します。
次の項では、プロキシ・サービスとビジネス・サービスのWS-Policyの構成について説明します。
Webサービス・ポリシー(WS-Policy)は、Webサービスの制約と要件を定義するための標準ベースのフレームワークです。それは、それぞれ1つまたは複数のアサーションを含む、ポリシーと呼ばれるXML文の集合で制約と要件を表します。
Service Busでは、WS-Policyアサーションを使用して、デジタル署名や暗号化に対するWebサービスの要件、および必要なセキュリティ・アルゴリズムや認証メカニズムを指定します。
WS-Policyフレームワークを使用すると、他の仕様で「ポリシー・アサーション」を宣言できます。ポリシー・アサーションは、<policy>
要素内に示されるドメイン固有のXML要素です。ポリシー・アサーションの仕様は、このドメイン固有のアサーションの構文とセマンティクスを記述します。
WS-SecurityPolicyは、ドメイン固有のアサーション言語の一例です。WS-SecurityPolicy仕様は、WS-Policyフレームワークで使用する一連のセキュリティ・ポリシー・アサーションを定義しています。
WS-ReliableMessagingは、ドメイン固有のアサーション言語のもう1つの例であり、信頼性のあるメッセージング・ポリシーを宣言するためのアサーションを定義しています。
Webサービス・セキュリティ(WS-Security)は、Webサービス・ポリシー・フレームワーク(WS-Policy)と連動して機能します。次の用語の意味とこれらがどのように関係するのかを理解することが重要です。
Webサービス・セキュリティ(WS-Security)はOASIS標準の1つです。SOAPメッセージにメッセージ・レベルのセキュリティを組み込むための相互運用可能なメカニズムを定義しています。WS-Securityによって、メッセージ・レベルのセキュリティが「どのように」 SOAPメッセージに組み込まれるかが決まります。
WS-Securityは、メッセージの整合性と機密性をサポートします。また、SOAPエンベロープにセキュリティ・トークンを含める拡張モデルや、SOAPエンベロープ内からセキュリティ・トークンを参照するモデルも定義しています。WS-Securityでは、SOAPメッセージのどの部分をデジタル署名または暗号化するかを指定できます。
Webサービス・ポリシー・フレームワーク(WS-Policy)は、Webサービスのポリシーを記述して通信するための汎用モデルとその構文を提供します。WS-Policyは、抽象XMLフレームワークです。WS-Policyの特徴は、ポリシー「アサーション」と呼ばれる子要素です。
WS-SecurityPolicyは、WS-Policyのセキュリティ面を指定するためのアサーションを定義します。WS-SecurityPolicyは、SOAPメッセージで「どの」メッセージ・レベルのセキュリティが必要かを決定します。
ポリシーでは、セキュリティで保護する操作と、Webサービス・クライアントが適用する必要があるセキュリティ対策を決定できます。
プロキシ・サービスまたはビジネス・サービスのWS-Policyを構成するときに、WS-Policyに1つまたは複数のセキュリティ・ポリシー・アサーションが含まれている場合、プロキシ・サービスまたはビジネス・サービスは、WS-Securityが有効になっていると見なされます。
WS-Policy仕様に基づいて(Oracle独自のセキュリティ・ポリシー・スキーマを使用して)記述されたセキュリティ・ポリシー・アサーションの場合、WebLogic Webサービス実行時環境では、2つのタイプのWS-Policy文を認識します。
具象WS-Policy文では、認証、暗号化、およびデジタル署名のために使用されるセキュリティ・トークンを指定します。具象暗号化ポリシーでは、必ず、サーバーの暗号化証明書が、base 64でエンコードされた証明書の形式でX.509バイナリ・セキュリティ・トークンに組み込まれます。
必要な認証のタイプ(X.509またはSAMLトークンの使用など)が設計時にわかっている場合は、具象WS-Policy文を作成できます。
抽象WS-Policy文では、セキュリティ・トークンを指定しません。具体的には、WS-Policyファイルの<Identity>
要素や<Integrity>
要素(またはアサーション)に<SupportedTokens><SecurityToken>
子要素が含まれないこと、およびWS-Policyファイルの<Confidentiality>
要素に<KeyInfo><SecurityToken>
子要素が含まれないことです。
抽象ポリシーが受け取るセキュリティ・トークンのタイプは、Service Busの実行時環境で決定します。
この項では、WS-Policy仕様に基づき、Oracle独自のセキュリティ・ポリシー・スキーマを使用して記述されたセキュリティ・ポリシー・アサーションを使用する際に考慮すべきベスト・プラクティスについて説明します。
注意:
WS-SecurityPolicyを設計する前に、セキュリティ要件を入念に分析してください。このベスト・プラクティスは、特定のビジネス・セキュリティのニーズには当てはまらない可能性もあります。
操作のレスポンス・ポリシーでは、IDアサーションを使用しないでください。結果として、レスポンス・ポリシーでは、定義済のAuth.xml
ポリシーを使用しないでください。
アクティブな仲介プロキシ・サービスに対してインバウンドでWS-Securityユーザー名トークンを使用する場合、ユーザー名/パスワードをバックエンド・サービスに渡すと(ユーザー名/パスワードのパススルー)、ユーザー名トークンには、パスワードをクリア・テキストで含める必要があります。
WS-Securityのユーザー名トークンをクリア・テキストのパスワードで使用する場合、必ずトークン全体を(WS-Securityで)暗号化するか、メッセージをSSLで送信して、ユーザー名トークンの機密性を保護することを強くお薦めします。
IDアサーションを使用する場合は、Integrityアサーションを使用して、機密メッセージ・コンテンツ(SOAP本体およびSOAPヘッダー部分)とともに、認証トークン(ユーザー名、X.509またはSAMLトークン)にデジタル署名することもできます。デジタル署名は、署名されたコンテンツの整合性を保護し、認証トークンとメッセージ・コンテンツをバインドします。これは、第三者による認証トークンの任意のSOAPエンベロープへのコピーと、それによるメッセージの偽造を防止するために重要です(Integrityアサーションを使用する代わりに、SSLを使用してメッセージを送信することもできます)。
Integrityアサーションを使用する場合は、MessageAgeアサーションも使用してください。また、署名トークン(つまり検証証明書)をwsse:Securityヘッダーに含めること、およびデジタル署名で、署名するSOAP本体またはSOAPヘッダー部分に加えて、署名トークンおよびタイムスタンプを対象とすることもお薦めします。MessageAgeアサーションは、タイムスタンプがセキュリティ・ヘッダーに含まれることを保証します。タイムスタンプは、反射攻撃の防止に使用されます。定義済のSign.xml
ポリシーは、このベスト・プラクティスに従っています。
JMSでタイム・スタンプを使用する場合は(MessageAgeアサーション)、MessageAgeアサーションの有効期限を適切に設定するようにしてください。値が小さ過ぎると、キューに置かれている間にメッセージが有効期限切れになる可能性があります。
IDアサーションで、X.509トークンをサポートされるトークン・リストに含める場合は、ポリシーにもIntegrityアサーションを含める必要があります。X.509トークンがデジタル署名で使用されていない場合、サーバーはX.509トークンを認証の証拠として受け入れません。
IDアサーションがその他のトークン・タイプを受け入れる場合、IntegrityアサーションのX509AuthConditional属性を使用して、実際の認証トークンがX.509トークンの場合のみ、デジタル署名を必要とすることを指定できます。抽象IDアサーションは、デプロイ時にあらかじめ処理されており、実行時環境によってサポートされているすべてのトークン・タイプのリストを挿入することで、具象アサーションに変換されます。
ポリシーでは抽象IDアサーションを使用しないことをお薦めします。かわりに、認証でサポートされるトークン・タイプを直接正確に指定するようにしてください。また、IDアサーションでサポートするトークン・タイプは1つのみにすることをお薦めします。
注意:
これにより、サポートされるトークン・タイプがあいまいでなくなるため、IntegrityアサーションのX509AuthConditional属性は不要になります。
結果として、可能なかぎりAuth.xml
ポリシー・ファイルを使用せずに、Sign.xml
およびEncrypt.xml
のポリシーを使用することをお薦めします。
Service Busプロキシがデジタル署名(インバウンド・リクエスト・メッセージまたはバックエンド・レスポンス・メッセージ上)を処理するときは常に、セキュリティ・レルムに証明書レジストリを構成し、取引パートナの証明書をレジストリにインポートすることを強くお薦めします。
ポリシー・サブジェクトは、サービス、エンドポイント、操作、メッセージなどのエンティティであり、これにポリシーを関連付けることができます。1つのWS-Policy文を複数のポリシー・サブジェクトと関連付けることができ、反対に、複数のWS-Policy文を1つのポリシー・サブジェクトを関連付けることができます。ポリシー・スコープは、ポリシーが適用されるポリシー・サブジェクトの集合です。たとえば、wsd:binding/wsdl:operation/wsdl:input
に付加されたポリシーが適用されるポリシー・スコープは、入力メッセージ、操作、エンドポイント、およびサービスです。
特定のポリシー・サブジェクトの 有効ポリシー は、スコープにそのポリシー・サブジェクトを含むすべてのポリシーを結合したものになります。たとえば、バインディング操作の入力メッセージの有効ポリシーは、次に付加されるすべてのポリシーを結合したものになります。
バインディング操作の入力メッセージ
バインディング操作
バインディング
ポートのタイプの操作の入力メッセージ
ポートのタイプの操作
ポートのタイプ
サービス
WS-Policy文を使用してプロキシ・サービスまたはビジネス・サービスを構成した場合、Oracle Service Busコンソールに有効ポリシーが表示されます(読取り専用)。