| Oracle® Fusion Middleware Oracle Service Bus開発者ガイド 11gリリース1 (11.1.1.6.2) B61435-05 |
|
 前 |
 次 |
この章では、Oracle Service Bus (OSB)の様々なトランスポートに対して、トランスポート・レベルのセキュリティを構成する方法について説明します。
トランスポート・レベルのセキュリティは、サービス・コンシューマとプロキシ・サービス、ビジネス・サービス間の接続を確立する一環として、セキュリティ・チェックを適用します。Oracle Service Busが適用するセキュリティ・チェックのタイプは、プロキシ・サービスやビジネス・サービスが通信で使用するプロトコルによって異なります。プロトコルによっては、クライアントとエンドポイント間の通信を暗号化して、第三者による傍受を防止することもできます。
インバウンド・トランスポート・レベルのセキュリティは、クライアントとOracle Service Busプロキシ・サービス間の通信を保護します。アウトバウンドトランスポート・セキュリティは、Oracle Service Busプロキシ・サービスからアウトバウンド・リクエストを送信する3つすべてのテクニック(ルート・アクション、パブリッシュ・アクション、コールアウト・アクション)を保護します。
この章の内容は以下のとおりです。
49.9項「メッセージ・コンテキストでのトランスポート・レベルのセキュリティ要素」
|
注意: トランスポート・レベルのセキュリティは、接続自体のみを保護します。HTTPSやJMSプロトコルを使用して通信を暗号化する場合でも、Webサービス・クライアントとOracle Service Busプロキシ・サービスの間にルーターやメッセージ・キュー、別のプロキシ・サービスなどの仲介がある場合、仲介はプレーン・テキストでSOAPメッセージを取得します。仲介が2番目の受信者にメッセージを送信するとき、2番目の受信者は元の送信者が誰か知りません。意図しない仲介がSOAPまたはJMSメッセージを参照したり変更しないようにするには、トランスポート・レベルのセキュリティに加えてメッセージ・レベルのセキュリティを構成します。第52章「Webサービスのメッセージ・レベルでのセキュリティの構成」を参照してください。 |
HTTPSプロトコルは、通信を保護するためにSSLを使用します。SSLを使用して通信を暗号化し、メッセージの整合性を保証するとともに、強力なサーバーおよびクライアントの認証を要求することができます。HTTPSを使用する前に、Oracle WebLogic ServerでSSLを構成する必要があります。45.7項「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。
以下の項で、HTTPSプロトコルのトランスポート・レベルのセキュリティの構成について説明します。
HTTPSプロトコルを介して通信する各プロキシ・サービスやビジネス・サービスについて、次のレベルの認証のいずれかを要求するようにサービスを構成できます。
一方向SSL、認証なし
このレベルでは、暗号化された通信が可能ですが、クライアントに資格証明を要求しません。一方向のSSL接続を確立するには、クライアントが接続を開始して、Oracle Service Busがその証明書をクライアントに送信します。つまり、クライアントがOracle Service Busを認証します。
一方向SSL、BASIC認証
このレベルでは暗号化された通信が可能で、一方向SSL通信が確立された後にクライアントはユーザー名とパスワードを提供する必要があります。クライアントは、ユーザー名とパスワードをHTTPリクエスト・ヘッダー(SSLで暗号化されます)にエンコードして提供します。プロキシ・サービスは暗号化されたリクエストを受信すると、資格証明をドメインの認証プロバイダに引き渡し、認証プロバイダがクライアントの資格証明が作成されたユーザー・アカウントに一致するかどうかを判断します。
二方向SSL、CLIENT CERT認証
このレベルでは暗号化された通信が可能で、強力なクライアント認証(二方向SSL)が行われます。
二方向のSSL接続を確立するには、クライアントが接続を開始してOracle Service BusがそのX.509証明書をクライアントに送信します。続いて、クライアントは自身の証明書をOracle Service Busに送信し、Oracle Service Busがクライアントを認証します。
クライアントの証明書からユーザー名を取得するには、IDアサーション・プロバイダを構成し、そのプロバイダが証明書のフィールドを抽出してクライアントのID (X.509トークン)として使用します。通常は証明書のSubjectDistinguishedNameのCN(共通名)またはE(電子メール)です。X.509トークンを抽出したら、トークンはOracle Service Bus管理コンソールの「セキュリティ構成」モジュールのユーザー・アカウントと比較されます。
SSLおよびIDアサーション・プロバイダの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のセキュリティの基礎概念に関する項を参照してください。
トランスポート・レベルのカスタム資格証明
カスタム認証トークンを使用して、トランスポートレベルでクライアントのリクエストを認証できます。トランスポート・レベルのカスタム資格証明は、インバウンド・リクエストでのみサポートされています。カスタム・トークンは、HTTPヘッダーで指定します。サービス定義ウィザードのHTTPに固有な構成ページを使用すると、クライアントの認証を構成できます。カスタム認証の概念については、第54章「カスタム認証の構成」で説明しています。
プロキシ・サービスのインバウンド・トランスポート・レベルのセキュリティを構成する手順は、以下のとおりです。
使用するHTTPS認証レベルに応じて、SSLおよび認証プロバイダ、IDアサーション・プロバイダをサポートするWebLogicのセキュリティ・フレームワークを構成したことを確認してください。
クライアント認証をなしにする場合(匿名リクエスト)、「クライアント認証」を「なし」に設定します。
基本的な認証については、「クライアント認証」を「基本」に設定します。『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のユーザーの追加に関する項を参照してください。
SSLクライアント認証の場合、「クライアント認証」を「クライアント証明書」に設定し、WebLogic IDアサーション・プロバイダとWebLogic証明書パス・プロバイダを構成します。
カスタムの認証トークンの場合、「クライアント認証」を「カスタム認証」に設定します。カスタムの認証トークンは、HTTPSヘッダーで送信される、IDアサーション・プロバイダに以前に構成された任意のアクティブなトークンを使用できます。カスタム認証の概念については、第54章「カスタム認証の構成」で説明しています。
|
注意: 最初に、54.5項「カスタム・トークン用IDアサーション・プロバイダの構成」の説明に従って、Oracle WebLogic ServerのIDアサーション・プロバイダを構成、または作成して構成し、Oracle Service Bus管理コンソールの「セキュリティ構成」モジュールにアクセスを許可するクライアントのユーザー名とパスワードを追加してください。 |
プロキシ・サービスを作成するときは、「トランスポート構成」ページで、「HTTP」を選択します。
HTTPトランスポート構成ページで、「HTTPSが必要」オプションを選択します。
49.1.1項「HTTPSの認証レベル」の説明に従って、認証レベルを選択します。
4.3項「プロキシ・サービスの構成」の説明に従って、ディスパッチ・ポリシー、リクエストのエンコーディング、レスポンスのエンコーディングの選択を行います。
作成するサービスがWSDLベースで操作がある場合、「操作選択構成」ページで選択を行います。WS-I準拠を実行して(SOAP 1.1サービスのみ)、使用する選択アルゴリズムを選び、このプロキシ・サービスが呼び出す操作を決定します。このオプションは、WSDLに基づいて定義されたSOAPサービスまたはXMLサービスでのみ使用できます。
アウトバウンド・トランスポート・レベル・セキュリティでは、ビジネス・サービスとの接続を開くクライアントはプロキシ・サービスです。
アウトバウンド・トランスポート・レベル・セキュリティを構成する手順は、次のとおりです。
(開発やテスト環境とは対照的に)本番環境でトランスポート・レベルのセキュリティを構成する場合、「ホスト名検証」が有効になっているか確認します。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の「SSLの構成」のホスト名検証の使用に関する項を参照してください。
ビジネス・サービスを作成するときは、トランスポート構成ページで、「HTTP」を選択します。
認証レベルを選択します。
Oracle Service Busがクライアントを認証しないようにプロキシ・サービスを構成した場合、エンタープライズ・システムを構成し、一方向SSLの認証レベル(BASIC認証オプション)を選択することによりクライアントを認証してください。
URIにより、HTTPとHTTPSのどちらを使用するかが決まります。HTTPビジネス・サービスは、HTTPとHTTPSのURLを合わせることができます。ただし、認証方法がクライアント証明書の場合を除きます。この場合は、すべてのURLをHTTPSにする必要があります。
ビジネス・サービスがHTTPSとBASIC認証を使用する場合は、サービス・アカウントを作成して、ビジネス・サービスで要求するユーザー名とパスワードを指定します。
You can add a user name and password directly to the service account, or configure the service account to pass through the credentials that it received from its client's request, or you can map a client user name to an Oracle Service Bus user.Oracle Service Busがクライアントを認証しないようにプロキシ・サービスを構成した場合、資格証明をパススルーするサービス・アカウントを作成してください。
ビジネス・サービスでクライアント証明書認証を使用する場合、以下を実行します。
サービス・キー・プロバイダを作成して、プロキシ・サービスがビジネス・サービスのSSLクライアント認証に使用するキー・ペアを指定します。『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「サービス・キー・プロバイダ」を参照してください。
プロキシ・サービスを作成するか、既存のプロキシ・サービスを編集して、サービス・キー・プロバイダを指定します。2.3項「プロキシ・サービスの操作」を参照してください。
HTTPプロトコルは、クライアントとプロキシ・サービスまたはビジネス・サービス間の通信を暗号化 しません が、BASIC認証はサポートしています。BASIC認証では、ユーザー名とパスワードがリクエスト内で送信されます。また、HTTPはカスタム・トークン認証をサポートしています。
|
注意: パスワードがクリア・テキストで送信されるため、強力なネットワーク・セキュリティを構成していない限り、本番環境ではHTTPとBASIC認証を一緒に使用しないようお薦めします。かわりに、BASIC認証とHTTPSを併用してください。 |
以下の項で、HTTPプロトコルのトランスポート・レベルのセキュリティの構成について説明します。
プロキシ・サービスのインバウンド・トランスポート・レベルのセキュリティを構成する手順は、以下のとおりです。
プロキシ・サービスを作成するときは、「トランスポート構成」ページで、「HTTP」を選択します。「クライアント認証」オプションでは、「なし」、「基本」または「カスタム認証」を選択します。カスタム認証を選択すると、トークンを送信するHTTPヘッダーとトークンのタイプも指定する必要があります。
トランスポート・レベルのカスタム資格証明を構成する手順の説明は、2.3項「プロキシ・サービスの操作」にあります。カスタム認証の概念については、第54章「カスタム認証の構成」で説明しています。
カスタム認証のトークンには、任意のアクティブなトークン・タイプで、以前にIDアサーション・プロバイダ用に構成され、HTTPヘッダーで送信されたものを使用できます。
|
注意: カスタム認証を使用するには、54.5項「カスタム・トークン用IDアサーション・プロバイダの構成」の説明に従って、最初にOracle WebLogic Server IDアサーション・プロバイダを構成、あるいは作成してから構成する必要があります。 Oracle Service Busでクライアントを認証(基本またはカスタム認証)する場合、クライアントのユーザー・アカウントを作成する必要があります。47.3項「管理セキュリティの構成:主な手順」を参照してください。 |
プロキシ・サービスのデフォルトのトランスポート・レベルでのアクセス制御ポリシーを変更します。このポリシーにより、ユーザーやグループ、ロールがプロキシ・サービスにアクセスできる条件を指定します。『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトランスポート・レベルのアクセス・ポリシーの編集に関する項を参照してください。
アウトバウンド・トランスポート・レベル・セキュリティでは、ビジネス・サービスとの接続を開くクライアントはプロキシ・サービスです。
アウトバウンド・トランスポート・レベル・セキュリティを構成する手順は、次のとおりです。
ビジネス・サービスを作成するときは、「トランスポート構成」ページで、「HTTP」を選択します。HTTPトランスポート・ページで、「基本」を選択します。
2.2項「ビジネス・サービスの操作」を参照してください。
サービス・アカウントを作成して、ビジネス・サービスで要求するユーザー名とパスワードを指定します。2.1.15項「サービス・アカウント・リソースの作成」を参照してください。
ユーザー名とパスワードを直接サービス・アカウントに追加するか、クライアントのリクエストから受け取った資格証明をサービス・アカウントがパススルーするように構成するか、または、クライアント・ユーザー名をOracle Service Busユーザーにマップすることができます。Oracle Service Busがクライアントを認証しないようにプロキシ・サービスを構成した場合、資格証明をパススルーするサービス・アカウントを作成してください。
プロキシ・サービスを作成するか、既存のプロキシ・サービスを編集して、サービス・アカウントを指定します。
JMSのトランスポート・レベルのセキュリティは、JMSメッセージングに対してエンド・ツー・エンドのセキュリティを提供しませんが、以下は提供されます。
Oracle Service BusとJMSサーバー間でJMSメッセージを送受信するための、保護されたSSLチャネルを使用するオプション。
|
注意: JMSトランスポートでは、双方向SSLはサポートされません。 |
Oracle Service Busは、ローカルのJMSサーバーや外部のJMSサーバーと通信できます。JMSサーバーへの接続は、T3Sプロトコル(SSLを介したT3)によって保護されます。T3とT3Sは、Oracle独自のプロトコルです。
JMSサーバーとの接続を確立し、JNDIツリー内のJMS宛先をルックアップする際に、Oracle Service Busプロキシ・サービスが認証に使用するユーザー名とパスワードを指定する機能。
|
注意: JMS管理者は、Oracle WebLogic Server管理コンソールを使用して、WebLogic JMSサーバーおよびJNDIツリー内の宛先へのアクセスを制限するアクセス制御ポリシーを作成します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』と、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSシステム・リソースの構成方法に関する項を参照してください。 JMS管理者がJMS宛先のアクセス制御ポリシーを構成または変更する場合、Oracle WebLogic Serverが変更を認識するまで最高60秒かかります。 デフォルトでは、Oracle WebLogic Server JMSは60秒ごとに各JMS宛先のポリシーを確認します。この動作を変更するには、Oracle WebLogic Serverの起動コマンドを変更して、次のシステム・プロパティをOracle WebLogic Server JMSによるアクセス制御ポリシーの確認頻度(秒単位)に設定してください。 このプロパティの値を |
以下の項で、JMSトランスポート・レベルのセキュリティの構成について説明します。
インバウンドJMSトランスポート・レベル・セキュリティを構成する手順は、次のとおりです。
JMSプロキシ・サービスを作成または編集するときは、トランスポート構成ページの「詳細設定」の下で、「SSLを使用」チェック・ボックスを選択します。
Oracle Service Busは、T3Sプロトコルを使用するためにJMSプロキシ・サービスを構成します。
JMS管理者がJMS接続プールへのアクセスを制限するアクセス制御ポリシーを作成した場合、JMSサーバーへの接続時に認証するようプロキシ・サービスを構成してください。
サービス・アカウントを作成して、JMSサーバーで要求するユーザー名とパスワードを指定します。2.1.15項「サービス・アカウント・リソースの作成」を参照してください。
プロキシ・サービスのJMSサービス・アカウントは、JMSオブジェクトのアクセスだけでなく、JNDIのルックアップにも使用されます。
サービス・アカウントにユーザー名とパスワードを直接追加する必要があります。JMSは、クライアントのリクエストから受信した資格証明をパススルーしたり、クライアントのユーザー名をOracle Service Busユーザーにマッピングするサービス・アカウントを使用できません。
プロキシ・サービスを作成または編集する場合、JMSトランスポート・ページで、「JMSサービス・アカウント」の横にある「参照」ボタンをクリックします。前述の手順で作成したサービス・アカウントを選択します。
アウトバウンドJMSトランスポート・レベル・セキュリティを構成する手順は、次のとおりです。
JMSビジネス・サービスを作成または編集する場合、「トランスポート構成」ページの「詳細設定」の下で、「SSLを使用」チェック・ボックスを選択します。
Oracle Service Busは、T3Sプロトコルを使用するためにJMSビジネス・サービスを構成します。
JMS管理者がJMS接続プールへのアクセスを制限するアクセス制御ポリシーを作成した場合、JMSサーバーへの接続時に認証するようビジネス・サービスを構成してください。
サービス・アカウントを作成して、JMSサーバーで要求するユーザー名とパスワードを指定します。2.1.15項「サービス・アカウント・リソースの作成」を参照してください。
プロキシ・サービスのJMSサービス・アカウントは、JMSオブジェクトのアクセスだけでなく、JNDIのルックアップにも使用されます。
サービス・アカウントにユーザー名とパスワードを直接追加する必要があります。JMSは、クライアントのリクエストから受信した資格証明をパススルーしたり、クライアントのユーザー名をOracle Service Busユーザーにマッピングするサービス・アカウントを使用できません。
ビジネス・サービスを作成または編集する場合、JMSトランスポート・ページで、「JMSサービス・アカウント」の横にある「参照」ボタンをクリックします。前述の手順で作成したビジネス・アカウントを選択します。
メッセージを送信するときにOracle Service Busで認証されたサブジェクトを渡すには、「呼出し元のサブジェクトを渡す」チェック・ボックスを選択します。
26.5項「SFTPトランスポート」の説明にあるように、Oracle Service Busはインバウンドおよびアウトバウンドのトランスポート・レベル・セキュリティのSFTPトランスポートをサポートしています。SFTPトランスポートでは、Secure Shell (SSH)バージョン2を使用して、ファイルを転送します。
SFTP認証は双方向です。SFTPサーバーとSFTPクライアント(Oracle Service Busサービス)は、異なるメカニズムを用いて互いを認証します。
SFTPサーバーは、トランスポート構成ページで指定した認証方法(「ユーザー名パスワード」、「ホスト・ベース」、;「公開鍵」)を使用してSFTPクライアント(Oracle Service Busサービス)を認証します。
SFTPクライアント(Oracle Service Busサービス)は、known_hostsファイルを使用してSFTPサーバーを認証します。Oracle Service Busプロキシ・サービス(インバウンド・リクエスト)またはビジネス・サービス(アウトバウンド・リクエスト)システム上のknown_hostsファイルには、ホスト名とIPアドレス、プロキシ・サービスまたはビジネス・サービスが接続可能なリモートSFTPサーバーの公開鍵が必要です。SSHバージョン2は、この公開鍵を使用して接続を認証します。
SFTPクライアント(Oracle Service Busサービス)は、トランスポート構成ページで3つの認証方法のうちどれが選択されたかに関係なく、常にknown_hostsファイルを使用して、SFTPサーバーに接続するかどうかを決定します。つまり、どの場合でもSFTPサーバーは、このファイルにある情報を使用してOracle Service Busサービスにより認証されます。こうすることで、Oracle Service Busサービスが既知のサーバーに接続することを確認します。
たとえば、「ユーザー名パスワード」による認証の場合、SFTPクライアント(Oracle Service Busサービス)は、known_hostsファイルにあるSFTPサーバーの公開鍵に対してSFTPサーバーを認証します。SFTPサーバーは、サービス・アカウントのユーザー名とパスワードを用いて、クライアント(Oracle Service Busサービス)を認証します。
トランスポート構成ページでどの認証方法を選択しても、Oracle Service Busプロキシ・サービス(インバウンド・リクエスト)またはビジネス・サービス(アウトバウンド・リクエスト)システム上のknown_hostsファイルには、ホスト名とIPアドレス、プロキシ・サービスまたはビジネス・サービスが接続可能なリモートSFTPサーバーの公開が必要です。
Oracle Service Busサービスは、known_hostsファイルにある公開鍵/ホスト/IPの組合せを用いてSFTPサーバーを認証します。
|
注意: このSSH認証メカニズムは、一般的なOracle Service Busサービス・キー・プロバイダ/PKI資格証明マッパー・プロセスには属しません。 |
認証時にknown_hostsファイルの要件が満たされる必要があります。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。
known_hostsファイルの作成
known_hostsテキスト・ファイルを作成するには、任意のエディタを使用します。
known_hostsの形式は次のとおりです。
Hostname,IP algorithm public-key
Hostname、IP、public_keyは、SFTPサーバーを識別します。
RSA(ssh-rsaとしてのみ入力)およびDSA(ssh-dsaまたはssh-dssとしてのみ入力)でサポートされるアルゴリズム。
このファイルの公開鍵の形式は、「OpenSSH公開鍵形式」です。
例:
getafix,172.22.52.130 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtR+M3Z9HFxnKZTx66fZdnQqAHQcF1vQe1+EjJ/HWYtgAnqsn0hMJzqWMatb/u9yFwUpZBirjm3g2I9Qd8VocmeHwoGPhDGfQ5LQ/PPo3esE+CGwdnCOyRCktNHeuKxo4kiCCJ/bph5dRpghCQIvsQvRE3sks+XwQ7Wuswz8pv58=
行ごとに1つのエントリで、複数のエントリがサポートされています。
known_hostsファイルを次のディレクトリに移動します。
MW_HOME/user_projects/domains/osb_domain/osb/transports/sftp
/transports/sftpディレクトリは、自動的に作成されるわけではありません。ユーザーが作成する必要があります。
次の原則は、プロキシ・サービスとビジネス・サービスの両方のSFTP認証プロセスに適用されます。
接続: Oracle Service Busサービス(プロキシおよびビジネス)は、常にSFTPクライアントとして機能し、SFTPサーバーに接続します。
SFTPサーバーによる認証: 公開鍵とホスト・ベースの認証の場合、SFTPサーバーはOracle Service Busサービスの公開鍵を使用して接続を認証します。ユーザー名/パスワードの場合、SFTPサーバーはユーザー名とパスワードを使用して接続を認証します。
SFTPクライアントによる認証: Oracle Service Busサービスは、常にknown_hostsファイルにある公開鍵/ホスト/IPの組合せを用いてSFTPサーバーを認証します。
接続の確立: サーバー認証とクライアント認証の両方に成功した場合のみ、接続が確立されて転送の準備が完了します。
転送: プロキシ・サービスの場合は、ファイル(メッセージ)がダウンロードされ、ビジネス・サービスの場合はアップロードされます。
SFTPの認証プロセスは次のとおりです。
プロキシ・サービスへの一方向のインバウンド・ダウンロード
SFTPクライアントであるプロキシ・サービスは、SFTPサーバーに接続しようとします。
プロキシ・サービスは、トランスポート構成ページで選択された認証メカニズムによって、SFTPサーバーから認証されます。
ホスト・ベースと公開鍵による認証の場合、リモートSFTPサーバーはプロキシ・サービスのホスト名と公開鍵を使用してOracle Service Busシステムを認証します。ユーザー名/パスワードによる認証の場合、SFTPサーバーは、プロキシ・サービスから(サービス・アカウントを通じて)提供されたユーザー名とパスワードを使用して、Oracle Service Busシステムを認証します。
(Oracle Service Busプロキシ・サービス・システム上の)known_hostsファイルは、Oracle Service Busプロキシ・サービスが接続可能なリモートSFTPサーバーの情報を保持します。
具体的には、このファイルにはホスト名とIPアドレス、認められたリモート・サーバーの公開鍵が含まれます。
SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。
認証が問題なく行われた場合、プロキシ・サービスはリモートSFTPサーバーに接続されたSFTPクライアントになります。
SFTPサーバーから許可された場合、プロキシ・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリをポーリングし、リモート・ディレクトリにあるすべてのファイル(メッセージ)をダウンロードします。
プロキシ・サービスの構成によって、ポーリングするリモート・ディレクトリやポーリングの頻度、ダウンロードされるファイル(メッセージ)の処理が決まります。
ビジネス・サービスからの一方向のアウトバウンド・アップロード
ビジネス・サービス(SFTPクライアント)は、SFTPサーバーに接続しようとします。
ビジネス・サービスは、トランスポート構成ページで選択された認証メカニズムによって、SFTPサーバーから認証されます。
ホスト・ベースと公開鍵による認証の場合、SFTPサーバーはビジネス・サービスのホスト名と公開鍵を使用してOracle Service Busシステムを認証します。ユーザー名/パスワードによる認証の場合、SFTPサーバーは(サービス・アカウントからの)ユーザー名とパスワードを使用して、Oracle Service Busシステムを認証します。
(Oracle Service Busビジネス・サービス・システム上の)known_hostsファイルは、Oracle Service Busビジネス・サービスが接続可能なSFTPサーバーの情報を保持します。
具体的には、このファイルにはホスト名とIPアドレス、認められたサーバーの公開鍵が含まれます。
SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。
認証が問題なく行われた場合、ビジネス・サービスはリモートSFTPサーバーに接続されたSFTPクライアントになります。
SFTPサーバーで許可された場合、ビジネス・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリにファイルをアップロードします。
ビジネス・サービスの構成によって、ファイルをアップロードするリモート・ディレクトリやアップロードの再試行の頻度、アップロードされるファイル名に追加するファイルの接頭辞や接尾辞が決まります。
プロキシ・サービスのインバウンド・トランスポート・レベルのセキュリティを構成する手順は、以下のとおりです。
49.4.2項「known_hostsファイルの使用」の説明に従って、Oracle Service Busプロキシ・サービス・システム上にknown_hostsファイルを作成します。
known_hostsは、Oracle Service Busプロキシ・サービスが接続可能なリモートSFTPサーバーの情報を保持します。具体的には、このファイルにはホスト名とIPアドレス、認められたリモート・サーバーの公開鍵が含まれます。
SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。
プロキシ・サービスを作成するときは、「トランスポート構成」ページで、「SFTP」を選択します。
エンド・ポイントのURIをsftp://hostname:port/directory形式で指定します。
hostname は、SFTPサーバーのホスト名またはIPアドレスです。
portは、SFTPサーバーがリスニングしているポートです。SFTPのデフォルト・ポートは22です。
directoryは、ファイルのために定期的にポーリングされる場所です。このディレクトリはユーザーのホーム・ディレクトリに相対します。
SFTPトランスポート構成ページで、「ユーザー名パスワード」、「ホスト・ベース」または「公開鍵」のいずれかの認証を選択します。
ここでは、認証の選択肢の概要について説明しています。詳細な情報については、26.5項「SFTPトランスポート」を参照してください。
ユーザー名/パスワードによる認証では、静的なサービス・アカウントが(SFTPサーバー上のユーザー資格証明を使用して)、この認証方法に関連付けられるよう指定します。サービス・アカウントは、プロキシ・サービスでSFTPサーバーへの認証に使用されるユーザー名とパスワードを提供します。SFTPクライアントは、提供された資格証明を使用して認証されます。サポートされているのは、静的なサービス・アカウントのみです。
ホスト・ベースの認証では、識別された既知のホストからの接続のみが許可されるよう指定します。この認証方法では、ユーザー名とサービス・キー・プロバイダを要求します。
SFTPサーバーは、プロキシ・サービスの公開鍵を使用してプロキシ・サービスを認証します。
|
注意: Oracle Service Busプロキシ・サービスは、SFTPサーバーからの資格証明を認証するために、自身でサービス・キー・プロバイダを使用することはありません。 |
プロキシ・サービスの公開鍵は、サービス・キー・プロバイダによって参照されるキー・ペア内に存在します。サービス・キー・プロバイダを設定する際に、このキーを抽出する必要があります。次に、この公開鍵を使用するため、SFTPサーバーを構成します。
たとえば、Linux上のSFTPサーバーの場合は、以下を行う必要があります。
/etc/ssh/shosts.equivファイルを編集し、Oracle Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加します。
/etc/ssh/ssh_known_hostsファイルを編集し、Oracle Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加して、その後に空白と公開鍵を続けます。
ユーザー名は、SFTPサーバー上のどのディレクトリをポーリングするかを決定するために使用されます。
公開鍵では、この認証方法を使用するためにユーザー名とサービス・キー・プロバイダが要求されることを指定します。各ユーザーは固有の秘密鍵を持っています。
SFTPサーバーは、公開鍵を用いてプロキシ・サービスを認証します。
|
注意: Oracle Service Busプロキシ・サービスは、SFTPサーバーからの資格証明を認証するために、自身でサービス・キー・プロバイダを使用することはありません。 |
プロキシ・サービスの公開鍵は、サービス・キー・プロバイダによって参照されるキー・ペア内に存在します。サービス・キー・プロバイダを設定する際に、このキーを抽出する必要があります。次に、この公開鍵を使用するため、SFTPサーバーを構成します。
たとえば、Linux上のSFTPサーバーについて、任意のIDに関してあるシステムにアクセス権限を許可するには、そのシステム上の$HOME/.ssh/authorized_keysファイルに公開鍵を入れます。そのファイルにリストされたすべての鍵にアクセスが許可されます。
ユーザー名は、SFTPサーバー上のどのディレクトリをポーリングするかを決定するために使用されます。また、ユーザー名はSFTPサーバー上の公開鍵の場所を識別するときにも使用されます。
リモートSFTPサーバーから許可された場合、プロキシ・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリをポーリングし、リモート・ディレクトリにあるすべてのファイルをダウンロードします。
プロキシ・サービスの構成によって、ポーリングするリモート・ディレクトリやポーリングの頻度、ダウンロードされるファイル(メッセージ)の処理が決まります。
ポーリングするディレクトリは絶対パスです。
ビジネス・サービスのアウトバウンド・トランスポート・レベルのセキュリティを構成する手順は、以下のとおりです。
49.4.2項「known_hostsファイルの使用」の説明に従って、Oracle Service Busビジネス・サービス・システム上にknown_hostsファイルを作成します。
known_hostsは、Oracle Service Busビジネス・サービスが接続可能なリモートSFTPサーバーの情報を保持します。具体的には、このファイルにはホスト名とIPアドレス、認められたリモート・サーバーの公開鍵が含まれます。
SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。
ビジネス・サービスを作成するときは、「トランスポート構成」ページで、「SFTP」を選択します。
エンド・ポイントのURIをsftp://hostname:port/directory形式で指定します。
hostname は、SFTPサーバーのホスト名またはIPアドレスです。
portは、SFTPサーバーがリスニングしているポートです。SFTPのデフォルト・ポートは22です。
directoryは、ファイルがアップロードされる場所です。このディレクトリはユーザーのホーム・ディレクトリに相対します。
SFTPトランスポート構成ページで、「ユーザー名パスワード」、「ホスト・ベース」または「公開鍵」のいずれかの認証を選択します。
ここでは、認証の選択肢の概要について説明しています。詳細な情報については、26.5項「SFTPトランスポート」を参照してください。
ユーザー名/パスワードによる認証では、静的なサービス・アカウントが(SFTPサーバー上のユーザー資格証明を使用して)、この認証方法に関連付けられるよう指定します。サービス・アカウントは、ビジネス・サービスでSFTPサーバーへの認証に使用されるユーザー名とパスワードを提供します。SFTPクライアントは、提供された資格証明を使用して認証されます。サポートされているのは、静的なサービス・アカウントのみです。
ホスト・ベースの認証では、識別された既知のホストからの接続のみが許可されるよう指定します。この認証方法では、ユーザー名とサービス・キー・プロバイダを要求します。
SFTPサーバーは、ビジネス・サービスの公開鍵を使用してビジネス・サービスを認証します。
|
注意: Oracle Service Busビジネス・サービスは、SFTPサーバーからの資格証明を認証するために、自身でサービス・キー・プロバイダを使用することはありません。 |
ビジネス・サービスの公開鍵は、サービス・キー・プロバイダによって参照されるキー・ペア内に存在します。サービス・キー・プロバイダを設定する際に、このキーを抽出する必要があります。次に、この公開鍵を使用するため、SFTPサーバーを構成します。
たとえば、Linux上のSFTPサーバーの場合は、以下を行う必要があります。
/etc/ssh/shosts.equivファイルを編集し、Oracle Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加します。
/etc/ssh/ssh_known_hostsファイルを編集し、Oracle Service Busドメインを実行しているマシンのホスト名またはIPアドレスを追加して、その後に空白と公開鍵を続けます。
ユーザー名を使用して、SFTPサーバー上のアップロード用ディレクトリを決定します。
公開鍵では、この認証方法を使用するためにユーザー名とサービス・キー・プロバイダが要求されることを指定します。各ユーザーは固有の秘密鍵を持っています。
SFTPサーバーは、公開鍵を用いてビジネス・サービスを認証します。
|
注意: Oracle Service Busビジネス・サービスは、SFTPサーバーからの資格証明を認証するために、自身でサービス・キー・プロバイダを使用することはありません。 |
ビジネス・サービスの公開鍵は、サービス・キー・プロバイダによって参照されるキー・ペア内に存在します。サービス・キー・プロバイダを設定する際に、このキーを抽出する必要があります。次に、この公開鍵を使用するため、SFTPサーバーを構成します。
たとえば、Linux上のSFTPサーバーについて、任意のIDに関してあるシステムにアクセス権限を許可するには、そのシステム上の$HOME/.ssh/authorized_keysファイルに公開鍵を入れます。そのファイルにリストされたすべての鍵にアクセスが許可されます。
ユーザー名は、SFTPサーバー上のアップロード・ディレクトリの決定と、SFTPサーバー上の公開鍵の場所を識別するときに使用されます。
リモートSFTPサーバーで許可された場合、ビジネス・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリにファイルをアップロードします。
ビジネス・サービスの構成によって、ファイルをアップロードするリモート・ディレクトリやアップロードの再試行の頻度、アップロードされるファイル名に追加するファイルの接頭辞や接尾辞が決まります。
アップロード・ディレクトリは絶対パスで、自動的に作成されます。
以下のセキュリティ属性は、インポート時に45.6.1項「セキュリティおよびポリシーの構成を保持」チェック・ボックスが有効な場合に保持されます。
クライアント認証方式
サービス・アカウントへの参照(ユーザー名/パスワード認証の場合)
サービス・キー・プロバイダへの参照(ホスト・ベースおよび公開鍵による認証の場合)
ユーザー名(ホスト・ベースおよび公開鍵による認証の場合)
以下の項では、電子メール、FTP、ファイル・プロトコルを介した通信で使用可能なセキュリティ対策について説明します。
電子メールとFTPは、セキュアなプロトコルではありません。これらは通常、セキュアでないチャネルを通して、脆弱な認証をサポートします。電子メールやFTPトランスポートでサポートされているセキュリティ方法は、電子メールやFTPサーバーへの接続に必要とされるユーザー名およびパスワードです。
電子メールを保護するには、ユーザー名およびパスワードの別名としてサービス・アカウントを指定する必要があります。サービスでは、SMTPサーバーに対する認証にユーザー名とパスワードを使用します。
FTPトランスポートを保護するには、external_userを選択し、ユーザー名とパスワードの別名としてサービス・アカウントを指定します。サービスは、FTPサーバーに対する認証にユーザー名とパスワードを使用します。
電子メールとFTPトランスポートへのセキュリティの追加の詳細は、2.2項「ビジネス・サービスの操作」を参照してください。
ファイル・トランスポートでサポートされているセキュリティ方法は、ファイルがあるコンピュータに対するユーザー・ログインです。
49.4項「SFTPトランスポートのトランスポート・レベルでのセキュリティの構成」に説明されているSFTPトランスポートは、FTPを保護する推奨メカニズムです。
Service Bus (SB)トランスポートでは、クライアントのOracle Service BusサーバーがRMI経由でOracle Service Busプロキシ・サービスを同期的に呼び出せます。RMIは、クライアントのOracle Service BusサーバーがSBトランスポートにアクセスできる唯一のメカニズムです。Oracle Service Busのこのリリースでは、関連のAPIは社内ユーザー専用であり、文書化はされていません。
SBプロキシ・サービスには、次の2つの方法のどちらかによりアクセスします。
プロキシ・サービスのOracle Service Busサーバーに接続するためにSBビジネス・サービスを使用するクライアントOracle Service Busサーバーから、JNDIコンテキストとプロキシ・サービスのURIを使用して。
SBプロキシ・サービスにアクセスするために独自のアーティファクトを使用するOracle WebLogic IntegrationとOracle Data Service Integratorなどの製品を使用して。これらのアーティファクトは製品に対して一意であり、ここでは説明しません。
SBビジネス・サービスは、SBプロキシ・サービスにだけメッセージを送信できます。JNDIプロバイダ(ビジネス・サービスのエンドポイントURIで指定)を使用して、リモートOracle Service Busサーバー上でJNDIルックアップを行います。具体的にはJNDIプロバイダは、SBプロキシ・サービスに対応するRMIスタブを取得するためにサービスがデプロイされているOracle Service Busサーバーを参照します。
たとえば、ビジネス・サービスで指定するエンドポイントのURIは、sb://some_secured_jndi_provider/some_remote_sb_proxyとなります。
セキュアなJNDIプロバイダは、セキュア・プロトコルを使用したプロバイダURLを持っている必要があります。SBビジネス・サービスの場合は、HTTPSやt3sプロトコルを使用できます。
(ビジネス・サービスの)サービス・アカウントは、リモートSBプロキシ・サービスの呼出しに使用されるユーザー資格証明を指定します。サービス・アカウントが指定されない場合は、このビジネス・サービスのインバウンド・プロキシ・サービス(インバウンド・クライアント)のユーザー資格証明)が、セキュリティ・コンテキストの伝播に使用されます。
SBトランスポートは、SSLを使用して協力なサーバーとクライアントの認証を要求できます。SBトランスポートとともにSSLを使用する前に、Oracle WebLogic ServerでSSLを構成する必要があります。45.7項「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。
|
注意: 「SSLを使用」フラグが設定されていると、リクエストをSSL接続経由で送信する必要があります。ただし、SBトランスポートではセキュアでない接続は禁止されていません。プロキシ・サービスはセキュアなURI( Oracle Service Busサーバー管理者は、サーバー上のセキュアでないすべてのプロトコル(t3、httpなど)を閉じ、セキュアなクライアント接続を厳密に強制する必要があります。 |
SBトランスポートでSAMLベースの認証を使用する場合は、以下の構成要件に従ってください。
SBクライアント側で、SAML資格証明マッパー・プロバイダを構成し、このクライアントから呼び出す予定がある各SBプロキシ・サービスにSAMLの依存側を作成します。対象のURLフィールドに、http://openuri.org/<OSBProxyServiceURI>と入力します。OSBProxyServiceURIは、SBプロキシ・サービスのサービスURIです。
(SBプロキシ・サービスが存在する)Oracle Service Bus側では、SAML IDアサーション・プロバイダを構成して、SAMLのアサーション側を作成します。対象のURLフィールドには、SBプロキシ・サービスのサービスURIを入力します。SBプロトコルやホスト/ポートの情報は含めないでください。たとえば、/<OSBProxyServiceURI>のようになります。
Webサービスの信頼性のあるメッセージング(WS-RM)の機能が、WSとしてOracle Service Busで使用できます。Oracle Service Busは、2005年2月に提出された仕様をサポートしています。この仕様の詳細は、「Web Services Reliable Messagingプロトコル(WS-ReliableMessaging)」(http://schemas.xmlsoap.org/ws/2005/02/rm/)を参照してください。
WSトランスポートには、プロキシ・サービス(インバウンド)とビジネス・サービス(アウトバウンド)の両方のコンポーネントがあり、それらはSOAP1.1-およびSOAP1.2をベースとしたWSDLとWS-RMポリシーに基づいています。一方向とリクエスト/レスポンスのパターンをどちらもサポートしていますが、レスポンスは信頼性に欠けます。
『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』の「ebサービスの信頼性のあるメッセージングの概要」で説明されているとおり、WS-RMはあるアプリケーション・サーバーで実行中のアプリケーションが、別のアプリケーション・サーバーで実行中のWebサービスを安定して呼び出すことができるフレームワークです。この場合、どちらのサーバーもWS-ReliableMessaging仕様を実装していることが前提です。「安定した」とは、2つのWebサービス間でメッセージの配信を保証する能力として定義できます。特に、仕様では相互運用可能なプロトコルと記述され、あるソースのエンドポイント(またはクライアントのWebサービス)から宛先のエンドポイント(または安定して操作を呼び出せるWebサービス)に送信されたメッセージが、1つ以上の配信保証に従って配信されたことが保証されるか、あるいはエラーが発生するというものです。
WSプロキシ・サービスは、Oracle WebLogic Server管理コンソールで表示されますが、WLSからポリシーを割り当てようとしても無視されます。
具体的には、管理者はOracle WebLogic Server管理コンソールで「ホーム」→「セキュリティ・レルムのサマリー」→「myrealm」→「レルム・ロール」ページに移動して、WSプロキシ・サービスのセキュリティ・ポリシーを外見上は編集できます。
ただし、このポリシーには何の効果もなく、実行時に評価されません。
EARアプリケーションはセッションをアクティブ化すると自動的に生成され、Oracle Service Busによってデプロイされます。これは、それぞれのWSプロキシ・サービスに対して1つのEARファイルです。
WSトランスポート・セキュリティは、WS-Policyファイルを通してWSDLから、あるいはサービスにバインドされる形で構成します。
Oracle Service Busは、WS-Policyファイルを使用して、宛先のエンドポイントがそのWS-RM機能および要件を記述、公開できるようにします。WS-Policy仕様は、Webサービスのポリシーを記述および伝達するための一般目的のモデルと構文を提供します。
これらのWS-Policyファイルは、サポートされるWS-ReliableMessaging仕様のバージョン、ソース・エンドポイントの再送信の間隔、宛先エンドポイントの受信確認の間隔などの機能を記述するXMLファイルです。
RMアサーションとWSSPトランスポート・レベルのセキュリティ・アサーションを持つWS-Policyは、WSトランスポートのみでサポートされています。
Oracle Service Busには、独自のWS-Policyファイルを作成しない場合に指定できる、2つの単純なWS-RM WS-Policyファイルが用意されています。
DefaultReliability.xml - 信頼性のあるメッセージングのポリシーのアサーションに一般的な値(非アクティブ・タイムアウト10分、確認応答の間隔200ミリ秒、基本的な再送信間隔3秒など)を指定します。
LongRunningReliability.xml - デフォルトの信頼性のあるメッセージングWS-Policyファイルと似ていますが、アクティビティのタイムアウト間隔に、より大きな値(24時間)を指定します。
これらのあらかじめパッケージされたファイルは変更できません。値がニーズに合わない場合は、独自のWS-Policyファイルを作成する必要があります。
たとえば、例49-1は完全なLongRunningReliability.xmlファイル(weblogic.jarから抽出されたもの)を示します。
例49-1 LongRunningReliability.xmlファイル
<?xml version="1.0"?>
<wsp:Policy
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:beapolicy="http://www.bea.com/wsrm/policy"
>
<wsrm:RMAssertion >
<wsrm:InactivityTimeout
Milliseconds="86400000" />
<wsrm:BaseRetransmissionInterval
Milliseconds="3000" />
<wsrm:ExponentialBackoff />
<wsrm:AcknowledgementInterval
Milliseconds="200" />
<beapolicy:Expires Expires="P1M" optional="true"/>
</wsrm:RMAssertion>
</wsp:Policy>
WSトランスポートを使用するプロキシまたはビジネス・サービスは、サービスに直接バインドされているか、WSDLからのRMアサーションを含むWS-Policyを持っている必要があります。他のトランスポートを使用するサービスが、RMアサーションを含むWS-Policyを持つことはできません。
RMアサーションはサービス・レベルでのみバインドでき、操作やリクエスト/レスポンスのレベルではバインドできません。
WS-RMは一方向とリクエスト/レスポンスという2つのメッセージング・パターンをサポートしています。WSトランスポートは両方のパターンをサポートしていますが、信頼性の高いレスポンスはサポートしていません。つまり、レスポンスは安全に送信されませんが、リクエストは常に信頼できます。
RMクライアントへのWSトランスポートを使用したプロキシ・サービスからの非同期レスポンスは、RMクライアントによって指定されるAcksToまたはReplyToエンドポイント参照に接続します。RMクライアントは、HTTP URLまたはHTTPS URLを使用できます。RMクライアントがHTTPSを使用する場合、RMクライアントはSSLハンドシェイク中にクライアント証明書をリクエストできます。WSトランスポートでは、リクエスト時にサービス・キー・プロバイダのSSLのキー・ペアを使用します。
WSトランスポートは、WS-Policyファイルにより以下のHTTPSセキュリティ・モードをサポートしています。
HTTPS - クライアント認証なし
HTTPS (BASIC認証あり)
HTTPS(クライアント証明書認証あり - 二方向SSL)
表49-0は、これらのモードを実装するあらかじめ構成されたセキュリティ・ポリシーと、それらを使用する状況を示します。
表49-1 WSトランスポートの認証一覧
| HTTPSが必要 | 要求される認証 | あらかじめ構成されたトランスポート・セキュリティ・ポリシー |
|---|---|---|
|
はい |
なし |
Wssp1.2-Https.xml |
|
はい |
BASIC |
Wssp1.2-HttpsBasic.xml |
|
はい |
クライアント証明書 |
Wssp1.2-HttpsClientCert.xml |
WSプロキシ・サービスは、WS-PolicyのWSSP 1.2トランスポート・レベルのセキュリティ・アサーションで決められているとおり、基本とクライアント証明書(二方向SSL)による認証をどちらもサポートしています。
例49-2にある、パッケージされたWssp1.2-Https.xmlポリシーから抽出された、HTTPSトークンとBasic256アルゴリズムの例について考えてみてください。
WS-policyで基本認証が指定されている場合、すべてのHTTPSリクエスト・メッセージ(WSプロキシ・サービスへのRMプロトコル・メッセージを含む)は、有効なユーザー名とパスワードを持っている必要があります。
例49-2 Wssp1.2-Https.xmlファイル(抜粋)
:
<sp:TransportBinding>
<wsp:Policy >
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken />
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
</wsp:Policy>
</sp:TransportBinding>
</wsp:Policy>
プロキシ・サービス認証のサポートは次のように行われます。
プロキシ・サービス用に構成されたサービス・キー・プロバイダに割り当てられたSSLキー・ペアを使用したクライアント証明書のアウトバウンド認証。
サービス・キー・プロバイダ(アウトバウンド・リクエストで鍵と証明書のペアを渡します)の作成を計画している場合は、Oracle WebLogic Server管理コンソールを使用して、PKI資格証明マッピング・プロバイダを構成します。Oracle Service Busをホストする任意のOracle WebLogic Serverドメインで、最大1つのPKI資格証明マッピング・プロバイダを構成できます。
WSプロキシ・サービス(基本認証を使用する)による他の任意のアウトバウンド・トランスポート、またはアウトバウンドWSSユーザー名トークンに対するユーザー名/パスワードのIDの伝播。
ビジネス・サービスでユーザー名とパスワード・トークンを要求する場合は、元のクライアント・リクエストからユーザー資格証明をパススルーするようにビジネス・サービスのサービス・アカウントを構成します。2.1.15項「サービス・アカウント・リソースの作成」を参照してください。
WSプロキシ・サービス(基本認証または双方向SSL認証)と他の任意のトランスポートとの間の資格証明のマッピング。
WSプロキシ・サービスからRMクライアントへのHTTPまたはHTTPSによる非同期レスポンスの送信(信頼性なし)。プロキシ・サービスとビジネス・サービスで使用されるデフォルトのプロトコルはHTTPです。
WSプロキシ・サービスから、RMクライアントによって指定される AcksTo または ReplyTo エンドポイント参照に接続するRMクライアントへの非同期レスポンス。RMクライアントはHTTP URLまたはHTTPS URLのどちらかを使用できます。RMクライアントがHTTPSを使用する場合、RMクライアントはSSLハンドシェイク中にクライアント証明書をリクエストできます。WSトランスポートでは、リクエスト時にサービス・キー・プロバイダのSSLのキー・ペアを使用します。
Preserve Security and Policy Configurationフラグが設定されている場合、WSトランスポート・プロバイダは以下のセキュリティ構成を保持します。サービス・アカウントへの参照(WSビジネス・サービスのみ)
Oracle Service Busには、ネイティブのメッセージ・キュー(MQ)トランスポートのサポートが備わっています。これは、WebSphere MQとの間でメッセージを送受信できる機能です。この文脈において、MQトランスポートは、MQライブラリを使用してMQサーバーに接続するクライアントです。
MQ接続リソースを作成する際に、トランスポートのセキュリティ関連のプロパティを構成します。続いて、これらのプロパティは、MQプロキシ又はビジネス・サービスによって使用されます。
MQ接続リソースには、以下の2つのモードが備わっています。
バインド・モード - バインド・モードを使用して、Oracle Service Busと同じマシンにあるMQキュー・マネージャに接続します。このモードでは、サービスはネットワークを介して通信するのでなく、既存のキュー・マネージャAPIに直接コールします。このモードは、ローカルのキュー・マネージャに接続する早い方法です。
tcpモード - tcpモードは、MQキュー・マネージャがOracle Service Busと同じマシン上にない場合に使用します。
プロキシ・サービスのインバウンド・トランスポート・レベルのセキュリティを構成する手順は、以下のとおりです。
MQトランスポートを使用するプロキシ・サービスを作成する前に、使用するトランスポートにMQ接続リソースを作成してください。以下のセキュリティ構成設定から選択します。
SSLが必要。メッセージの送信にHTTPSを使用する場合は、このチェック・ボックスを選択します。「双方向SSLが必要」オプションが選択されていない場合に、サーバー側のSSL(サーバーがクライアントに対して認証)がサポートされます。
暗号スイート。このオプションは、「SSLが必要」チェック・ボックスが選択されている場合にのみ使用できます。SSLで使用される暗号スイート・アルゴリズムを選択します。
暗号スイートは、キー交換アルゴリズムや対称暗号化アルゴリズム、セキュア・ハッシュ・アルゴリズムを含むSSL暗号化方式です。暗号化スイートは、通信の整合性を保護するために使用されます。
暗号化スイート・アルゴリズムは、WebSphere MQサーバーとMQトランスポート間のメッセージの通信を暗号化および復号化するときに使用されます。
双方向SSLが必要。このオプションは、「SSLが必要」チェック・ボックスが選択されている場合にのみ使用できます。クライアント側とサーバー側のSSL認証の使用を強制するには、このチェック・ボックスを選択します。
サービス・キー・プロバイダへの参照。「双方向SSLが必要」を選択した場合、適切なクライアント側SSLのキー・マネージャを取得するために、サービス・キー・プロバイダへの参照を指定する必要があります。
サービス・キー・プロバイダのパス(プロジェクト/フォルダ)と名前を入力するか、「参照」をクリックして、「サービス・キー・プロバイダの選択」ページから選択します。
静的なサービス・アカウントへの参照。ユーザー名とパスワードによる認証に必要です。静的なサービス・アカウントのパス(プロジェクト/フォルダ)および名前を入力するか、「参照」をクリックしてサービス・アカウントを選択します。
プロキシ・サービスを作成するときは、「トランスポート構成」ページで、「mq」を選択します。
ビジネス・サービスのアウトバウンド・トランスポート・レベルのセキュリティを構成する手順は、以下のとおりです。
MQトランスポートを使用するプロキシ・サービスを作成する前に、使用するトランスポートにMQ接続リソースを作成してください。以下のセキュリティ構成設定から選択します。
SSLが必要。メッセージの送信にHTTPSを使用する場合は、このチェック・ボックスを選択します。「双方向SSLが必要」オプションが選択されていない場合に、サーバー側のSSL(サーバーがクライアントに対して認証)がサポートされます。
暗号スイート。このオプションは、「SSLが必要」チェック・ボックスが選択されている場合にのみ使用できます。SSLで使用される暗号スイート・アルゴリズムを選択します。
暗号スイートは、キー交換アルゴリズムや対称暗号化アルゴリズム、セキュア・ハッシュ・アルゴリズムを含むSSL暗号化方式です。暗号化スイートは、通信の整合性を保護するために使用されます。
暗号化スイート・アルゴリズムは、WebSphere MQサーバーとMQトランスポート間のメッセージの通信を暗号化および復号化するときに使用されます。
双方向SSLが必要。このオプションは、「SSLが必要」チェック・ボックスが選択されている場合にのみ使用できます。クライアント側とサーバー側のSSL認証の使用を強制するには、このチェック・ボックスを選択します。
サービス・キー・プロバイダへの参照。「双方向SSLが必要」を選択した場合、適切なクライアント側SSLのキー・マネージャを取得するために、サービス・キー・プロバイダへの参照を指定する必要があります。
サービス・キー・プロバイダのパス(プロジェクト/フォルダ)と名前を入力するか、「参照」をクリックして、「サービス・キー・プロバイダの選択」ページから選択します。
静的なサービス・アカウントへの参照。ユーザー名とパスワードによる認証に必要です。静的なサービス・アカウントのパス(プロジェクト/フォルダ)および名前を入力するか、「参照」をクリックしてサービス・アカウントを選択します。
ビジネス・サービスを作成するときは、「トランスポート構成」ページで、「mq」を選択します。
クライアントを認証するためにプロキシ・サービスを構成する場合、クライアントのIDおよびクライアントが属するセキュリティ・グループに、プロキシ・サービスのパイプラインからアクセスできます。IDとグループ情報は、以下の場所にあるメッセージ・コンテキストにあります。
$inbound/ctx:security/ctx:transportClient/ctx:username
および
$inbound/ctx:security/ctx:transportClient/ctx:principals/ctx:group
(メッセージ・コンテキストには、ユーザーが属する各グループごとに1つのctx:group要素が含まれます)
プロキシ・サービスがクライアントを認証しない場合、$inbound/ctx:security/ctx:transportClient/ctx:usernameの値は<anonymous>で、ctx:group要素はありません。
詳細については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のインバウンド変数とアウトバウンド変数に関する項、および2.4項「プロキシ・サービス・メッセージ・フローの操作」を参照してください。
