| Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド 11gリリース1（11.1.1） B56247-01 |
|
 戻る |
 次へ |
この章の内容は次のとおりです。
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 WSM Policy Manager |
メタデータ・ストアの事前定義済ポリシーおよびカスタム・ポリシーを含め、ポリシーの読取り/書込みを行います。 |
|
Oracle WSM Agent |
ポリシー・インターセプタ・パイプラインによるポリシーの強制を管理します。 |
|
ポリシー・インターセプタ |
信頼できるメッセージング、管理、アドレッシング、セキュリティおよびMessage Transmission Optimization Mechanism（MTOM）を含むポリシーを実行します。詳細は、「ポリシー実行の仕組み」を参照してください。 |
|
メタデータ・ストア（MDS） |
ポリシーを格納します。ポリシーは、開発でサポートされているファイルシステムにファイルとして格納することも、本番環境でサポートされているOracle Fusion Middlewareデータベースに格納することもできます。 |
|
Oracle Fusion Middlewareデータベース |
MDSにデータベース・サポートを提供します。 |
ポリシーでは、メッセージを保護する必要性と保護する方法、メッセージを確実に送信する必要性と確実に送信する方法など、Webサービスの機能および要件を記述します。
Oracle Fusion Middleware 11gリリース1（11.1.1）では、次のタイプのポリシーがサポートされています。
WS-ReliableMessaging: SOAPメッセージの配信を保証し、一連のメッセージの配信順序を維持できるワイヤレベル・プロトコルを記述するWS-ReliableMessaging標準を実装する、信頼できるメッセージング・ポリシー。
このテクノロジは、メッセージが正しい順序で送信されることを保証するために使用できます。メッセージが順序どおりに送信されなかった場合には、メッセージが正しい順序で処理されるように受信システムを構成できます。また、メッセージが最低1回、または1回のみ送信されるようにシステムを構成することも可能です。メッセージが消失した場合は、受信システムが受信を確認するまで、送信システムがメッセージを再送信します。
管理: メッセージ・ログにリクエスト、レスポンスおよびフォルト・メッセージを記録する管理ポリシー。管理ポリシーにはカスタム・ポリシーが含まれます。
WS-Addressing: 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形式のイメージなどのバイナリ・コンテンツを受渡しできます。受渡しを可能にするために、バイナリ・コンテンツは通常、xsd:base64Binary文字列としてXMLドキュメントに挿入されます。この形式でバイナリ・コンテンツを送信すると、ネットワーク経由で送信されるメッセージのサイズが大幅に増加し、必要な処理領域と時間も増加します。
Message Transmission Optimization Mechanism（MTOM）を使用すると、バイナリ・コンテンツをMIME添付ファイルとして送信でき、ネットワークでの送信サイズが小さくなります。バイナリ・コンテンツは意味的にXMLドキュメントの一部です。MTOMポリシーを添付すると、Webサービスやクライアントに送信される前に、メッセージがMIME添付ファイルに変換されます。
ポリシーは、ポリシーの一元的な作成と管理を可能にする、Oracle WSMエンタープライズ・ポリシー・フレームワークの一部です。
ポリシーは、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サービス側にも対応するポリシー（たとえばポリシーの復号化）が存在する必要があります。存在しない場合、メッセージ・リクエストが失敗します。
サービス・コンシューマ（クライアントとも呼ばれる）からサービス・プロバイダ（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 1.0および1.1の両方をサポートする）WS-Security仕様で説明されているいくつかのセキュリティ・トークン・タイプに、WS-SecurityPolicyポリシーを設定する方法の例を説明するシナリオを定義します。Oracle WSMの事前定義済ポリシーでは、最も一般的な顧客のユース・ケースを表すWS-SecurityPolicyシナリオのサブセットがサポートされています。 |
複数のクライアントで同じポリシーを使用することもできます。各クライアントのポリシー構成要件（ユーザー名やパスワードなど）は異なる場合があります。
Oracle WSMポリシー構成のオーバーライド機能により、ユーザーは各クライアントに新しいポリシーを作成しなくても、クライアントごとに構成を更新できます。この方法では、デフォルトの構成値を定義し、実行時の要件に基づいてその値をカスタマイズするクライアント・ポリシーを作成できます。たとえば、クライアントごとに情報が異なる場合があることから、クライアント・ポリシーを構成するときにユーザー名とパスワードを指定することもできます。
クライアント・セキュリティ・ポリシー構成のオーバーライドの詳細は、「オーバーライド可能なクライアント・ポリシーの添付」を参照してください。
「カスタム・アサーションの作成」で説明されているように、カスタム・アサーションの作成時に構成プロパティをオーバーライド可能にするかどうかを定義できます。
ディレクトリ、ポリシーおよびアサーション・テンプレートの名前に使用できる文字は次のとおりです。
大文字および小文字
数字
通貨記号（$）
アンダースコア（_）
ハイフン（-）
空白
|
注意: 名前の先頭に、ハイフンまたは空白を使用することはできません。 |
一目で何をするポリシーかがわかるように、ポリシー名には可能なかぎり情報を含めることをお薦めします。たとえば、Oracle Fusion Middleware 11gリリース1（11.1.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トークン
oam_token: Oracle Access Managerトークン
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
