| Oracle® Fusion Middleware Oracle Web Services Managerの理解 12c (12.1.3) E57548-02 |
|
 前 |
 次 |
この章では、組織全体でのWebサービスの一貫性のある管理と保護を実現するOWSMポリシー・フレームワークについて説明します。
この章の内容は次のとおりです。
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ポリシー・フレームワーク
OWSMポリシー・フレームワークは次のコンポーネントで構成されます。
ポリシー・マネージャは、OWSMリポジトリの事前定義されたポリシーやカスタム・ポリシーなどの、ポリシーの読取りと書込みを行います。Oracle SOAのインストールでは、通常、Oracle SOA Service Infrastructure管理対象サーバーにデプロイされます。ポリシー・マネージャは個別の管理対象サーバーにデプロイできます。
エージェントは、ポリシーの施行、実行、およびランタイム統計の収集を行います。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サービス・メトリックも表示されます。
OWSMエージェントとOWSMポリシー・マネージャの相互作用の概要は、図2-2のようなものになります。
OWSMエージェントは、ドメインの少なくとも1つのノードにOWSMポリシー・マネージャがデプロイされていることを前提として動作します。
ポリシー・マネージャは、ステートレス・アプリケーションであり、キャッシュは一切行いません。ポリシー・マネージャがデプロイされている管理対象サーバーの起動時に実行される、アプリケーション・レベルの特別な起動シーケンスはありません。ポリシー・マネージャは、OWSMリポジトリと通信してポリシーを取得します。OWSMリポジトリをデータベースに格納することによって、MDSの高可用性を実現できます。
OWSMエージェントには、自動検出機能が備わっており、OWSMポリシー・マネージャを検索し、接続します。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したOWSMポリシー・アクセスの構成に関する項を参照してください。
エージェントは、ポリシー・マネージャに接続すると、最新バージョンのポリシーをダウンロードし、キャッシュします。エージェントが起動して実行されると、構成可能な間隔に基づいて定期的にキャッシュのリフレッシュが試行されます。デフォルトの時間は10分ごとです。
高可用性シナリオでは、OWSMアプリケーションのターゲットを複数のノードに設定する場合、個々の管理対象サーバーではなく、クラスタをターゲットにします。
OWSMによって保護されているWebサービスが管理対象サーバーにデプロイされているときに、OWSMエージェントが起動時にどのポリシー・マネージャとも通信できない場合、Webサービスの呼出しは失敗します。
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が適切に起動し、稼働するためには、この両方のコンポーネントが使用可能である必要があります。
クライアント・アプリケーションが保護されたWebサービスにアクセスすると、OWSMエージェントがポリシー・キャッシュへの問合せを実行して、適切なポリシーを施行します。リクエストの認証、暗号化、復号化、認可またはログは、ポリシーに基づいて行われます。これらの操作のいずれについても、ポリシー・マネージャへの接続は行われません。
ポリシー・マネージャの実行時の可用性は、OWSMエージェントの機能には影響しません。ただし、OWSMによって保護された新しいWebサービスのデプロイや既存のWebサービスへの新規ポリシーのアタッチなどの構成変更が行われた場合は、可用性による影響が生じます。このような構成変更があった場合、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のクラスタ全体で同期化されます。
Webサービス・プロバイダは、サービスが提供される条件(またはポリシー)を定義できます。WS-Policyフレームワークを使用すると、OWSMなどのWebサービス・アプリケーションによって処理されるポリシー情報の指定が可能になります。
ポリシーは、Webサービスの機能または要件を表す1つ以上のポリシー・アサーションとして表されます。たとえば、ポリシー・アサーションは、Webサービスへのリクエストを暗号化することを規定できます。同様に、ポリシー・アサーションでは、Webサービスで許容できる最大メッセージ・サイズを定義できます。
WS-Policy表記は、WS-PolicyAttachment仕様を使用して、様々なWebサービス・コンポーネントと関連付けられます。WS-Policy情報はWSDLファイルに埋込み可能なため、UDDIレジストリを介したWebサービス・ポリシーの公開が簡単になります。
ポリシーは、エンドポイントに直接アタッチできるほか、ポリシー・セットを使用して、デプロイメントの状態を問わず、同じタイプの一連のエンドポイントにグローバルにアタッチできます。
表2-1は、Oracle Fusion Middleware 12cがサポートしているポリシー・カテゴリを定義したものです。これらのポリシーは、ポリシーの一元的な作成と管理を可能にする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)アタッチメント |
JPEG形式のイメージなどのバイナリ・コンテンツは、クライアントとWebサービスの間で渡すことができます。受渡しを可能にするために、バイナリ・コンテンツは通常、 MTOMを使用すると、バイナリ・コンテンツをMIME添付ファイルとして送信できるため、ワイヤ書式の送信サイズを小さくできます。バイナリ・コンテンツは意味的にXMLドキュメントの一部です。MTOMポリシーをアタッチすると、メッセージはWebサービスやクライアントに送信される前にMIME添付ファイルに変換されます。 |
SOAP |
|
信頼できるメッセージング |
SOAPメッセージの配信を保証し、一連のメッセージの配信順序を維持できるワイヤレベル・プロトコルを記述するWS-ReliableMessaging標準を実装する、信頼できるメッセージング・ポリシー。 このテクノロジは、メッセージが正しい順序で送信されることを保証するために使用できます。メッセージが順序どおりに送信されなかった場合には、メッセージが正しい順序で処理されるように受信システムを構成できます。また、メッセージが最低1回、または1回のみ送信されるようにシステムを構成することも可能です。メッセージが消失した場合は、受信システムが受信を確認するまで、送信システムがメッセージを再送信します。WS-ReliableMessagingの詳細は、「Webサービスの信頼性のあるメッセージングの理解」を参照してください。 |
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 |
ポリシーは、1つ以上のポリシー・アサーションで構成されています。ポリシー・アサーションは、リクエスト操作とレスポンス操作のための特定のアクションを実行するポリシーの最小単位です。ポリシーなどのアサーションは、「アトミック・トランザクション」、「構成」、「管理」、「MTOMアタッチメント」、「信頼できるメッセージング」、「セキュリティ」、「SOAP over JMSトランスポート」および「WSアドレス」のいずれかのカテゴリに属します。
ポリシー・アサーションは、パイプライン内で連鎖しています。ポリシー内のアサーションは、リクエスト・メッセージおよびレスポンス・メッセージで実行され、どちらのタイプのメッセージでも同じアサーションのセットが実行されます。アサーションは、パイプライン内での順序で実行されます。
図2-3に、一般的な実行フローを示します。リクエスト・メッセージの場合、アサーション1が最初に実行され、アサーション2およびアサーションnがそれに続きます。レスポンス・メッセージで同じアサーションが実行されることもありますが(レスポンスが戻される場合)、レスポンス・メッセージで実行されるアクションはリクエスト・メッセージとは異なっており、アサーションが逆の順序で実行されます。図2-3のレスポンス・メッセージの場合、アサーションnが最初に実行され、アサーション2、アサーション1がそれに続きます。
たとえば、図2-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サービスに送信されると、表示されている順序でアサーションが実行されます。レスポンス・メッセージがクライアントに返されると、同じアサーションが実行されますが、順序は逆です。リクエスト・メッセージに対するアサーションの動作は、レスポンス・メッセージの動作とは異なります。インスタンスによっては、レスポンスで何も発生しない場合があります。たとえば前述の例では、認可アサーションはリクエストの一部としてのみ実行されます。
ポリシー強制に複数の選択肢を定義するには、サービス・ポリシー内に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に関する項を参照してください。
ポリシー・サブジェクトは、ポリシーのアタッチ先のターゲット・リソースです。Web Services Policy 1.5 Frameworkの仕様(http://www.w3.org/TR/ws-policy/)で定義されているように、ポリシー・サブジェクトは、ポリシーを関連付けることが可能なエンティティ(エンドポイント、メッセージ、リソース、操作など)です。異なるリソースのタイプ(Webサービスまたはクライアントなど)には異なるポリシーがあります。
表2-2に、OWSMポリシーをアタッチできるポリシー・サブジェクトを示します。さらに、表にはWLSTによるポリシー・サブジェクト・タイプの特定に使用する等価の名前、および各ポリシー・サブジェクト・タイプに対する有効なリソース・スコープがリストされています。リソース・スコープはポリシー・セットの作成時に適用可能です。詳細は、「ポリシー・セットを使用したグローバル・ポリシー・アタッチメント」を参照してください。WLSTでのリソース・スコープの指定方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のリソース・スコープの定義に関する項を参照してください。
表2-2 ポリシー・サブジェクトおよびリソース・スコープ
| ポリシー・サブジェクト | WLST名 | 有効なリソース・スコープ(ポリシー・セット) |
|---|---|---|
|
ADF RESTful Webサービス接続 |
将来使用するために予約されています。 |
将来使用するために予約されています。 |
|
ADF SOAP Webサービス接続 |
ws-connection |
|
|
ESS SOAP JOBコールバック |
job-callback |
|
|
ESS SOAP JOBインボーカ |
job-invoke |
|
|
OSB JCAビジネス・サービス |
business-jca-service |
|
|
OSB JCAプロキシ・サービス |
proxy-jca-service |
|
|
OSB RESTfulビジネス・サービス |
biz-rest-service |
|
|
OSB RESTfulプロキシ・サービス |
proxy-rest-reference |
|
|
OSB SOAPビジネス・サービス |
biz-service |
|
|
OSB SOAPプロキシ・サービス |
proxy-service |
|
|
RESTfulクライアント |
rest-client |
|
|
RESTfulリソース |
rest-resource |
|
|
SOAコンポーネント |
sca-component |
|
|
SOA JCA参照 |
sca-jca-reference |
|
|
SOA JCAサービス |
sca-jca-service |
|
|
SOA RESTful参照 |
sca-rest-reference |
|
|
SOA RESTfulサービス |
sca-rest-service |
|
|
SOA SOAP参照 |
sca-reference |
|
|
SOA SOAPサービス |
sca-service |
|
|
SOAP非同期コールバック・クライアント |
ws-callback |
|
|
SOAP Webサービス |
ws-service |
|
|
SOAP Webサービス・クライアント |
ws-client |
|
ポリシーのアタッチは、アプリケーションのライフサイクルの2つの時点、つまり設計時とポリシーのデプロイ後に行えます。
設計時には、プログラムによってOWSMポリシーをアプリケーションにアタッチできます。これを行うには、通常、Oracle JDeveloperなどの任意のIDEを使用します。Oracle JDeveloperはADFとSOAのクライアント・ポリシー・アタッチメントを自動化します。詳細は、『Oracle Jdeveloperによるアプリケーションの開発』のWebサービスの開発と保護に関する項を参照してください。
デプロイ後は、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTを使用して、OWSMポリシーをOracle Infrastructure Webサービス、RESTful WebサービスおよびJava EE Webサービスにアタッチできます。この場合、Webサービスのセキュリティがセキュリティ管理者の制御下に移るため、この方法は最も強力で柔軟性があります。ポリシーは直接エンドポイントにアタッチするか、ポリシー・セットを使用して一連のエンドポイントにグローバルにアタッチできます。
OWSMでは、ポリシーに含まれるアサーションのカテゴリに基づいて、サブジェクトにアタッチ可能なポリシーの数が制限されます。直接的および外部からの(グローバルな)ポリシー・アタッチメントをサポートするために、OWSMでは、各ポリシー内のアサーションのカテゴリ、ポリシー・アタッチメントの優先度、実行時の制約およびポリシー・アタッチメントのステータス(有効/無効)を考慮して、サブジェクトに対して有効なポリシー・セットを判別します。エンドポイントに対して有効なポリシー計算の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の有効なポリシー・セットの計算方法に関する項を参照してください。
ポリシーを設計時にアタッチする場合でもデプロイ後にアタッチする場合でも、クライアント側ポリシーは、Webサービスに関連付けられたポリシーと同等のものである必要があります。2つのポリシー・ファイルが異なり、各ファイルに含まれるアサーションの競合が発生している場合、Webサービスの操作を起動すると、エラーが返されます。
ポリシーのアタッチの詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のポリシーのアタッチに関する項を参照してください。
アプリケーションのデプロイ後は、SOAP Webサービス、クライアント・エンドポイント、RESTfulリソースおよびクライアントなどのポリシー・サブジェクトに、OWSMポリシーを直接アタッチできます。ポリシーをアタッチできるポリシー・サブジェクトの完全なリストは、「ポリシー・サブジェクトの理解」を参照してください。ポリシーを直接アタッチする方法の詳細は、Fusion Middleware Controlを使用したポリシーの直接アタッチに関する項とWLSTを使用したWebサービスおよびクライアントへのポリシーのアタッチに関する項を参照してください。
ポリシー・セットには、複数のポリシー参照を格納できます。ポリシー・セットは、デプロイメントの状態を問わず、同じタイプの一連のエンドポイントへのポリシーのグローバルなアタッチを可能にする抽象表現です。Fusion Middleware ControlおよびWebLogic Scripting Tool (WLST)の両方を使用して、ポリシー・セットを作成および管理できます。
ポリシー・セットを使用しているグローバル・ポリシー・アタッチメントは、SOAP、RESTfulベースのOracle Infrastructure、およびJava EE Webサービスとクライアントでサポートされます。ただし、Java EEエンドポイントに対する効果的なポリシー・セットが計算されている場合には、非セキュリティ・ポリシーは無視されます。グローバル・ポリシー・アタッチメントは、スタンドアロンのJava EEクライアントではサポートされていません。
ポリシー・セットを使用してポリシーをグローバルにアタッチすることによって、開発者、アセンブラまたはデプロイヤがアタッチするポリシーを明示的に指定しなかった状況において、管理者は、すべてのサブジェクトが確実に保護されるようにできます。たとえば、開発者が注釈内にポリシーを指定しなかった場合、またはデプロイメント・ディスクリプタにポリシー参照を含めなかった場合、デプロイヤはポリシーをアタッチする必要があり、このようにしないと、潜在的なセキュリティ・リスクが発生します。タイプ別のサブジェクトのセットに対してポリシーをグローバルにアタッチすることによって、管理者はデプロイメントに関係なく(かつデプロイメント前に)、すべてのサブジェクトがデフォルトで保護されるようにできます。たとえば、管理者はあるドメイン内のすべての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-2「ポリシー・サブジェクトおよびリソース・スコープ」に、OWSMポリシーをアタッチできるポリシー・サブジェクトと有効なリソース・スコープを示しています。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のグローバルにアタッチされたポリシーのリソースのタイプとスコープの定義に関する項を参照してください。
|
注意: ポリシー・セットを作成する場合、SOAP WebサービスおよびSOAP Webサービス・クライアントのサブジェクト・タイプが、Oracle InfrastructureのWebサービスとクライアントおよびJava EEのWebサービスとクライアントを両方とも参照します。 |
次に、ポリシーのグローバルなアタッチが役立つ一般的なシナリオをいくつか示します。
指定タイプのすべてのサブジェクトについて、それぞれデフォルトの構成を使用して、同じポリシー・セットにより保護する必要がある場合。たとえば、(SAMLまたはユーザー名トークンを使用して)認証およびWSS11メッセージ保護によりドメイン内のすべてのサービスを保護する必要があります。ドメイン内のすべてのサービスに適切なポリシーをアタッチするためにポリシー・セットを作成できます。
サブジェクトのサブセットを同じポリシー・セットにより保護する必要がありますが、こうしたポリシーがドメイン全体のデフォルトとは異なる場合。たとえば、(SAMLまたはユーザー名トークンを使用して)認証によりすべてのサービスを保護する必要がありますが、一般元帳アプリケーションではより強力なWSS11メッセージ保護も必要です。このような場合、すべてのサービスに認証ポリシーをアタッチする1つのポリシー・セットと、一般元帳アプリケーションにより強力なメッセージ保護ポリシーをアタッチする第2のポリシー・セットを作成します。
現セットのグローバル・ポリシー・アタッチメントがまだ適用されていないカテゴリのポリシーによって単一のサブジェクトを保護する必要があり、さらに両方のポリシーを適用する必要がある場合。たとえば、機密性の高い財務に基づくサービス・エンドポイントでは、必要な認証およびメッセージ保護に加えて、クライアントがアクセスするための権限を必要とします。このような場合は、財務に基づくサービス・エンドポイントに認可ポリシーを直接アタッチします。ダイレクト・アタッチメントとグローバルにアタッチされたポリシーを組み合せることで、両方のポリシーが強制されます。
アプリケーションが設計時のポリシー・アタッチメントによりデプロイされており、グローバル・ポリシー・アタッチメントを使用するように変換する必要がある場合。このアタッチメントを移行するために、migrateAttachments WLSTコマンドを使用できます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の直接ポリシー・アタッチメントからグローバル・ポリシー・アタッチメントへの移行に関する項を参照してください。
サービス・コンシューマ(クライアントとも呼ばれる)からサービス・プロバイダ(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)間のメッセージで動作するポリシー・インターセプタ
前の図が示しているように、クライアントまたはWebサービスがSOAPを介したメッセージの送信を開始すると、リクエスト・メッセージ(クライアントの場合)、レスポンス・メッセージ(Webサービスの場合)を問わず、管理、コンテキスト(SOAPリクエストおよびレスポンス・メッセージ処理用)、原子性トランザクション、信頼できるメッセージング、アドレッシング、セキュリティ、MTOMの順にポリシーがインターセプトされます。クライアントまたはWebサービスがSOAPを介してメッセージを受信すると、つまり、Webサービスの場合はリクエスト・メッセージ、クライアントの場合はレスポンス・メッセージを受信すると、ポリシーが逆の順序で実行されます。また、追加インターセプタが含められます。つまり、Fast Infoset、MTOM、セキュリティ、アドレッシング、MEX、信頼できるメッセージング、原子性トランザクション、コンテキスト、管理という順序で実行されます。
メッセージには、1つ以上のポリシーが添付されている場合があります。すべてのメッセージに各タイプのポリシーが含まれるわけではありません。メッセージに含まれるのが、セキュリティ・ポリシーとMTOMポリシーの場合もあります。この場合、セキュリティ・インターセプタはセキュリティ・ポリシーを実行し、MTOMインターセプタはMTOMポリシーを実行します。この例では、その他のインターセプタはメッセージの処理に関わりません。
次に、クライアントとWebサービス間のSOAPを介したメッセージで、ポリシー・インターセプタがどのように動作するかを説明します。(図2-5を参照。)
クライアントがWebサービスにリクエスト・メッセージを送信します。
ポリシー・インターセプタが、クライアントに添付されたポリシーをインターセプトおよび実行します。クライアント・ポリシーが正常に実行されると、リクエスト・メッセージがWebサービスに送信されます。
リクエスト・メッセージがポリシー・インターセプタによりインターセプトされ、Webサービスにアタッチされたサービス・ポリシーが実行されます。
サービス・ポリシーが正常に実行されたら、リクエスト・メッセージがWebサービスに渡されます。Webサービスによりリクエスト・メッセージが実行され、レスポンス・メッセージが返されます。
レスポンス・メッセージがポリシー・インターセプタによりインターセプトされ、Webサービスにアタッチされたサービス・ポリシーが実行されます。サービス・ポリシーが正常に実行されたら、レスポンス・メッセージがクライアントに送信されます。
レスポンス・メッセージがポリシー・インターセプタによりインターセプトされ、クライアントに添付されたクライアント・ポリシーが実行されます。
クライアント・ポリシーが正常に実行されたら、レスポンス・メッセージがクライアントに渡されます。
|
注意: このリリースでインストールされる定義済のポリシーおよびアサーション・テンプレートは読取り専用です。既存の事前定義済のポリシーおよびアサーション・テンプレートを変更した場合、それらは現在のリリースではオーバーライドされませんが、次のリリースでオーバーライドされます。 |
Oracle Fusion Middlewareをインストールすると自動的に使用可能になる、一連の事前定義済ポリシーとアサーション・テンプレートがあります。事前定義済ポリシーは、顧客のデプロイで使用される一般的なベスト・プラクティス・ポリシーのパターンに基づいています。
これらの定義済ポリシーは、Webサービスやクライアントにすぐにアタッチできます。事前定義済ポリシーを構成することも、事前定義済ポリシーのいずれかをコピーして新しいポリシーを作成することもできます。
事前定義済ポリシーは、事前定義済アサーション・テンプレートに基づくアサーションを使用して作成されています。必要に応じて、新しいアサーション・テンプレートを作成できます。
事前定義済ポリシーおよびアサーション・テンプレートの詳細は、次の項を参照してください。
Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理の事前定義済のポリシー
Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理の事前定義済のアサーション・テンプレート
|
注意: WS-SecurityPolicyは、WS-Security仕様(WS-Security1.0と1.1の両方をサポート)で説明される、複数のセキュリティ・トークンのタイプに対してWS-SecurityPolicyポリシーを設定する方法の例を説明する、シナリオを定義します。OWSMの事前定義済ポリシーでは、最も一般的なカスタマ・ユース・ケースを表すWS-SecurityPolicyシナリオのサブセットをサポートしています。 |
複数のWebサービスおよびWebクライアントで同じポリシーを使用することもできます。それぞれのポリシー構成要件(ユーザー名やパスワードなど)は異なる場合があります。
OWSMポリシー構成のオーバーライド機能により、サービスまたはクライアントごとに構成を更新できます。個別にポリシーを新規作成する必要はありません。この方法により、デフォルトの構成値を定義するポリシーを作成しておき、その値を実行時の要件に基づいてカスタマイズできます。
たとえば、クライアントごとに情報が異なる場合があることから、クライアント・ポリシーを構成するときにユーザー名とパスワードを指定することもできます。
セキュリティ・ポリシー構成のオーバーライドの詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のポリシー構成プロパティのオーバーライドに関する項を参照してください。
カスタム・アサーションの作成時に、構成プロパティがオーバーライド可能かどうかを定義できます。Oracle Web Services Manager拡張可能アプリケーションの開発のカスタム・アサーションの作成に関する項を参照してください。
ディレクトリ、ポリシーおよびアサーション・テンプレートの名前に使用できる文字は次のとおりです。
大文字および小文字
数字
通貨記号($)
アンダースコア(_)
ハイフン(-)
空白
|
注意: 名前の先頭に、ハイフンまたは空白を使用することはできません。 |
一目で何をするポリシーかがわかるように、ポリシー名には可能なかぎり情報を含めることをお薦めします。たとえばOracle Fusion Middleware 12cに付属している定義済セキュリティ・ポリシーの1つは、oracle/wss10_username_token_with_message_protection_service_policyという名前です。図2-6で、この事前定義済ポリシー名の各部分を確認します。
事前定義済ポリシーに名前を付ける際には、次の表記規則が使用されます。ポリシー名の各部分は、アンダースコア文字(_)で区切られます。
パスの場所 - すべてのポリシーは、ポリシーが存在するディレクトリによって識別されます。すべての定義済のOWSMポリシーは、oracleディレクトリにあります。作成するポリシーは、定義済ポリシーが存在するoracleディレクトリとは別のディレクトリに保存することをお薦めします。
Webサービス標準 - ポリシーでWS-Security標準が使用されている場合は、wss10 (WS-Security 1.0)またはwss11 (WS-Security 1.1)で識別されます。また、WS-Security 1.0または1.1に依存しないことを示すためにのみ設定することも可能です。
認証トークン - ポリシーでユーザーを認証する場合は、トークンのタイプを指定します。事前定義済オプションは次のとおりです。
http_token - HTTPトークン
kerberos_token - Kerberosトークン
saml_token - SAMLトークン
username_token - ユーザー名およびパスワードのトークン
x509_token - X.509証明書トークン
カスタムの認証トークンを定義することもできます。
トランスポート・セキュリティ - ポリシーでセキュア・トランスポート・レイヤーによるメッセージ送信を要求する場合は、wss_http_token_over_ssl_client_templateなどのように、トークン名の後にover_sslを付けます。
メッセージ保護 - ポリシーでメッセージの機密保護およびメッセージ整合性も提供されている場合は、図2-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_を使用する(例: oracle_wss_http_token_service_policy)ことは、ベスト・プラクティスとしてお薦めしません。 |
