| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.1.3) E53004-06 |
|
 前 |
 次 |
この章では、Service Busセキュリティに関してよく聞かれる質問に対する回答を提供します。
この章の内容は次のとおりです。
Service BusではWebLogicセキュリティ・フレームワークを利用しています。このフレームワークの詳細は、『Oracle WebLogic Serverセキュリティの理解』の「WebLogicセキュリティ・サービスのアーキテクチャ」にあるWebLogicセキュリティ・フレームワークに関する項を参照してください。Service Busでセキュリティを構成する前に、「Oracle WebLogicセキュリティ・フレームワークの構成: 主な手順」の説明に従って、WebLogic Serverセキュリティ・レルムやその他のサーバーの構成(SSLなど)をWebLogic Serverで行う必要があります。
トランスポート・レベルのセキュリティは、メッセージのトランスポートに使用する接続を保護する転送プロトコルを指します。トランスポート・レベルのセキュリティの例として、HTTPS (HTTP over SSL)があります。SSLのセキュリティはポイント・ツー・ポイントですが、メッセージの経路に仲介者がいるとメッセージが保護されません。詳細は、「トランスポート・レベルのセキュリティの構成」を参照してください。
Webサービス・セキュリティ(WS-Security)はOASIS標準の1つです。SOAPメッセージにメッセージ・レベルのセキュリティを組み込むための相互運用可能なメカニズムを定義しています。WS-Securityは、メッセージの整合性と機密性をサポートします。また、SOAPエンベロープにセキュリティ・トークンを含める拡張モデルや、SOAPエンベロープ内からセキュリティ・トークンを参照するモデルも定義しています。WS-Securityトークン・プロファイルは、コアのWS-Security仕様内での特定のトークン・タイプの使用方法を指定します。メッセージの整合性はXMLデジタル署名を使用することで確保され、メッセージの機密性はXML暗号化を使用することで確保されます。WS-Securityでは、SOAPメッセージのどの部分をデジタル署名または暗号化するかを指定できます。Service Busは、HTTP (HTTPSを含む)およびJMSによってWS-Securityをサポートします。
注意:
Oracle Web Services Manager (OWSM)は、Oracle Service Busで使用されるWebサービス・セキュリティ・メカニズムです。ビジネス・サービスやプロキシ・サービスなどの新規作成されたすべてのリソースでは、セキュリティにOWSMポリシーを使用します。WLS 9ポリシーは非推奨になったため、新しいService Busリソースのセキュリティの構成には使用できません。
ただし、WLS 9ポリシーですでに構成されたリソースをService Busプロジェクトにインポートできます。これらのWLS 9ポリシーの編集または変更はできませんが、OWSMポリシーに置き換えることができます。
Webサービス・ポリシー・フレームワーク(WS-Policy)は、Webサービスのポリシーを記述して通信するための汎用モデルとその構文を提供します。WS-Policyは、様々なサービスの要件、プリファレンスおよび機能を記述するために他のWebサービス仕様で使用および拡張できる一連の基本構成要素を定義しています。WLS9 Webサービスのポリシーの詳細は、「Webサービス・セキュリティとは何ですか。」の「注意」を参照してください。詳細は、「WS-PolicyによるOracle Service Busプロキシ・サービスとビジネス・サービスの保護」を参照してください。
Web Services Policy Assertions Language (WS-PolicyAssertions)は、セキュリティ・ポリシー内で指定できる一連の共通メッセージ・ポリシー・アサーションを指定しています。この仕様は、WS-Policyで使用する一般的なメッセージング関連のアサーションを定義しています。個別の仕様で、セキュリティ・アサーションと信頼性の高いメッセージング・アサーションについて、ドメイン固有のアサーションの構文とセマンティクスを記述します。WLS9 Webサービスのポリシーの詳細は、「Webサービス・セキュリティとは何ですか。」の「注意」を参照してください。
いいえ。アクセス制御ポリシーは、特定のリソース(プロキシ・サービス、Webアプリケーション、EJBなど)へのアクセスのリクエストの承認および拒否を決定するために評価されるブール式です。通常、アクセス制御ポリシーはリクエスト側のロールに基づいています。WS-Policyは、サービス定義(WSDL)を補完する、Webサービスについてのメタデータです。WS-Policyは、「すべてのリクエストはクライアントのデジタル署名が必要である」などの、すべてのサービス・クライアントが満たすべき要件を表すために使用できます。
WS-Securityパススルーのシナリオで、クライアントは、WS-Securityをリクエスト・メッセージやレスポンス・メッセージに適用します。プロキシ・サービスは、セキュリティ・ヘッダーを処理しません。そのかわりに、セキュアなリクエスト・メッセージをそのままビジネス・サービスに渡します。Service Busは、メッセージにWS-Securityを適用しませんが、ヘッダーの値に基づいてメッセージをルーティングできます。ビジネス・サービスは、メッセージを受け取った後にセキュリティ・ヘッダーを処理し、リクエストに応答します。ビジネス・サービスには、WS-Policyセキュリティ文が構成されている必要があります。保護されたレスポンス・メッセージがそのままクライアントに渡されます。たとえば、クライアントはメッセージを暗号化して署名し、そのメッセージをプロキシ・サービスに送信します。プロキシ・サービスはメッセージの復号化、またはデジタル署名の確認を行いません。単にメッセージをビジネス・サービスにルーティングします。ビジネス・サービスはメッセージを復号化してデジタル署名を確認してから、リクエストを処理します。レスポンス・パスは同様です。これは、受動型中間プロキシと呼ばれることがあります。
アクティブな仲介シナリオでは、クライアントがリクエスト・メッセージとレスポンス・メッセージにWS-Securityを適用します。プロキシ・サービスが、セキュリティ・ヘッダーを処理してWS-Securityポリシーを適用します。たとえば、クライアントがメッセージを暗号化および署名してプロキシ・サービスに送信し、プロキシ・サービスがメッセージを復号化してデジタル署名を検証してから、メッセージをルーティングします。プロキシ・サービスは、レスポンスをクライアントに返す前に、メッセージに署名して暗号化します。クライアントはメッセージを復号化し、プロキシのデジタル署名を確認します。
アウトバウンドWS-Securityは、Service Busプロキシ・サービスとビジネス・サービスの間のセキュリティを表します。ビジネス・アプリケーションとプロキシ・サービスの間のリクエストとレスポンスの両方が含まれます。詳細は、「メッセージ・レベルのセキュリティについて」を参照してください。
SAML (Security Assertion Markup Language)は、OASIS標準ベースの拡張可能なXMLフレームワークです。認証および認可情報を交換することによって、最新のネットワーク環境でのシングル・サインオンを可能にします。
デフォルトでは、アウトバウンドSAMLトークン内のサブジェクトIDは、インバウンド・ユーザー名と同じです。サブジェクトIDの形式は、カスタムのSAML名前マッパー・プロバイダを記述することでカスタマイズできます。詳細は、『Oracle WebLogic Serverセキュリティの管理』のSAML資格証明マッピング・プロバイダの構成に関する項を参照してください。
証明書検索および検証(CLV)プロバイダは、証明書のパスを完成させてX509証明書チェーンを検証します。CLVプロバイダには次の2つのタイプがあります。
証明書パス・ビルダー - Webサービスまたはアプリケーション・コードから、証明書、証明書チェーンまたは証明書への参照(チェーン内の目的の証明書、または証明書のサブジェクトDN)を受け取ります。このプロバイダが、チェーン内の証明書を検索および検証します。
証明書パス検証プロバイダ - SSLプロトコル、Webサービスまたはアプリケーション・コードから証明書チェーンを受け取り、失効チェックなど追加の検証を実行します。
証明書パス・ビルダーと証明書パス検証プロバイダは、セキュリティ・レルムに少なくとも1つずつ構成する必要があります。1つのセキュリティ・レルムに、複数の証明書パス検証プロバイダを構成することもできます。複数のプロバイダを構成した場合は、すべての証明書パス検証プロバイダの検証が正常に終了しないと、証明書または証明書チェーンは有効になりません。WebLogic Serverでは、CLVプロバイダの機能をWebLogic証明書パス・プロバイダと証明書レジストリで提供します。詳細は、『Oracle WebLogic Serverセキュリティの理解』にある「WebLogicセキュリティ・サービスのアーキテクチャ」の証明書検索および検証に関する項を参照してください。
はい。Service Busは、IDの伝播で2つのタイプの方法をサポートしています。
Webサービス・セキュリティに準拠してSAMLアサーションを生成することにより、これを行います。
これは、プロキシがルーティングするビジネス・サービスでSAML holder-of-keyまたはsender-vouchesのWS-Policyを設定することで実行されます。
ビジネス・サービスでユーザー名とパスワード・トークンを要求する場合は、元のクライアント・リクエストからユーザー資格証明をパススルーするようにビジネス・サービスのサービス・アカウントを構成します。「サービス・アカウントの操作」を参照してください。
厳密に言えば、Service Busメッセージング・シナリオでは、シングル・サインオン(SSO)は様々な理由で使用できません。まず、Service Busはステートレスであるため、セッションの概念や複数のパーティ間での会話がありません。次に、Service Busのクライアントは、通常は他のエンタープライズ・ソフトウェア・アプリケーションであり、Webブラウザを使用するユーザーではありません。そのため、このようなクライアントがリクエストごとにユーザー名とパスワードなどの資格証明を送信する必要があっても、通信がSSLやWS-Securityなどの方法で保護されるかぎり、許容されます。ただし、Oracle Service BusコンソールとWebLogic Server管理コンソールの間のSSOはサポートされています。詳細については、『Oracle WebLogic Serverセキュリティの理解』の「セキュリティの基礎概念」にあるシングル・サインオンに関する項を参照してください。
WS-Securityエラーのみが、Service Busモニター・フレームワークによってモニターされます。SSLハンドシェイク・エラー、トランスポート・レベルの認証、トランスポート・レベルのアクセス制御などのトランスポート・レベルのセキュリティ・エラーはモニターされません。ただし、監査プロバイダを構成して、トランスポート・レベルの認証と認可を監査することができます。詳細は、『Oracle Service Busの管理』のセキュリティ・ポリシーのモニタリングと管理に関する項を参照してください。
