ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Web Services Managerの理解
12c(12.1.2)
E47995-01
  目次へ移動
目次
前
前 		 次
次		  

2 OWSMポリシー・フレームワークの理解

この章では、組織全体でのWebサービスの一貫性のある管理と保護を実現するOWSMポリシー・フレームワークについて説明します。

この章の構成は、次のとおりです。

2.1OWSMポリシー・フレームワークの概要

Oracle Web Services Manager (OWSM)には、組織全体でのWebサービスの一貫性のある管理と保護を実現するポリシー・フレームワークが備わっています。これは、セキュリティ、信頼できるメッセージング、MTOM、アドレス・ポリシーなどのWebサービス・ポリシーを構築、施行、実行および監視する機能を提供します。OWSMは、設計時に開発者が使用することも、本番環境で管理者が使用することもできます。

ポリシー・フレームワークは、WS-Policy標準を使用して作成されています。OWSMのポリシー強制ポイント(PEP)は、図2-1のように、認証および権限ベースの認可にOracle Platform Security Service (OPSS)およびOracle WebLogic Serverオーセンティケータを活用します。

図2-1 OPSSおよびOracle WebLogic Serverセキュリティを活用するOWSMポリシー・フレームワーク

図2-1の説明が続きます。
「図2-1 OPSSおよびOracle WebLogic Serverセキュリティを活用するOWSMポリシー・フレームワーク」の説明

2.1.1 OWSMポリシー・フレームワークのコンポーネント

OWSMポリシー・フレームワークは次のコンポーネントで構成されます。

  • ポリシー・マネージャは、OWSMリポジトリの事前定義されたポリシーやカスタム・ポリシーなどの、ポリシーの読取りと書込みを行います。ポリシー・マネージャは個別の管理対象サーバーにデプロイできます。

  • エージェントは、ポリシーの施行、実行、およびランタイム統計の収集を行います。OWSMエージェントは、Oracle Fusion Middlewareのすべての管理対象サーバー上で使用できます。これは、保護対象のアプリケーションと同じサーバー上で構成されます。

    OWSMエージェントは、jarファイルのセットで構成され、このセットが基盤のWebサービス・スタックの一部となります。これには、セッションの状態はありません。エージェントは、メモリー内ポリシー・キャッシュを保持し、これがエージェントの起動時に移入されます。JTAまたはJMSは使用しません。

    OWSMエージェントは次の2つの部分で構成されます。

    • ポリシー・アクセス・ポイント(PAP)は、ポリシー・マネージャと通信します。エージェントは、EJBを起動することによって、ポリシー・マネージャと通信します。

    • ポリシー・インターセプタは、Webサービスがデプロイされてアクティブ化されたとき、またはポリシーがEnterprise Managerを使用してWebサービスにアタッチされたときに生成されます。新たなWebサービスがOWSMを使用して保護された場合は、各新規Webサービスに対してインターセプタの追加インスタンスが生成されます。インターセプタは、ポリシーを施行します。

  • OWSMリポジトリ・ポリシーはOWSMリポジトリに格納されます。通常は、Oracle Databaseがバックエンドで使用されます。高可用性を確保するため、OWSMリポジトリのバックエンドとしてOracle RACデータベースを使用することをお薦めします。

  • OWSMの構成には、Enterprise Managerが使用されます。OWSMによって収集された様々なWebサービス・メトリックも表示されます。

2.1.2 OWSMエージェントとポリシー・マネージャの相互作用

OWSMエージェントとOWSMポリシー・マネージャの相互作用の概要は、図2-2のようなものになります。

OWSMエージェントは、ドメインの少なくとも1つのノードにOWSMポリシー・マネージャがデプロイされていることを前提として動作します。

図2-2 OWSMエージェントとポリシー・マネージャの相互作用

図2-2の説明が続きます。
「図2-2 OWSMエージェントとポリシー・マネージャの相互作用」の説明

ポリシー・マネージャは、ステートレス・アプリケーションであり、キャッシュは一切行いません。ポリシー・マネージャがデプロイされている管理対象サーバーの起動時に実行される、アプリケーション・レベルの特別な起動シーケンスはありません。ポリシー・マネージャは、OWSMリポジトリと通信してポリシーを取得します。OWSMリポジトリをデータベースに格納することによって、MDSの高可用性を実現できます。

OWSMエージェントは、OWSMポリシー・マネージャを検出して接続するための自動検出機能を備えています。また、リモートのポリシー・マネージャに接続するように、エージェントを明示的に構成することもできます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のOWSMポリシー・アクセスの構成に関する項を参照してください。

エージェントは、ポリシー・マネージャに接続すると、最新バージョンのポリシーをダウンロードし、キャッシュします。エージェントが起動して実行されると、構成可能な間隔に基づいて定期的にキャッシュのリフレッシュが試行されます。デフォルトの時間は10分ごとです。

高可用性シナリオでは、OWSMアプリケーションのターゲットを複数のノードに設定する場合、個々の管理対象サーバーではなく、クラスタをターゲットにします。

OWSMによって保護されているWebサービスが管理対象サーバーにデプロイされているときに、OWSMエージェントが起動時にどのポリシー・マネージャとも通信できない場合、Webサービスの呼出しは失敗します。

2.1.3 OWSMエージェントとポリシー・マネージャの特性

OWSMエージェントは、Webサービス・スタック内のOracle Fusion Middlewareのすべての管理対象サーバーで使用可能な.jarファイルのセットです。

ポリシー・マネージャは、wsm-pm.earファイルに格納されます。OWSMで提供されるサービスはいずれもシングルトンではないため、完全なアクティブ/アクティブ・モードで実行可能です。OWSMサービスは、http://host:port/wsm-pm/validatorで検証できます。このバリデータには、OWSMポリシーが表示されます。

OWSMエージェントとOracle Enterprise Managerは、EJBインタフェースを使用してポリシー・マネージャと対話します。OWSMで使用されるEJBはステートレスであり、クラスタ化された環境にデプロイできます。そのため、クラスタ内で状態のレプリケーションを有効化するための要件はありません。

OWSMエージェントとポリシー・マネージャを同じ場所に配置する必要はありません。ただし、エージェントは、ポリシー・マネージャがドメインの最低1つのノードにデプロイされていることを前提として動作します。OWSMエージェントには、ドメインにデプロイされているポリシー・マネージャを自動検出する機能があります。

外部依存性

OWSMポリシー・マネージャは次のコンポーネントに依存します。

  • ポリシーを格納するためのOWSMリポジトリ

  • OWSMエージェントは、OWSMポリシー・マネージャにのみ依存します。

OWSMが適切に起動し、稼働するためには、この両方のコンポーネントが使用可能である必要があります。

2.1.4 OWSMエージェントとポリシー・マネージャのリクエスト・フロー

クライアント・アプリケーションが保護されたWebサービスにアクセスすると、OWSMエージェントがポリシー・キャッシュへの問合せを実行して、適切なポリシーを施行します。リクエストの認証、暗号化、復号化、認可またはログは、ポリシーに基づいて行われます。これらの操作のいずれについても、ポリシー・マネージャへの接続は行われません。

ポリシー・マネージャの実行時の可用性は、通常、OWSMエージェントの機能には影響しません。ただし、OWSMによって保護された新しいWebサービスのデプロイや既存のWebサービスへの新規ポリシーのアタッチなどの構成変更が行われた場合は、可用性による影響が生じます。このような構成変更があった場合、OWSMエージェントは、ポリシー・マネージャに接続して適切なポリシーを取得する必要があります。初期起動後に接続できない場合は、キャッシュされているポリシーに基づいて動作し続けます。

2.1.5 OWSM構成アーティファクト

Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のOWSMドメイン構成の管理に関する項で説明しているように、次のような設定を指定できます。

  • ポリシー・マネージャのURL(構成されている場合)。

  • キャッシュ・リフレッシュ間隔

  • 時間誤差(クライアントとサーバーのシステム・クロックの誤差を許容します)。

これらのオプションは、OWSMエージェント・インストールごとに、Oracle Enterprise Manager Fusion Middleware Controlから設定できます。

OWSMリポジトリの場所のデータ・ソースやアプリケーションのターゲット指定など、コンテナ・レベルの他の構成オプションは、Oracle WebLogic Serverのドメイン構成の一部として保持され、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ全体で同期化されます。

2.2 ポリシーの理解

Webサービス・プロバイダは、サービスが提供される条件(またはポリシー)を定義します。WS-Policyフレームワークを使用すると、OWSMなどのWebサービス・アプリケーションによって処理されるポリシー情報の指定が可能になります。

ポリシーは、Webサービスの機能または要件を表す複数のポリシー・アサーションとして表現されます。たとえば、ポリシー・アサーションは、Webサービスへのリクエストが暗号化されることを規定します。同様に、ポリシー・アサーションでは、Webサービスで受信できる最大メッセージ・サイズを定義できます。

WS-Policyの式は、WS-PolicyAttachment仕様を使用して、様々なWebサービス・コンポーネントと関連付けられます。WS-Policy情報はWSDLファイルに埋込み可能なため、UDDIレジストリを介したWebサービス・ポリシーの公開が簡単になります。

ポリシーは、エンドポイントに直接アタッチできるほか、ポリシー・セットを使用して、デプロイメントの状態を問わず、同じタイプの一連のエンドポイントにグローバルにアタッチできます。


注意:

ポリシー・セットは、RESTful Webサービスおよびクライアントと、Oracle Infrastructure Webサービスおよびクライアントに対してサポートされています。Java EE Webサービスおよびクライアントに対してはサポートされていません。

表2-1は、Oracle Fusion Middleware 12c (12.1.2)がサポートしているポリシー・カテゴリを定義したものです。これらのポリシーは、ポリシーの一元的な作成と管理を可能にするOWSMエンタープライズ・ポリシー・フレームワークの一部です。

表2-1 ポリシー・カテゴリ

ポリシー・カテゴリ 説明 適用対象: SOAP、RESTまたはその両方

アドレス

SOAPメッセージに、WS-Addressing仕様に準拠したWS-Addressingヘッダーが含まれることを検証するWS-Addressingポリシー。情報の伝達はネットワーク・レベルの転送に依存しておらず、トランスポート・レベルのデータはXMLメッセージに含まれます。WS-Addressingの詳細は、「Web Services Addressingの理解」を参照してください。

SOAP

原子性トランザクション

WebLogic Webサービスは、次の仕様のサポートを通じて、WebSphere、Microsoft .NETなどの他の外部トランザクション処理システムとの相互運用を可能にします。

原子性トランザクションの詳細は、Oracle Infrastructure Webサービスの開発のWebサービスの原子性トランザクションの使用に関する項を参照してください。

SOAP

構成

Fast Infoset、スキーマ検証、永続性などのWebサービス機能の構成を可能にする構成ポリシー。

SOAP

管理

メッセージ・ログにリクエスト、レスポンスおよびフォルト・メッセージを記録する管理ポリシー。管理ポリシーにはカスタム・ポリシーが含まれます。

SOAP

メッセージ転送最適化メカニズム(MTOM)アタッチメント

クライアントとWebサービス間で、JPEG形式のイメージなどのバイナリ・コンテンツを受渡しできます。受渡しを可能にするために、バイナリ・コンテンツは通常、xsd:base64Binary文字列としてXMLドキュメントに挿入されます。この形式でバイナリ・コンテンツを送信すると、ネットワーク経由で送信されるメッセージのサイズが大幅に増加し、必要な処理領域と時間も増加します。

MTOMを使用すると、バイナリ・コンテンツをMIME添付ファイルとして送信できるため、ワイヤ書式の送信サイズを小さくできます。バイナリ・コンテンツは意味的にXMLドキュメントの一部です。MTOMポリシーを添付すると、Webサービスやクライアントに送信される前に、メッセージがMIME添付ファイルに変換されます。

SOAP

信頼できるメッセージング

SOAPメッセージの配信を保証し、一連のメッセージの配信順序を維持できるワイヤレベル・プロトコルを記述するWS-ReliableMessaging標準を実装する、信頼できるメッセージング・ポリシー。

このテクノロジは、メッセージが正しい順序で送信されることを保証するために使用できます。メッセージが順序どおりに送信されなかった場合には、メッセージが正しい順序で処理されるように受信システムを構成できます。また、メッセージが最低1回、または1回のみ送信されるようにシステムを構成することも可能です。メッセージが消失した場合は、受信システムが受信を確認するまで、送信システムがメッセージを再送信します。WS-ReliableMessagingの詳細は、「Web Services Reliable Messagingの理解」を参照してください。

SOAP

セキュリティ

WS-Security 1.0および1.1標準が実装されたセキュリティ・ポリシー。メッセージの保護(メッセージ整合性とメッセージ機密保護)と、Webサービスのリクエスタおよびプロバイダの認証と認可が実行されます。ユーザー名トークン、X.509証明書、KerberosチケットおよびSecurity Assertion Markup Language (SAML)アサーションなどのトークン・プロファイルがサポートされています。Webサービス・セキュリティ・トークンの詳細は、「セキュリティ・ポリシーの理解」と「セキュリティ・トークンの理解」を参照してください。

両方

セキュリティ・ポリシーのサブセットがRESTful Webサービスに対してサポートされています。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のRESTful Webサービスに対してサポートされているOWSMポリシーに関する項を参照してください。

SOAP Over JMSトランスポート

SOAP over JMSトランスポートを使用すると、WebサービスとクライアントがHTTP接続ではなくJMS宛先を使用して通信するようになるため、次の利点があります。

  • 信頼性

  • スケーラビリティ

  • サービス品質

SOAP over JMSトランスポートの使用の詳細は、Oracle WebLogic Server JAX-WS Webサービスの開発のSOAP Over JMSトランスポートの使用を参照してください。

SOAP

2.3 ポリシー・アサーションを使用したポリシーの作成

ポリシーは、1つ以上のポリシー・アサーションで構成されています。ポリシー・アサーションは、リクエスト操作とレスポンス操作のための特定のアクションを実行するポリシーの最小単位です。ポリシーなどのアサーションは、信頼できるメッセージング、管理、WS-Addressing、セキュリティ、およびMTOMのいずれかのカテゴリに属します。

ポリシー・アサーションは、パイプライン内で連鎖しています。ポリシー内のアサーションは、リクエスト・メッセージおよびレスポンス・メッセージで実行され、どちらのタイプのメッセージでも同じアサーションのセットが実行されます。アサーションは、パイプライン内での順序で実行されます。


注意:

ORグループを使用したポリシー強制の複数の選択肢の定義の詳細は、第2.3.1項「複数のポリシー選択肢の定義(ORグループ)」を参照してください。

図2-3に、一般的な実行フローを示します。リクエスト・メッセージの場合、アサーション1が最初に実行され、アサーション2およびアサーションnがそれに続きます。レスポンス・メッセージで同じアサーションが実行されることもありますが(レスポンスが戻される場合)、レスポンス・メッセージで実行されるアクションはリクエスト・メッセージとは異なっており、アサーションが逆の順序で実行されます。図2-3のレスポンス・メッセージの場合、アサーションnが最初に実行され、アサーション2、アサーション1がそれに続きます。

図2-3 アサーションを含むポリシー

図2-3の説明が続きます。
「図2-3 アサーションを含むポリシー」の説明

たとえば、図2-4では、ポリシーに2つのアサーションが含まれています。

  1. wss11-username-with-certificates: wss11_username_token_with_message_protection_service_templateを使用して作成され、WS-Security UsernameToken SOAPヘッダーの資格証明に基づいてユーザーを認証します。

  2. binding-authorization: binding_authorization_templateを使用して作成され、SOAPバインディング・レベルの認証されたサブジェクトに基づいてリクエストに対する簡単なロールベースの認可を行います。

図2-4 アサーションが2つ含まれるサンプルのポリシー

図2-4の説明が続きます。
「図2-4 アサーションが2つ含まれるサンプルのポリシー」の説明

リクエスト・メッセージがWebサービスに送信されると、表示されている順序でアサーションが実行されます。レスポンス・メッセージがクライアントに返されると、同じアサーションが実行されますが、順序は逆です。リクエスト・メッセージに対するアサーションの動作は、レスポンス・メッセージの動作とは異なります。インスタンスによっては、レスポンスで何も発生しない場合があります。たとえば前述の例では、認可アサーションはリクエストの一部としてのみ実行されます。

2.3.1 複数のポリシー選択肢の定義(ORグループ)

ポリシー強制に複数の選択肢を定義するには、サービス・ポリシー内にORグループと呼ばれるアサーションのセットを定義します。実行時には、サービス側でORグループに定義したアサーションに基づいて、強制するアサーションをクライアントが柔軟に選択できます。

たとえば、サービス側ポリシーで次のアサーションで構成されるORグループを定義するとします。

  • wss11-saml-with-certificates

  • wss11-username-with-certificates

クライアントは実行時に、wss11-saml-with-certificatesアサーションまたは(OR) wss11-username-with-certificatesアサーションのどちらを強制するかを選択できます。

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 Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/wss_saml_or_username_token_over_ssl_service_policyに関する項を参照してください。

  • oracle/wss_saml_or_username_token_service_policy: 詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/wss_saml_or_username_token_service_policyに関する項を参照してください。

  • oracle/wss11_saml_or_username_token_with_message_protection_service_policy: 詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/wss11_saml_or_username_token_with_message_protection_service_policyに関する項を参照してください。

  • oracle/multi_token_rest_service_policy: 詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/multi_token_rest_service_policyに関する項を参照してください。

  • oracle/multi_token_over_ssl_rest_service_policy: 詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/multi_token_over_ssl_rest_service_policyに関する項を参照してください。

ORグループを含む事前定義済サービス・ポリシーは、次の3つです。

  • oracle/wss_saml_or_username_token_over_ssl_service_policy: 詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/wss_saml_or_username_token_over_ssl_service_policyに関する項を参照してください。

  • oracle/wss_saml_or_username_token_service_policy: 詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/wss_saml_or_username_token_service_policyに関する項を参照してください。

  • oracle/wss11_saml_or_username_token_with_message_protection_service_policy: 詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のoracle/wss11_saml_or_username_token_with_message_protection_service_policyに関する項を参照してください。

2.4 ポリシー・サブジェクトの理解

ポリシー・サブジェクトは、ポリシーのアタッチ先のターゲット・リソースです。Web Services Policy 1.5 Frameworkの仕様(http://www.w3.org/TR/ws-policy/)で定義されているように、ポリシー・サブジェクトは、ポリシーを関連付けることが可能なエンティティ(エンドポイント、メッセージ、リソース、操作など)です。リソースのタイプ(Webサービスなど)に応じた様々なポリシーがあります。

表2-2に、OWSMポリシーをアタッチできるポリシー・サブジェクトを示します。また、この表では、WLSTを使用したポリシー・サブジェクト・タイプの識別に使用される同等の名前を示すとともに、有効なリソース・スコープを示します(これは、「ポリシー・セットを使用したグローバル・ポリシー・アタッチメント」で説明しているポリシー・セットの作成に関連します)。

表2-2 ポリシー・サブジェクトおよびリソース・スコープ

ポリシー・サブジェクト WLST名 有効なリソース・スコープ(ポリシー・セット)

ADF SOAP Webサービス接続

ws-connection

  • ドメイン

  • アプリケーション

  • アプリケーション・モジュールまたは接続

  • 参照またはWebサービス・クライアント

  • ポート

ESS SOAP JOBコールバック

将来使用するために予約されています。

将来使用するために予約されています。

ESS SOAP JOBインボーカ

将来使用するために予約されています。

将来使用するために予約されています。

OSB JCAビジネス・サービス

将来使用するために予約されています。

将来使用するために予約されています。

OSB JCAプロキシ・サービス

将来使用するために予約されています。

将来使用するために予約されています。

OSB RESTfulビジネス・サービス

将来使用するために予約されています。

将来使用するために予約されています。

OSB RESTfulプロキシ・サービス

将来使用するために予約されています。

将来使用するために予約されています。

OSB SOAPビジネス・サービス

将来使用するために予約されています。

将来使用するために予約されています。

OSB SOAPプロキシ・サービス

将来使用するために予約されています。

将来使用するために予約されています。

RESTfulクライアント

rest-client

  • ドメイン

  • アプリケーション

  • アプリケーション・モジュールまたは接続

  • リソース・パス

RESTfulリソース

rest-resource

  • ドメイン

  • アプリケーション

  • アプリケーション・モジュールまたは接続

  • RESTfulアプリケーション、サービスまたはWebサービス・エンドポイント

  • リソース・パス

  • HTTPメソッド

  • RESTfulリソースのサブパス

SOAコンポーネント

将来使用するために予約されています。

将来使用するために予約されています。

SOA JCAサービス

将来使用するために予約されています。

将来使用するために予約されています。

SOA JCA参照

将来使用するために予約されています。

将来使用するために予約されています。

SOA RESTful参照

将来使用するために予約されています。

将来使用するために予約されています。

SOA RESTfulサービス

将来使用するために予約されています。

将来使用するために予約されています。

SOA SOAP参照

将来使用するために予約されています。

将来使用するために予約されています。

SOA SOAPサービス

将来使用するために予約されています。

将来使用するために予約されています。

SOAP非同期コールバック・クライアント

ws-callback

  • ドメイン

  • アプリケーション

  • アプリケーション・モジュールまたは接続

  • コールバック・インタフェース

SOAP Webサービス

ws-service

  • ドメイン

  • アプリケーション

  • アプリケーション・モジュールまたは接続

  • RESTfulアプリケーション、サービスまたはWebサービス・エンドポイント

  • ポート

SOAP Webサービス・クライアント

ws-client

  • ドメイン

  • アプリケーション

  • アプリケーション・モジュールまたは接続

  • 参照またはWebサービス・クライアント

  • ポート

2.5 ポリシー・サブジェクトへのポリシーのアタッチ

ポリシーのアタッチは、アプリケーションのライフサイクルの2つの時点、つまり設計時とポリシーのデプロイ後に行えます。


注意:

ポリシー・セットは、RESTful Webサービスおよびクライアントと、Oracle Infrastructure Webサービスおよびクライアントに対してサポートされています。Java EE Webサービスおよびクライアントに対してはサポートされていません。

OWSMでは、ポリシーに含まれるアサーションのカテゴリに基づいて、サブジェクトにアタッチ可能なポリシーの数が制限されます。直接的および外部からの(グローバルな)ポリシー・アタッチメントをサポートするために、OWSMでは、各ポリシー内のアサーションのカテゴリ、ポリシー・アタッチメントの優先度、実行時の制約およびポリシー・アタッチメントのステータス(有効/無効)を考慮して、サブジェクトに対して有効なポリシー・セットを判別します。エンドポイントに対して有効なポリシー計算の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の有効なポリシー・セットの計算方法に関する項を参照してください。

ポリシーを設計時にアタッチする場合でも、デプロイ後にアタッチする場合でも、クライアント側のポリシーは、Webサービスに関連付けられたポリシーと同等のものである必要があります。2つのポリシー・ファイルが異なり、各ファイルに含まれるアサーションの競合が発生している場合、Webサービスの操作を起動すると、エラーが返されます。

ポリシーのアタッチの詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のポリシーのアタッチに関する項を参照してください。

2.5.1 直接ポリシー・アタッチメント

アプリケーションのデプロイ後は、SOAP Webサービス、クライアント・エンドポイント、ADF SOAP Webサービス接続、RESTfulリソースおよびクライアントなどのポリシー・サブジェクトに、OWSMポリシーを直接アタッチできます。ポリシーを直接アタッチする方法の詳細は、Fusion Middleware Controlを使用したポリシーの直接アタッチに関する項とWLSTを使用したWebサービスおよびクライアントへのポリシーのアタッチに関する項を参照してください。

2.5.2 ポリシー・セットを使用したグローバル・ポリシー・アタッチメント


注意:

ポリシー・セットは、RESTful Webサービスおよびクライアントと、Oracle Infrastructure Webサービスおよびクライアントに対してサポートされています。Java EE Webサービスおよびクライアントに対してはサポートされていません。

ポリシー・セットには、複数のポリシー参照を格納できます。ポリシー・セットは、デプロイメントの状態を問わず、同じタイプの一連のエンドポイントへのポリシーのグローバルなアタッチを可能にする抽象表現です。Fusion Middleware ControlおよびWebLogic Scripting Tool (WLST)の両方を使用して、ポリシー・セットを作成および管理できます。

ポリシー・セットを使用してポリシーをグローバルにアタッチすることによって、開発者、アセンブラまたはデプロイヤがアタッチするポリシーを明示的に指定しなかった状況において、管理者は、すべてのサブジェクトが確実に保護されるようにできます。たとえば、開発者が注釈内にポリシーを指定しなかった場合、またはデプロイメント・ディスクリプタにポリシー参照を含めなかった場合、デプロイヤはポリシーをアタッチする必要があり、このようにしないと、潜在的なセキュリティ・リスクが発生します。タイプ別のサブジェクトのセットに対してポリシーをグローバルにアタッチすることによって、管理者はデプロイメントに関係なく(かつデプロイメント前に)、すべてのサブジェクトがデフォルトで保護されるようにできます。たとえば、管理者はあるドメイン内のすべてのWebサービス・エンドポイントに対してセキュリティ・ポリシーをアタッチするポリシー・セットを定義できます。この場合、ドメインに追加されるすべての新規サービスには、ポリシー・セットに定義されたセキュリティ構成が自動的に継承されます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のエンドポイントのセキュア・ステータスの判別に関する項を参照してください。

また、ポリシー・セットを使用してグローバルにアタッチされたポリシーにより、次のことが可能になります。

  • 参照されたポリシーに対する構成のオーバーライドを指定できます。このオーバーライドは、ポリシー・セットのスコープが設定されたすべてのエンドポイントに適用されます。オーバーライドの構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理のグローバルにアタッチされたポリシーの構成プロパティのオーバーライドに関する項を参照してください。

  • 実行時制約を指定できます。この制約によってそのポリシー・セットが関連するコンテキストが決定されます。たとえば、セキュリティ保護されていない公衆回線でメッセージが送信される可能性があるため、外部クライアントと通信する場合にのみ、サービスでメッセージ保護を使用するように指定できます。ただし、信頼できるネットワークで内部クライアントと通信するときは、メッセージ保護を要求しない場合もあります。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のポリシー・セットでの実行時制約の指定に関する項を参照してください。

Fusion Middlewareインストールに含まれるいかなる動作も強制しない事前定義済ポリシーを使用して、特定のエンドポイントまたはエンドポイントの範囲に対して、グローバルにアタッチされたポリシーを無効にできます。このようなポリシーのいずれかを特定のエンドポイントにアタッチするか、より下位のスコープでアタッチすると、上位のスコープでグローバルにアタッチされたポリシーの動作が無効になります。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のグローバルにアタッチされたポリシーの無効化に関する項を参照してください。

ポリシー・セット定義は、独立したXMLドキュメントとして、OWSMリポジトリの/policysets/globalディレクトリに格納されます。

2.5.2.1 サブジェクト・タイプおよびリソース・スコープ

表2-2「ポリシー・サブジェクトおよびリソース・スコープ」に、OWSMポリシーをアタッチできるポリシー・サブジェクトと有効なリソース・スコープを示しています。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のグローバルにアタッチされたポリシーのリソースのタイプとスコープの定義に関する項を参照してください。


注意:

ポリシー・セットを作成する際、サブジェクト・タイプであるSOAP WebサービスおよびSOAP Webサービス・クライアントは、それぞれOracle Infrastructure Webサービスおよびクライアントのみを参照します。Java EE Webサービスおよびクライアント用のポリシー・セットは作成できません。

2.5.2.2 グローバル・ポリシー・アタッチメントの一般的な用途

次に、ポリシーのグローバルなアタッチが役立つ一般的なシナリオをいくつか示します。

  • 指定タイプのすべてのサブジェクトについて、それぞれデフォルトの構成を使用して、同じポリシー・セットにより保護する必要がある場合。たとえば、(SAMLまたはユーザー名トークンを使用して)認証およびWSS11メッセージ保護によりドメイン内のすべてのサービスを保護する必要があります。ドメイン内のすべてのサービスに適切なポリシーをアタッチするためにポリシー・セットを作成できます。

  • サブジェクトのサブセットを同じポリシー・セットにより保護する必要がありますが、こうしたポリシーがドメイン全体のデフォルトとは異なる場合。たとえば、(SAMLまたはユーザー名トークンを使用して)認証によりすべてのサービスを保護する必要がありますが、一般元帳アプリケーションではより強力なWSS11メッセージ保護も必要です。このような場合、すべてのサービスに認証ポリシーをアタッチする1つのポリシー・セットと、一般元帳アプリケーションにより強力なメッセージ保護ポリシーをアタッチする第2のポリシー・セットを作成します。

  • 現セットのグローバル・ポリシー・アタッチメントがまだ適用されていないカテゴリのポリシーによって単一のサブジェクトを保護する必要があり、さらに両方のポリシーを適用する必要がある場合。たとえば、機密性の高い財務に基づくサービス・エンドポイントでは、必要な認証およびメッセージ保護に加えて、クライアントがアクセスするための権限を必要とします。このような場合は、財務に基づくサービス・エンドポイントに認可ポリシーを直接アタッチします。ダイレクト・アタッチメントとグローバルにアタッチされたポリシーを組み合せることで、両方のポリシーが強制されます。

  • アプリケーションが設計時のポリシー・アタッチメントによりデプロイされており、グローバル・ポリシー・アタッチメントを使用するように変換する必要がある場合。このアタッチメントを移行するために、migrateAttachments WLSTコマンドを使用できます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の直接ポリシー・アタッチメントからグローバル・ポリシー・アタッチメントへの移行に関する項を参照してください。

2.6 ポリシー実行の仕組み

サービス・コンシューマ(クライアントとも呼ばれる)からサービス・プロバイダ(Webサービスとも呼ばれる)にリクエストが行われると、リクエストは1つ以上のポリシー・インターセプタによりインターセプトされます。これらのインターセプタにより、クライアントおよびWebサービスに添付されたポリシーが実行されます。いくつかのインターセプタ・タイプは、他のインターセプタ・タイプと一緒にポリシー・インターセプタ・チェーンを形成します。各インターセプタは、同じタイプのポリシーを実行します。セキュリティ・インターセプタはセキュリティ・ポリシーを、MTOMインターセプタはMTOMポリシーをインターセプトして実行します。

クライアントまたはWebサービスに添付されたポリシーは、図2-5に示されるように、ポリシー・インターセプタ・パイプラインによって特定の順序で実行されます。


注意:

OWSMポリシーのサブセットがRESTful Webサービスに対してサポートされています。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のRESTful Webサービスに対してサポートされているOWSMポリシーに関する項を参照してください。RESTでは、図2-5に示すセキュリティ・ポリシー・インターセプタ・タイプのみが使用されます。

図2-5 クライアントおよびWebサービス(SOAP)間のメッセージで動作するポリシー・インターセプタ

図2-5の説明が続きます。
「図2-5 クライアントおよびWebサービス(SOAP)間のメッセージで動作するポリシー・インターセプタ」の説明

前の図が示しているように、クライアントまたはWebサービスがSOAPを介したメッセージの送信を開始すると、リクエスト・メッセージ(クライアントの場合)、レスポンス・メッセージ(Webサービスの場合)を問わず、管理、コンテキスト(SOAPリクエストおよびレスポンス・メッセージ処理用)、原子性トランザクション、信頼できるメッセージング、アドレッシング、セキュリティ、MTOMの順にポリシーがインターセプトされます。クライアントまたはWebサービスがSOAPを介してメッセージを受信すると、つまり、Webサービスの場合はリクエスト・メッセージ、クライアントの場合はレスポンス・メッセージを受信すると、ポリシーが逆の順序で実行されます。また、追加インターセプタが含められます。つまり、Fast Infoset、MTOM、セキュリティ、アドレッシング、MEX、信頼できるメッセージング、原子性トランザクション、コンテキスト、管理という順序で実行されます。

メッセージには、1つ以上のポリシーが添付されている場合があります。すべてのメッセージに各タイプのポリシーが含まれるわけではありません。メッセージに含まれるのが、セキュリティ・ポリシーとMTOMポリシーの場合もあります。この場合、セキュリティ・インターセプタはセキュリティ・ポリシーを実行し、MTOMインターセプタはMTOMポリシーを実行します。この例では、その他のインターセプタはメッセージの処理に関わりません。

次に、クライアントとWebサービス間のSOAPを介したメッセージで、ポリシー・インターセプタがどのように動作するかを説明します。(図2-5を参照。)

  1. クライアントがWebサービスにリクエスト・メッセージを送信します。

  2. ポリシー・インターセプタが、クライアントに添付されたポリシーをインターセプトおよび実行します。クライアント・ポリシーが正常に実行されると、リクエスト・メッセージがWebサービスに送信されます。

  3. リクエスト・メッセージがポリシー・インターセプタによりインターセプトされ、Webサービスに添付されたサービス・ポリシーが実行されます。

  4. サービス・ポリシーが正常に実行されたら、リクエスト・メッセージがWebサービスに渡されます。Webサービスによりリクエスト・メッセージが実行され、レスポンス・メッセージが戻されます。

  5. レスポンス・メッセージがポリシー・インターセプタによりインターセプトされ、Webサービスに添付されたサービス・ポリシーが実行されます。サービス・ポリシーが正常に実行されたら、レスポンス・メッセージがクライアントに送信されます。

  6. レスポンス・メッセージがポリシー・インターセプタによりインターセプトされ、クライアントに添付されたクライアント・ポリシーが実行されます。

  7. クライアント・ポリシーが正常に実行されたら、レスポンス・メッセージがクライアントに渡されます。

2.7 OWSMの事前定義済のポリシーおよびアサーション・テンプレート


注意:

このリリースでインストールされる事前定義済のポリシーおよびアサーション・テンプレートは読取り専用です。既存の事前定義済のポリシーおよびアサーション・テンプレートを変更した場合、それらは現在のリリースではオーバーライドされませんが、次のリリースでオーバーライドされます。

Oracle Fusion Middlewareをインストールすると自動的に使用可能になる、一連の事前定義済ポリシーとアサーション・テンプレートがあります。事前定義済ポリシーは、顧客のデプロイで使用される一般的なベスト・プラクティス・ポリシーのパターンに基づいています。

これらの事前定義済ポリシーは、Webサービスやクライアントにすぐに添付できます。事前定義済ポリシーを構成することも、事前定義済ポリシーのいずれかをコピーして新しいポリシーを作成することもできます。

事前定義済ポリシーは、事前定義済アサーション・テンプレートに基づくアサーションを使用して作成されています。必要に応じて、新しいアサーション・テンプレートを作成できます。

事前定義済ポリシーおよびアサーション・テンプレートの詳細は、次の項を参照してください。


注意:

WS-SecurityPolicyは、WS-Security仕様(WS-Security1.0と1.1の両方をサポート)で説明される、複数のセキュリティ・トークンのタイプに対してWS-SecurityPolicyポリシーを設定する方法の例を説明する、シナリオを定義します。OWSMの事前定義済ポリシーでは、最も一般的なカスタマ・ユース・ケースを表すWS-SecurityPolicyシナリオのサブセットをサポートしています。

2.8 セキュリティ・ポリシー構成のオーバーライド

複数のWebサービスおよびWebクライアントで同じポリシーを使用することもできます。それぞれのポリシー構成要件(ユーザー名やパスワードなど)は異なる場合があります。

OWSMポリシー構成のオーバーライド機能により、サービスまたはクライアントごとに構成を更新できます。個別にポリシーを新規作成する必要はありません。この方法により、デフォルトの構成値を定義するポリシーを作成しておき、その値を実行時の要件に基づいてカスタマイズできます。

たとえば、クライアントごとに情報が異なる場合があることから、クライアント・ポリシーを構成するときにユーザー名とパスワードを指定することもできます。

セキュリティ・ポリシー構成のオーバーライドの詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のポリシー構成プロパティのオーバーライドに関する項を参照してください。

カスタム・アサーションの作成時に、構成プロパティがオーバーライド可能かどうかを定義できます。Oracle Web Services Manager拡張可能アプリケーションの開発のカスタム・アサーションの作成に関する項を参照してください。

2.9 ポリシーの推奨ネーミング規則

ディレクトリ、ポリシーおよびアサーション・テンプレートの名前に使用できる文字は次のとおりです。


注意:

名前の先頭に、ハイフンまたは空白を使用することはできません。

一目で何をするポリシーかがわかるように、ポリシー名には可能なかぎり情報を含めることをお薦めします。たとえばOracle Fusion Middleware 12c (12.1.2)リリースに付属している事前定義済セキュリティ・ポリシーの1つは、oracle/wss10_username_token_with_message_protection_service_policyという名前です。図2-6で、この事前定義済ポリシー名の各部分を確認します。

図2-6 ポリシー名の各部分の確認

図2-6の説明が続きます。
「図2-6 ポリシー名の各部分の確認」の説明

事前定義済ポリシーに名前を付ける際には、次の表記規則が使用されます。ポリシー名の各部分は、アンダースコア文字(_)で区切られます。

どのような表記規則を適用する場合でも、ポリシー名の付け方を十分に検討することをお薦めします。これにより、エンタープライズが成長して新しいポリシーを作成する場合に、ポリシーの追跡が簡単になります。

作成するポリシーは、事前定義済ポリシーが存在するoracleディレクトリとは別のディレクトリに保存することをお薦めします。ポリシーは、ルート・レベル、oracle以外のディレクトリ、またはサブディレクトリで管理できます。たとえば、次のいずれも有効です。


注意:

ポリシー名に接頭辞oracle_を使用する(例: oracle_wss_http_token_service_policy)ことは、ベスト・プラクティスとしてお薦めしません。

  前
前 		 次
次
  目次へ移動
目次