| Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド 11g リリース1(11.1.1.7) B56247-06 |
|
 戻る |
 次へ |
この章の内容は次のとおりです。
Oracle Web Services Manager(WSM)には、組織全体で一貫してWebサービスを管理および保護するためのポリシー・フレームワークが備わっています。Oracle WSMは、開発者が設計時に使用することも、システム管理者が本番環境で使用することも可能です。
ポリシー・フレームワークは、WS-Policy標準を使用して作成されています。Oracle WSMのポリシー強制ポイント(PEP)は、次の図のように、認証および権限ベースの認可にOracle Platform Security Service(OPSS)とOracle WebLogic Server認証プロバイダを活用します。
図3-1 OPSSおよびOracle WebLogic Serverセキュリティを活用するOracle WSMのポリシー・フレームワーク
開発者は、Oracle JDeveloperからOracle WSMのポリシー・フレームワークを使用できます。詳細は、Oracle JDeveloperのオンライン・ヘルプにあるWebサービスでの開発に関する項を参照してください。
システム管理者は、Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle WSMで次のことを実行できます。
Oracle WSM Policy Managerを使用して、ポリシーを一元的に定義。
Oracle WSMのセキュリティおよび管理ポリシーを実行時にローカルで実行。
管理者は、Oracle Enterprise Manager Fusion Middleware ControlからOracle WSMのすべての機能にアクセスできます。セキュリティ・タスクと管理タスクの詳細は、第II部「基本管理」および第III部「高度な管理」を参照してください。
次に、Oracle WSMを使用して実行できる特定タスクの例を示します。
WS-Securityの処理(暗号化、復号化、署名、署名検証など)
LDAPディレクトリに対する認証および認可ポリシーの定義。
複数のWebサービス全体に単一トランザクションで使用されるアイデンティティを伝播するための標準セキュリティ・トークン(SAMLトークンなど)の生成。
様々なフォルダにポリシーを作成することによる、異なるネームスペースへのポリシーのセグメント化。
ログ・ファイルの調査。
図3-2に、Oracle WSMアーキテクチャの主なコンポーネントを示します。
表3-1に、前述の図に示されているOracle WSMのコンポーネントを説明します。
表3-1 Oracle WSMアーキテクチャのコンポーネント
| Oracle WSMのコンポーネント | 説明 |
|---|---|
|
Oracle Enterprise Manager Fusion Middleware Control |
管理者がOracle WSMの機能にアクセスして、Webサービスを管理、保護および監視できるようにします。 |
|
Oracle JDeveloper |
Webサービスのエンドツーエンド開発に使用できるフル機能のSOA用Java IDEを提供します。開発者は、ビジュアルな宣言型ツールを使用してOracle SOA、ADF、WebCenterおよびWebLogic Java EE Webサービスを構築し、それらをOracle WebLogic Serveのインスタンスに自動的にデプロイして、ただちにWebサービスの動作をテストできます。また、JDeveloperを使用して、WSDL記述からWebサービスの作成を行うこともできます。JDeveloperはAntに対応しています。このツールを使用して、クライアントのアセンブルおよびサービスのアセンブルとデプロイを行うAntスクリプトを作成し、実行できます。詳細は、Oracle JDeveloperのオンライン・ヘルプを参照してください。JDeveloperのインストールの詳細は、『Oracle Fusion Middleware Oracle JDeveloperインストレーション・ガイド』を参照してください。 |
|
WebLogic Scripting Tool(WSLT) |
管理者がWebサービスを表示、構成し、コマンドラインからWebサービス・ポリシーを管理できるようにします。詳細は、WebLogic Scripting Toolコマンド・リファレンスを参照してください。 |
|
Oracle WSM Policy Manager |
Oracle WSMリポジトリの事前定義済ポリシーやカスタム・ポリシーなど、ポリシーの読取り/書込みを行います。 |
|
Oracle WSMエージェント |
ポリシー・インターセプタ・パイプラインによるポリシーの強制を管理します。 |
|
ポリシー・インターセプタ |
信頼できるメッセージング、管理、アドレッシング、セキュリティおよびMessage Transmission Optimization Mechanism(MTOM)を含むポリシーを実行します。詳細は、「ポリシー実行の仕組み」を参照してください。 |
|
Oracle WSMリポジトリ |
ポリシー、ポリシー・セット、アサーション・テンプレートおよびポリシーの使用状況データなどのOracle WSMメタデータを格納します。Oracle WSMリポジトリは、データベースとして(本番用)またはファイル・システム内のファイルとして(JDeveloperでの開発用)利用できます。 |
|
Oracle Fusion Middlewareデータベース |
Oracle WSMリポジトリのデータベース・サポートを提供します。 |
ポリシーでは、メッセージを保護する必要性と保護する方法、メッセージを確実に送信する必要性と確実に送信する方法など、Webサービスの機能および要件を記述します。
Oracle Fusion Middleware 11gリリース1では、表3-2で定義されているポリシー・タイプがサポートされています。ポリシーは、ポリシーの一元的な作成と管理を可能にする、Oracle WSMエンタープライズ・ポリシー・フレームワークの一部です。
表3-2 ポリシーのタイプ
| ポリシー・タイプ | 説明 |
|---|---|
|
WS信頼できるメッセージング |
SOAPメッセージの配信を保証し、一連のメッセージの配信順序を維持できるワイヤレベル・プロトコルを記述するWS-ReliableMessaging標準を実装する、信頼できるメッセージング・ポリシー。 このテクノロジは、メッセージが正しい順序で送信されることを保証するために使用できます。メッセージが順序どおりに送信されなかった場合には、メッセージが正しい順序で処理されるように受信システムを構成できます。また、メッセージが最低1回、または1回のみ送信されるようにシステムを構成することも可能です。メッセージが消失した場合は、受信システムが受信を確認するまで、送信システムがメッセージを再送信します。 |
|
管理 |
メッセージ・ログにリクエスト、レスポンスおよびフォルト・メッセージを記録する管理ポリシー。管理ポリシーにはカスタム・ポリシーが含まれます。 |
|
WSアドレス |
SOAPメッセージに、WS-Addressing仕様に準拠したWS-Addressingヘッダーが含まれることを検証するWS-Addressingポリシー。情報の伝達はネットワーク・レベルの転送に依存しておらず、トランスポート・レベルのデータはXMLメッセージに含まれます。 |
|
セキュリティ |
WS-Security 1.0および1.1標準が実装されたセキュリティ・ポリシー。メッセージの保護(メッセージ整合性とメッセージ機密保護)と、Webサービスのリクエスタおよびプロバイダの認証と認可が実行されます。ユーザー名トークン、X.509証明書、KerberosチケットおよびSecurity Assertion Markup Language(SAML)アサーションなどのトークン・プロファイルがサポートされています。Webサービス・セキュリティの概念および標準の詳細は、「Webサービス・セキュリティの概念について」および「Webサービス・セキュリティ標準」を参照してください。 |
|
Message Transmission Optimization Mechanism(MTOM) |
クライアントとWebサービス間で、JPEG形式のイメージなどのバイナリ・コンテンツを受渡しできます。受渡しを可能にするために、バイナリ・コンテンツは通常、 Message Transmission Optimization Mechanism(MTOM)を使用すると、バイナリ・コンテンツをMIME添付ファイルとして送信でき、ネットワークでの送信サイズが小さくなります。バイナリ・コンテンツは意味的にXMLドキュメントの一部です。MTOMポリシーを添付すると、Webサービスやクライアントに送信される前に、メッセージがMIME添付ファイルに変換されます。 |
ポリシーは、1つ以上のポリシー・アサーションで構成されています。ポリシー・アサーションは、リクエスト操作とレスポンス操作のための特定のアクションを実行するポリシーの最小単位です。ポリシーなどのアサーションは、信頼できるメッセージング、管理、WS-Addressing、セキュリティ、およびMTOMのいずれかのカテゴリに属します。
ポリシー・アサーションは、パイプライン内で連鎖しています。ポリシー内のアサーションは、リクエスト・メッセージおよびレスポンス・メッセージで実行され、どちらのタイプのメッセージでも同じアサーションのセットが実行されます。アサーションは、パイプライン内での順序で実行されます。
図3-3に、一般的な実行フローを示します。リクエスト・メッセージの場合、アサーション1が最初に実行され、アサーション2およびアサーションnがそれに続きます。レスポンス・メッセージで同じアサーションが実行されることもありますが(レスポンスが戻される場合)、レスポンス・メッセージで実行されるアクションはリクエスト・メッセージとは異なっており、アサーションが逆の順序で実行されます。図3-3のレスポンス・メッセージの場合、アサーションnが最初に実行され、アサーション2、アサーション1がそれに続きます。
たとえば、図3-4では、ポリシーに2つのアサーションが含まれています。
wss11-username-with-certificates: wss11_username_token_with_message_protection_service_templateを使用して作成されており、WS-Security UsernameToken SOAPヘッダーの資格証明に基づき、ユーザーを認証します。
binding-authorization: binding_authorization_templateを使用して作成されており、SOAPバインディング・レベルの認証されたサブジェクトに基づき、リクエストに対して簡単なロールベースの認可を行います。
リクエスト・メッセージがWebサービスに送信されると、表示されている順序でアサーションが実行されます。レスポンス・メッセージがクライアントに返されると、同じアサーションが実行されますが、順序は逆です。リクエスト・メッセージに対するアサーションの動作は、レスポンス・メッセージの動作とは異なります。インスタンスによっては、レスポンスで何も発生しない場合があります。たとえば前述の例では、認可アサーションはリクエストの一部としてのみ実行されます。
ポリシー・サブジェクトは、ポリシーを添付するターゲット・リソースです。ポリシー・サブジェクトには、Webサービス・エンドポイント、Webサービス・クライアント、SOAサービス・エンドポイント、SOAクライアントおよびSOAコンポーネントが含まれます。異なるリソースのタイプ(WebサービスまたはSOAコンポーネントなど)には異なるポリシーがあります。
個々のポリシーをサブジェクトに個別に添付するか、一括添付を使用することにより、ポリシー・サブジェクトに1つ以上のポリシーを添付できます。ポリシー・セットを使用すると、サブジェクトのセットにポリシーをグローバルに添付することもできます。詳細は、「ポリシー・セットを使用したポリシーのグローバルなアタッチ」を参照してください。ポリシーをポリシー・サブジェクトに添付すると、ポリシーがすぐに有効化されます。
クライアント側のポリシーによってメッセージが変更される場合(たとえばメッセージの暗号化)、Webサービス側にも対応するポリシー(たとえばポリシーの復号化)が存在する必要があります。存在しない場合、メッセージ・リクエストが失敗します。
|
注意: ポリシー・セットは、Oracle Infrastructure Webサービスでのみサポートされます。 |
ポリシー・セットとは、内部に複数のポリシー参照を格納し、同じタイプの一連のエンドポイントに対してグローバルにポリシーを添付する手段を提供する抽象表現の1つです。ポリシー・セットを使用してグローバルにポリシーを添付することで、開発者、アセンブラまたはデプロイヤがポリシーのアタッチを明示的に指定しなかった状況でも、管理者はすべてのサブジェクトのセキュリティを確実に確保できます。ポリシー・セットを使用してアタッチされるポリシーは、外部的にアタッチされたと見なされます。ポリシー・セットを使用してポリシーをグローバルに添付する方法の詳細は、第9章「ポリシー・セットの作成および管理」を参照してください。
サービス・コンシューマ(クライアントとも呼ばれる)からサービス・プロバイダ(Webサービスとも呼ばれる)にリクエストが行われると、リクエストは1つ以上のポリシー・インターセプタによりインターセプトされます。これらのインターセプタにより、クライアントおよびWebサービスに添付されたポリシーが実行されます。インターセプタには、連携してポリシー・インターセプタ・チェーンを形成する5つのタイプ(信頼できるメッセージング、管理、WS-Addressing、セキュリティおよびMTOM)があります。各インターセプタは、同じタイプのポリシーを実行します。セキュリティ・インターセプタはセキュリティ・ポリシーを、MTOMインターセプタはMTOMポリシーをインターセプトして実行します。
クライアントまたはWebサービスに添付されたポリシーは、図3-5に示されるように、ポリシー・インターセプタ・パイプラインによって特定の順序で実行されます。
前述の図に示されているように、クライアントまたはWebサービスによりメッセージが開始されると、クライアントの場合のリクエスト・メッセージであってもWebサービスの場合のレスポンス・メッセージであっても、ポリシーは、信頼できるメッセージング、管理、アドレッシング、セキュリティ、MTOMの順序でインターセプトされます。クライアントまたはWebサービスがメッセージを受信する、つまり、Webサービスの場合はリクエスト・メッセージ、クライアントの場合はレスポンス・メッセージを受信すると、ポリシーは、MTOM、セキュリティ、アドレッシング、管理、および信頼できるメッセージングという逆の順序で実行されます。
メッセージには、1つ以上のポリシーが添付されている場合があります。すべてのメッセージに各タイプのポリシーが含まれるわけではありません。メッセージに含まれるのが、セキュリティ・ポリシーとMTOMポリシーの場合もあります。この場合、セキュリティ・インターセプタはセキュリティ・ポリシーを実行し、MTOMインターセプタはMTOMポリシーを実行します。この例では、その他のインターセプタはメッセージの処理に関わりません。
次に、クライアントとWebサービス間のメッセージで、ポリシー・インターセプタがどのように動作するかを説明します。(図3-5を参照。)
クライアントがWebサービスにリクエスト・メッセージを送信します。
ポリシー・インターセプタが、クライアントに添付されたポリシーをインターセプトおよび実行します。クライアント・ポリシーが正常に実行されると、リクエスト・メッセージがWebサービスに送信されます。
リクエスト・メッセージがポリシー・インターセプタによりインターセプトされ、Webサービスに添付されたサービス・ポリシーが実行されます。
サービス・ポリシーが正常に実行されたら、リクエスト・メッセージがWebサービスに渡されます。Webサービスによりリクエスト・メッセージが実行され、レスポンス・メッセージが戻されます。
レスポンス・メッセージがポリシー・インターセプタによりインターセプトされ、Webサービスに添付されたサービス・ポリシーが実行されます。サービス・ポリシーが正常に実行されたら、レスポンス・メッセージがクライアントに送信されます。
レスポンス・メッセージがポリシー・インターセプタによりインターセプトされ、クライアントに添付されたクライアント・ポリシーが実行されます。
クライアント・ポリシーが正常に実行されたら、レスポンス・メッセージがクライアントに渡されます。
Oracle Fusion Middlewareをインストールすると自動的に使用可能になる、一連の事前定義済ポリシーとアサーション・テンプレートがあります。事前定義済ポリシーは、顧客のデプロイで使用される一般的なベスト・プラクティス・ポリシーのパターンに基づいています。
これらの事前定義済ポリシーは、Webサービスやクライアントにすぐに添付できます。事前定義済ポリシーを構成することも、事前定義済ポリシーのいずれかをコピーして新しいポリシーを作成することもできます。
事前定義済ポリシーは、事前定義済アサーション・テンプレートに基づくアサーションを使用して作成されています。必要に応じて、新しいアサーション・テンプレートを作成できます。
事前定義済ポリシーおよびアサーション・テンプレートの詳細は、次の項を参照してください。
|
注意: WS-SecurityPolicyは、WS-Security仕様(WS-Security1.0と1.1の両方をサポート)で説明される、複数のセキュリティ・トークンのタイプに対してWS-SecurityPolicyポリシーを設定する方法の例を説明する、シナリオを定義します。Oracle WSMの事前定義済ポリシーでは、最も一般的な顧客のユース・ケースを表すWS-SecurityPolicyシナリオのサブセットがサポートされています。 |
ポリシー強制に複数の選択肢を定義するには、サービス・ポリシー内にORグループと呼ばれるアサーションのセットを定義します。実行時には、サービス側でORグループに定義したアサーションに基づいて、強制するアサーションをクライアントが柔軟に選択できます。
たとえば、サービス側ポリシーで次のアサーションで構成されるORグループを定義するとします。
wss11-saml-with-certificates
wss11-username-with-certificates
クライアントは実行時に、wss11-saml-with-certificatesアサーションまたは(OR)wss11-username-with-certificatesアサーションのどちらを強制するかを選択できます。
ORグループに含めることのできるアサーションの数に制限はありません。ORグループ内のアサーションのセットで、リクエスト・メッセージが最初のアサーションに一致した場合、最初のアサーションが実行され、対応するレスポンスが送信されます。
各アサーションがそのポリシーに有効であり、ポリシーの要件を満たしている必要があります。たとえば、他にセキュリティ・アサーションを含み、セキュリティを強制するように設計されているORグループに、ログ・アサーションを含めてはいけません。この場合、セキュリティ・アサーションに不具合が生じた場合にログ・アサーションが渡され、結果としてセキュリティがなくなります。
ORグループを定義するとき、アサーションが追加される順序と構成される設定について慎重に検討します。たとえば、次の状況を想定します。
クライアントの側でInclude Timestampを有効化した状態で、wss11_username_token_with_message_protection_client_policyポリシーを添付しました。
サーバーの側で、2つのwss11_username_token_with_message_protection_service_templateアサーションを定義した状態でカスタムORグループ・ポリシーを添付しました。1つ目ではInclude Timestampが無効になっており、2つ目ではInclude Timestampが有効になっています。
このシナリオでは、1つ目のアサーションが実行されると、レスポンスはタイムスタンプなしで送信されます。その結果として、タイムスタンプが予期されているために、クライアントの側での処理は失敗します。このような状況は、クライアント・ポリシー・アサーションで、実行されたクライアント・ポリシー・アサーションよりも多くのセキュリティ要件が予期されるたびに発生します。
次の事前定義済サービス・ポリシーは、ORグループを含みます。
oracle/wss_saml_or_username_token_over_ssl_service_policy: 詳細は、「oracle/wss_saml_or_username_token_over_ssl_service_policy」を参照してください。
oracle/wss_saml_or_username_token_service_policy: 詳細は、「oracle/wss_saml_or_username_token_service_policy」を参照してください。
oracle/wss11_saml_or_username_token_with_message_protection_service_policy: 詳細は、「oracle/wss11_saml_or_username_token_with_message_protection_service_policy」を参照してください。
oracle/multi_token_rest_service_policy: 詳細は、「oracle/multi_token_rest_service_policy」を参照してください。
oracle/multi_token_over_ssl_rest_service_policy: 詳細は、「oracle/multi_token_over_ssl_rest_service_policy」を参照してください。
複数のWebサービスおよびWebクライアントで同じポリシーを使用することもできます。それぞれのポリシー構成要件(ユーザー名やパスワードなど)は異なる場合があります。
Oracle WSMポリシー構成のオーバーライド機能により、ユーザーは各サービスまたはクライアントに新しいポリシーを作成しなくても、サービスまたはクライアントごとに構成を更新できます。この方法により、デフォルトの構成値を定義するポリシーを作成しておき、その値を実行時の要件に基づいてカスタマイズできます。
たとえば、クライアントごとに情報が異なる場合があることから、クライアント・ポリシーを構成するときにユーザー名とパスワードを指定することもできます。
セキュリティ・ポリシー構成のオーバーライドの詳細は、「オーバーライド可能なクライアント・ポリシーの添付」および「オーバーライド可能なWebサービス・ポリシーの添付」を参照してください。
Oracle Web Services Manager拡張性ガイドのカスタム・アサーションの作成に関する項で説明されているように、カスタム・アサーションの作成時に構成プロパティをオーバーライド可能にするかどうかを定義できます。
ディレクトリ、ポリシーおよびアサーション・テンプレートの名前に使用できる文字は次のとおりです。
大文字および小文字
数字
通貨記号($)
アンダースコア(_)
ハイフン(-)
空白
|
注意: 名前の先頭に、ハイフンまたは空白を使用することはできません。 |
一目で何をするポリシーかがわかるように、ポリシー名には可能なかぎり情報を含めることをお薦めします。たとえば、Oracle Fusion Middleware 11gリリース1に提供されている事前定義済セキュリティ・ポリシーの1つは、oracle/wss10_username_token_with_message_protection_service_policyという名前です。図3-6で、この事前定義済ポリシー名の各部分を確認します。
事前定義済ポリシーに名前を付ける際には、次の表記規則が使用されます。ポリシー名の各部分は、アンダースコア文字(_)で区切られます。
パスの場所 - すべてのポリシーは、ポリシーが存在するディレクトリによって識別されます。製品に提供されているすべての事前定義済ポリシーは、oracleディレクトリにあります。
Webサービス標準 - ポリシーでWS-Security標準が使用されている場合は、wss10(WS-Security 1.0)またはwss11(WS-Security 1.1)で識別されます。また、WS-Security 1.0または1.1に依存しないことを示すために、単にwssと設定することも可能です。
認証トークン - ポリシーでユーザーを認証する場合は、トークンのタイプを指定します。事前定義済オプションは次のとおりです。
http_token - HTTPトークン
kerberos_token - Kerberosトークン
saml_token - SAMLトークン
username_token - ユーザー名およびパスワードのトークン
x509_token - X.509証明書トークン
カスタムの認証トークンを定義することもできます。
トランスポート・セキュリティ - ポリシーで、安全なトランスポート・レイヤーでのメッセージ送信が要求されている場合は、wss_http_token_over_ssl_client_templateなどのように、トークン名にover_sslが付けられます。
メッセージ保護 - ポリシーでメッセージの機密保護およびメッセージ整合性も提供されている場合は、図3-6にあるように、with_message_protectionというフレーズを使用してこのことが示されます。
ポリシー・タイプ - clientまたはserviceによって、ポリシーやアサーション・テンプレートのタイプを示します。ポリシーであることを示す場合はpolicyを、アサーション・テンプレートであることを示す場合はtemplateを使用します。次に、事前定義済ポリシーとテンプレート・アサーションの区別の例を示します。
wss10_message_protection_service_policy
wss10_message_protection_service_template
どのような表記規則を適用する場合でも、ポリシー名の付け方を十分に検討することをお薦めします。これにより、エンタープライズが成長して新しいポリシーを作成する場合に、ポリシーの追跡が簡単になります。
作成するポリシーは、事前定義済ポリシーが存在するoracleディレクトリとは別のディレクトリに保存することをお薦めします。ポリシーは、ルート・レベル、oracle以外のディレクトリ、またはサブディレクトリで管理できます。たとえば、次のいずれも有効です。
wss10_message_protection_service_policy
oracle/hq/wss10_message_protection_service_policy
hq/wss10_message_protection_service_policy
|
注意: ポリシー名に接頭辞「oracle_」を使用することは、ベスト・プラクティスとしてお薦めしません。 |
