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