Oracle® Fusion Middleware

Oracle Web Services Managerの理解

12c (12.2.1.1)

E77309-01(原本部品番号:E71226-01)

2016年6月

開発者および管理者を対象としており、Oracle Web Services Manager (OWSM)ポリシー・フレームワークの各機能および基本的なセキュリティの概念について紹介します。

Oracle Fusion Middleware Oracle Web Services Managerの理解, 12c (12.2.1.1)

E77309_01

Copyright © 2013, 2016, Oracle and/or its affiliates. All rights reserved.

原本主著者: Sudhira Subudhi

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- リリース12c (12.2.1.1)の新機能と変更された機能

- リリース12c (12.2.1)の新機能と変更された機能

- リリース12c (12.1.3)の新機能と変更された機能

- リリース12c (12.1.2)の新機能と変更された機能

- リリース12c (12.1.2)の当該ドキュメントにおけるその他の重要な変更

1 Oracle Web Services Managerの概要

- 1.1 Oracle Web Services Managerの概要

- 1.2 Oracle Web Services Managerの機能の概要

- 1.3 Oracle Web Services Managerのアーキテクチャの概要

2 Webサービス・セキュリティの概念の理解

- 2.1 Webサービスのセキュリティについて

- 2.2 トランスポート・レベルおよびアプリケーション・レベルのセキュリティの理解

- 2.3 認証の理解

- 2.3.1 Digest認証について

- 2.4 認可の理解

- 2.5 メッセージ保護の概要

- 2.5.1 メッセージ保護の理解

- 2.5.2 メッセージの暗号化について

- 2.5.3 メッセージの署名(XML署名)について

- 2.6 セキュリティおよび認証での鍵および証明書のロールの概要

- 2.6.1 秘密鍵と証明書について

- 2.6.2 様々なセキュリティ・ポリシーでの秘密鍵および証明書の使用方法の理解

- 2.6.2.1 メッセージ保護ポリシー・タイプの概要

- 2.6.2.1.1 SSLポリシーについて

- 2.6.2.1.2 wss11ポリシーについて

- 2.6.2.1.3 wss10ポリシーについて

- 2.6.2.2 認証トークン・ポリシー・タイプの概要

- 2.6.2.2.1 ユーザー名トークンについて

- 2.6.2.2.2 Kerberosトークンについて

- 2.6.2.2.3 X.509証明書トークンについて

- 2.6.2.2.4 SAML送信者保証トークンについて

- 2.6.2.2.5 STSからのSAMLベアラーおよびSAML HOKトークンについて

- 2.6.3 OWSMでのJKSキーストア用のキーストアおよびキー・パスワードの特定の仕組み

- 2.6.4 SSLポリシー用の秘密鍵および証明書について

- 2.6.5 メッセージ保護ポリシー用の秘密鍵および証明書の設定について

- 2.6.5.1 Sample Basic構成の理解

- 2.6.5.2 詳細な設定に関する考慮事項について

- 2.7 OWSMでの資格証明ストアの使用の仕組みの理解

- 2.8 セキュリティ・ポリシーの理解

- 2.9 セキュリティ・トークンの概要

- 2.9.1 セキュリティ・トークンの理解

- 2.9.2 ユーザー名トークンについて

- 2.9.3 X.509証明書について

- 2.9.4 Kerberosトークンについて

- 2.9.5 SAMLトークンについて

- 2.10 セキュア・アタッチメントの理解

- 2.11 セキュア通信の概要

- 2.11.1 セキュア通信について

- 2.11.2 WS-SecureConversationの使用方法の概要

- 2.11.2.1 WS-SecureConversationを使用する状況

- 2.11.2.2 WS-SecureConversationの長所

- 2.11.2.3 WS-ReliableMessagingでのWS-SecureConversationの使用について

- 2.11.3 WS-SecureConversationのアーキテクチャ

- 2.11.4 WS-SecureConversationを使用する状況

- 2.11.5 再認証を使用する状況

- 2.11.6 ブートストラップ・モードの設定について

- 2.11.7 永続性の概要

- 2.11.7.1 デフォルトのドメイン全体の永続性の実装について

- 2.11.7.2 クライアント固有およびWebサービス固有の永続性の実装について

- 2.12 Kerberosプロトコルの概要

- 2.12.1 Kerberosプロトコルの理解

- 2.12.2 Kerberosでの資格証明の委任の理解

- 2.12.3 KerberosとSPNEGOの理解

- 2.12.4 KerberosとWS-SecureConversationの導出キーについて

- 2.13 Web Services Addressingの理解

- 2.14 Webサービス信頼性の理解

- 2.15 Webサービスの信頼性のあるメッセージングの理解

- 2.16 Oracle Entitlements Serverを使用したファイングレイン認可の概要

- 2.16.1 OESドキュメントへの参照

- 2.16.2 OES統合の概要

- 2.16.2.1 OES統合: 全体像

- 2.16.2.2 データ・マスキング

- 2.16.2.3 XACML責任について

- 2.16.2.4 OESのファイングレイン認可および大まかな認可の概要

- 2.16.2.4.1 OESファイングレイン(責任)

- 2.16.2.4.2 SAMLのファイングレイン

- 2.16.2.4.3 OESの大まかな認可

- 2.16.3 OWSM OESのポリシーについて

- 2.16.4 リソースのマッピングおよび命名の概要

- 2.16.4.1 リソースのマッピングおよび命名

- 2.16.4.2 OESポリシーの例

- 2.16.5 属性の処理方法

- 2.16.6 ガード要素について

- 2.17 個人の身元を特定する情報の概要

- 2.17.1 PIIデータの概要

- 2.17.1.1 PIIデータについて

- 2.17.1.2 PIIセキュリティ・ポリシーについて

- 2.17.2 PIIデータを保護する方法の例

- 2.17.3 PIIポリシーのXPath式について

- 2.17.4 PIIポリシーを使用する状況

- 2.17.4.1 単一のSOAコンポジットのユースケース

- 2.17.4.2 ビジネス・サービス・ユースケースへのOracle Service Busプロキシ・サービス

- 2.17.4.3 JCAバインディング・ユースケースにおけるPII

- 2.17.5 PIIに対するアクセス権を持っているのは誰か

- 2.17.6 アンマーシャリングに関するその他の考慮事項について

- 2.18 RESTおよびSOAPのサービスおよびクライアントのOAuth 2.0の理解

- 2.19 資格証明およびキーストアの管理のためのREST APIの理解

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

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

- 3.1.1 OWSMポリシー・フレームワークのコンポーネントについて

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

- 3.1.3 OWSMエージェントとポリシー・マネージャの特性について

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

- 3.1.5 OWSM構成アーティファクトについて

- 3.2 Webサービス・ポリシーの理解

- 3.3 ポリシーのアサーションを使用したWebサービス・バインディングの概要

- 3.3.1 ポリシーのアサーションを使用したWebサービス・バインディングについて

- 3.3.2 複数のポリシー選択肢の定義(ORグループ)について

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

- 3.5 ポリシー・サブジェクトへのポリシーのアタッチの概要

- 3.5.1 ポリシー・サブジェクトへのポリシーのアタッチについて

- 3.5.2 直接ポリシー・アタッチメントについて

- 3.5.3 ポリシー・セットを使用したグローバル・ポリシー・アタッチメントの概要

- 3.5.3.1 ポリシー・セットを使用したグローバル・ポリシー・アタッチメントについて

- 3.5.3.2 サブジェクト・タイプおよびリソース・スコープについて

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

- 3.6 ポリシーの実行方法の理解

- 3.7 OWSMの事前定義済ポリシーとアサーション・テンプレートについて

- 3.8 セキュリティ・ポリシー構成のオーバーライドについて

- 3.9 WSMリポジトリで作成されたドキュメントの推奨命名規則について

A Webサービス・セキュリティ標準

- A.1 セキュリティ標準

例の一覧

図一覧

- 1-1 OWSMエージェントによって確保されるセキュリティ

- 1-2 OWSMアーキテクチャのコンポーネント

- 2-1 メッセージ保護のためのOWSMキーストア構成

- 2-2 STSトークンの交換

- 2-3 機密データのマスキング

- 2-4 ファイングレイン認可

- 2-5 大まかな認可

- 2-6 Oracle Service BusのPII暗号化

- 2-7 単一のSOAコンポジットのユースケース

- 2-8 JCAアダプタPIIのユースケース

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

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

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

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

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

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

表一覧

- 1-1 OWSMアーキテクチャのコンポーネント

- 2-1 リソース文字列の決定

- 2-2 リソース文字列の例

- 2-3 OESポリシーでサポートされている属性タイプ

- 3-1 ポリシー・カテゴリ

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

- A-1 Webサービスの標準および仕様のURL

はじめに

この項では、対象読者、このガイドの使用方法を説明し、ドキュメントのアクセシビリティについての情報を提供します。

対象読者

このガイドの対象読者は次のとおりです。

- Webサービスおよびセキュリティを管理するシステムおよびセキュリティ管理者

- Webサービスを開発し、Webサービスをデプロイする前にセキュリティのテストを行うアプリケーション開発者

- セキュリティ・ポリシーを作成するセキュリティ・アーキテクト

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracleサポートへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middleware Webサービスのドキュメント・セットにある次のドキュメントを参照してください。

- 『Webサービスの管理』

- 『Oracle JDeveloperによるアプリケーションの開発』のWebサービスの開発と保護に関する項

- Oracle Web Services Manager拡張可能アプリケーションの開発

- Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

- Oracle WebLogic ServerのJAX-WS Webサービスの開発

- Oracle WebLogic ServerのJAX-RPC Webサービスの開発

- Oracle Infrastructure Webサービスの開発

- Oracle Web Services Manager相互運用性ソリュー ション・ガイド

- 『Oracle SOA Suiteを使用したSOAアプリケーションの開発』

- Oracle JDeveloperによる、WebCenter Portalアセットおよびカスタム・コンポーネントの開発

- Oracle WebLogic ServerのWebLogic Webサービスの保護

- Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理

- Oracle WebLogic ServerのWebLogic Webサービスの理解

- Webサービスの理解

- Oracle Web Services Managerを使用したWebサービスの保護のユース・ケース

- Oracle WebLogic ServerのWebLogic Webサービス・リファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

次の各トピックでは、Oracle Web Services Manager (OWSM)の新機能と変更された機能およびこのガイドで説明する主な変更について紹介し、追加情報へのリンクを示します。

リリース12c (12.2.1.1)の新機能と変更された機能

この項では、リリース12c (12.2.1.1)での新機能および変更された機能について説明します。

修正や訂正などのマイナー更新がこのドキュメントに対して行われました。

リリース12c (12.2.1)の新機能と変更された機能

このドキュメントに記載されているOracle Fusion Middleware 12c (12.2.1)の新機能と変更された機能は次のとおりです。

- RESTおよびSOAPのサービスおよびクライアントに対するOAuth 2.0のサポート詳細は、「RESTおよびSOAPのサービスおよびクライアントのOAuth 2.0の理解」を参照してください。

- 資格証明およびキーストアの管理のためのREST APIが導入されました。詳細は、「資格証明およびキーストアの管理のためのREST APIの理解」を参照してください。

リリース12c (12.1.3)の新機能と変更された機能

このドキュメントに記載されているOracle Fusion Middleware 12c (12.1.3)の新機能と変更された機能は次のとおりです。

- 次のようなセキュリティ拡張。

- Oracle Entitlements Server (OES)とOWSMの統合。詳細は、「Oracle Entitlements Serverを使用したファイングレイン認可の概要」.を参照してください。

- SOAコンポジットの個人の身元を特定する情報(PII)、およびSOAアダプタとOracle Service Bus JCAアダプタを保護する機能。詳細は、「個人の身元を特定する情報の概要」を参照してください。

- Oracle Service BusとOracle SOA Suite (SOAP/RESTful WebサービスとJCAアダプタ)、およびOracle Enterprise Schedulerのサポート。これらのコンポーネントについては、必要に応じてこのドキュメント全体を通して言及しています。これらのコンポーネントにOWSMポリシーをアタッチする際に使用するポリシー・サブジェクトは、「ポリシー・サブジェクトの理解」で指定されています。

リリース12c (12.1.2)の新機能と変更された機能

このドキュメントにおける、Oracle Fusion Middleware 12c (12.1.2)の新機能と変更された機能は次のとおりです。

- 次のようなセキュリティ拡張。

- セキュア通信。「セキュア通信の概要」を参照してください。

- Kerberosセキュリティの強化(資格証明の委任、SPNEGOを使用したシングル・サインオンなど)と導出キーのサポート。「Kerberosプロトコルの概要」.を参照してください。

- Digest認証。「Digest認証について」を参照してください。

- フェデレーテッドSTS信頼およびトークン・キャッシュのサポート。「Webサービス信頼性の理解」を参照してください。

- Oracle Web Services Manager (OWSM)ポリシーを使用したRESTful Webサービス・セキュリティ。「Webサービス・ポリシーの理解」を参照してください。

- ポリシーの新たなカテゴリ。「表 3-1」を参照してください。

- 新規および更新されたサブジェクト・タイプ。「表 3-2」を参照してください。

リリース12c (12.1.2)でのこのドキュメントにおけるその他の重要な変更

このガイドは12c (12.1.2)でいくつかの点が更新されました。次の表に、追加または変更された項を示します。

- Oracle Fusion Middleware 11gで提供されている『Webサービスのためのセキュリティおよび管理者ガイド』は、このリリースでは次の3つのドキュメントに分割されました。

- Oracle Web Services Managerの理解(このドキュメント)

- Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理

- 『Webサービスの管理』

- 「Oracle Web Services Managerの概要」は、OWSM 12cの機能とアーキテクチャを反映するように更新されました。

- 図3-5で説明しているポリシー・インターセプタ・パイプラインは、12cでサポートしているすべてのポリシー・インターセプタを反映するように更新されました。

- 直接ポリシー・アタッチメントとグローバル・ポリシー・アタッチメントの説明が補強されました。「ポリシー・サブジェクトへのポリシーのアタッチの概要」を参照してください。

1 Oracle Web Services Managerの概要

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

詳細は、次の項を参照してください。

- Oracle Web Services Managerの概要

- Oracle Web Services Managerの機能の概要

- Oracle Web Services Managerのアーキテクチャの概要

このマニュアルおよびこの他のマニュアルに、なじみのない用語が出てきた場合は、用語集で定義を確認してください。

1.1 Oracle Web Services Managerの概要

Oracle Web Services Manager (OWSM)を使用すると、実行中のビジネス・プロセスを中断させることなく、ポリシーの変更をリアルタイムで施行できるため、ビジネスにおける俊敏性が確保され、セキュリティ上の問題やセキュリティ違反に即座に対応できます。

図1-1に示すように、OWSMは、クライアント・エージェントを介して最前線のセキュリティを確保することによってWebサービス・クライアントを保護するとともに、サーバー・エージェントを介して最後部のセキュリティを確保することによってWebサービスを保護します。Webサービスが企業イントラネットの内部からのみアクセス可能な場合でも、通常は認証と認可を必要とします。また、多くの場合、規制遵守に対処するための監査も必要です。

図1-1 OWSMエージェントによって確保されるセキュリティ

OWSMでは、Webサービスをポリシー駆動によって集中管理できるとともに、ローカルでポリシーを施行できます。OWSMには、組織全体でのWebサービスの一貫性のある管理と保護を実現するポリシー・フレームワークが備わっています。

このポリシー駆動アプローチの利点は次のとおりです。

- セキュリティを宣言的で外部化されたものにすることが可能です。

- 実行中のビジネス・プロセスを中断させることなく、ポリシーの変更をリアルタイムで施行できるため、ビジネスにおける俊敏性が確保され、セキュリティ上の問題やセキュリティ違反に即座に対応できます。

- 開発者は、セキュリティ仕様およびセキュリティ実装の詳細を意識する必要がなくなります。

OWSMによって、次のことが可能になります。

- 複数のWebサービスに適用する宣言的なポリシーの集中的な定義および格納。

- 構成可能なエージェントを介した、ローカルでのポリシーの施行。

- 認証や認可の失敗などの実行時のセキュリティ・イベントの監視。

OWSMを使用して、次のカテゴリのOracle Webサービスを保護できます。

- Oracle Infrastructure Webサービス—SOA、Application Development Framework (ADFおよびWebCenter)、Oracle Service BusおよびOracle Enterprise Schedulerの各サービス

- Java EE Webサービス: SOAP (JAX-WS)サービスおよびRESTful (JAX-RS) Webサービス

世界中の企業がイントラネット環境およびインターネット環境の両方において、Webサービスを使用してサービス指向アーキテクチャ(SOA)を積極的にデプロイしています。Webサービスには従来の方法(オブジェクトの配布やカスタム・ソフトウェアなど)に比べて多くの利点がありますが、相互接続されたWebサービスのネットワークをデプロイするには、特にセキュリティと管理の面で依然として重大な課題があります。

1.2 Oracle Web Services Managerの機能の概要

次に示すように、OWSMは様々なポリシーおよび管理機能を備えています。

- ポリシー管理:

- グローバル・ポリシー・アタッチメントと直接ポリシー・アタッチメント。

- 設計時およびデプロイ後のポリシー・アタッチメント。

- 1つのWebサービスまたはクライアントへの複数のポリシーのアタッチ/デタッチ機能。

- クライアント・ポリシーの自動選択。

- 複数のWebサービス間でのアイデンティティの伝播。

- WSDLでのポリシー通知。

- 監視/管理:

- 集中的な管理、監査およびレポート作成。

- ポリシーのバージョニングとロールバック。

- パフォーマンス管理(サービス、ポート、操作などのメトリック、ポートごとのポリシー依存性、セキュリティ違反数、起動数など)。

- ポリシーのエクスポートとインポート。

- ポリシーの影響分析。

- サポートされているセキュリティ標準:

- 様々なセキュリティ標準(表A-1を参照)をサポート。

- 事前定義された再利用可能なポリシー(セキュリティ・ポリシー、信頼性ポリシー、アドレス・ポリシー、管理ポリシー、MTOMポリシーなど)。

- カスタムのポリシー拡張。

OWSMでは、ポリシーのアタッチメントを設計時とデプロイ後の両方でサポートしているため、開発者とシステム管理者のどちらもポリシーをアタッチできます。

- 開発者は、Oracle JDeveloperのコンテキスト・メニューおよびプロパティ・インスペクタからOWSMポリシーをアタッチできます。詳細は、『Oracle JDeveloperによるアプリケーションの開発』のWebサービスの開発と保護に関する項を参照してください。

- システム管理者は、Oracle Enterprise Manager Fusion Middleware ControlおよびWLSTを介してOWSMを活用できます。OWSMポリシー・マネージャを使用してポリシーを集中的に定義し、実行時にローカルでOWSMポリシーを施行できます。

OWSMを使用して実行できる個別タスクの例を次に示します。

- WS-Securityの処理(暗号化、復号化、署名、署名検証など)。

- LDAPディレクトリに対する認証および認可ポリシーの定義。

- 複数のWebサービス全体に単一トランザクションで使用されるアイデンティティを伝播するための標準セキュリティ・トークン(SAMLトークンなど)の生成。

- 様々なフォルダにポリシーを作成することによる、異なるネームスペースへのポリシーのセグメント化。

- ログ・ファイルの調査。

1.3 Oracle Web Services Managerのアーキテクチャの概要

Oracle Web Services Manager (OWSM)エージェント、ポリシー・マネージャおよびリポジトリは、OWSMアーキテクチャの主要なコンポーネントです。

図1-2は、主要なOWSMコンポーネントおよびOracle Fusion Middleware Controlコンソールの間の相互作用を示します。

注意:

OWSMポリシーのサブセットがRESTful Webサービスに対してサポートされています。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のRESTful Webサービスに対してサポートされているOWSMポリシーに関する項を参照してください。図1-2に示すポリシー・インターセプタ・タイプの一部は、このサブセットには含まれません。

図1-2 OWSMアーキテクチャのコンポーネント

表1-1に、図1-2内のOWSMコンポーネントについて説明し、図内でのその用途を示します。

表1-1 OWSMアーキテクチャのコンポーネント

OWSMコンポーネント

説明

Oracle Enterprise Manager Fusion Middleware Control。

管理者がOWSMの機能にアクセスして、Webサービスを管理、保護および監視できるようにします。

Oracle JDeveloper

Webサービスのエンドツーエンド開発に使用できるフル機能のJava IDEを提供します。開発者は、ビジュアルな宣言型ツールを使用してOracle SOA、ADF、WebCenterおよびWebLogic Java EE Webサービスを構築し、それらをOracle WebLogic Serveのインスタンスに自動的にデプロイして、ただちにWebサービスの動作をテストできます。また、JDeveloperを使用して、WSDL記述からWebサービスの作成を行うこともできます。JDeveloperはAntに対応しています。このツールを使用して、クライアントのアセンブリや、サービスのアセンブリおよびデプロイ用のAntスクリプトを構築および実行することができます。詳細は、Oracle JDeveloperのオンライン・ヘルプを参照してください。JDeveloperのインストールの詳細は、『Oracle JDeveloperのインストール』を参照してください

WebLogic Scripting Tool(WLST)

管理者がWebサービスを表示、構成し、コマンドラインからWebサービス・ポリシーを管理できるようにします。詳細は、WebLogic Server WLSTコマンド・リファレンスを参照してください。

OWSMポリシー・マネージャ

OWSMリポジトリの事前定義済ポリシーやカスタム・ポリシーなど、ポリシーの読取り/書込みを行います。

OWSMエージェント

ポリシー・インターセプタ・パイプラインによるポリシーの強制を管理します。

ポリシー・インターセプタ

ポリシーを施行します。詳細は、「ポリシー実行の仕組みの理解」を参照してください。

OWSMリポジトリ

ポリシー、ポリシー・セット、アサーション・テンプレート、ポリシーの使用状況データなどのOWSMメタデータを格納します。OWSMリポジトリは、データベースとして(本番用)またはファイル・システム内のファイルとして(JDeveloperでの開発用)利用できます。

Oracle Fusion Middlewareデータベース

OWSMリポジトリのデータベース・サポートを提供します。

このドキュメントの後続の章では、OWSMポリシー・フレームワークの概念に関する情報を提供するとともに、セキュリティの概念について説明します。また、このドキュメントには、Oracle Infrastructure Webサービスのセキュリティ標準に関する項も含まれます。

コンパニオン・ドキュメントであるOracle Web Services ManagerによるWebサービスと保護とポリシーの管理およびWebサービスの管理では、OWSMを使用したWebサービスの保護方法と管理方法についてそれぞれ説明しています。

2 Webサービス・セキュリティの概念の理解

この章では、Webサービス・セキュリティの概念について説明します。Webサービス・セキュリティには、認証、認可、メッセージ保護など、いくつかの要件が含まれます。

この章の内容は次のとおりです。

- Webサービスのセキュリティについて

- トランスポート・レベルおよびアプリケーション・レベルのセキュリティの理解

- 認証の理解

- 認可の理解

- メッセージ保護の概要

- セキュリティおよび認証での鍵および証明書のロールの概要

- OWSMでの資格証明ストアの使用の仕組みの理解

- セキュリティ・ポリシーの理解

- セキュリティ・トークンの概要

- セキュア・アタッチメントの理解

- セキュア通信の概要

- Kerberosプロトコルの概要

- Web Services Addressingの理解

- Webサービス信頼性の理解

- Webサービスの信頼性のあるメッセージングの理解

- Oracle Entitlements Serverを使用したファイングレイン認可の概要

- 個人の身元を特定する情報の概要

- RESTおよびSOAPのサービスおよびクライアントのOAuth 2.0の理解

- 資格証明およびキーストアの管理のためのREST APIの理解

注意:

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

この項では主に、SOAPを使用したWebサービスについて説明します。

2.1 Webサービスのセキュリティについて

Webサービスには疎結合の接続という特性があり、またオープン・アクセス(主にHTTP)が使用されるため、Webサービスによって実装されるSOAでは、次に示す一連の新たなセキュリティ要件が追加されます。

Webサービス・セキュリティの主要なコンポーネントは次のとおりです。

- 認証: ユーザーが表明しているとおりのユーザーであるかを検証します。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。資格証明には次のものがあります。

1. ユーザーが所有しているもの。たとえばパスポート(実世界)やスマート・カード(ITの世界)など、信頼できる機関が発行した資格証明。

2. ユーザーが知っているもの。たとえばパスワードなどの共有の秘密鍵。

3. ユーザーの特性。たとえばバイオメトリック情報。

複数のタイプの資格情報を組み合せて使用することは、強い認証と呼ばれます。たとえば、ATMカード(ユーザーが持っているもの)とPINやパスワード(ユーザーが知っていること)を使用する場合などです。詳細は、「認証の理解」を参照してください。

- 認可(またはアクセス制御): 認証されたユーザーの権限に基づいて、特定のリソースへのアクセスを許可します。権限は1つ以上の属性によって定義されます。属性とはユーザーのプロパティまたは特性のことです。たとえば、「Marc」はユーザーで、「会議の発言者」は属性です。詳細は、「認可の理解」を参照してください。

- 機密保護、プライバシ: 情報の機密性を保ちます。Webサービス・リクエストや電子メールなどのメッセージと、送信ユーザーおよび受信ユーザーのアイデンティティに、機密を保つ方法でアクセスします。メッセージのコンテンツを暗号化し、送信ユーザーおよび受信ユーザーのアイデンティティを不明瞭化することで機密保護とプライバシが実現されます。詳細は、「メッセージ保護の概要」を参照してください。

- 整合性、否認防止: 送信ユーザーがメッセージにデジタルで署名することによって、メッセージが転送中に変更されないようにします。デジタル署名を使用することによって、署名が検証され、否認防止が実現されます。署名内のタイムスタンプにより、このメッセージが有効期限後にリプレイされることを防ぎます。詳細は、「メッセージ保護の概要」を参照してください。

Webサービス・セキュリティの要件には、資格証明の仲介(信頼できる環境でのセキュリティ・トークンの交換)およびサービスの機能と制約(Webサービスがどの環境で何を実行できるかを定義する)も含まれます。

多くの場合、OWSMのようなWebサービス・セキュリティ・ツールは、公開鍵インフラストラクチャ(PKI)環境に依存します。PKIでは、暗号鍵(データの暗号化または復号化に使用される数学関数)を使用します。鍵は秘密鍵、公開鍵のいずれかになります。非対称暗号モデルでは、受信ユーザーの公開鍵を使用してプレーン・テキストが暗号化され、受信ユーザーの対応する秘密鍵を使用して暗号文が復号化されます。また、メッセージに署名することによって秘密鍵がデジタル署名の作成に使用され、公開鍵が署名の検証に使用されます。公開鍵証明書(または略して証明書)は、公開鍵の整合性を保証するために使用されます。

Webサービス・セキュリティ要件は、トランスポート・レベル(Secure Socket Layer)およびXMLフレームワークに依存するアプリケーション・レベルの両方で、業界標準によってサポートされています。

Webサービスでサポートされている仕様および標準の詳細は、「Webサービス・セキュリティ標準」を参照してください。

注意:

オラクル社は新しい標準、特にOASIS Web Services Secure Exchange技術委員会が主導する仕様の普及に貢献しています。

Oracle Web Services Manager (OWSM)は、異種の環境においてWebサービスのセキュリティを定義して実装できるように設計されています。たとえば、認証、認可、メッセージの暗号化と復号化、署名の生成と検証、および複数のWebサービス間のアイデンティティ伝播などを使用して、1つのトランザクションが完成します。

Webサービス・セキュリティ要件をまとめると次のようになります。

- トランスポート・セキュリティの使用。Webサービス・コンシューマとWebサービス・プロバイダ間の通信チャネルを保護します。

- メッセージ・レベルのセキュリティの使用。メッセージ部分のデジタル暗号化によって機密性を確保し、デジタル署名によって整合性を確保します。また、ユーザー名、X.509またはSAMLトークンを要求して認証を実行します。

2.2 トランスポート・レベルおよびアプリケーション・レベルのセキュリティの理解

セキュリティの概念は、トランスポート・レベルに関連する概念とアプリケーション・レベルに関連する概念に分けることができます。トランスポート・レベルのセキュリティでは、アプリケーション間の通信チャネルが保護されます。トランスポート・レベルのセキュリティ・プロトコルの例として、Secure Socket Layer (SSL)があります。このプロトコルは、Transport Layer Security (TLS)と呼ばれることもあります。TLSは、Internet Engineering Task Force (IETF)によって公式に標準化されたSSLバージョンです。最も広く使用されている、このトラスポート・レベルのデータ通信プロトコルでは、次の機能が提供されます。

- 認証(通信は信頼できる2つのパーティ間に確立されます)。

- 機密保護(交換されるデータは暗号化されます)。

- メッセージ整合性(データが破損しているかどうか確認されます)。

- クライアントおよびサーバー間での安全な鍵の交換。

SSLでは、通信チャネルは保護されますが、転送中でないデータは保護されません。このため、マルチステップ・トランザクション中の攻撃に対して環境が脆弱になります。(SSLでは、エンドツーエンドではなくポイントツーポイントのセキュリティが提供されます。)

SSLは次の3つのモードで使用できます。

- 認証なし: クライアントもサーバーもお互いに認証しません。証明書も送信または交換されません。この場合は、機密保護(暗号化/復号化)のみが使用されます。

- 一方向認証(またはサーバー認証): サーバーのみがクライアントに対して自身を認証します。サーバーは、自身が信頼できることを検証する証明書をクライアントに送信します。この方法は、オンライン・バンキングなどのインターネット・トランザクションで使用されます。

- 双方向認証(または相互認証): クライアントとサーバーの両方が、相互に証明書を送信することでお互いに認証します。この方法は、プロキシとWebサービス・エンドポイント間での攻撃の防止に必要です。

SSLでは、秘密鍵および公開鍵暗号化を組み合せて通信を保護します。SSLトラフィックでは、暗号化と復号化に秘密鍵が使用され、通信に関わるパーティの相互認証で公開鍵の交換が行われます。

アプリケーション・レベルのセキュリティはトランスポート・レベルのセキュリティを補完します。アプリケーション・レベルのセキュリティでは、XMLフレームワークに基づいて、メッセージの機密保持、整合性、信頼性(メッセージ保護とも呼ばれる)、メッセージ構造、信頼の管理およびフェデレーションが定義されます。アプリケーション・レベルのセキュリティのこれらのコンポーネントについては、「メッセージ保護の概要」、「認証の理解」および「認可の理解」の各項で詳しく説明します。

2.3 認証の理解

認証とは、ユーザーが表明しているとおりのユーザーであることを検証することです。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。資格証明には次のものがあります。

- ユーザーが所有するもの。たとえば、信頼できる機関によって発行された資格証明(デジタル証明書など)、標準のSecurity Assertion Markup Language (SAML)トークン、Kerberosトークン。

- ユーザーが知っているもの。たとえばパスワードなどの共有の秘密鍵。

- ユーザーの特性。たとえばバイオメトリック情報。

複数のタイプの資格情報を組み合せて使用することは、強い認証と呼ばれます。たとえば、ATMカード(ユーザーが持っているもの)とPINやパスワード(ユーザーが知っていること)を使用する場合などです。

SAMLは非常に興味深いセキュリティ・トークンであり、認証と認可の両方がサポートされています。SAMLは、XMLドキュメントを使用してインターネット上でセキュリティ情報を共有するオープン・フレームワークです。SAMLには次の3つの部分が含まれます。

- SAMLアサーション: 認証および認可情報を定義する方法。

- SAMLプロトコル: 必要なアサーションを要求(SAMLリクエスト)し、取得(SAMLレスポンス)する方法。

- SAMLバインディングおよびSAMLプロファイル: SAMLアサーションを業界標準のトランスポートおよびメッセージングのフレームワークに組み込む方法。

SAMLの完全仕様は、ブラウザベースのフェデレーションにおいて使用されます。それに対し、OWSMのようなWebサービス・セキュリティ・システムでは、SAMLアサーションのみが使用されます。プロトコルおよびバインディングは、WS-Securityおよびトランスポート・プロトコル(HTTPなど)により提供されます。

SAMLアサーションおよびアサーション識別子への参照はWS-Securityヘッダー要素に含まれ、SOAPエンベロープのヘッダー要素に含まれることになります(WS-Security SAMLのトークン・プロファイルに記述されます)。SAMLセキュリティ・トークンは、特にアイデンティティ伝播が必須である場合に関連します。

2.3.1 Digest認証について

OWSMは、ユーザー名トークン認証ポリシーでDigestベースの認証をサポートしています。

Digest認証は、WebアプリケーションがサーバーにDigest(パスワード、nonceおよびタイムスタンプの暗号ハッシュ)を送ることによって、Webサービスに対して自身を認証する認証メカニズムです。

Digest認証の使用時には、次の処理が行われます。

1. クライアントがWebサービスに対して未認証リクエストを実行します。サーバーは、Digest認証をサポートしていることを示すDigest認証チャレンジ付きのレスポンスを送信します。

2. クライアントはnonceを生成し、それをタイムスタンプ、Digestおよびユーザー名とともにサービスに送信します。ダイジェストは、パスワード、nonce、およびタイムスタンプの暗号ハッシュです。

3. サーバー自身も、パスワード(サービス・ストアから取得)、nonceおよび(メッセージの)タイムスタンプからハッシュを生成します。サーバーが生成したハッシュがリクエスト内のハッシュと一致すると、リクエストが許可されます。

ダイジェスト認証の利点は、リプレイ攻撃に対する抵抗力です。ダイジェスト認証を実装すると、使用されたnonce/タイムスタンプのキャッシュが、指定した期間保持されます。指定したタイムスタンプより古いタイムスタンプのリクエストはすべて拒否されます。また、キャッシュに保持されている最新のタイムスタンプ/nonceペアと同じタイムスタンプ/nonceペアを使用するリクエストもすべて拒否されます。WebLogic Serverでは、このキャッシュはデータベースに格納されます。

2.4 認可の理解

多くの場合、認証はユーザーにWebサービスへのアクセスを許可するかどうかを決定する最初の手順となります。ユーザーが認証されたら、2番目の手順は、ユーザーがWebサービスへのアクセスを認可されていることを検証することです。

認可(アクセス制御とも呼ばれる)とは、認証されたユーザーの資格に基づいて特定のリソースへのアクセス権を付与することです。権限は1つ以上の属性によって定義されます。属性とはユーザーのプロパティまたは特性のことです。たとえば、「Marc」はユーザーで、「会議の発言者」は属性です。

認可によって、認証されたクライアントがアクセスできる操作を決定できます。認可には次の3つの基本アプローチがあります。

- ロール・ベース: ロール・ベースのセキュリティの基盤となる概念は、プリンシパルと呼ばれるアイデンティティのセットをロールにグループ化し、各ロールにポリシーを割り当てることができる、というものです。

- アイデンティティ・ベース: アイデンティティ・モデルでは、クライアントの認可のために、クレームとポリシーを管理できます。このアプローチでは、認証されたユーザーの資格証明に含まれているクレームを検証できます。これらのクレームは、Windows Communication Foundation (WCF)サービスのための認証ポリシーのセットと比較できます。クライアントが提供するクレームに応じて、サービスは操作またはリソースへのアクセス権を付与するか、アクセスを拒否します。アイデンティティ・モデルは、ファイングレイン認可に役立ち、発行トークン認証の使用時に最も有効です。

- リソース・ベース: Windowsアクセス制御リスト(ACL)を使用して、個別リソースが保護されます。

2.5 メッセージ保護の概要

この項では、メッセージ保護およびデータの暗号化のプロセスの様々な概念およびメッセージ署名について説明します。

次のトピックが含まれています:

- メッセージ保護の理解

- メッセージの暗号化について

- メッセージの署名(XML署名)について

2.5.1 メッセージ保護の理解

メッセージ保護には、メッセージ機密保護とメッセージ整合性の2つの概念があります。

メッセージの機密保護には、送信ユーザーおよび受信ユーザーのアイデンティティのみでなく、データの機密性も関係します。メッセージのコンテンツを暗号化し、送信ユーザーおよび受信ユーザーのアイデンティティを不明瞭化することで機密保護が実現されます。送信者は受信者の公開鍵を使用してメッセージを暗号化します。メッセージは受信者の秘密鍵でのみ正常に復号化できるため、送信中に第三者によってメッセージが読み取られることはありません。Webサービス・クライアントが使用できるように、Webサービスのbase64エンコード形式の公開証明書がWSDLで発行されます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のサービス・アイデンティティ証明書拡張の使用に関する項を参照してください

メッセージ整合性は、認証局がメッセージにデジタルで署名することにより実現します。デジタル署名は、SOAPメッセージの送信者を認証したり、SOAPメッセージの整合性(SOAPメッセージが送信中に変更されていないこと)を保証したりするために使用されます。

デジタル署名がSOAPメッセージに適用されると、メッセージから一意のハッシュが生成されます。このハッシュは送信者の秘密鍵で暗号化されます。メッセージを受信すると、受信者は送信者の公開鍵を使用してハッシュを復号化します。

注意:

通常、証明書を検証するために受信者のキーストアに送信者の公開鍵を格納しておく必要はありません。キーストアにルート証明書があれば、証明書チェーンを検証できます。ただし、ThumbprintやSerialIssuerメカニズムなど、メッセージに送信者の公開鍵が存在しない場合は、送信者の公開鍵を受信者のキーストアに格納する必要があります。

送信者のみが秘密鍵を使用してハッシュを暗号化できるため、これで送信者を認証できます。受信者はメッセージとともに送信されるハッシュと、受信者側で生成するハッシュを比較できるため、SOAPメッセージが送信中に改ざんされていないことを確認できます。

次の内容を実行することで、メッセージ保護アサーション・テンプレートおよび事前定義済ポリシーを、リクエストやレスポンス・メッセージの保護に使用できます。

- メッセージの署名

- メッセージの暗号化

- メッセージの署名および暗号化

- メッセージの復号化

- 署名の検証

- メッセージの復号化と署名の検証

2.5.2 メッセージの暗号化について

XML暗号化の仕様には、データを暗号化し、その結果をXMLで表すためのプロセスが記述されています。

XML暗号化では、具体的に次のことが定義されています。

- デジタル・コンテンツが暗号化および復号化される仕組み。

- 暗号化キーの情報が受信者に渡される仕組み。

- 暗号化を簡略化するために暗号化されたデータが識別される仕組み。

XMLドキュメントは、全体または一部を暗号化できます。

次の例では、XMLで表現したクレジット・カード・データについて説明します。

<PaymentInfo xmlns="http://www.example.com/payment">
<CreditCard>
<Name>John Smith</Name>
<CreditCardNumber>4019 2445 0277 5567</NCreditCardNumber>
<Limit>5000</Limit>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>

次の例では、同じXMLスニペットを、クレジット・カード番号を暗号化して暗号値で表したものを示しています。

<PaymentInfo xmlns='http://www.example.com/payment">
<CreditCard>
<Name>John Smith</Name>
<CreditcardNumber>
<EncryptedData xmlns="http://www..." Type="http://www...">
<CipherData>
<CipherValue>A23B4...5C56</CipherValue>
</CipherData>
</EncryptedData>
<Limit>5000</Limit>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>

2.5.3 メッセージの署名(XML署名)について

XML署名の仕様には、署名の処理ルールと構文が記述されています。XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは、送信者の秘密鍵を使用して署名され、署名は送信者の公開鍵を使用して検証されます。

署名の検証は、非対称鍵または対称鍵を使用して行われます。XML署名は、署名エンティティの否認防止も保証し、署名後にメッセージが変更されていないことを証明します。

次の例に示すように、署名はドキュメント全体にも、ドキュメントの一部のみにも適用できます。

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<!-- The signedInfo element allows us to sign any portion of a
document -->
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www..."/>
<SignatureMethod Algorithm="http://www..."/>
<Reference URI="#Body">
<DigestMethod Algorithm="http://www..."/>
<DigestValue>o+jtqlieRtF6DrUb...X8O9M/CmySg</DigestValue>
</Reference>
</SignedInfo>
<!-- Following is the result of running the algorithm over the
document. If changes are made to the document, the SignatureValue is
changed. The security application verifies the SignatureValue,
extracts the X.509 cert and uses it to authenticate the user -->
<SignatureValue>oa+ttbsvSFi...EtRD2oNC5</SignatureValue>
<KeyInfo>
<KeyValue>
<!-- Following is the public key that matches the private key
that signs the document -->
<RSAKeyValue>
<Modulus>5TT/oolzTiP++Ls6GLQUM8xoFFrAlZQ...</Modulus>
<Exponent>EQ==</Exponent>
</RSAKeyValue>
</KeyValue>
<!-- Following is the certificate -->
<X509Data>
<X509Certificate>wDCCAXqgAwIBAgI...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>

2.6 セキュリティおよび認証での鍵および証明書のロールの概要

Webサービスを構成する前に、必要な秘密鍵および証明書のタイプ、鍵およびキーストアの名前を決定する必要があります。それから、それらに従って環境を設定できます。

SSLセキュリティ・ポリシーによるメッセージ保護および認証、またはメッセージ保護セキュリティ・ポリシーを使用するには、キーストアおよびトラストストアを設定する必要があります。認証のみのセキュリティ・ポリシーでは鍵は不要であることに注意してください。認証ポリシーの詳細は、「OWSMポリシー・フレームワークの理解」を参照してください。

キーストアには、エンティティ秘密鍵およびその秘密鍵に関連付けられた証明書が含まれます。トラストストアには、認証局(CA)からの証明書、またはこのエンティティが信頼する他のエンティティからの証明書が含まれます。キーストアとトラストストアは、たとえばOracle Web Services Manager (OWSM)などを使用して、共通のストアで一緒に管理できます。

詳細は、次のトピックを参照してください。

- 秘密鍵と証明書について

- 様々なセキュリティ・ポリシーでの秘密鍵および証明書の使用方法の理解

- OWSMでのJKSキーストア用のキーストアおよびキー・パスワードの特定の仕組み

- SSLポリシー用の秘密鍵および証明書について

- メッセージ保護ポリシー用の秘密鍵および証明書の設定について

2.6.1 秘密鍵と証明書について

サーバーのIDと信頼は、秘密鍵、デジタル証明書、および信頼性のある認証局によって確立され、検証されます。

SSLでは、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバーの公開鍵と秘密鍵が生成されます。公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号化でき、公開鍵で検証されたデータは対応する秘密鍵でのみ署名できます。秘密鍵は注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを復号化できます。

公開鍵は、公開鍵の所有者を示す他の情報(名前、住所および電子メール・アドレスなど)とともにデジタル証明書に埋め込まれています。秘密鍵およびデジタル証明書は、サーバーのアイデンティティを提供します。

デジタル証明書に組み込まれたデータは認証局によって検証され、その認証局のデジタル証明書でデジタル署名されます。十分に認知された認証局には、VerisignやEntrust.netなどがあります。信頼できる認証局(CA)の証明書により、証明書の信頼性が確立されます。

SSL接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Webブラウザ、サーバー、およびその他のSSL対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバーの証明書は、サーバーのデジタル証明書内のホスト名がクライアントによって指定されたURLと一致しない場合は無効になります。

それぞれの環境で使用可能な様々なタイプの信頼できる証明書と、その長所および短所は次のとおりです。

- 自己署名証明書 — 自己署名証明書は、作成元のエンティティによって署名される証明書です。
長所:

- JKSキーストアのkeytoolコマンドなどを使用して自分で生成できるため、容易に生成できます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の秘密鍵の生成とJavaキーストアの作成に関する項を参照してください。

- 自身で生成した新しい証明書のみを使用するかぎり、本番で使用できます。

短所:

- 相互に通信する必要がある多数のクライアントおよびサービスが存在する場合に、自己署名証明書は短期間で管理が難くなることがあります。たとえば、2つのサービスと通信する3つのクライアントが存在する場合に、両サービスについて秘密鍵および自己署名証明書を生成し、3つのクライアントすべてのトラストストアにその2つの証明書をインポートする必要があります。

- デモ用認証局(CA)署名証明書— WebLogic Serverには、開発専用のデモ用秘密鍵、デジタル証明書および信頼できる認証局のセットが含まれています。
長所:

- 開発環境内のデフォルトのWebLogic Serverインストールで使用可能であり、そのために構成されているので、簡単に使用できます。

短所:

- 本番環境では決して使用できません。デモ用証明書CAの秘密鍵は、WebLogic Serverのすべてのインストールで使用可能です。したがって、各インストールで同じ鍵を使用してデモ用CA署名証明書を生成できます。したがって、こうした証明書は信頼できません。

- 内部CA署名証明書 — 内部CA署名証明書は、イントラネット用に設定可能な内部CAを使用して自身で発行する証明書です。このタイプの証明書は、サービスがほとんど内部専用である場合に使用できます。
長所:

- 証明書を自身で作成するので、証明書の発行プロセスを完全に制御できます。証明書の発行先、証明書の有効期間などを制御できます。たとえば、パートナに証明書を発行する場合に、優良なパートナに発行先を限定できます。

短所:

- すべてのクライアントでトラストストアに内部CAルート証明書がインポートされていることを確認する必要があります。

- 外部CA署名証明書 — 外部CA署名証明書は、VerisignやEntrust.netなどの信頼できるCAによって発行された証明書です。このタイプの証明書は、サービスが外部向けである場合に使用すべきです。
長所:

- ほとんどの場合、クライアントはこうした外部CAを信頼するようにすでに設定されています。したがって、このようなクライアントでトラストストアを変更する必要はありません。

短所:

- 証明書発行プロセスを制御することはできません。

2.6.2 様々なセキュリティ・ポリシーでの秘密鍵および証明書の使用方法の理解

秘密鍵の使用を必要とするOWSMセキュリティ・ポリシーは、メッセージ保護および認証の2つの側面に対応します。

- メッセージ保護には、メッセージ機密保護とメッセージ整合性の2つの概念があります。メッセージの機密保持では、データの機密性を維持します。そのために、メッセージのコンテンツは暗号化されます。メッセージ整合性では、送信ユーザーがメッセージにデジタル署名することによって、転送中にメッセージが変更されないことを確認します。

- 認証では、ユーザーが表明しているとおりのユーザーであることを検証します。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。

インストールに含まれている事前定義済のOWSMポリシーでは、メッセージ保護および認証の様々なオプションをサポートしています。これらのオプションについては、次に示す項で説明します。

注意:

OWSMポリシーで使用される命名規則により、使用オプションのタイプが識別されます。たとえば、ポリシーoracle/wss10_username_token_with_message_protection_service_policyは、wss10 Webサービス標準を使用し、認証のためにusername_tokenを必要とするメッセージ保護サービス・ポリシーです。ポリシーの命名規則の詳細は、「WSMリポジトリで作成されたドキュメントの推奨命名規則について」を参照してください。

詳細は、次のトピックを参照してください。

- メッセージ保護ポリシー・タイプの概要

- 認証トークン・ポリシー・タイプの概要

2.6.2.1 メッセージ保護ポリシー・タイプの概要

SSL、wss11およびwss10メッセージ保護ポリシーは、Oracle Web Service Managerでサポートされています。

- SSLポリシーについて

- wss11ポリシーについて

- wss10ポリシーについて

2.6.2.1.1 SSLポリシーについて

oracle/wss_saml_or_username_token_over_ssl_service_policyなど、SSLオプションを含むポリシーでは、メッセージ保護のために一方向SSLを使用します。

このタイプのポリシーを使用する場合、次のことを実行する必要があります。

- サービス側では、「SSLポリシー用の秘密鍵および証明書について」の説明に従って、SSL終端ポイントで秘密鍵を設定します。

- クライアント側では、サービスの鍵を信頼するようにトラストストアを設定します。

秘密鍵は、クライアントとサービスが共有セッション・キーについて同意したときに、SSLハンドシェイクのためのメッセージ保護に使用されます。SSLハンドシェイクの後は、秘密鍵は使用されず、クライアント間のトラフィックおよびサービスはすべて共有セッション・キーを使用して署名および暗号化されます。

SSLの構成方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のトランスポート・レベルのセキュリティ(SSL)の構成に関する項を参照してください。

2.6.2.1.2 wss11ポリシーについて

このタイプのポリシーでは、メッセージ保護にWS-Security 1.1を使用します。

wss11ポリシーを使用する場合、次のことを実行する必要があります。

- サービス側では、OWSMの「キーストアの構成」画面で、秘密鍵を設定し、「暗号化鍵の別名」として定義します。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したOWSMキーストアの構成に関する項を参照してください。

- クライアント側では、次のいずれかの方法でサーバー証明書を取得することにより、クライアント側の信頼を構成する必要があります。

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のサービス・アイデンティティ証明書拡張の使用に関する項の説明に従って、サービス・アイデンティティ証明書拡張を使用して、WSDLで発行されたサービスの公開証明書を使用します。また、サーバー証明書を発行したCAから、サーバー証明書自体またはルート証明書のいずれかをクライアントのトラストストアにインポートする必要があります。サーバー証明書について、任意の別名を選択できます。

- 選択した任意の別名を使用してクライアントのキーストアにサーバー証明書をインポートします。別名は、ポリシーのアタッチ時に構成オーバーライドを使用して、keystore.recipient.aliasプロパティにより指定します。この方法では、実際のサーバー証明書をインポートする必要があります。CAルート証明書をインポートすることはできません。

各リクエストに関して、次のことが実行されます。

1. クライアントは対称鍵を作成し、暗号化鍵の別名により構成されたサービスの公開鍵でこの対称鍵を暗号化した後、対称鍵によりメッセージ全体の暗号化および署名を行います。

2. サービスがこのメッセージを受信すると、まず暗号化された鍵を復号化し、次にメッセージ全体を復号化して検証します。

3. 次にWebサービスは、クライアントに返信するレスポンスの暗号化および署名のために、同じ対称鍵を使用します。

2.6.2.1.3 wss10ポリシーについて

このタイプのポリシーでは、メッセージ保護にWS-Security 1.0を使用します。

wss10ポリシーを使用する場合、次のことを実行する必要があります。

- クライアント側およびサービス側の両方で秘密鍵を設定します。クライアント側で署名鍵の別名を設定し、サービス側で暗号化鍵の別名および署名鍵の別名の両方を設定する必要があります。通常は、両方で同じ鍵を使用できます。

- クライアント側では、次のいずれかの方法でサーバー証明書を取得することにより、クライアント側の信頼を構成する必要があります。

- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のサービス・アイデンティティ証明書拡張の使用に関する項の説明に従って、サービス・アイデンティティ証明書拡張を使用して、WSDLで発行されたサービスの公開証明書を使用します。また、サーバー証明書を発行したCAから、サーバー証明書自体またはルート証明書のいずれかをクライアントのトラストストアにインポートする必要があります。サーバー証明書について、任意の別名を選択できます。

- 選択した任意の別名を使用してクライアントのキーストアにサーバー証明書をインポートします。別名は、ポリシーのアタッチ時に構成オーバーライドを使用して、keystore.recipient.aliasプロパティにより指定します。この方法では、実際のサーバー証明書をインポートする必要があります。CAルート証明書をインポートすることはできません。

- サービス側では、こうした証明書を直接インポートするか、こうした証明書を発行したCAをインポートすることにより、クライアントを信頼するようにサービスを構成する必要があります。

wss11オプションの場合と同様に、クライアントは対称鍵を作成した後、サービスの公開鍵により対称鍵を暗号化します。ただし、メッセージの暗号化のためにのみこの対称鍵を使用する点が異なり、メッセージの署名のためにはこの対称鍵は使用しません。そのかわりに、クライアントは、署名鍵の別名によって定義された独自の秘密署名鍵によりリクエスト・メッセージに署名し、サービスはその秘密署名鍵によりレスポンスに署名します。

2.6.2.2 認証トークン・ポリシー・タイプの概要

認証でサポートされるトークンは、ユーザー名、Kerberos、X.509証明書、SAML送信者保証、STSからのSAMLベアラーおよびSAML HOKトークンです。

認証の構成方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の認証の構成に関する項を参照してください。

注意:

次の各項において、「署名鍵の別名」という用語は、コンテキストに応じて意味が異なります。

- SAML送信者保証ポリシーでは、署名鍵の別名はSAMLアサーションの署名に使用される鍵です。これにより、SAMLアサーションの認証性が証明されます。またSAMLログイン・モジュールは、SAMLアサーションで指定されたユーザーをアサートします。

- wss10ポリシーでは、署名鍵の別名は、リクエストおよびレスポンス・メッセージの署名に使用される鍵で、それらがオンライン上で改ざんされることを防ぎます。

- X.509認証ポリシーでは、署名鍵の別名は特定のエンド・ユーザーの認証に使用される鍵です。

詳細は、次のトピックを参照してください。

- ユーザー名トークンについて

- Kerberosトークンについて

- X.509証明書トークンについて

- SAML送信者保証トークンについて

- STSからのSAMLベアラーおよびSAML HOKトークンについて

2.6.2.2.1 ユーザー名トークンについて

ユーザー名トークンは、ユーザー名やパスワードなどのBasic認証情報を伝達します。ユーザー名トークンが認証のみのポリシーとともに使用される場合、秘密鍵は使用されません。認証およびメッセージ保護を含むポリシーで使用された場合、メッセージ保護に必要な鍵が要求されます。

2.6.2.2.2 Kerberosトークンについて

Kerberosトークンは、バイナリ認証およびセッション・トークンから構成されます。Kerberosトークンが認証のみのポリシーとともに使用される場合、秘密鍵は使用されません。認証およびメッセージ保護を含むポリシーで使用された場合、メッセージ保護に必要な鍵が要求されます。

2.6.2.2.3 X.509証明書トークンについて

リクエスト・メッセージは、エンド・ユーザーの署名鍵により署名されます。クライアント側では、エンド・ユーザーの署名鍵により署名鍵の別名を構成する必要があります。

2.6.2.2.4 SAML送信者保証トークンについて

SAML送信者保証では、クライアントは自身の秘密署名鍵によりSAMLトークンに署名します。

SAML送信者保証トークンは、各メッセージ保護オプションとともに次のように使用します。

- SSLを使用: SAML送信者保証では双方向SSLが必要です。したがって、クライアント側でSSL秘密鍵およびサービス側で対応する信頼証明書を設定する必要があります。SSLがOracle HTTP Serverやロード・バランサなど、WebLogic Serverの前で終端する場合、WebLogic Serverに至るまでクライアント証明書が伝播するようにこうしたレイヤーを構成する必要があります。

- wss11を使用: 通常、wss11ではクライアント側の署名鍵は不要です。しかし、SAMLでwss11を使用する場合は、クライアント側で署名鍵を設定し、署名鍵の別名を使用して署名鍵を構成する必要があります。また、このクライアント証明書またはその発行者をサービスのトラストストアに追加する必要があります。

- wss10を使用: SAMLを使用するための追加設定は必要ありません。リクエストの署名のために使用される通常のクライアント署名鍵がSAMLトークンの署名にも使用されます。

注意:

SAML署名鍵を使用する場合には細心の注意が必要です。これは非常に強力な鍵であり、クライアント側で任意のユーザーを偽装できます。信頼できるDNリストを設定することにより、許容されるSAML署名者の数を制限するサーバー側の構成を検討してください。信頼できるDNの設定の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したSAMLの信頼できる発行者およびDNリストの構成に関する項を参照してください。

2.6.2.2.5 STSからのSAMLベアラーおよびSAML HOKトークンについて

これらのオプションでは、クライアントはSAMLトークンを作成しません。そのかわりに、SAMLトークンの作成および署名を行うのはSTSです。

STSからトークンを使用する場合、サービスのトラストストアにSTSの証明書またはその発行者を追加する必要があります。必要に応じて、信頼できるDNリストでSTSを構成できます。

2.6.3 OWSMでのJKSキーストア用のキーストアおよびキー・パスワードの特定の仕組み

OWSMは、JKSキーストアおよびキー・パスワードが資格証明ストア・フレームワーク(CSF)に含まれていることを前提とします。次に、このしくみを示します。

注意:

OPSSキーストア・サービスの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスを使用したキーと証明書の管理に関する項を参照してください。

- JKSキーストア・ファイルは、キーストアのパスワードによって保護されています。

- キーストア・ファイルは、0個以上の秘密鍵および0個以上の信頼できる証明書から構成されます。各秘密鍵は、独自のパスワードを持ちます(ただし、鍵のパスワードとキーストアのパスワードが同じであることが一般的です)。OWSMは、キーストアとキー・パスワードの両方を認識する必要があります。

- CSFは、それぞれが個別の名前を持つ多数のマップから構成されます。OWSMは、マップoracle.wsm.securityのみを使用します。

- 各マップ内部で、複数のcsf-keyエントリから対応する資格証明にマッピングされています。csf-keyは、簡単な名前ではあっても、様々なタイプの資格証明が考えられます。最も一般的なタイプの資格証明は、主にユーザー名とパスワードで構成されるパスワード資格証明です。
OWSMは、oracle.wsm.securityマップ内でJKSキーストアの次のcsf-keyを参照します。

- keystore-csf-key - この鍵には、キーストアのパスワードを含める必要があります。ユーザー名は無視されます。

- enc-csf-key - この鍵には、ユーザー名として暗号化鍵の別名、および対応する鍵のパスワードを含める必要があります。

- sign-csf-key - この鍵には、ユーザー名として署名鍵の別名、および対応する鍵のパスワードを含める必要があります。

これらのcsf-keyに加えて、OWSMで新しい秘密鍵を使用するたびに(構成オーバーライドで署名鍵および暗号化鍵を指定する場合など)、対応するcsf-keyエントリを追加する必要があります。

図2-1に、OPSSのJKSキーストア構成、資格証明ストアのoracle.wsm.securityマップおよびOWSM Javaキーストアの関係を示します。

図2-1 メッセージ保護のためのOWSMキーストア構成

図を見ると次のことがわかります。

- keystore.csf.mapプロパティは、CSF別名を含む資格証明ストア内のOWSMマップを指します。この場合、keystore.csf.mapはお薦めの名前であるoracle.wsm.securityとして定義されていますが、任意の値でかまいません。

- keystore.pass.csf.keyプロパティは、JKSキーストアのユーザー名およびパスワードにマップされたCSF別名keystore-csf-keyを指します。パスワードのみが使用されます。キーストアの場合、ユーザー名は冗長です。

- keystore.sig.csf.keyプロパティは、JKSキーストアで署名に使用される秘密鍵のユーザー名およびパスワードにマップされたCSF別名sign-csf-keyを指します。

- keystore.enc.csf.keyプロパティは、JKSキーストアで復号化に使用される秘密鍵のユーザー名およびパスワードにマップされたCSF別名enc-csf-keyを指します。

2.6.4 SSLポリシー用の秘密鍵および証明書について

鍵およびトラストをクライアントおよびサービス側で構成し、SSLポリシーを使用します。

- サービス側の構成: SSLセキュリティ・ポリシー用に、SSL終端ポイントで秘密鍵を設定する必要があります。こうした終端ポイントは一般的に、次のいずれかから構成されます。

- WebLogic ServerなどのJava EEコンテナ。構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のSSLのキーストアの構成に関する項を参照してください。

- Oracle HTTP Server(クライアントとWebLogic Server間のWebプロキシとして構成している場合)。構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のOracle HTTP ServerでのSSLの構成に関する項を参照してください。

- ロード・バランサ(WebLogic ServerまたはOracle HTTP Serverの前にロード・バランサを配置している場合)。

注意:

SSLでは、サーバーごとに1つの秘密鍵のみを持つことができます。したがって、同じサーバー上で実行する複数のWebサービスが存在する場合は、そのすべてで同じ秘密鍵を使用します。このSSL秘密鍵は、ホスト名と同じDNで生成する必要があります。ただし、テスト目的のために、このホスト名の検証機能はクライアント側でオフにできます。

基本構成例: WebLogic Serverに含まれるデモ用のデジタル証明書、秘密鍵および信頼できるCA証明書を使用します。これらの鍵および証明書は、開発用にのみ提供されています。本番環境では使用しないでください。

詳細構成: 本番環境では、内部CAまたは外部CAを使用します。

- クライアント側の構成: クライアント側では、クライアントのトラストストアにサーバー証明書をインポートする必要があります。サーバー側で自己署名証明書を使用している場合は、その自己署名証明書を直接含める必要があります。サーバー側でCAを使用して署名された証明書を使用している場合は、クライアント・トラストストアにそのCAルート証明書をインポートします。各タイプのWebサービス・クライアントでそのクライアント・トラストストアは異なることに注意してください。

- Java EE (WebLogic) Webサービスでは、WebLogic Serverトラストストアに鍵をインポートする必要があります。デモ用CA証明書は、WebLogic Serverトラストストアにすでに含まれています。

- Oracle Infrastructure Webサービスでは、javax.net.ssl*システム・プロパティを使用してトラストストアを指定するか、または接続でトラストストアを指定する必要があります。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のWebサービス・クライアントのSSLの構成に関する項を参照してください。

- SOAコンポジット・アプリケーションでは、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の双方向SSL通信用のSOAコンポジット・アプリケーションの構成に関する項の説明に従って、javax.net.ssl*プロパティを使用してトラストストアを指定する必要があります。

- 非同期Webサービスでは、『Oracle Infrastructure Webサービスの開発』の非同期Webサービス用のSSLの構成に関する項の説明に従ってトラストストアを構成する必要があります。

2.6.5 メッセージ保護ポリシー用の秘密鍵および証明書の設定について

OWSMメッセージ保護セキュリティ・ポリシーでは、OWSMキーストアで秘密鍵を設定する必要があります。

ドメインごとに単一のOWSMキーストアが存在し、ドメイン内で実行するすべてのWebサービスおよびクライアントによってそのキーストアが共有されます。このキーストアには、秘密鍵および信頼証明書の両方が含まれます。JDK cacertsファイルは、OWSMでは使用されません。

次の各項では、OWSMキーストアの基本構成と詳細な構成について説明します。

- Sample Basic構成の理解

- 詳細な設定に関する考慮事項について

2.6.5.1 Sample Basic構成の理解

OWSMキーストアを設定する最も簡単な方法は、自己署名秘密鍵を1つ作成し、それをドメイン全体で使用することです。秘密鍵およびキーストアを作成する際には、キーストアの名前とパスワードを指定します(たとえば、JKSキーストアを使用する場合、キーストア名としてdefault-keystore.jks、このキーストアのパスワードとしてwelcome1を指定します)。また、秘密鍵を参照する場合に使用する別名とパスワードも指定します(たとえば、別名としてorakey、鍵のパスワードとしてwelcome1など)。署名鍵の別名と暗号化鍵の別名の両方で同じ鍵および別名を使用し、キーストアと別名の両方で同じパスワードを使用できます。秘密鍵に関連付けた証明書は、自動的に信頼できるものと見なされるので、信頼できる証明書を追加する必要はありません。

鍵およびキーストアを作成したら、キーストアのパスワードと、別名およびパスワードをOWSMに指定する必要があります。この指定には、Fusion Middleware ControlまたはWLSTのいずれかを使用できます。

Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の秘密鍵の生成とJavaキーストアの作成に関する項とFusion Middleware Controlを使用したOWSMキーストアの構成に関する項の手順では、この例で指定しているユーザー名とパスワードを使用してJKSキーストアの基本構成を設定する方法について説明しています。それぞれの環境では、構成に対して適切な名前およびパスワードを使用する必要があります。

クライアントとサーバーが同じドメインにあるかぎり、この設定はほとんどのポリシーで問題なく使用できます。つまり、SAMLの有無を問わず、任意のwss10またはwss11のポリシーを使用できます。

共通のJPSルートを共有する複数の関連ドメインが存在する場合は、すべてのドメインにこのキーストア・ファイルをコピーできます。これによって、関連するすべてのドメインがすべての暗号化および署名についてこの単一の鍵を共有します。

2.6.5.2 詳細な設定に関する考慮事項について

メッセージ保護セキュリティを設定する最も簡単な方法は、ドメイン内のすべてのWebサービスについて単一の秘密鍵を用意することです。

より機密性の高いWebサービスを得るには、独自の秘密暗号化鍵を使用するように各Webサービスを構成する必要があります。これらの秘密鍵はOWSMキーストアに存在する必要があります。それぞれが異なる別名(たとえばServiceAおよびServiceB)を使用し、その別名を資格証明ストアに追加していることを確認します。サービスにポリシーをアタッチした場合、Webサービスが必要とする特定の別名を示すために構成オーバーライドを使用する必要があります。そうしない場合、ドメインに対して構成したデフォルトの別名(たとえばorakey)が使用されます。

Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の資格証明ストアへの鍵およびユーザー資格証明の追加に関する項の手順では、これらの別名サンプルを資格証明ストアに追加する方法について説明しています。

また、信頼できるCA証明書を管理する方が格段に容易であるために、自己署名証明書ではなく内部CAまたは外部CAによって発行された信頼できる証明書を使用すべきです。ただし、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したSAMLの信頼できる発行者およびDNリストの構成に関する項の説明に従って、SAML署名者の信頼できるDNリストを必ず設定してくださいこれは、OWSMキーストアに外部CA証明書をインポートした場合に特に重要です。この設定を行わないと、証明書を持つユーザーなら誰でも、SAMLトークンに署名することによって、任意のユーザーになりすますことが可能になります。

2.7 OWSMでの資格証明ストアの使用の仕組みの理解

資格証明ストア・フレームワーク(CSF)は、Webサービスや他のアプリケーションの資格証明を格納、取得および削除する手段を提供します。OWSMでは、次の情報を取得することにより、CSFを使用して保護された形式で資格証明を管理できます。

- Javaキーストア内の鍵の別名およびパスワード
OWSMでの資格証明ストアを使用した別名およびパスワードの検索の仕組みの詳細は、「OWSMでのJKSキーストア用のキーストアおよびキー・パスワードの特定の仕組み」を参照してください。

- 認証に使用されるユーザー名およびパスワード
たとえば、認証のためにユーザー名トークンを受け入れるWebサービスがあるとします。このWebサービスと対話するWebサービス・クライアントを作成した場合、Webサービスに送信できるユーザー名およびパスワードでWebサービス・クライアントを構成する必要があります。(Fusion Middleware ControlまたはWLSTのいずれかを使用して)資格証明ストアにこのユーザー名とパスワードを格納し、それにCSFキーを割り当てます。

たとえば、oracle/wss_username_token_client_policyポリシーにはcsf-keyプロパティが含まれており、そのデフォルト値はbasic.credentialsです。wss_username_token_client_policyを使用するには、資格証明名basic.credentialsと、クライアントが接続時に使用する必要があるユーザー名およびパスワードを使用して、CSF内に新しいパスワード資格証明を作成します。この同じクライアント・ポリシーを使用する2つのWebサービス・クライアントが存在する場合、これらのクライアントで同じパスワード資格証明(デフォルト値はbasic.credentials)を共有することもできますし、それぞれが独自の資格証明を持つこともできます。後者の場合は、クライアント1およびクライアント2についてそれぞれ、CSF内に2つのパスワード資格証明(たとえばApp1.credentials、App2.credentials)を作成する必要があります。クライアント1ではcsf-key構成オーバーライドにApp1.credentialsを設定し、クライアント2ではcsf-keyプロパティにApp2.credentialsを設定します。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のポリシー構成プロパティのオーバーライドに関する項を参照してください。いずれの場合も、ユーザー名およびパスワードがOPSSアイデンティティ・ストア内の有効なユーザーを表す必要があることに注意してください。

OPSS CSFには、ユーザー名とパスワードを格納できます。汎用的な資格証明はどのような資格証明オブジェクトも保存できます。

OPSS CSF構成は、domain-home/config/fmwconfigディレクトリのjps-config.xmlファイル内で維持されます。

Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したOWSMキーストアの構成に関する項の説明に従って、Fusion Middleware Controlを使用してOWSMキーストアを構成すると、指定した別名およびパスワードが資格証明ストアに安全に格納されます。しかし、キーストアに他の別名を追加する場合や、クライアントの認証資格証明を追加する必要がある場合は、資格証明ストアでそれらを構成して格納する必要があります。

2.8 セキュリティ・ポリシーの理解

WS-SecurityPolicyは、OASISが策定するWeb Services Secure Exchange (WS-SX)の仕様の一部です(WS-SecurityPolicyに加え、WS-SX技術協議会がWS-TrustおよびWS-SecureConversationの2つの仕様一式を定義しています。これらはこの章で後述します)。

WS-SecurityPolicyは、WS-Policyフレームワークのコンテキストで使用する一連のセキュリティ・ポリシー・アサーションを定義します。WS-SecurityPolicyアサーションは、通信パスでメッセージの安全性を確保する方法を示すものです。オラクル社は、OASIS WS-SX技術協議会のいくつかの実用セキュリティ・シナリオに貢献しています(OWSM 12cには、これらのシナリオのサブセットが付属しています)。各セキュリティ・シナリオは、WS-SecurityPolicyのポリシー表記を示します。

WS-SecurityPolicyのシナリオには、(WS-Security 1.0および1.1の両方をサポートする)WS-Security仕様に記述されている複数のセキュリティ・トークン・タイプについて、WS-SecurityPolicyポリシーを設定する方法の例が記述されています。OWSM 12cでサポートしているWS-SecurityPolicyシナリオのサブセットは、最も一般的なカスタマ・ユース・ケースを表すものです。各シナリオは、複数ベンダーのWS-Security環境でテストされています。

WS-SecurityPolicyについて説明するために、ここでは、OWSMでサポートされているシナリオの1つである、プレーン・テキスト・パスワード付きのUsernameTokenのシナリオを使用することにします。前述したように、ユーザー名トークンはWS-Securityで指定されるセキュリティ・トークンの1つです。この特定のシナリオでは、リクエスタがユーザー名トークンを検証する権限を持つ受信者に対して、ユーザー名トークンでパスワードを送信する必要があるとするポリシーが使用されます。パスワードは、WS-Securityユーザー名トークン・プロファイル1.1のデフォルト要件です。

このシナリオは、本番前のテスト環境シナリオでダミーのパスワードを使用する場合など、パスワードの秘匿性が重視されていない状況においてのみ推奨されます。

<wsp:Policy>
<sp:SupportingTokens>
<wsp:Policy>
<sp:UsernameToken/>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:Policy>

前述のポリシーに準拠するメッセージの例を次に示します。

<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:soap="...">
<soap:Header>
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="...">
<wsse:UsernameToken>
<wsse:Username>Marc</wsse:Username>
<wsse:Password Type="http://docs.oasis open.org...>
XYZ
</wsse:Password>
<wsse:Nonce EncodingType="...#Base64Binary">qB...</wsse:Nonce>
<wsu:Created>2008-01-02T00:01:03Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<Oracle xmlns=http://xmlsoap.org/Oracle>
<text>EchoString</text>
</Oracle>
</soap:Body>
</soap:Envelope>

この例には、<Nonce>要素と<Created>タイムスタンプが含まれています。これらはオプション機能ですが、リプレイ攻撃などに対するリクエストのセキュリティを向上するために推奨されています。Nonceは、ランダムに生成される(固有の)数字です。タイムスタンプは、セキュリティ・トークンの有効期間の定義に使用できます。

2.9 セキュリティ・トークンの概要

Web Services Security (WS-Security)は、XML暗号化により機密保護を、XML署名によりデータ整合性を実現するSOAPセキュリティ拡張機能を指定します。WS-Securityには、タイプの異なるバイナリとXMLセキュリティ・トークンを、認証および認可の目的でWS-Securityヘッダーに挿入する方法を指定するプロファイルも含まれています。

- セキュリティ・トークンの理解

- ユーザー名トークンについて

- X.509証明書について

- Kerberosトークンについて

- SAMLトークンについて

2.9.1 セキュリティ・トークンの理解

Webサービス・セキュリティは、次のセキュリティ・トークンをサポートします。

- ユーザー名: Webサービス・コンシューマが、認証の資格証明としてユーザー名を指定する方法を定義します。詳細は、「ユーザー名トークンについて」を参照してください。

- X.509証明書: 受信パーティに公開鍵を送信するために設計された署名付きデータ構造。詳細は、「X.509証明書について」を参照してください。

- Kerberosチケット: バイナリ認証およびセッション・トークン。詳細は、「Kerberosトークンについて」を参照してください。

- Security Assertion Markup Language (SAML)アサーション: XMLドキュメントを使用して、インターネット上でセキュリティ情報を共有します。詳細は、「SAMLトークンについて」を参照してください。

2.9.2 ユーザー名トークンについて

ユーザー名トークンはBasic認証情報を伝達します。username-token要素は、メッセージを認証するためにユーザー名とパスワードの情報を伝播します。

2.9.3 X.509証明書について

X.509デジタル証明書は、受信パーティに公開鍵を送信するために設計された署名付きデータ構造です。証明書には、証明書ID、発行者の識別名(DN)、有効期間、所有者のDN、所有者の公開鍵などの標準フィールドが含まれています。

証明書は、認証局(CA)によって発行されます。CAは、エンティティのアイデンティティを検証して証明書を付与し、CAの秘密鍵で署名します。CAは、公開鍵が含まれる独自の証明書を発行します。

各ネットワーク・エンティティには、信頼するCAの証明書のリストがあります。別のエンティティと通信する前に、指定されたエンティティはこのリストを使用して、別のエンティティの証明書の署名が信頼できるCAのものであることを検証します。

2.9.4 Kerberosトークンについて

Kerberosトークンは、クロス・プラットフォーム認証のシングル・サインオン・システムです。Kerberosプロトコルを使用すると、共有の秘密鍵(対称鍵)に依存する2つのエンティティ間で相互認証を実行できます。Kerberosでは次の用語が使用されます。

- プリンシパルはユーザーのアイデンティティ(ユーザーにプリンシパルが割り当てられるということ)、またはKerberosサービスを提供するアプリケーションのアイデンティティです。

- レルムはKerberosサーバー環境です。Kerberosレルムは、EXAMPLE.COM(表記規則により大文字で表現)などのドメイン名にすることもできます。

Kerberosにはクライアントとサーバーに加え、両者を仲介するKey Distribution Center (KDC)と呼ばれる信頼できるパーティが関わっています。各Kerberosレルムには、最低1つのKDCがあります。KDCは、使用する操作プラットフォームによって異なるパッケージが用意されています(たとえば、Microsoft Windowsの場合、KDCはドメイン・サービスです)。WS-SecurityのKerberos Token Profileを使用すると、ビジネス・パートナはサービス指向アーキテクチャでKerberosトークンを使用できます。

2.9.5 SAMLトークンについて

Security Assertion Markup Language (SAML)は、XMLドキュメントを使用して、インターネット上でセキュリティ情報を共有するためのオープン・フレームワークです。SAMLは次の内容に対応するために設計されました。

- 単一ドメインに対するWebブラウザCookieの制限: SAMLには、複数のインターネット・ドメインにCookieを送信する標準の方法が用意されています。

- 固有のWebシングル・サインオン(SSO): SAMLには、単一ドメインまたは複数ドメインにSSOを実装する標準の方法が用意されています。この機能は、Oracle Identity Federation製品により提供されます。

- フェデレーション: SAMLを使用すると、1人のユーザーが複数のWebサイトで複数のアイデンティティを使用している場合にアカウントをリンクするなど、アイデンティティ管理が簡単になります。この機能も、Oracle Identity Federationでサポートされています。

- Webサービス・セキュリティ: SAMLは、標準のWebサービス・セキュリティ・フレームワーク(WS-Securityなど)で使用できる、標準のセキュリティ・トークン(SAMLアサーション)を備えています。これは、特にWebサービス・セキュリティに関連するSAMLの使用方法であり、OWSMで完全にサポートされています。

- アイデンティティ伝播: SAMLには、ビジネス・プロセスまたはトランザクションの複数のステップで、ブラウザからポータル、Webサービスのネットワークへと渡すことができるセキュリティ・トークンを表現する標準の方法が用意されています。この機能もOWSMでサポートされています。

SAMLフレームワークは4つの部分に分かれています。

- アサーション: 認証および認可情報を定義する方法。

- プロトコル: 必要なアサーションを要求(SAMLリクエスト)し、取得(SAMLレスポンス)する方法。

- バインディング: SAMLプロトコルを業界標準のトランスポート(HTTPなど)およびメッセージング・フレームワーク(SOAPなど)に組み込む方法。

- プロファイル: 特定のユースケースをサポートするために、SAMLプロトコルおよびバインディングを組み合せる方法。

WS-Securityのコンテキストで使用されるのは、SAMLアサーションのみです。プロトコルおよびバインディングは、WS-Securityフレームワークにより提供されます。SAMLは、ブラウザベースのフェデレーションおよびWebサービス・フローにより有効化されたフェデレーションの両方において、業界で広く採用されています。

SAMLアサーションは、表現が豊富で、中間者攻撃やリプレイ攻撃の防止に役立つため、WS-Securityでは非常に一般的なセキュリティ・トークンです。

一般的に、SAMLアサーションでは、プリンシパル(ユーザーまたはアプリケーション)に関する記述を行います。すべてのSAMLアサーションには、次の共通の情報が含まれます。

- 発行者のIDおよび発行のタイムスタンプ

- アサーションID

- サブジェクト

- 名前

- オプションのサブジェクト確認(公開鍵など)

- オプションの条件(アサーションが有効な条件)

- オプションのアドバイス(アサーションの作成方法に関するもの)

SAMLアサーションには、次の3つのタイプの文が含まれます。

- 認証文: サブジェクトの認証の成功時、認証局により発行されます。サブジェクトSが手段Mによって時間Tに認証されたことをアサートします。

- 属性文: ポリシーに基づいて属性認証局により発行されます。サブジェクトSが、値a、bなどを持つ属性A、Bなどに関連付けられていることをアサートします。

- 認可決定文(SAML 2.0では非推奨で、現在はXACMLでサポートされている): サブジェクトSによるリソースR(ファイル、アプリケーション、Webサービスなど)に対するアクションA(読取り、書込みなど)を証拠Eに基づいて許可するかどうかを決定する認証局によって発行されます。

SAMLアサーションは埋込み可能です(つまり、SAMLアサーションには別のSAMLアサーションを含めることができます)。SAMLアサーションには、(XML署名を使用した)署名または(XML暗号化を使用した)暗号化、あるいはその両方を行うこともできます。

2.10 セキュア・アタッチメントの理解

OWSMポリシーでは、添付ファイルを保護するための2つのメカニズムとして、添付ファイル付きのSOAPメッセージのパッケージ化(SwA)とメッセージ転送最適化メカニズム(MTOM)をサポートしています。

SOAPエンベロープ内に配置できないデータをアタッチメント(SwA)とともにSOAPメッセージをパッケージングすることは、標準的なことになってきています。プライマリSOAPメッセージでは、アタッチメントまたはMIMEヘッダー付きのアタッチメントとして追加のエンティティを参照できます。詳細は、Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理のSwAの添付ファイルの保護に関する項を参照してください

MTOMを使用すると、バイナリ・コンテンツをMIME添付ファイルとして送信できるため、ワイヤ書式の送信サイズを小さくできます。バイナリ・コンテンツは意味的にXMLドキュメントの一部です。MTOMポリシーをアタッチすると、メッセージはWebサービスやクライアントに送信される前にMIME添付ファイルに変換されます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のMTOMアタッチメント・ポリシーに関する項を参照してください。

2.11 セキュア通信の概要

OWSMはWeb Services Trust (WS-Trust 1.3)およびWeb Services Secure Conversation (WS-SecureConversation 1.3)仕様を実装します。これらはともにWebサービスとそのクライアント間のセキュアな通信を提供します。

- セキュア通信について

- WS-SecureConversationの使用方法の概要

- WS-SecureConversationのアーキテクチャ

- WS-SecureConversationを使用する状況

- 再認証を使用する状況

- ブートストラップ・モードの設定について

- 永続性の概要

2.11.1 セキュア通信について

Web Services Secure Conversation Language (WS-SecureConversation)仕様では、セキュリティ・コンテキストまたは任意の資格証明の確立メカニズムと共有メカニズムや、確立されたセキュリティ・コンテキスト(または任意の共有の秘密)からのキーの導出メカニズムが定義されています。

Web Services Secure Conversation Language (WS-SecureConversation)の仕様(http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.doc)では、Web Services Security (WS-Security) 1.1と1.0、およびWeb Services Trust Language (WS-Trust)で構築された、1つ以上のメッセージでセキュア通信を可能にする拡張機能が定義されています。

OWSMには、WS-SecureConversationがデフォルトで有効なポリシーが含まれています。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のWS-SecureConversationをサポートしているポリシーに関する項を参照してください。事前定義済のWS-SecureConversationポリシーを使用することで、セキュリティ・タスクの概要表示と管理が簡素化される場合があります。

また、WS-SecureConversationをサポートしているポリシーに関する項で説明している各OWSMセキュリティ・ポリシーには、そのポリシーでのWS-SecureConversationの有効化と構成を可能にする構成設定が含まれています。

2.11.2 WS-SecureConversationの使用方法の概要

この項では、WS-SecureConversationを使用する状況および使用しない場合に発生する現象について説明します。また、WS-SecureConversationをWS-ReliableMessagingと組合せて使用する長所についても説明します。

- WS-SecureConversationを使用する状況

- WS-SecureConversationの長所

- WS-ReliableMessagingでのWS-SecureConversationの使用について

2.11.2.1 WS-SecureConversationを使用する状況

WS-SecureConversationを使用する主な理由として、パフォーマンスとセキュリティがあります。

OWSMセキュリティ・ポリシーで採用している標準であるWS-Securityでは、メッセージ保護の基本メカニズムが提供されます。

しかし、WS-SecureConversationを使用しない場合、複数のメッセージをやりとりするOWSMセキュリティ・ポリシー(oracle/wss11_username_with_message_protectionなど)を使用するクライアントは、リクエストごとに繰り返し自身を認証し、キー交換などの負荷の高い非対称操作を実行する必要があります。

通常、複数のメッセージを安全にやりとりするためには、クライアントとWebサービスは、メッセージ交換のためのセキュリティ・コンテキストを必要とします。WS-SecureConversationでは、このようなコンテキストが提供されます。これによってハンドシェイク・プロセスが追加されます。Webサービスとそのクライアントは、このプロセスを通じて相互認証を実行して、共有セキュリティ・コンテキストを確立できるようになります。通信セッションの存続期間中は、このセキュリティ・コンテキストがクライアントとWebサービスによって共有されます。このコンテキストには共有の秘密が格納され、この鍵を使用して、クライアントとサービス間の後続のメッセージが保護されます。複数のメッセージを交換する際には、鍵を何度も交換しなくてもすむので、パフォーマンスを向上させることができます。

セキュア通信の有効化とは、鍵を繰り返し交換したり、毎回認証する必要がないことを意味します。

次の順序を考えてみます。

1. クライアントが最初のリクエストを送信すると、クライアントとWebサービス間でハンドシェイクが実行されます。

2. クライアントは、WS-Trustプロトコルを使用したブートストラップ・ポリシーでの定義に従って、サービスに対して自身を認証します。

3. Webサービスは、セキュア・コンテキスト・トークン(SCT)を返します。SCTにはバイナリの秘密鍵が含まれており、後続のリクエストでこの秘密鍵を使用することで、通信セッション中のメッセージが保護されます。

注意:

Webサービスが要求する認証メカニズムは変わりません。認証操作の実行頻度のみが変わります。

2.11.2.2 WS-SecureConversationの長所

WS-SecureConversationを使用する長所の詳細は、Wss11、Wss10またはSSL OWSMポリシーの比較を参照してください。

WS-SecureConversationによる利点は、Wss11、Wss10またはSSL OWSMポリシーのどれを使用するかに応じて異なります。

- Wss11: Wss11シナリオでは、ポリシーに応じて1つまたは2つの非対称暗号化操作がリクエストで実行されます。WS-SecureConversationを使用した場合、認証および非対称暗号化操作はブートストラップ時に1回のみ実行され、後続のアプリケーション・リクエストではSCTを使用してメッセージが保護されます。SCTでは、負荷が比較的かからない対称暗号化操作が使用されます。
たとえば、WS-SecureConversationで「メッセージ保護付きユーザー名」ポリシーが有効になっている場合、ブートストラップ・ポリシーによって、ユーザー名トークンを使用した認証と、Wss11を使用したメッセージ保護が行われます。しかし、後続のメッセージでは、認証はまったく実行されず、メッセージはSCTによって保護されます。

- Wss10: Wss10シナリオでは、4つの非対称暗号化操作がリクエスト・メッセージおよびレスポンス・メッセージで実行されます。WS-SecureConversationを使用した場合、認証および非対称暗号化操作はブートストラップ時に1回のみ実行され、後続のアプリケーション・リクエストではSCTを使用してメッセージが保護されます。SCTでは、負荷が比較的かからない対称暗号化操作が使用されます。
たとえば、WS-SecureConversationで「メッセージ保護付きユーザー名」ポリシーが有効になっている場合、ブートストラップ・ポリシーによって、ユーザー名トークンを使用した認証と、Wss10を使用したメッセージ保護が行われます。しかし、後続のメッセージでは、認証はまったく実行されず、メッセージはSCTによって保護されます。

- SSL: SSLシナリオでは、セッション期間中、通信はSSLを介して実行されます。ブートストラップ時には認証が実行されます。後続のリクエストでは、SCTを使用してタイムスタンプの署名が行われ、認証トークンはまったく送信されません。SCTに基づくタイムスタンプの署名によって、そのリクエストが認証済クライアントから送信されたものであることが証明されます。
これらのシナリオでは、SSLを使用してメッセージが保護され、SCTによるタイムスタンプの署名を使用して認証が実行されます。

たとえば、「SSLを介したユーザー名」ポリシーに対してWS-SecureConversationが有効になっている場合、ブートストラップ・ポリシーによって、ユーザー名トークンを使用した認証と、SSLを使用したメッセージ保護が行われます。SSLは後続のメッセージでも使用されますが、ユーザー名トークンのかわりに、SCTによるタイムスタンプの署名が格納されます。

2.11.2.3 WS-ReliableMessagingでのWS-SecureConversationの使用について

WS-SecureConversationの特に重要な用途の1つは、WS-ReliableMessaging (WS-RM)ポリシーに対してセキュリティを提供することです。セキュア通信を使用することにより、WS-RMでシーケンス攻撃を防止できるようになります。

WS-ReliableMessagingの仕様(http://docs.oasis-open.org/ws-rx/wsrm/v1.2/wsrm.html)で説明されているように、複数のメッセージ交換を行う場合は信頼できるメッセージ・シーケンスの使用が前提となるため、WS-TrustおよびWS-SecureConversationメカニズムを使用してシーケンスを保護することによって、セキュリティ・コンテキストを確立することをお薦めします。

そのため、WS-SecureConversationが有効になっているセキュリティ・ポリシーをWS-RMポリシーにアタッチしてください。

2.11.3 WS-SecureConversationのアーキテクチャ

WS-SecureConversation仕様は、Web Services Security (WS-Security)およびWeb Services Trust Language (WS-Trust)に基づく拡張を定義します。

仕様(http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.doc)には、WS-SecureConversationアーキテクチャ、特性および機能に関する情報のソースが最も含まれています。

最低でも、次の概念について精通しておく必要があります。

- WS-Trust: Oracle WebLogic Server WebLogic Webサービスの理解のWeb Services Trust Language (WS-Trust)に関する項で説明しているように、Web Services Trust Language (WS-Trust)の仕様では、Web Services Security (WS-Security) 1.1と1.0で構築された、セキュリティ・トークンのリクエストおよび発行と、信頼関係の仲介のためのフレームワークを提供する拡張機能が定義されています。

- セキュリティ・コンテキスト: セキュリティ・コンテキストは、確立された認証状態とネゴシエートされた鍵を指す抽象概念です。セキュリティに関連するその他のプロパティを持つ場合もあります。

- セキュリティ・コンテキスト・トークン: セキュリティ・コンテキスト・トークン(SCT)は、セキュリティ・コンテキスト抽象概念の表現です。SCTにより、URIに基づく名前をコンテキストに付けて、WS-Securityで使用できるようになります。コンテキストと秘密の確立(認証)が完了すると、セキュアなコンテキストで各鍵を使用するたびに導出キーを計算できます。

- 導出キー: WS-SecureConversationの仕様(http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.doc)には、次のように記載されています。「セキュリティ・コンテキスト・トークンは、共有の秘密を暗示または含有します。この秘密は、メッセージの署名または暗号化(あるいはその両方)で使用可能ですが、導出キーは、セキュリティ・コンテキストにのみ関連付けられたメッセージの署名と暗号化に使用することをお薦めします。」
さらに、WS-SecureConversationの仕様には、次のように記載されています。「コンテキストと秘密の確立(認証)が完了すると、セキュアなコンテキストで鍵が使用されるたびに、導出キーに関する項で説明しているメカニズムを使用して導出キーを計算できます。」

導出キーはメッセージの保護に役立ちます。複数のリクエストで同じSCTを使用するかわりに、リクエストごとに異なるSCT導出キーを使用することで、全体的なセキュリティが強化されます。

ポリシーでWS-SecureConversationを有効にすると、OWSMは、WSS10およびWSS11に対して、デフォルトで導出キーを使用します。(SSLポリシーの場合は、SSLを使用してメッセージが保護されるため、導出キーは不要です。)

- セッション管理: OWSMは、計算されたセッションIDに基づいて、クライアントとサーバーのセキュア通信セッション情報を保持します。
Webサーバー側では、Webサービスの使用ポートに基づいてセッションIDが保持されます。

クライアント・セッションは、「参照」という用語で表現されます。これは、メッセージ通信を有効にするクライアント・ポート/バインディングやとSOA参照と類似する概念です。

WS-SecureConversationの実装では、各クライアント参照は個別のWS-SecureConversationセッションになります。Webサービス・クライアント・リクエストの観点では、これを前提として、次のことが導かれます。

- 複数のリクエストが同じ参照に属する場合がある。

- 同じセッションIDを持つリクエストはすべて、同じセッションに属する。

- セッションIDが有効となる状態は、再認証設定に依存する。

OWSMは実行時にメッセージごとにセッションIDを計算し、1つのセッションに1つ以上のリクエストを関連付けます。OWSMは、ユーザーの資格証明、サービス情報、ポリシー・データおよび構成データを使用して、セッションIDを計算します。

セッションIDは、Oracle WS-RMポリシーで使用されたときに特に重要になります。このポリシーでは、セキュリティとパフォーマンス上の理由から、RMセッション内の複数のメッセージが同じセキュア通信セッションで保護されます。

- 内部ポリシーと外部ポリシー: OWSMにおけるWS-SecureConversation実装では、セキュア通信ポリシーには、実際には内部と外部の2種類のポリシーが含まれます。ブートストラップ(内部)ポリシーは、トークンの取得と、クライアントとWebサービス間のハンドシェイクの確立に使用されます。外部ポリシーは、トークンを使用したリクエストの実行時にアプリケーション・メッセージに対して使用されます。
wss11_username_with_message_protectionなどの元のOWSM WS-Securityポリシーから、外部ポリシーのメッセージ・セキュリティ設定が取得されます。その後、外部ポリシーから、内部ポリシーのメッセージ・セキュリティ設定が導出されます。

ほとんどの場合、内部および外部ポリシーはOWSMによって処理されるため、これらのポリシーの詳細を意識する必要はありません。ただし、OWSMのWS-SecureConversation実装では、追加制御のための詳細設定を指定することもできます。「ブートストラップ・モードの設定について」を参照してください。

- 再認証: OWSMには、ユーザーごとに個別にセッションを作成するか、複数のユーザーが同じセッションを共有できるようにするかを指定する再認証制御機能があります。再認証がtrueに設定されているかどうかにかかわらず、ユーザーの認証は1回のみ実行されます。
サポートしているユースケースの1つに、SAML送信者保証付きのID伝播があります。これは、アプリケーション・メッセージごとにユーザーIDが異なる場合があるために、WS-SecureConversationセッション中にメッセージごとに認証を実行する必要があるユースケースです。

再認証によって、複数のユーザーが同じセッションを共有できるようになります。この場合、複数のユーザーがセッションを共有するため、リクエストごとに認証トークンが送信されます。ただし、後続のリクエストでは、鍵を交換する必要はなく、非対称操作(署名、暗号化)は実行されません。

セッションIDが有効となる状態は、再認証設定に依存します。

- 再認証がfalseに設定されている場合、クライアント側では、特定のユーザーの単一の参照に対してセッションIDが保持されます。
サーバー側では、Webサービスの使用ポートに基づいてセッションIDが保持されます。

- 再認証がtrueに設定されている場合、クライアント側では、単一の参照に対してセッションIDが保持されます。この参照には、複数のユーザーが関係している場合があります。
サーバー側では、Webサービスの使用ポートに基づいてセッションIDが保持されます。

2.11.4 WS-SecureConversationを使用する状況

次のシナリオでは、WS-SecureConversationの使用を検討してください。

- OWSM WS-RMポリシーを使用している。

- OWSMセキュリティ・ポリシー(oracle/wss11_username_with_message_protectionなど)を使用してWebサービス・クライアントを保護しており、複数のメッセージが頻繁にやりとりされる。

WS-SecureConversationの有効化が有意義なのは、Webサービス・クライアントまたはサービスがOWSMで保護されており、このクライアントまたはサービスで複数のメッセージ交換が行われることが想定される場合です。WS-SecureConversationを有効化することで、パフォーマンスが向上します。クライアントとサービス間の後続のメッセージがSCTによって保護されるため、認証操作と公開鍵暗号化操作を繰り返し実行するオーバーヘッドが発生しないからです。

注意:

ID伝播ユースケースでは、WS-SecureConversationを使用することによって、主にメッセージ保護におけるパフォーマンスが向上します。セッション中にメッセージごとに認証トークンを送信した場合、その分パフォーマンスが犠牲になるからです。

複数のメッセージ交換が行われることがあり、WS-SecureConversationが役立つ可能性がある次のシナリオについて考えてみてください。

- 1対1: この場合、クライアント・アプリケーションが、単一ユーザーのために、特定のWebサービスを複数回起動します。

- re-authenticate=trueを設定した1対1(アイデンティティ伝播): この場合、クライアント・アプリケーションが特定のWebサービスを複数回起動します。ただし、後続のリクエストでは、リクエストごとに異なるアイデンティティをWebサービスに渡す必要がある場合があります。
すべてのユーザー用に単一のセキュア通信セッションが作成されます。

2.11.5 再認証を使用する状況

SAML送信者保証付きID伝播ポリシーの場合にのみ、再認証制御を有効化できます。再認証は、アプリケーション・メッセージごとにユーザーIDが異なる可能性があるときに使用します。この場合、各メッセージでユーザーが認証されます。

クライアント・アイデンティティを使用してブートストラップが実行され、サービスへのすべてのアプリケーション・リクエストでエンド・ユーザー・アイデンティティが渡されます。WS-SecureConversationを使用することによって、主にメッセージ保護における利点が得られます。セッション中にメッセージごとに認証トークンを送信した場合、その分パフォーマンスが犠牲になるからです。

デフォルトでは、WS-SecureConversationでの再認証制御は設定されていません。再認証制御は、WS-SecureConversationが有効化されている場合にのみ有効化できます。

2.11.6 ブートストラップ・モードの設定について

OWSMにおけるWS-SecureConversation実装では、セキュア通信ポリシーには、実際にはブートストラップ(内部)と外部の2種類のポリシーが含まれます。

ブートストラップ(内部)ポリシーは、トークンの取得と、クライアントとWebサービス間のハンドシェイクの確立に使用されます。外部ポリシーは、トークンを使用したリクエストの実行時にアプリケーション・メッセージに対して使用されます。

外部ポリシーのメッセージ・セキュリティ設定は、oracle/wss11_username_with_message_protectionなどの元のOWSM WS-Securityポリシーから取得されます。その後、外部ポリシーから、内部ポリシーのメッセージ・セキュリティ設定が導出されます。

したがって、ほとんどの場合、内部および外部ポリシーはOWSMによって処理されるため、これらのポリシーの詳細を意識する必要はありません。ただし、OWSM WS-SecureConversationの実装では、追加のコントロールが提供されます。

次の「ブートストラップ・メッセージ・セキュリティ」オプションを使用できます。

- アプリケーション設定から継承

- 独立した設定を使用:

- アルゴリズム・スイート

- タイムスタンプを含める

- 署名の確認

- 署名の暗号化

2.11.7 永続性の概要

次の2つの永続性の実装が使用できます。デフォルトのドメイン全体の永続性およびクライアント固有/Webサービス固有の永続性です。

この項では、前述の次のような永続性の実装について説明します。

- デフォルトのドメイン全体の永続性の実装について

- クライアント固有およびWebサービス固有の永続性の実装について

2.11.7.1 デフォルトのドメイン全体の永続性の実装について

OWSMには、Coherenceクラスタとメモリー内永続性プロバイダをサポートする、デフォルトのドメイン全体の永続性の実装が含まれています。

Coherence永続性プロバイダがWebLogic Serverで実行されている場合は、このプロバイダが、Webサービス・クライアントとWebサービスの両方に対してデフォルトになります。それ以外の場合は、メモリー内プロバイダがデフォルトになります。

セッション・リカバリの永続性粒度レベルは、セッション・オブジェクトです。

この永続性の実装は、デフォルトで有効になっており、構成を行う必要はまったくありません。

2.11.7.2 クライアント固有およびWebサービス固有の永続性の実装について

各クライアントおよびWebサービスでは、1つ以上(ポートごとに1つ)の永続性プロバイダを指定できます。Coherenceプロバイダまたはメモリー内プロバイダのいずれかの指定が可能です。

この指定を行うには、「永続性の構成」で説明しているいずれかのメカニズムを使用します。

2.12 Kerberosプロトコルの概要

Kerberosは、非セキュア・ネットワークを介して通信するコンピュータ(クライアントおよびサーバー)が、信頼できる第三者を利用して、互いに自身のアイデンティティを安全な方法で証明できるようにする認証プロトコルです。

- Kerberosプロトコルの理解

- Kerberosでの資格証明の委任の理解

- KerberosとSPNEGOの理解

- KerberosとWS-SecureConversationの導出キーについて

2.12.1 Kerberosプロトコルの理解

Kerberosでは、この信頼できる第三者は、キー配布センター(KDC)です。KDCには、プリンシパルと呼ばれる、クライアントとサーバーのキー情報が格納されます。KDCは次の2つのコンポーネントで構成されます。

- 認証(AS): KDCでプリンシパルを認証します。

- チケット認可サービス(TGS): 認証されたプリンシパルに、KDC内の他のプリンシパルにサービスをリクエストするために使用できるチケットを提供します。

OWSMでは、KDCとしてMIT KerberosとMicrosoft Active Directoryをサポートしています。MIT Kerberosの使用の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のMIT Kerberosの使用に関する項を参照してください。Microsoft Active Directoryの使用の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のキー配布センターでのMicrosoft Active Directoryの使用に関する項を参照してください。

クライアント・プリンシパルとサーバー・プリンシパル間のメッセージ・セキュリティにKerberosが使用されているときに実行されるステップの概要は次のとおりです。

1. AS-REQ(認証サービスへのリクエスト): クライアントが、ASにユーザーIDを送信することによって、認証プロセスを開始します。

2. AS-REP(認証サービスからの返信): ASはレスポンスとして次のものを返します。

- KDCからのユーザーのパスワードのハッシュを使用して暗号化されたクライアント/TGSセッション・キー

- TGSの秘密鍵を使用して暗号化されたチケット認可チケット(TGT)

3. TGS-REQ(チケット認可サービスへのリクエスト): サービスとの通信を開始するために、クライアントは最初に次のものをTGSに送信します。

- ASから受信したTGT

- リクエストしたサービスのID

- ASからのクライアント/TGSセッション・キーを使用して暗号化されたオーセンティケータ

4. TGS-REP(チケット認可サービスからの返信): TGSは、秘密鍵を使用してTGTを復号化し、そこからクライアント/TGSセッション・キーを抽出します。次に、このセッション・キーを使用して、オーセンティケータを復号化します。その後、レスポンスとして次のものを返します。

- クライアント/TGSセッション・キーを使用して暗号化されたクライアント/サーバー・セッション・キー

- サービスの秘密鍵を使用して暗号化されたサービス・チケット(ST)

5. AP-REQ(アプリケーションへのリクエスト): クライアントは、TGSからの返信を受信すると、次のものを送信して、サービスとの通信を開始します。

- TGSから受信したST

- TGSからのクライアント/サーバー・セッション・キーを使用して暗号化された新しいオーセンティケータ

6. AP-REP(アプリケーションからの返信): サービスは秘密鍵を使用してSTを復号化し、クライアント/サーバー・セッション・キーを抽出します。次に、このセッション・キーを使用してオーセンティケータを復号化します。その後、復号化されたオーセンティケータからタイムスタンプを抽出し、それに新しいタイムスタンプを追加します。そして、クライアント/サーバー・セッション・キーを使用してこの値を暗号化して、クライアントに返送します。

7. クライアントは確認を復号化し、タイムスタンプが適切に更新されているかどうかをチェックします。更新されている場合、クライアントはサーバーを信頼し、サービス・リクエストの発行を開始できます。

KerberosプロトコルをサポートするようにOWSMを構成する方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のKerberosログイン・モジュールの構成に関する項およびKerberosトークンの構成に関する項を参照してください。

2.12.2 Kerberosでの資格証明の委任の理解

Kerberosは、サービスが別のサービスまたはサーバーにアクセスしてクライアント・リクエストを完了する必要がある場合、資格証明委任のメカニズムを使用します。Kerberosでは、このような接続を確立するために、クライアントのユーザー・アカウントと認可レベルを使用して、2番目のサービスまたはサーバーに対して最初のサービスを認証する必要があります。

Kerberosで資格証明の委任を行う一般的な方法は、KerberosチケットでFORWARDABLEおよびFORWARDEDフラグを使用することです。これは転送されたTGTと呼ばれる方法です。転送されたTGTの使用に関連するステップの概要を次に示します。

1. ユーザーが、最初のAS-REQで、FORWARDABLEというKDCオプションを設定することによって、forwardableフラグが設定されたTGT(転送可能TGT)をKDCにリクエストします。

2. クライアントが、この転送可能TGTをTGSに提示することによって、FORWARDEDチケットをリクエストします。クライアントはまた、新しいチケットのサービス・アドレス・セットを提供するとともに、FORWARDEDというKDCオプションをリクエスト(TGS_REQ)に設定します。

3. ステップ2で取得したFORWARDEDチケットを提供することによって、このようなチケット(FORWARDEDフラグが設定されたチケット)をKDCからさらに取得できます。

次に、より詳細なステップでメッセージの順序を指定します。

1. ユーザーが、KRB_AS_REQメッセージを送信することによってKDCに対して認証を行い、転送可能TGTをリクエストします。

2. KDCから、KRB_AS_REPメッセージで転送可能TGTが返されます。

3. ユーザーは、ステップ2で取得した転送可能TGTに基づいて、転送されたTGTをリクエストします。これはKRB_TGS_REQメッセージで行われます。

4. KDCから、KRB_TGS_REPメッセージで、転送されたTGTがユーザーに対して返されます。

5. 5. ユーザーは、ステップ2で返されたTGTを使用して、サービス1のサービス・チケットをリクエストします。これはKRB_TGS_REQメッセージで行われます。

6. チケット認可サービス(TGS)から、KRB_TGS_REPメッセージでサービス・チケットが返されます。

7. ユーザーは、KRB_AP_REQメッセージを送信し、サービス・チケット、転送されたTGTおよび転送されたTGTのセッション・キーを提示することによって、サービス1に対するリクエストを行います。

8. ユーザーのリクエストを満たすために、サービス1はサービス2を起動して、ユーザーにかわってなんらかのアクションを実行する必要があります。サービス1は、ユーザーの転送されたTGTを使用し、KRB_TGS_REQメッセージでこのTGTをKDCに送信することによって、ユーザーにかわってサービス2のチケットを要求します。

9. KDCから、KRB_TGS_REPメッセージで、サービス2のチケットがサービス1に返されます。また、サービス1が使用可能なセッション・キーも一緒に返されます。このチケットでは、サービス1ではなくユーザーがクライアントとして指定されています。

10. サービス1は、KRB_AP_REQを使用して、ユーザーにかわってサービス2に対するリクエストを行います。

11. サービス2によってタスクが実行され、レスポンスが返されます。

12. サービス2から取得したレスポンスが、ユーザーのリクエストへのレスポンスとして、サービス1からユーザーに返されます。

資格証明の委任を使用するためのOWSMの構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の資格証明の委任の構成に関する項を参照してください。

2.12.3 KerberosとSPNEGOの理解

SPNEGO (Simple and Protected GSS-API Negotiation Mechanism)は、クライアントとサービスが認証に使用する方法をネゴシエートすることを可能にする標準です。SPNEGOではネゴシエーションを実行するためにHTTPヘッダーを使用するので、HTTPを使用するSOAPおよびRESTのエンドポイントが一般的であるWebなどのクロス・プラットフォームのコンテキストで特に役立ちます。

SPNEGOネゴシエーションでKerberosが使用される場合、KerberosトークンはHTTPヘッダーのauth-scheme Negotiateの下でラップされます。次のようにして、クライアントとサービス間でSPNEGOトークンの通信のために、WWW-AuthenticateおよびAuthorizationヘッダーが使用されます。

1. クライアント・リクエストが、Authorizationヘッダーなしで、サーバーの保護されたサービスにアクセスします。

2. リクエストにはAuthorizationヘッダーがないので、サーバーはレスポンスとして、ステータス・コード401(未認可)と、Negotiateに設定されたWWW-Authenticateヘッダーを返します。

3. クライアントは、Kerberosトークンを取得するためにユーザー資格証明を使用し、新しいリクエストのAuthorizationヘッダーでサーバーにそのトークンを送信します。たとえば、Authorization: Negotiate a87421000000492aa874209....のようになります。

4. サーバーはAuthorizationヘッダーのトークンをデコードします。コンテキストが完了していない場合(相互認証の場合など)、サーバーはレスポンスとして、ステータス・コード401と、デコードされたデータを含むWWW-Authenticateヘッダーを返します。たとえば、WWW-Authenticate: Negotiate 74900a2a....のようになります。

5. クライアントはこのデータをデコードし、新しいデータをサーバーに返信します。セキュリティ・コンテキストが確立されるまで、このサイクルが続行されます。

SPNEGOでKerberosを使用するためのOWSMの構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のSPNEGOネゴシエーションでのKerberosの構成に関する項を参照してください。

2.12.4 KerberosとWS-SecureConversationの導出キーについて

Web Services Secure Conversation (WS-SecureConversation)の仕様には、導出キーと呼ばれる機能が含まれています。この機能では、相互に認証済の二者が、共通の秘密を使用して、メッセージの署名や暗号化などの様々な用途で追加のキーを導出できます。

また、WS-SecureConversationの仕様では、次の2つのタイプの導出キーが定義されています。

- 明示的な導出キー: wsc:DerivedKeyToken要素を使用して、トークン情報が格納されます。そして、この情報の参照がds:KeyInfo要素に格納されます。

- 暗黙的な導出キー: ds:KeyInfo要素にトークン情報が直接格納されます。

WS-SecureConversationのコンテキストでKerberosを使用する場合は、Kerberosに関するOWSMアサーションで「導出キーの使用」オプションを有効化することによって、導入キーを使用するようにOWSMを構成できます。

2.13 Web Services Addressingの理解

Webサービス・アドレス(WS-Addressing)の仕様(http://www.w3.org/TR/ws-addr-core/)は、Webサービスおよびメッセージに対応する、特定のトランスポートに依存しないメカニズムを提供します。特に、この仕様では、Webサービスのエンドポイントを識別したり、メッセージ内のエンドポイントIDをエンド・ツー・エンドで保護したりするのに使用される多数のXML要素が定義されています。

SOAPには、メッセージの送信先やレスポンスまたはフォルトを返す標準的な方法がありません。WS-Addressingは、Webサービスのエンドポイントを識別し、メッセージにおけるエンド・ツー・エンドのエンドポイント識別を確保するXMLフレームワークを提供します。

Webサービス・エンドポイントは、Webサービスがメッセージを送信するリソース(アプリケーションやプロセッサなど)です。

次の例は、WS-Addressingを使用したものです(wsaはWS-Addressingのネームスペースです)。

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<S:Header>
<wsa:MessageID>http://example.com/xyz-abcd-123</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://example.myClient1</wsa:Address>
</wsa:ReplyTo>

WS-Addressingは、リクエストはJMSで行い、レスポンスはHTTPで行うといったように、トランスポート層に依存しません。また、WS-Policyなど、その他のWS-*仕様と組み合せて使用できます。

2.14 Webサービス信頼性の理解

WS-Trust 1.3仕様(http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html)は、セキュリティ・トークンのリクエストおよび発行を行うフレームワークを提供するWS-Securityへの拡張機能と、ブローカ信頼関係への拡張機能を定義します。WS-Trust拡張機能は、セキュリティ・トークンの発行、更新および検証を行う方法を提供しています。Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。WS-Trustの仕様に定義されているように、このような資格証明は信頼ブローカとして機能するSecurityTokenService (STS)から取得できます。

STSの使用を検討したほうがよいシナリオの例を次に示します。

- トークンの交換/変換: ある種類のトークンを別のタイプのトークンに交換する必要がある場合を想定してください。たとえば、クライアントが保持しているトークンがKerberosトークンであるときに、WebサービスからはSAMLトークンを要求されている場合があります。STSを使用することで、KerberosトークンをSAMLトークンに交換できます。

- フェデレーション: アイデンティティ・フェデレーションを使用して、ユーザーは複数のサービス・プロバイダで構成した多数のローカル・アイデンティティを統合できます。フェデレーテッド・アイデンティティを使用することで、個々のユーザーは1つのサービス・プロバイダ・サイトにログインした後、再認証もアイデンティティの再確立も行うことなく、関連するサービス・プロバイダ・サイトに移動できます。
たとえば、STSを使用して、クライアント・ユーザー名を、Webサービスによって要求されるユーザー名にマップできます。

- 信頼の集中化: STSはWebサービス・クライアントとWebサービスの両方から信頼されます。この信頼を使用して、相互運用可能なセキュリティ・トークンを提供します。

図2-2に示すトークン交換シナリオについて、考えてみてください。このシナリオでは、カスタマのデスクトップ・アプリケーション(.NET Webサービスなど)が、SAMLトークンを受け入れることができるバックエンドのWebサービスと通信します。

図2-2 STSトークンの交換

図2-2では、joeというユーザーがデスクトップにログインし、Kerberosチケットが作成されます。ユーザーがデスクトップ・アプリケーションを開いて操作を実行すると、バックエンドのWebサービスがコールされます。この場合、joeというアイデンティティをバックエンドのアプリケーションに伝播させる必要があります。しかし、クライアント側にあるのはKerberosトークンであり、バックエンドのWebサービスはSAMLトークンしか受け入れません。STSを使用することで、トークンの変換または交換を実行できます。

KerberosプロトコルをサポートするようにOWSMを構成する方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のWS-Trustの構成に関する項を参照してください。

2.15 Webサービスの信頼性のあるメッセージングの理解

WS-ReliableMessagingによって、信頼性のあるメッセージ交換が行われます。ソフトウェア・コンポーネント、システムまたはネットワークの障害に関係なく、分散アプリケーション間でメッセージの信頼性のある配信が確実に行われる必要があります。順序付き配信が保証されているため、クライアント・アプリケーションごとに、失敗したメッセージの自動再送信をコーディングする必要はありません。

Webサービスで次の問題が発生している場合は、信頼できるメッセージングの使用を検討してください。

- ネットワーク障害や接続の切断

- メッセージの転送中の消失

- メッセージの順不同での宛先への到着

WS-ReliableMessagingでは、メッセージの送信元と宛先はクライアント・サーバー・モデルに依存しないものとみなされます。つまり、クライアントとサーバーはそれぞれ、通信パスでメッセージの送信元および宛先の両方として同時に機能できます。

WS-ReliableMessaging (WS-RM)の詳細は、Oracle Infrastructure Webサービスの開発の Webサービスの信頼性のあるメッセージングの使用に関する項を参照してください。

2.16 Oracle Entitlements Serverを使用したファイングレイン認可の概要

Oracle Entitlements Server (OES)は、エンタープライズ全体のアプリケーションとサービスを保護するために使用できるファイングレイン認可サービスです。これは、複雑なアプリケーション権限の一元化した定義、およびこれらの権限の実行時における分散化された施行をサポートしています。OESを使用すると権限を外部化できるため、アプリケーションからセキュリティ決定の必要性を排除します。

OWSM OES統合はOESを使用した高度な認可のユースケースをサポートしており、次の機能が用意されています。

- OES認可をSOAPベースのWebサービスに適用できます。OES認可ポリシーでは、あるサブジェクトが、指定されたリソースに対して特定のアクションを実行するための権限が付与または拒否されます

- OESでは、付与/拒否に関する決定がコンテキスト属性に基づいて行われます。コンテキスト属性は、XPath文を使用して抽出したSOAPリクエスト・メッセージからの情報、またはHTTPヘッダーに基づいたものにすることができます。

- データ・マスキング。OWSM OESでは、Webサービスのリクエストに対するレスポンスで特定の情報を(任意の文字を使用して)マスクできます。

この項では、Oracle Entitlements Server (OES)をOWSMに統合する方法、およびファイングレイン認可でOESをOWSMと一緒に使用する方法について説明します。

- OESドキュメントへの参照

- OES統合の概要

- OWSM OESのポリシーについて

- リソースのマッピングおよび命名の概要

- 属性の処理方法

- ガード要素について

構成については、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のOracle Entitlements Serverを使用したファイングレイン認可の構成に関する項を参照してください。

2.16.1 OESドキュメントへの参照

この項では、多くのOESの概念と機能を参照しています。しかし、この項の焦点はOWSMとの統合であり、OESの概念を詳細に説明するものではありません。

OESに精通していない場合は、まず次のOESドキュメントを参照してください。

注意:

OWSMは、バージョン11.1.2.2.0以降のOESをサポートしています。

- ファイングレイン認可: Oracle Entitlements Serverを使用するためのテクニカル・インサイト

2.16.2 OES統合の概要

OWSMとOESを統合する場合は、次の操作を実行します。

- OWSM認証ポリシーをWebサービスにアタッチします。

- この項の説明に従って、OWSM oracle/binding_oes_authorization_policyポリシーまたはoracle/component_oes_authorization_policyポリシーを単体で、またはoracle/binding_oes_masking_policyポリシーと組み合せてアタッチします。

- OESコンソールを使用して認可ポリシーとデータ・マスキング・ポリシーを作成します。通常は「責任」に対して別個のポリシーを設定します。

注意:

OWSMでは、OES関連の構成が公開されていません。そのため、ここではOESコンソールを使用します。

詳細は、次のトピックを参照してください。

- OES統合: 全体像

- データ・マスキング

- XACML責任について

- OESのファイングレイン認可および大まかな認可の概要

2.16.2.1 OES統合: 全体像

OWSMエージェントは、OES内で定義されているポリシーに基づいて、保護されているWebサービスについてSOAPリクエストの認可をチェックします。そのために、OWSMはOESに、認証済サブジェクト、ターゲット・リソース、リクエストされたアクション、および認可リクエストで常に渡される一連の暗黙属性を渡します。

OESポリシーでは、SOAPリクエスト、HTTPヘッダー、メッセージ・コンテキストのプロパティからのコンテキスト属性、またはサブジェクト、ロール、グループなどのアイデンティティ情報に基づいて追加の必須値を定義できます。許可または拒否の決定を行うために、これらのコンテキスト属性がさらに必要なことをOESで構成した場合は、それらのコンテキスト属性もOWSMによって渡されます。

具体的には、OESに対して認可の決定を問い合せるための2つの方法があります(2ステップの方法と、1ステップの方法)。これらのどちらを選択するかは、oracle/binding_oes_authorization_policyおよびoracle/component_oes_authorization_policy内のuse.single.step属性を指定することによって決定します。

これらのメソッドは、次のように機能します。

- 2ステップのプロセスでは、OESコンソールでファイングレイン認可に必要な属性を事前に識別している必要があります。その後、OWSMでそれらの属性を使用します。
OWSMはまずOESをコールして必要な属性を割り出し、リクエスト・ペイロードから属性を取得した後、OESを再度コールしてOES認可ポリシーを使用して実際の認可を実行します。これは、実際には2つのOESポリシー(必要な属性を取得するためのポリシーと認可自体のポリシー)を定義していることを意味します。

常に渡される暗黙属性、および時間、日付などのOESの定義済属性も使用できます。

この方法は、「OESのファイングレイン認可および大まかな認可」で説明されているように、ファイングレイン認可に使用されます。

- 1ステップのプロセスでは、OWSMがOESに1回のみコールして、OES認可ポリシーを使用して認可を実行します。1ステップのプロセスでは、属性を事前に識別しておく必要ありません。2ステップのプロセスと同様に、常に渡される暗黙属性、および時間、日付などのOESの定義済属性も使用できます。
この方法は、「OESのファイングレイン認可および大まかな認可」で説明されているように、大まかな認可に使用できます。

2.16.2.2 データ・マスキング

OWSMをOESと統合すると、Webサービス・コードを変更せずにWebサービスからのレスポンスにある特定の情報を(アスタリスクで)マスクできます。

Webサービスのクライアント・リクエストに対するレスポンスで、機密データがネットワーク経由で渡されないようにすると仮定します。OESコンソールをoracle/binding_oes_masking_policyポリシーとともに使用して、図2-3に示すように、Webサービスからの機密データ(社会保障番号、会計情報など)をアスタリスクに置換します。

図2-3 機密データのマスキング

機密データのマスキングは、それを求める人、およびリクエストに存在するその他のコンテキスト属性に応じて実行されます。

図2-3に示すWebサービス・レスポンスに対する次のコードの流れについて、考えてみてください。

データ・マスキング・コード・フローの理解

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

2. インバウンド・リクエストで、OWSMはリクエスト・ポリシーを施行し、ユーザーBob Doeの適切な認証と認可を実行します。

3. リクエストが許可されると、OWSMはペイロードをサービス・プロバイダに渡します。サービス・プロバイダはペイロードを操作し、コール元に返信するレスポンスを準備します。

4. レスポンス処理の際には、OWSMがoracle/binding_oes_masking_policyポリシーを起動してマスキングが必要な機密データがあるかどうかを判断します。
OWSMは、コール元の情報とレスポンス・ペイロードから抽出した任意のユーザー定義の属性を渡します。

5. OESで定義されたデータ・マスキングのルールは、(トランスポート属性を介した)クライアント情報、現在のサブジェクト、リソース、アクション、およびそのポリシーで構成されている任意のレスポンス属性を考慮します。

6. 各ペイロード属性について、OESは、「XACML責任について」に従い、その属性をそのまま渡すか、マスキングするかを指定します。

7. OWSMは、OESが返すXACML責任についてを受け付け、OESによって機密データとマークされている属性はマスキングします。

2.16.2.3 XACML責任について

OESでは、XACMLの概念である責任の機能がサポートされています。のポリシー・モデルの理解に関する項で説明されているように、ポリシーで責任を使用することで、ポリシー施行コンポーネントに対して追加要件を要求することができます。

責任はOESコンソールで構成します。責任とは、コール元(OWSM)に返される任意の属性名/値のペア(またはその他の単純な名前/値のペア)のことです。OWSMとOESの統合の場合、責任になり得るのは、XPath問合せ、HTTPトランスポート・ヘッダー・プロパティまたはメッセージ・コンテキスト・プロパティです。

責任のもう1つの用途はデータ・マスキングです。データ・セキュリティのユースケースなどの一部のアプリケーションでは、「はい」または「いいえ」のような簡単な回答では不十分で、図2-3に示されているように、どのデータをどのような値でマスキングするかを指定する責任がOES認可ポリシーによって返される場合があります。

2.16.2.4 OESのファイングレイン認可および大まかな認可の概要

OWSM OESポリシーを使用して認可を実行するための2つの方法があります(ファイングレイン認可および大まかな認可)。認可タイプについては、次の各トピックで定義します。

- OESファイングレイン(責任)

- SAMLのファイングレイン

- OESの大まかな認可

2.16.2.4.1 OESファイングレイン(責任)

コンシューマのアイデンティティ、および責任内で指定されているトランスポート・ヘッダーまたはペイロードの特定のコンテンツに基づいてリソースへのアクセスを判断します。　これが一般的なユースケースです。

このユースケースでは、OESアクセス・ポリシーで属性を定義します。OWSMは、この属性をリクエストから抽出し、認可時にはこれをOESに返します。つまり、OESアクセス・ポリシーは、アイデンティティ属性とリクエスト・ペイロードから抽出された属性の組合せに基づいています。

たとえば、「SOAP本文に特定の顧客IDが含まれている場合、および認証済ユーザーがTrustedPartnersグループに属している場合にアクセスを許可する」というOESのアクセス権チェックを実行できます。

図2-4に、ファイングレイン認可のユースケースを示します。

図2-4 ファイングレイン認可

図2-4に示すWebサービス・レスポンスに対する次のコードの流れについて、考えてみてください。

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

2. このWebサービスは、OWSM認証ポリシーとOWSM OES認可ポリシーで保護されています。

3. OWSMが認証を実行し、認可のためにOESを起動します。

4. OWSMには、サブジェクト、リソース、参照アクション、およびOESに対するすべての定義済プロパティが用意されています。

5. OESは、保護されたリソースに構成されている参照アクションをコールし、構成済の責任(ある場合)でOWSMに応答します。責任は、アクションに基づいて返される可能性があります。各アクションでは、異なるXPathsなどを定義できます。

6. OWSMは、責任を評価してSOAP/XMLペイロードでXPathを実行するか、トランスポート・ヘッダーまたはメッセージ・コンテキストからプロパティ値を検出します。

7. OWSMは、サブジェクト、リソース、アクションのほかに、手順6で評価したすべての属性をOESに再提供します。

8. OESは、サブジェクト、リソース、アクションおよび属性に基づいてアクセスを決定します。

9. OESは、許可または拒否で応答します。

10. 許可された場合、OWSMがサービス・プロバイダにメッセージを渡します。

11. 拒否された場合、OWSMがリクエストを却下し、認証の失敗が示されます。

2.16.2.4.2 SAMLのファイングレイン

コンシューマのアイデンティティ、およびSAMLトークンで渡された属性に基づいてリソースへのアクセスを決定します。(SAML属性の引渡しについては、Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理のuser.attributesおよびuser.roles.includeを参照してください。)

OWSMは、SAMLアサーションから属性を渡します。SAML属性は、常に抽出されて(存在する場合)自動的に送信される暗黙属性の一部です。この属性名は、SAMLアサーション内の属性名で、値は文字列のリストです。OESでは、これらのSAML属性に加え、サブジェクト、リソース、アクションに基づいてアクセスを決定できます。

このユースケースには、2つの実装方法があります。最初の方法では、OESカスタム属性リトリーバを作成します。のカスタム属性リトリーバの作成に関する項を参照してください。2つ目の方法では、責任をSAML属性値を指すXPathと一緒に使用してOESを応答させます。

OESカスタム属性リトリーバを使用する方法に関する、次のコードの流れについて考えてみてください。

1. Webサービス・クライアントは、SOAPリクエストに属性文が指定されているSAMLトークンを送信します。

2. このWebサービスは、oracle/wss10_saml_token_service_policyおよびOWSM OES認可ポリシーで保護されています。

3. OWSMが認証を実行し、AttributeStatementに対するSAMLアサーションを確認します。属性が存在する場合、その属性を抽出して、アクセス・リクエスト用にOESを起動する際に属性として渡します。

4. OWSMは、サブジェクト、リソース、アクションをその他の定義済属性とともに提供します。

5. OESは、SAML属性、サブジェクト、リソースおよびアクションに基づいてアクセスを決定します。OESは、カスタム属性リトリーバを使用して、SAML属性を取得します。

6. OESは、許可または拒否で応答します。

7. 許可された場合、OWSMがサービス・プロバイダにメッセージを渡します。

8. 拒否された場合、OWSMがアクセス拒否フォルトでリクエストを却下します。

2.16.2.4.3 OESの大まかな認可

コンシューマのアイデンティティ、およびコールされたWebサービス操作に基づいてリソースへのアクセスを決定します。OESアクセス・チェックは、ユーザー名、グループおよびロールに限定されたアイデンティティ属性に基づいています。暗黙属性、および時間、日付などOESの定義済属性も使用できます。

このモードを使用するには、OWSM OESポリシーでuse.single.stepをtrueに設定する必要があります。

図2-5に、大まかな認可のユースケースを示します。このユースケースでは、コンシューマがサービスへのアクセスを許可されているかどうかを判断する認可ポリシーを使用して、サービスを保護することを前提としています。コンシューマのアイデンティティ(認証されたサブジェクト)および起動されたWebサービス操作に基づいてリソースへのアクセスを決定します。たとえば図2-5では、ユーザーBob Doeは顧客の詳細の取得は認可されていますが、顧客レコードの削除は認可されていません。

図2-5 大まかな認可

図2-5に示すWebサービス・レスポンスに対する次のコードの流れについて、考えてみてください。

1. Webサービス・クライアントがSOAPリクエストまたはXMLリクエストを送信します。

2. このWebサービスは、OWSM認証ポリシーとOWSM OESポリシーで保護されています。

3. OWSMが認証を実行し、アクセス・リクエストのためにOESを起動します。OWSMは、サブジェクト、リソース、アクション情報をOESに提供します。

4. OESは、サブジェクト、リソースおよびアクション情報に基づいてアクセスを決定します。

5. OESは、許可または拒否で応答します。

6. 許可された場合、OWSMがサービス・プロバイダにメッセージを渡します。

7. 拒否された場合、OWSMがアクセス拒否フォルトでリクエストを却下します。

2.16.3 OWSM OESのポリシーについて

OWSMには、次のOES認可ポリシーとマスキング・ポリシーが含まれています。

各ポリシー固有の構成情報については、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の事前定義済ポリシーに関する項を参照してください。

- oracle/binding_oes_authorization_policy: このポリシーは、OESで定義されているポリシーに基づいてユーザー認可を実行します。認可は、属性、現在の認証されたサブジェクト、およびクライアントが起動したWebサービスのアクションに基づいています。
このポリシーは、use.single.step属性の設定に応じて、Webサービスの任意の操作における大まかな認可またはファイングレイン認可に使用されます。(「OESのファイングレイン認可および大まかな認可の概要」を参照してください。)

OWSM OESポリシーには認証されたサブジェクトが必要であるため、認証ポリシーをOWSM OES認可ポリシーと一緒に使用する必要があります。

このポリシーでは、リソース、アクションおよび制約のmatch値を定義するためにguard要素(orawsp:guardを参照)も使用されます。これらの値によって、guardの結果がtrueの場合にのみ、アサーション実行が許可されるようになります。アクセスしたリソース名およびアクションが一致した場合にのみ、アサーションの実行が許可されます。デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。

このポリシーは、SOAPベースのすべてのエンドポイントにアタッチできます。

- oracle/component_oes_authorization_policy: このポリシーは、OESで定義されているポリシーに基づいてユーザー認可を実行します。
このポリシーは、use.single.step属性の設定に応じて、SOAコンポーネントの任意の操作における大まかな認可またはファイングレイン認可に使用されます。(「OESのファイングレイン認可および大まかな認可の概要」を参照してください。)

OWSM OESポリシーには認証されたサブジェクトが必要であるため、認証ポリシーをOWSM OES認可ポリシーと一緒に使用する必要があります。認可は、属性、現在の認証されたサブジェクト、およびクライアントが起動したWebサービスのアクションに基づいています。

このポリシーでは、リソース、アクションおよび制約のmatch値を定義するためにguard要素(orawsp:guardを参照)も使用されます。これらの値によって、guardの結果がtrueの場合にのみ、アサーション実行が許可されるようになります。アクセスしたリソース名およびアクションが一致した場合にのみ、アサーションの実行が許可されます。デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。

このポリシーは、SOAコンポーネントのファイングレイン認可に使用されます。

- oracle/binding_oes_masking_policy: このポリシーは、OESで定義されているポリシーに基づいてレスポンスのマスキングを実行します。認証ポリシーは、OWSM OESマスキング・ポリシーと一緒に使用できます。(サブジェクトが存在しない場合、マスキング決定時にユーザーが考慮されない。)マスキングは、属性、現在の認証されたサブジェクト、およびクライアントが起動したWebサービスのアクションに基づいています。
このポリシーでは、リソース、アクションおよび制約のmatch値を定義するためにguard要素(orawsp:guardを参照)が使用されます。これらの値によって、guardの結果がtrueの場合にのみ、アサーション実行が許可されるようになります。アクセスしたリソース名およびアクションが一致した場合にのみ、アサーションの実行が許可されます。デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。

このポリシーは、Webサービスの任意の操作におけるファイングレイン・マスキングに使用されます。

2.16.4 リソースのマッピングおよび命名の概要

OESリソース名は、OWSMリソース名にマップする必要があります。OWSMから認可コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。

- リソースのマッピングおよび命名

- OESポリシーの例

2.16.4.1 リソースのマッピングおよび命名

表2-1に、OESポリシーのリソース文字列の構成方法を示します。

命名規則に従う際には、OWSMポリシーにリソース名を設定する必要はありません。OWSMにより、リソース名が導出されます。

注意:

これがデフォルトのマッピングです。このマッピングを変更する必要がある場合には、構成オーバーライドを使用します。Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の構成プロパティと構成オーバーライドに関する項を参照してください。

表2-1 リソース文字列の決定

OESフィールド

使用する値

アプリケーション

デプロイされているアプリケーション名。

SOAの場合、コンポジット名がアプリケーション名として使用されます。

リソース・タイプ

サブジェクト・タイプに基づいて固定されます。

- SOAPの場合、WS_SERVICEである必要があります。

- SOAコンポーネントの場合、COMPONENTである必要があります。

リソース名

- SOAPおよびSOA参照の場合、web-service-name/port/web service operationの形式である必要があります。

- SOAコンポーネントの場合、SOA component name/web service operationの形式である必要があります。

アクション

デフォルトでは、次のいずれかになります。

- request.lookup (認可の責任ポリシー。)

- response.lookup (マスキングの責任ポリシー。)

- mask (実際のマスキング・ポリシー。)

- authorize (実際の認可ポリシー。)

2.16.4.2 OESポリシーの例

SOAコンポジット(SOA1)に2つのサービス・バインディング(Serv1とServ2)があるとします。

- Serv1にはport11があります。

- Serv2にはport21があります。

- port11にはoper11、oper12があります。

- port21にはoper21があります。

OESでは、表2-2に示すように、アプリケーション、リソース・タイプ、リソース名およびアクションを定義する必要があります。

表2-2 リソース文字列の例

OESフィールド

使用する値

アプリケーション

soa1

リソース・タイプ

WS_SERVICE

リソース名

Serv1/port11/oper11、

Serv1/port11/oper12、

Serv2/port21/oper21

アクション

次のいずれかになります。

- request.lookup (認可の責任ポリシー。)

- response.lookup (マスキングの責任ポリシー。)

- mask (実際のマスキング・ポリシー。)

- authorize (実際の認可ポリシー。)

表2-2に基づいた認可とマスキングのOESポリシーは、次のとおりです。

- 返される責任

- 任意の操作に対して責任を返す1つのポリシー:

GRANT (action: request.lookup; Resource: WS_SERVICE/Serv1/Port11, WS_SERVICE/Serv2/Port21; User: any) Obligation: XPath11

- 操作固有の責任を返す複数のポリシー:

GRANT (action: request.lookup; Resource: WS_SERVICE/Serv1/Port11/oper11;User:any) Obligation: XPath11
GRANT (action: request.lookup; Resource: WS_SERVICE/Serv1/Port11/oper12;User:any) Obligation: XPath12
GRANT (action: request.lookup; Resource: WS_SERVICE/Serv2/Port21/oper21;User:any) Obligation: XPath21

- 実際の認可

- リソースやアクションとは関係なく同じ認可を実行する１つのポリシー:

GRANT/DENY (action: authorize; Resource: WS_SERVICE/Serv1/Port11, WS_SERVICE/Serv2/Port21; User:<actual user>)

- 操作固有の認可を実行する複数のポリシー:

GRANT/DENY (action: authorize; Resource: WS_SERVICE/Serv1/Port11/oper11;User:<actual user>)
GRANT/DENY (action: authorize; Resource: WS_SERVICE/Serv1/Port11/oper12;User:<actual user>)

- マスキングする責任の戻り値:

GRANT (action: response.lookup; Resource: WS_SERVICE/Serv1/Port11/oper11;User:any) Obligation: XPath11
GRANT (action: response.lookup; Resource: WS_SERVICE/Serv1/Port11/oper12;User:any) Obligation: XPath12
GRANT (action: response.lookup; Resource: WS_SERVICE/Serv2/Port21/oper21;User:any) Obligation: XPath21

- 実際のマスキング:

GRANT/DENY (action: mask; Resource: WS_SERVICE/Serv1/Port11/oper11;User:<actual user>)
GRANT/DENY (action: mask; Resource: WS_SERVICE/Serv2/Port21/oper21;User:<actual user>)

2.16.5 属性の処理方法

OES管理者は、OESポリシー内の属性を責任として定義します。これは、OWSMによってペイロードから抽出された後、OESに返されます。

具体的には、OESを使用すると、責任をOESコンソールで作成できます。また、複数の属性名/値のペアが提供されます。たとえば、Employeeという名前の責任を作成して、{Name=John, Age=21, SSN=123456}などの複数の属性を指定できます。

属性は、XPath、HTTPヘッダー、メッセージ・コンテキストおよに定数(名前/値)から取得できます。これらの属性は、表2-3で説明されているように、特定の命名規則に従う必要があります。

表2-3 OESポリシーでサポートされる属性タイプ

属性タイプ

説明

必要な形式

XPath問合せ

属性名と値は、OESコンソールでXPath問合せとして指定します。

OWSMはこのXPath問合せをSOAPメッセージで実行し、その値を属性値として使用します。XPath問合せの結果は、単一値であることも複数の値であることもあります。複数の値の場合、すべての値を渡すには文字列のリストを使用します。

いずれかのXPath問合せでSOAPメッセージの評価に失敗した場合、その問合せは無視され、警告メッセージがログ内に生成されます。OWSMは、次のXPath問合せの評価を続行します。

XPath (大/小文字を区別しない)を責任名として使用し、それがXPathであることを示します。

責任は、XPath問合せで使用されているすべてのネームスペースも返します。すべてのネームスペースはNAMESPACE (大/小文字を区別しない)という属性名と一緒に返され、その値はカンマ区切りのネームスペースになります。

たとえば、認可にSAML発行者名を使用する場合、次の責任形式を使用します。

Name = XPath, values = {saml_issuer=.//saml:Assertion/@Issuer, CC_Name=ns1:sayHello/arg0, NAMESPACE=ns1=http://...,wsse=http://...}

認可フェーズでは、OWSMが属性名saml_issuerを渡し、その値はXPath問合せの結果になります。デフォルトのネームスペースは、接頭辞にマップする必要があります。(接頭辞名はアプリケーション内で一意である必要がある。)

次に例を示します。

saml=urn:oasis:names:tc:SAML:1.0:assertion,ns0=http://wsm.oracle.com,myPrefix=http://default_namespace

ネームスペースの定義はカンマで区切られています。

HTTPヘッダー

HTTPヘッダー名は、OESコンソールで指定します。

この値は、現在のリクエストHTTPヘッダーからフェッチされます。

HTTPヘッダーのプロパティを取得するには、「HTTPHeader」(大/小文字を区別しない)という名前の責任を定義します。これには、複数のHTTPヘッダー名が存在する可能性があります。

属性の名前には、値の割当て先の名前を指定する必要があります。つまり、値は実際のHTTPヘッダー名である必要があります。

次に例を示します。

Name = HTTPHeader, values = {AuthHeader=Authorization}

認可フェーズでは、OWSMがHTTPヘッダーを取得し、それを属性名で指定されている名前に割り当てます。

Message Context Properties

メッセージ・コンテキスト・プロパティ名は、OESコンソールで指定します。

この値は、現在のメッセージ・コンテキストからフェッチされます。

「MessageContext」(大/小文字を区別しない)という名前の責任を定義します。これには、複数のメッセージ・コンテキスト・プロパティ名が存在する可能性があります。

属性の名前には、値の割当て先の名前を指定する必要があります。つまり、値は実際のメッセージ・コンテキスト・プロパティ名である必要があります。

次に例を示します。

Name = MessageContext, values = {authMethod=oracle.wsm.internal.authentication.method, endpoint=oracle.j2ee.ws.runtime.endpoint-url}

認可フェーズでは、OWSMがメッセージ・コンテキスト・プロパティを取得し、それを属性名で指定されている名前に割り当てます。

たとえば、前述の例は次のように解決されます。

authMethod=USERNAME_TOKEN & endpoint=http://localhost:7001/myService

定数

定数は、OWSMで認識されないユーザー定義属性であり、そのまま渡されます。

Employeeという名前の責任は、定数の一例です。

暗黙的

OWSMは、すべての認可リクエスト内の暗黙属性を渡します。それらを渡すための構成を行う必要はありません。次の暗黙属性が常に渡されます。

- serviceURL: WebサービスのURL。

- serviceNS: Webサービスのネームスペース。

- clientIP: クライアントのIPアドレス。

- processingStage: リクエストまたはレスポンスのどちらであるか。使用可能な値は、request、responseおよびfaultです。

- isRequestOverSSL: ブール。リクエストが一方向または双方向のSSLの場合はtrue。

- authenticationMethod: 認証方式。使用可能な値は、SAML_SV、KERBEROS、SAML_HOK、X509_TOKEN_AUTHENTICATION、SAML_BEARERおよびUSERNAME_TOKENです。

- requestOrigin: VIRTUAL_HOST_TYPEトランスポート・ヘッダーから判別される内部または外部のリクエスト元。

- clientSigningCertDN: 双方向SSLにおけるX509署名用証明書またはクライアント証明書。

- operationName: ユーザーが起動した操作名。

- samlIssuer: SAMLアサーションから抽出されたSAML発行者。

- type: OESへのリクエスト・タイプ。使用可能な値は、request.lookup、response.lookup、authorizeまたはmaskです。この属性は常に送信されます。

不要。これらは常に渡されます。

通常、これらの定数をOESコンソールの「条件」で使用します。

2.16.6 ガード要素について

OWSM OES認可ポリシーでは、orawsp:guard要素が使用されます。これにより、ガードの結果がtrueの場合にのみアサーションが実行されるようにできます。つまり、アクセスしたリソース名とアクションが一致した場合にのみ、OES認可エンジンがコールされます。

デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。ただし、特定のリソース名、アクションおよび制約を設定した場合は、いずれかの構成プロパティおよびOESポリシーを使用するには、その要件を満たしている必要があります。

ガードのリソース命名規則は、OESの標準命名規則とは異なります。ガードのリソース名は、<Webservice_NS>/<SERVICE_NAME>の形式にする必要があります。

2.17 個人の身元を特定する情報の概要

個人の身元を特定する情報 (PII)は、社会保障番号、住所、銀行の口座番号、およびその他の類似情報を指しています(通常は1人の特定のユーザーに関連付けられており、保護する必要がある)。OWSMは、セキュリティ・ポリシーの制御範囲外にあるPIIを保護するためのソリューションを提供します。これにより、PIIがログ内、メッセージ内、監査証跡内で非表示になります。

- PIIデータの概要

- PIIポリシーのXPath式について

- PIIポリシーを使用する状況

- PIIに対するアクセス権を持っているのは誰か

- アンマーシャリングに関するその他の考慮事項について

2.17.1 PIIデータの概要

OWSM WS-Securityポリシーには、メッセージ保護を使用して情報を選択的に暗号化する方法が用意されています。ただし、この情報がSOAコンポジット内部で処理されるときなど、セキュリティ・ポリシーの制御範囲外にあって暗号化されないことがあります。

- PIIデータについて

- PIIセキュリティ・ポリシーについて

2.17.1.1 PIIデータについて

ビジネス上の慣習で、アプリケーション内での情報(特にPII情報)フローであっても暗号化が必要な場合があります。

ご使用の環境がこのケースに当てはまる場合は、各コンポーネントへのメッセージ・フローにおいてPII情報を暗号化したままにしておく必要があります。たとえば、SOAの場合、PIIはSOAコンポジットのエントリ・ポイントで暗号化し、参照バインディングの終了ポイントで復号化する必要があるということです。

oracle/pii_security_policyポリシーは、この目的でデータを暗号化するために提供されています。

文字列ではないデータのアンマーシャル時における追加情報については、「アンマーシャリングに関するその他の考慮事項について」を参照してください。

注意:

OWSM WS-Securityポリシーは、情報暗号化の方法を提供していますが、このメカニズムを使用してPIIデータを暗号化することはできません。アプリケーションが、特定のXML構造を備えた情報を予期していたり、そのような情報に依存している可能性があるためです。OWSMポリシーでは、XML構造にCipherData (http://www.w3.org/TR/xmlenc-core/#sec-CipherData)要素が追加されます。ご使用のアプリケーションがこの要素を予期していない可能性があります。

2.17.1.2 PIIセキュリティ・ポリシーについて

oracle/pii_security_policyには次の設定と、保護するPIIデータを正確に指定する構成プロパティが含まれています。ポリシーをアタッチする際にこれらの属性を設定したり、必要に応じてオーバーライドすることができます。

注意:

ローカルの最適化(OWSMポリシー(SOAコンポジット)でのローカルの最適化の使用に関する項を参照)はデフォルトでオフになっているため、oracle/pii_security_policyポリシーが常に施行されます。SOAコンポジットから移動する前には、PIIが復号化されます。その影響を理解しないまま、oracle/pii_security_policyポリシーに対するローカルの最適化をオンにしないでください。

XPathsを使用してPIIデータを使用する方法については、「PIIポリシーのXPath式について」を参照してください。

- encryption-algorithm: データ暗号化アルゴリズム。AES/CBC/PKCS5Paddingにする必要があります。

- algorithm: 鍵導出アルゴリズム。PBKDF2にする必要があります。

- Salt: 鍵導出で使用されるNULL以外の空でないsalt。デフォルト値はpii-securityです。

- Iteration: 鍵導出の反復回数。デフォルトは1000です。

- Keysize: 鍵導出で使用する鍵のサイズ。デフォルトは128です。

- request.xpaths: リクエストのXPathのカンマ区切りのリスト。デフォルト値は空白です。たとえば、//ns2:ShipToLocationIdです。

- request.namespaces: リクエストのネームスペースのカンマ区切りのリスト。各ネームスペースの接頭辞とURIは、等号(=)で区切られます。デフォルト値は空白です。

- response.xpaths: レスポンスのXPathのカンマ区切りのリスト。デフォルト値は空白です。たとえば、//ns2:ShipToLocationIdです。

- response.namespaces: ネームスペースのカンマ区切りのリスト。各ネームスペースの接頭辞とURIは、等号(=)で区切られます。デフォルト値は空白です。

- csf.key: oracle/pii_security_policyポリシーは、対称鍵を生成する際に指定したパスワードのCSFキー属性を使用します。この鍵は、PIIデータの暗号化と復号化に使用されます。デフォルト値はpii-csf-keyです。

- reference.priority: ポリシー・アタッチメントの優先度の指定に関する項を参照してください。

注意:

pii-securityアサーションは、ポリシー内の唯一のアサーションである必要があります。pii-securityアサーションは、他のアサーションを持つポリシーに追加しないでください。そうすると、ポリシーが無効になります。

2.17.2 PIIデータを保護する方法の例

セキュリティ・ポリシーがコントロール外の場合に、PIIをoracle/pii_security_policyポリシーで保護することが重要である理由を理解するには、例を使用するのが最適です。

図2-6に示すOracle Service Busの例について考えます。図2-6で示すように、PII保護の主要な原則は次のとおりです。

- サービス側(proxy service)にアタッチされたPIIポリシーは、リクエストの受信後にPIIを暗号化し、レスポンスを送信する前にPIIを復号化する必要があります。

- クライアント側(ビジネス・サービス)にアタッチされたPIIポリシーは、リクエストを送信する前にPIIを復号化し、レスポンスを受信した後でPIIを暗号化する必要があります。

PIIデータの暗号化には、入口ポイントと出口ポイントの両方が必要です。PIIデータは入る前に暗号化され、出る前に復号化されます。

図2-6 Oracle Service BusのPII暗号化

図2-6のコントロールのフローは、次のとおりです。

1. OWSM Webサービス・クライアントは、クライアント・リクエストに署名し、クライアント・リクエストを暗号化して、プロキシ・サービスに送信します。

2. 外部Webサービスを仮想化するには、OSBプロキシ・サービスを作成して、ビジネス・サービスに接続するパイプラインとして使用します。つまり、OWSMサービス側のポリシーをプロキシにアタッチします。
OWSMエージェントは、メッセージ保護ポリシーを使用してメッセージを復号化します。

3. この時、すべてのPII情報は脆弱になる可能性があります。それを防ぐために、PIIポリシーはメッセージでPIIを暗号化します。

4. Oracle Service Busはメッセージのコントロールを想定し、プロキシ・サービスはリクエストをビジネス・サービスに渡します。

5. ビジネス・サービスはメッセージ・データにアクセスし、これには暗号化されたばかりのPIIデータが必要に応じ、含まれる場合があります。

6. OWSMエージェントは再び、PIIポリシーを適用し、PIIフィールドを復号化します。

7. ビジネス・サービスは、基本的にすべてのクライアント構成で、外部サービスのコールのために必要です。Oracle Service Busは、OWSMクライアント・ポリシーのビジネス・サービスへのアタッチをサポートします。
メッセージ保護ポリシーが適用され(署名され、暗号化されて)、メッセージはWebサービスに送信されます。

8. プロセスは、レスポンスを繰り返し、Webサービス・クライアントに戻されます。

2.17.3 PIIポリシーのXPath式について

XPath式を使用して、保護するPIIデータを指定します。

より具体的には、XPath式を使用して、保護する要素を正確に指定します。XPathは、XPathテキスト・ノードで終了する必要があります。

XPathの結果がテキスト・ノードである場合、テキスト・ノードのコンテンツは暗号化されます。空の(つまり、すべて空白の)テキスト・ノードは、暗号化も復号化もされません。

XPathで複数のノードが返された場合は、それらのすべてが暗号化されます。何も返されない場合は、無視されます。

指定したXPathsは、env:Bodyの最初の子要素をルート・ノードとして設定して評価されます。

JDeveloperを使用して、次のSOAPメッセージを表示するとします。

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body

xmlns:ns1="http://xmlns.oracle.com/apps/prc/po/editDocument/purchaseOrderService/types/">
<ns1:createPurchaseOrder>
<ns1:createOrderEntry

xmlns:ns2="http://xmlns.oracle.com/apps/prc/po/editDocument/purchaseOrderService/">
<ns2:DocumentStyleId>1</ns2:DocumentStyleId>
<ns2:ProcurementBuId>204</ns2:ProcurementBuId>
<ns2:BuyerId>100010026863783</ns2:BuyerId>
<ns2:RequisitioningBuId>204</ns2:RequisitioningBuId>
<ns2:SupplierId>559</ns2:SupplierId>
<ns2:SupplierSiteId>5058</ns2:SupplierSiteId>
<ns2:SupplierContactId>100000011552368</ns2:SupplierContactId>
<ns2:ApprovalActionCode>BYPASS</ns2:ApprovalActionCode>
<ns2:DocumentDescription>DO NOT TOUCH THIS ORDER (V15)</ns2:DocumentDescription>
<ns2:PurchaseOrderEntryLine>
<ns2:LineTypeId>1</ns2:LineTypeId>
<ns2:ItemId>199</ns2:ItemId>
<ns2:Quantity>10</ns2:Quantity>
<ns2:UnitOfMeasureCode>Ea</ns2:UnitOfMeasureCode>
<ns2:PurchaseOrderEntrySchedule>
<ns2:ShipToLocationId>207</ns2:ShipToLocationId>
<ns2:ShipToOrganizationId>207</ns2:ShipToOrganizationId>
<ns2:NeedByDate>2020-12-31</ns2:NeedByDate>
<ns2:PurchaseOrderEntryDistribution />
</ns2:PurchaseOrderEntrySchedule>
</ns2:PurchaseOrderEntryLine>
</ns1:createOrderEntry>
</ns1:createPurchaseOrder>
</soap:Body>
</soap:Envelope>

次に、XPathの例をいくつか示します。

- //ns2:ShipToLocationId
//表記法(子孫または自己の軸)を使用して、ShipToLocationIdsの本体全体を検索することを示します。これらのXPathsでは、ドキュメント全体の検索が必要になるため低速になります。

- /ns1:createPurchaseOrder/ns1:createOrderEntry/ns2:BuyerId
このXPathでは、本体の子createPurchaseOrder、次にcreatePurchaseOrderの子createOrderEntry、最後にcreateOrderEntryの子BuyerIdを参照することが明確に指定されています。

PIIポリシーには、リクエスト・メッセージとレスポンス・メッセージの両方にXPathリストが必要です。

2.17.4 PIIポリシーを使用する状況

oracle/pii_security_policyポリシーは、単一のSOAコンポジットおよびPIIがJCAバインディングにあるユースケースでのみ使用できます。

注意:

グローバル・ポリシー・アタッチメントは、oracle/pii_security_policyポリシーでの使用をお薦めしません。

この項には次のトピックが含まれます:

- 単一のSOAコンポジットのユースケース

- ビジネス・サービス・ユースケースへのOracle Service Busプロキシ・サービス

- JCAバインディング・ユースケースにおけるPII

注意:

Fusion Middleware ControlおよびJDeveloperコントロールでは、サポートされていないサブジェクト・タイプにpii_security_policyポリシーをアタッチすると、実行時の検証エラーが発生します。

WLSTでは、サポートされていないサブジェクト・タイプにポリシーをアタッチすると、検証エラーが発生します。

The web service configuration is invalid in this context because of the following error: WSM-01832 : PII Policy oracle/pii_security_policy is not supported on the Resource, as the PII policy
is not supported on SubjectType : WS_SERVICE

2.17.4.1 単一のSOAコンポジットのユースケース

pii_security_policyポリシーはSOAコンポジットにのみアタッチ可能で、そのコンポジット内のPIIのみを保護できます。その他のSOAユースケースはサポートされていません。

pii_security_policyポリシーをSOAコンポジットにアタッチした場合、メッセージがSOAコンポジットに入るときにPIIは暗号化され、(SOA参照バインディング・コンポーネントで)そのコンポジットから出るときに復号化されます。具体的には、次のようになります。

- サービス側(サービス・バインディング)では、pii_security_policyポリシーが、リクエストの受信後にPIIを暗号化し、レスポンスの送信前にPIIを復号化します。

- クライアント側(参照バインディング)では、pii_security_policyポリシーが、リクエストの送信前にPIIを復号化し、レスポンスの受信後にPIIを暗号化します。

注意:

PIIデータには、入口ポイントと出口ポイントの両方が必要です。PIIデータは入る前に暗号化され、出る前に復号化されます。

pii_security_policyポリシーをクライアント側でアタッチした場合、それをサービス側でもアタッチする必要があります。逆の場合も同様です。暗号化/復号化のメカニズムでは、その両方が必要です。

図2-7に示すように、BPEL、Oracle Mediatorなど、コンポジットの様々なコンポーネントを流れるメッセージでは、PIIは暗号化されたままです。

図2-7 単一のSOAコンポジットのユースケース

PIIおよび認可ポリシーの両方がアタッチされている場合の重要な考慮事項の理解

pii_security_policyポリシーと認可ポリシーの両方がSOAコンポジットにアタッチされている場合は、認可ポリシーがPIIポリシーより前に実行されます。そうしないと、pii_security_policyポリシーが、認可で使用するフィールドを暗号化する場合があります。

ただし、認可ポリシーがかわりにSOAコンポーネント・レベルでアタッチされていて、pii_security_policyで暗号化されたフィールドが認可で必要とされる場合、認可に失敗します。これは、サポートされているユースケースではありません。

2.17.4.2 ビジネス・サービス・ユースケースへのOracle Service Busプロキシ・サービス

詳細は、次のドキュメントを参照してください。

Oracle Service Busへのoracle/pii_security_policyのアタッチ方法については、Oracle Service Busでのサービスの開発のメッセージ内の個人の身元を特定する情報の非表示に関する項を参照してください。

2.17.4.3 JCAバインディング・ユースケースにおけるPII

PIIポリシーは、SOAとOracle Service Busの両方のJCAアダプタにアタッチできます。

OSBでは、Oracle Service Busへのoracle/pii_security_policyのアタッチ方法については、Oracle Service Busでのサービスの開発のメッセージ内の個人の身元を特定する情報の非表示に関する項を参照してください。

この項の残りの部分では、SOAのユースケースについて説明します。

『Oracle SOA Suiteを使用したSOAアプリケーションの開発』のJCAアダプタに関する項で説明されているように、JCAアダプタを使用すると、SOAのサービスおよび参照をデータベースやファイル・システムなどのテクノロジと統合できます。JCAアダプタは、Oracle Fusion MiddlewareプラットフォームのJCAバインディング・コンポーネントと統合されます。これにより、その他のサービス・エンジンおよびバインディング・コンポーネントとの統合も実現されます。

図2-8に示すJCAアダプタPIIのユースケースについて、考えてみてください。

図2-8 JCAアダプタPIIのユースケース

コンポジットには、インバウンド・サービス・バインディング・コンポーネント(インバウンド・アダプタ)、BPELプロセスなどのサービス・コンポーネントおよびアウトバウンド参照バインディング・コンポーネント(アウトバウンド・アダプタ)が含まれます。

注意:

PIIデータには、入口ポイントと出口ポイントの両方が必要です。PIIデータは入る前に暗号化され、出る前に復号化されます。

pii_security_policyポリシーを参照バインディング側でアタッチした場合、それをサービス・バインディング側でもアタッチする必要があります。逆の場合も同様です。暗号化/復号化のメカニズムでは、その両方が必要です。

このユースケースでは、PIIは次のように保護されます。

- サービス・バインディング・コンポーネントは、SOAコンポジット・アプリケーションへの外部からのエントリ・ポイントを提供します。
サービス側(JCAバインディング)では、pii_security_policyポリシーが、リクエストの受信後にPIIを暗号化し、レスポンスの送信前にPIIを復号化します。

- BPEL、Oracle Mediatorなど、コンポジットの様々なコンポーネントを流れているメッセージでは、PIIは暗号化されたままです。

- 参照バインディング・コンポーネントは、SOAコンポジット・アプリケーションから外部サービスへのメッセージの送信を可能にします。
クライアント側(JCAバインディング(参照))では、pii_security_policyポリシーが、リクエストの送信前にPIIを復号化し、レスポンスの受信後にPIIを暗号化します。

JCAアダプタとSOA環境の統合方法の詳細は、『テクノロジ・アダプタの理解』を参照してください。

2.17.5 PIIに対するアクセス権を持っているのは誰か

管理者は常に、PIIの暗号化で使用する鍵へのアクセス権を持っており、PIIの暗号化を再構成することもできます。そのため、PIIポリシーによって、管理者や管理者権限を持つその他のユーザーからデータを保護することはできません。これは、そのような目的での使用を意図されていません。

ただし、管理者は、次のシナリオで暗号化キーとPIIデータが表示されていないことを確認する必要があります。

- OWSMメッセージ・ログ、サーバーの診断ログ、SOAメッセージ・ログなどの任意の種類のログ。ログは頻繁にコピーされ、管理者以外のユーザーに対しても公開されます。

- 管理者以外のユーザーが表示できる任意の画面。
そのようなユーザーに対しては、PII情報が非表示になるはずです。このユーザーはログを参照できますが、ログには暗号化されたPIIデータがあります。このユーザーは復号化に必要なキー情報を表示できません。

- オペレータ、モニターなどのロール。これらのロールでは、PII暗号化キーまたはPIIデータにアクセスできません。また、復号化されたPIIデータを含むどのログ・ファイルにもアクセスできません。

2.17.6 アンマーシャリングに関するその他の考慮事項について

アンマーシャリングでは、XMLドキュメントを変換して、Javaプログラム要素やオブジェクトのツリーを作成します。これは、Javaコードでアクセス可能なドキュメントのコンテンツや構成を表しています。コンテンツ・ツリーでは、複合タイプは値クラスにマップされます。属性宣言または単純型を持つ要素は、値クラス内のプロパティまたはフィールドにマップされ、その値にアクセスするにはgetメソッドとsetメソッドを使用します。

アンマーシャリング は、JAXBバインディング・フレームワークによって管理されています。

PIIデータが暗号化されると、メッセージの元のテキストは暗号化された文字列で置き換えられます。ただし、文字列以外のデータ型(整数、日付など)が暗号化された文字列内にある場合、後続のアンマーシャリングが破損することがあります。

pii_security_policyポリシーを実装する前は、アンマーシャリングの影響に注意してください。アンマーシャリングが関係している場合は、文字列データ型のみが動作し、それ以外は破損する可能性があります。

アンマーシャリングは、SOAの次のバインディングで発生することがあります。

- EJBアダプタ

- レガシーSDO EJBアダプタ

- ADFアダプタ

- 直接バインディング

- ルール・エンジン

アンマーシャリングは、次のSOAコンポーネントで発生することがあります。

- BPELエンティティ変数

- Springサービス・エンジン

アンマーシャリングは、Oracle Service Busの次のポイントで発生することがあります。

- SOA直接バインディング

- EJBトランスポート

2.18 RESTおよびSOAPのサービスおよびクライアントのOAuth 2.0の理解

Oracle WSMでは、Webサービス・クライアントがMobile and Social OAuth 2.0サーバーが実装するSOAPおよびRESTのWebサービスと対話し、2-legged認可を行うことができます。

詳細は、『Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOracle Web Services ManagerでのOAuth2の使用に関する項を参照してください。

2.19 資格証明およびキーストアの管理のためのREST APIの理解

資格証明およびキーストアを管理するREST APIは、ドメインまたはWebサービスの資格証明ストア、キーストアおよびトラスト・ストアを作成、構成するためのエンドポイントを提供します。詳細は、『Oracle® Fusion Middleware Oracle Web Services Managerでの資格証明およびキーストアの管理のためのREST API』を参照してください。

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

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

この章の内容は次のとおりです。

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

- Webサービス・ポリシーの理解

- ポリシーのアサーションを使用したWebサービス・バインディングの概要

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

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

- ポリシーの実行方法の理解

- OWSMの事前定義済ポリシーとアサーション・テンプレートについて

- セキュリティ・ポリシー構成のオーバーライドについて

- WSMリポジトリで作成されたドキュメントの推奨命名規則について

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

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

- OWSMポリシー・フレームワークのコンポーネントについて

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

- OWSMエージェントとポリシー・マネージャの特性について

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

- OWSM構成アーティファクトについて

3.1.1 OWSMポリシー・フレームワークのコンポーネントについて

OWSMポリシー・フレームワークは、WS-Policy標準を使用して作成されています。

OWSMのポリシー強制ポイント(PEP)は、図3-1のように、認証および権限ベースの認可にOracle Platform Security Service (OPSS)およびOracle WebLogic Serverオーセンティケータを活用します。

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

のOWSMポリシー・マネージャ、エージェント、リポジトリおよびEnterprise Managerが、ポリシー・フレームワークを形成します。

- ポリシー・マネージャは、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サービス・メトリックも表示されます。

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

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

OWSMエージェントとOWSMポリシー・マネージャの高レベルの相互作用を、図3-2に示します。

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

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

OWSMエージェントには、自動検出機能が備わっており、OWSMポリシー・マネージャを検索し、接続します。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したOWSMポリシー・アクセスの構成に関する項を参照してください。

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

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

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

3.1.3 OWSMエージェントとポリシー・マネージャの特性について

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

ポリシー・マネージャは、wsm-pm.earファイルに格納されます。OWSMで提供されるサービスはいずれもシングルトンではないため、完全なアクティブ/アクティブ・モードで実行可能です。OWSMサービスは、http://host:port/wsm-pm/validatorで検証できます。このvalidatorには、OWSMポリシー、アサーション・テンプレートおよびビルド・ラベルや作成タイムスタンプなどのコントリビューションの詳細が表示されます。

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

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

外部依存性

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

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

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

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

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

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

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

3.1.5 OWSM構成アーティファクトについて

OWSMドメイン構成設定は、OWSMエージェント・インストールごとに、Oracle Enterprise Manager Fusion Middleware Controlから設定できます。

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

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

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

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

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

3.2 Webサービス・ポリシーの理解

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

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

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

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

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

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

ポリシー・カテゴリ

説明

適用対象: SOAP、RESTまたはその両方

Addressing

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

SOAP

アトミック・トランザクション

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

- WS-AtomicTransaction(WS-AT)バージョン1.0、1.1および1.2: http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec-cs-01/wstx-wsat-1.2-spec-cs-01.html

- WS-Coordinationバージョン1.0、1.1および1.2: http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-cs-01/wstx-wscoor-1.2-spec-cs-01.html

アトミック・トランザクションの詳細は、『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サービスの信頼性のあるメッセージングの理解」を参照してください。

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

3.3 ポリシーのアサーションを使用したWebサービス・バインディングの概要

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

詳細は、次のトピックを参照してください。

- ポリシーのアサーションを使用したWebサービス・バインディングについて

- 複数のポリシー選択肢の定義(ORグループ)について

3.3.1 ポリシーのアサーションを使用したWebサービス・バインディングについて

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

アサーションは、パイプライン内での順序で実行されます。

注意:

ORグループにポリシーを実施する複数の選択肢を定義する方法の詳細は、「複数のポリシー選択肢の定義(ORグループ)について」を参照してください。

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

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

たとえば、図3-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バインディング・レベルの認証されたサブジェクトに基づいてリクエストに対する簡単なロールベースの認可を行います。

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

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

3.3.2 複数のポリシー選択肢の定義(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に関する項を参照してください

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

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

表3-2に、OWSMポリシーをアタッチできるポリシー・サブジェクトを示します。さらに、表にはWLSTによるポリシー・サブジェクト・タイプの特定に使用する等価の名前、および各ポリシー・サブジェクト・タイプに対する有効なリソース・スコープがリストされています。リソース・スコープはポリシー・セットの作成時に適用可能です。詳細は、「ポリシー・セットを使用したグローバル・ポリシー・アタッチメントの概要」を参照してください。WLSTでのリソース・スコープの指定方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のリソース・スコープの定義に関する項を参照してください。

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

ポリシー・サブジェクト

WLST名

有効なリソース・スコープ(ポリシー・セット)

ADF RESTful Webサービス接続

rest-connection

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

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

- ドメイン

- アプリケーション

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

- リソース・パス

ADF SOAP Webサービス接続

ws-connection

- ドメイン名

- アプリケーション名

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

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

- ポート名

ESS SOAP JOBコールバック

job-callback

- ドメイン名

- アプリケーション名

- ESSジョブ名

ESS SOAP JOBインボーカ

job-invoke

- ドメイン名

- アプリケーション名

- ESSジョブ名

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

- ドメイン名

- アプリケーション名

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

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

- リソース・パス

SOAコンポーネント

SOA JCA参照

sca-jca-reference

- ドメイン名

- アプリケーション名

- SOAパーティション名

- SOAコンポジット名

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

SOA JCAサービス

sca-jca-service

- ドメイン名

- アプリケーション名

- SOAパーティション名

- SOAコンポジット名

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

SOA RESTful参照

sca-rest-reference

- ドメイン名

- アプリケーション名

- SOAパーティション名

- SOAコンポジット名

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

SOA RESTfulサービス

sca-rest-service

- ドメイン名

- アプリケーション名

- SOAパーティション名

- SOAコンポジット名

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

SOA SOAP参照

sca-reference

- ドメイン名

- アプリケーション名

- SOAパーティション名

- SOAコンポジット名

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

- ポート名

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

SOA SOAPサービス

sca-service

- ドメイン名

- アプリケーション名

- SOAパーティション名

- SOAコンポジット名

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

- ポート名

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

ws-callback

- アプリケーション名

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

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

SOAP Webサービス

ws-service

- アプリケーション名

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

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

- ポート名

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

ws-client

- アプリケーション名

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

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

- ポート名

- Java EE Webサービス・クライアントのEJB名

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

この項では、様々なタイプのポリシーを紹介し、異なるポリシーをアプリケーションにアタッチするプロセスについて説明します。

- ポリシー・サブジェクトへのポリシーのアタッチについて

- 直接ポリシー・アタッチメントについて

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

3.5.1 ポリシー・サブジェクトへのポリシーのアタッチについて

OWSMでは、ポリシーに含まれるアサーションのカテゴリに基づいてサブジェクトにアタッチできるポリシーの数が制限されます。直接的および外部からの(グローバルな)ポリシー・アタッチメントをサポートするために、OWSMでは、各ポリシー内のアサーションのカテゴリ、ポリシー・アタッチメントの優先度、実行時の制約およびポリシー・アタッチメントのステータス(有効/無効)を考慮して、サブジェクトに対して有効なポリシー・セットを判別します。

ポリシーのアタッチは、アプリケーションのライフサイクルの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サービスのセキュリティがセキュリティ管理者の制御下に移るため、この方法は最も強力で柔軟性があります。ポリシーはエンドポイントに直接アタッチできます。また、ポリシー・セットを使用してエンドポイントの範囲に対してグローバルにアタッチできます。

エンドポイントに対して有効なポリシー計算の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の有効なポリシー・セットの計算方法に関する項を参照してください。

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

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

3.5.2 直接ポリシー・アタッチメントについて

アプリケーションのデプロイ後は、SOAP Webサービス、クライアント・エンドポイント、RESTfulリソースおよびクライアントなどのポリシー・サブジェクトに、OWSMポリシーを直接アタッチできます。

ポリシーをアタッチできるポリシー・サブジェクトの完全なリストは、「ポリシー・サブジェクトの理解」を参照してください。ポリシーを直接アタッチする方法の詳細は、Fusion Middleware Controlを使用したポリシーの直接アタッチに関する項とWLSTを使用したWebサービスおよびクライアントへのポリシーのアタッチに関する項を参照してください。

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

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

- ポリシー・セットを使用したグローバル・ポリシー・アタッチメントについて

- サブジェクト・タイプおよびリソース・スコープについて

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

3.5.3.1 ポリシー・セットを使用したグローバル・ポリシー・アタッチメントについて

ポリシー・セットを使用しているグローバル・ポリシー・アタッチメントは、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ディレクトリに格納されます。

3.5.3.2 サブジェクト・タイプおよびリソース・スコープについて

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

注意:

ポリシー・セットを作成する場合、SOAP WebサービスおよびSOAP Webサービス・クライアントのサブジェクト・タイプが、Oracle InfrastructureのWebサービスとクライアントおよびJava EEのWebサービスとクライアントを両方とも参照します。

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

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

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

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

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

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

3.6 ポリシーの実行方法の理解

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

3.7 OWSMの事前定義済ポリシーとアサーション・テンプレートについて

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シナリオのサブセットをサポートしています。

3.8 セキュリティ・ポリシー構成のオーバーライドについて

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

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

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

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

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

3.9 WSMリポジトリで作成されたドキュメントの推奨命名規則について

そのドキュメントの目的がすぐにわかるように、ポリシーの名前、ポリシー・セットまたはアサーション・テンプレートにできるだけ多くの情報を暗号化することをお薦めします。

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

- 大文字と小文字

- 数値

- 通貨記号($)

- アンダースコア (_)

- ハイフン(-)

- Spaces

注意:

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

たとえばOracle Fusion Middleware 12cに付属している定義済セキュリティ・ポリシーの1つは、oracle/wss10_username_token_with_message_protection_service_policyという名前です。図3-6で、この事前定義済ポリシー名の各部分を確認します。

図3-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証明書トークン

- jwt_token – JWTTトークン

- oauth2_token – Oauthトークン

カスタムの認証トークンを定義することもできます。

- トランスポート・セキュリティ - ポリシーでセキュア・トランスポート・レイヤーによるメッセージ送信を要求する場合は、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_を使用する(例: oracle_wss_http_token_service_policy)ことは、ベスト・プラクティスとしてお薦めしません。

A Webサービス・セキュリティ標準

この付録には、Oracle Infrastructure Webサービスのセキュリティ標準がまとめられています。Oracle Infrastructure Webサービスに対してサポートされている標準の完全なリストは、『Oracle Infrastructure Webサービスの開発』のサポートされている標準に関する項を参照してください。

この項には次のトピックが含まれます:

- セキュリティ標準

A.1 セキュリティ標準

セキュリティ標準は、トランスポート・レベルのXML以外のフレームと、アプリケーション・レベルのXMLフレームワークに実装されています。

表A-1に、トランスポート・レベルとアプリケーション・レベルの両方で安全かつ管理可能なSOA環境を提供するために不可欠な標準を示します。

WebLogic Webサービスの標準の完全なリストと各標準の説明は、『Oracle WebLogic Server WebLogic Webサービスの理解』のWebLogic Webサービスでサポートされている機能および標準に関する項を参照してください。

表A-1 Webサービスの標準および仕様のURL

標準

説明および仕様のURL

Webサービスの相互運用性組織: Basic Security Profile

オラクル社は、Webサービス・プラットフォームの相互運用性は、可能なあらゆるケースのWebサービス仕様に対してサポートを提供するよりも重要であると考えます。当社はWebサービスの相互運用性組織による次の仕様を遵守しており、これをWebサービスの相互運用性に対するベースラインとしています。

詳細は、次を参照してください。

- Basic Security Profile 1.0仕様: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html

Transport Layer Security - SSL

Transport Layer Security (TLS)とも呼ばれるSecure Sockets Layer (SSL)は、最も広く使用されているトランスポート・レイヤー・データ通信プロトコルです。

詳細は、次を参照してください。

- 「トランスポート・レベルおよびアプリケーション・レベルのセキュリティの理解」

- SSL 3.0: http://tools.ietf.org/html/rfc6101

XML暗号化(機密保護)

XML暗号化の仕様には、データを暗号化し、その結果をXMLで表すためのプロセスが記述されています。

詳細は、次を参照してください。

- 「メッセージの暗号化について」

- XML Encryption Syntax and Processing仕様: http://www.w3.org/TR/xmlenc-core

XML署名(整合性、認証性)

XML署名の仕様には、署名の処理ルールと構文が記述されています。XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは、送信者の秘密鍵を使用して署名され、署名は送信者の公開鍵を使用して検証されます。

詳細は、次を参照してください。

- 「メッセージの署名(XML署名)について」

- XML Signature WG仕様: http://www.w3.org/Signature/

WS-Security

Web Services Security (WS-Security)は、XML暗号化により機密保護を、XML署名によりデータ整合性を実現するSOAPセキュリティ拡張機能を指定します。WS-Securityには、タイプの異なるバイナリとXMLセキュリティ・トークンを、認証および認可の目的でWS-Securityヘッダーに挿入する方法を指定するプロファイルも含まれています。

詳細は、次を参照してください。

- 「セキュリティ・ポリシーの理解」

- OASIS Web Services Security (WSS) TC仕様: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

ユーザー名トークン

ユーザー名トークンはBasic認証情報を伝達します。username-token要素は、メッセージを認証するためにユーザー名とパスワードの情報を伝播します。

詳細は、次を参照してください。

- 「ユーザー名トークンについて」

- Web Services Security UsernameToken Profile 1.0仕様: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf

X.509証明書

X.509デジタル証明書は、受信パーティに公開鍵を送信するために設計された署名付きデータ構造です。証明書には、証明書ID、発行者の識別名(DN)、有効期間、所有者のDN、所有者の公開鍵などの標準フィールドが含まれています。

詳細は、次を参照してください。

- 「X.509証明書について」

- Web Services Security X.509 Certificate Token Profile仕様: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf

Kerberosトークン

Kerberosトークンは、クロス・プラットフォーム認証のシングル・サインオン・システムです。Kerberosプロトコルを使用すると、共有の秘密鍵(対称鍵)に依存する2つのエンティティ間で相互認証を実行できます。

詳細は、次を参照してください。

- 「Kerberosトークンについて」

- Web Services SecurityKerberos Token Profile 1.1仕様: http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf

SAMLトークン

Security Assertion Markup Language (SAML)は、XMLドキュメントを使用して、インターネット上でセキュリティ情報を共有するためのオープン・フレームワークです。

詳細は、次を参照してください。

- 「SAMLトークンについて」

- Web Services Security SAML Token Profile仕様: http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf

WS-Policy

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

詳細は、次を参照してください。

- 「Webサービス・ポリシーの理解」

- Web Services Policy 1.2 - Framework (WS-Policy)仕様: http://www.w3.org/Submission/WS-Policy/

WS-SecurityPolicy

WS-SecurityPolicyは、WS-Policyフレームワークのコンテキストで使用する一連のセキュリティ・ポリシー・アサーションを定義します。WS-SecurityPolicyアサーションは、通信パスでメッセージの安全性を確保する方法を示すものです。

詳細は、次を参照してください。

- 「セキュリティ・ポリシーの理解」

- WS-SecurityPolicy 1.2仕様: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html

Webサービス・アドレス(WS-Addressing)

SOAPには、メッセージの送信先やレスポンスまたはフォルトを返す標準的な方法がありません。WS-Addressingは、Webサービスのエンドポイントを識別し、メッセージにおけるエンド・ツー・エンドのエンドポイント識別を確保するXMLフレームワークを提供します。

詳細は、次を参照してください。

- 「Web Services Addressingの理解」

- Web Services Addressing 1.0 - Core仕様: http://www.w3.org/TR/ws-addr-core/

WS-Trust

セキュリティ・トークンのリクエストおよび発行と、信頼関係の仲介のためのフレームワークを提供する、WS-Securityへの拡張機能が定義されています。WS-Trust拡張機能は、セキュリティ・トークンの発行、更新および検証を行う方法を提供しています。

詳細は、次を参照してください。

- 「Webサービス信頼性の理解」

- WS-Trust 1.3仕様: http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html

WS-ReliableMessaging

WS-ReliableMessaging (WS-RM)は、Webサービス・エンドポイント間の信頼できるメッセージ配信を確認および管理するフレームワークを定義します。

詳細は、次を参照してください。

- 『Oracle Fusion Middleware Oracle Infrastructure Webサービス開発者ガイド』のWebサービスの信頼性のあるメッセージングの使用に関する項

- Web Services Reliable Messaging仕様: http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01-e1.html

WS-SecureConversation

Web Services Secure Conversation Language (WS-SecureConversation)は、WS-SecurityおよびWS-Policyモデル上に構築されており、サービス間のセキュアな通信機能を提供します。この仕様では、セキュア通信を可能にするための、セキュリティ・コンテキストの確立および共有メカニズムと、セキュリティ・コンテキストからのキーの導出メカニズムが定義されています。

詳細は、次を参照してください。

- WS-SecureConversation 1.4仕様: http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/ws-secureconversation.html

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。