| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.1.3) E53004-06 |
|
 前 |
 次 |
この章では、Service Busの様々なトランスポートに対して、トランスポート・レベルのセキュリティを構成する方法について説明します。
トランスポート・レベルのセキュリティは、サービス・コンシューマとプロキシ・サービス、ビジネス・サービス間の接続を確立する一環として、セキュリティ・チェックを適用します。Service Busが適用するセキュリティ・チェックのタイプは、プロキシ・サービスやビジネス・サービスが通信で使用するプロトコルによって異なります。プロトコルによっては、クライアントとエンドポイント間の通信を暗号化して、第三者による傍受を防止することもできます。
インバウンド・トランスポート・レベルのセキュリティは、クライアントとService Busプロキシ・サービス間の通信を保護します。アウトバウンド・トランスポート・セキュリティは、Service Busプロキシ・サービスからアウトバウンド・リクエストを送信する3つすべてのテクニック(ルート・アクション、パブリッシュ・アクション、コールアウト・アクション)を保護します。
この章の内容は次のとおりです。
ビジネス・サービスおよびプロキシ・サービスでセキュリティを構成する手順については、「ビジネス・サービスとプロキシ・サービスの保護」を参照してください。
HTTPSプロトコルは、通信を保護するためにSSLを使用します。SSLを使用して通信を暗号化し、メッセージの整合性を保証するとともに、強力なサーバーおよびクライアントの認証を要求することができます。HTTPSを使用する前に、WebLogic ServerでSSLを構成する必要があります。「Oracle WebLogicセキュリティ・フレームワークの構成: 主な手順」を参照してください。
次の項で、HTTPSプロトコルのトランスポート・レベルのセキュリティの構成について説明します。
HTTPSプロトコルを介して通信する各プロキシ・サービスやビジネス・サービスについて、次のレベルの認証のいずれかを要求するようにサービスを構成できます。
一方向SSL、認証なし
このレベルでは、暗号化された通信が可能ですが、クライアントに資格証明を要求しません。一方向のSSL接続を確立するには、クライアントが接続を開始して、Service Busがその証明書をクライアントに送信します。つまり、クライアントがService Busを認証します。
一方向SSL、基本認証
このレベルでは暗号化された通信が可能で、一方向SSL通信が確立された後にクライアントはユーザー名とパスワードを提供する必要があります。クライアントは、ユーザー名とパスワードをHTTPリクエスト・ヘッダー(SSLで暗号化されます)にエンコードして提供します。プロキシ・サービスは暗号化されたリクエストを受信すると、資格証明をドメインの認証プロバイダに引き渡し、認証プロバイダがクライアントの資格証明が作成されたユーザー・アカウントに一致するかどうかを判断します。
双方向SSL、クライアント証明書認証
このレベルでは暗号化された通信が可能で、強力なクライアント認証(二方向SSL)が行われます。
双方向のSSL接続を確立するには、クライアントが接続を開始してService BusがそのX.509証明書をクライアントに送信します。続いて、クライアントは自身の証明書をService Busに送信し、Service Busがクライアントを認証します。
クライアントの証明書からユーザー名を取得するには、IDアサーション・プロバイダを構成し、そのプロバイダが証明書のフィールドを抽出してクライアントのID (X.509トークン)として使用します。通常は証明書のSubjectDistinguishedNameのCN(共通名)またはE(電子メール)です。X.509トークンを抽出した後、そのトークンをFusion Middleware Controlで作成されたユーザー・アカウントと比較します。
SSLおよびIDアサーション・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの理解』のセキュリティの基礎概念に関する項を参照してください。
トランスポート・レベルのカスタム資格証明。
カスタム認証トークンを使用して、トランスポート・レベルでクライアントのリクエストを認証できます。カスタム・トークンは、HTTPヘッダーで指定します。サービス定義ウィザードのHTTPに固有な構成ページを使用すると、クライアントの認証を構成できます。カスタム認証の概念については、「カスタム認証の構成」で説明しています。
アウトバウンド・トランスポート・レベル・セキュリティでは、ビジネス・サービスとの接続を開くクライアントはプロキシ・サービスです。
アウトバウンド・トランスポート・レベル・セキュリティを構成するには:
(開発やテスト環境とは対照的に)本番環境でトランスポート・レベルのセキュリティを構成する場合、「ホスト名検証」が有効になっているか確認します。『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項のホスト名の使用方法を参照してください。
ビジネス・サービスを作成するときは、トランスポート構成ページで、「HTTP」を選択します。
「HTTPSの認証レベル」の説明に従って、認証レベルを選択します。
Service Busがクライアントを認証しないようにプロキシ・サービスを構成した場合、エンタープライズ・システムを構成し、一方向SSLの認証レベル(基本認証オプション)を選択することによりクライアントを認証してください。
URIにより、HTTPとHTTPSのどちらを使用するかが決まります。HTTPビジネス・サービスは、HTTPとHTTPSのURLを組み合せることができます。ただし、認証方法がクライアント証明書の場合を除きます。この場合は、すべてのURLをHTTPSにする必要があります。
ビジネス・サービスが基本認証のHTTPSを使用する場合は、サービス・アカウントを作成して、ビジネス・サービスで要求するユーザー名とパスワードを指定します。
ユーザー名とパスワードを直接サービス・アカウントに追加するか、クライアントのリクエストから受け取った資格証明をサービス・アカウントがパススルーするように構成するか、またはクライアント・ユーザー名をService Busユーザーにマップできます。Service Busがクライアントを認証しないようにサービスを構成した場合は、資格証明をパススルーするサービス・アカウントを作成します。
ビジネス・サービスでクライアント証明書認証を使用する場合、次を実行します。
サービス・キー・プロバイダを作成して、プロキシ・サービスがビジネス・サービスのSSLクライアント認証に使用するキー・ペアを指定します。サービス・キー・プロバイダの詳細は、「サービス・キー・プロバイダの操作」を参照してください。
プロキシ・サービスを作成するか、既存のプロキシ・サービスを編集して、サービス・キー・プロバイダを指定します。
ビジネス・サービスでカスタム認証を使用する場合、認証のカスタムJavaクラスを指定します。
HTTPプロトコルは、クライアントとプロキシ・サービスまたはビジネス・サービス間の通信を暗号化しませんが、基本認証はサポートしています。基本認証では、クライアントがユーザー名とパスワードをリクエスト内で送信します。また、HTTPはカスタム・トークン認証をサポートしています。
警告:
パスワードがクリア・テキストで送信されるため、強力なネットワーク・セキュリティを構成していないかぎり、本番環境では基本認証とHTTPを一緒に使用しないようお薦めします。かわりに、基本認証とHTTPSを併用してください。
次の項で、HTTPプロトコルのトランスポート・レベルのセキュリティの構成について説明します。
アウトバウンド・トランスポート・レベル・セキュリティでは、ビジネス・サービスとの接続を開くクライアントはプロキシ・サービスです。
アウトバウンド・トランスポート・レベル・セキュリティを構成するには:
アウトバウンドでカスタム認証を使用するには、com.bea.wli.sb.transports.http.OutboundAuthenticationインタフェースのdoOutboundAuthenticationメソッドを実装する必要があります。Oracle Service Busice Busでは、OutboundAuthentication実装を呼び出す前に、HttpUrlConnectionFactoryを接続パラメータで初期化します。
カスタム認証コードでは、HttpURLConnectionの新しいインスタンスの取得にファクトリ・メソッドHttpUrlConnectionFactory.newConnection()を使用できます。ファクトリ・メソッドから返されるHttpURLConnectionインスタンスは、Service Busランタイムで設定されるパラメータで構成されます。
認証プロセスの最後の手順で、ビジネス・サービスのペイロードとユーザー・ヘッダーを、認証パラメータとともにターゲット・サービスに送信する必要があります。Service Busは、これを自動的に処理します。そのため、カスタム・オーセンティケータでは、カスタム認証コードで作成される最後のHttp接続インスタンスに認証パラメータのみが設定されていることを確認する必要があります。ターゲット・サービスへの接続を確立する次のHttpURLConnectionメソッドは、カスタム認証コードで作成されるHttpURLConnectionの最後のインスタンスに対して呼び出さないでください。
connect
getResponseCode
getResponseMessage
getHeaderメソッド
getContent
getInputStream
getOutputStream
JMSのトランスポート・レベルのセキュリティは、JMSメッセージングに対してエンド・ツー・エンドのセキュリティを提供しませんが、次のものは提供されます。
Service BusとJMSサーバー間でJMSメッセージを送受信するための、保護されたSSLチャネルを使用するオプション。
注意:
JMSトランスポートでは、双方向SSLはサポートされません。
Service Busは、ローカルのJMSサーバーや外部のJMSサーバーと通信できます。JMSサーバーへの接続は、T3Sプロトコル(SSLを介したT3)によって保護されます。T3とT3Sは、Oracle独自のプロトコルです。
JMSサーバーとの接続を確立し、JNDIツリー内のJMS宛先をルックアップする際に、Service Busプロキシ・サービスが認証に使用するユーザー名とパスワードを指定する機能。
注意:
JMS管理者は、Oracle WebLogic Server管理コンソールを使用して、WebLogic JMSサーバーおよびJNDIツリー内の宛先へのアクセスを制限するアクセス制御ポリシーを作成します。詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のポリシーで保護できるリソース・タイプに関する項と『Oracle WebLogic Server JMSリソースの管理』のJMSシステム・リソースを構成するためのメソッドに関する項を参照してください。
JMS管理者がJMS宛先のアクセス制御ポリシーを構成または変更する場合、WebLogic Serverが変更を認識するまで最大60秒かかります。
デフォルトでは、WebLogic Server JMSは60秒ごとに各JMS宛先のポリシーを確認します。この動作を変更するには、WebLogic Serverの起動コマンドを変更して、システム・プロパティweblogic.jms.securityCheckIntervalを、WebLogic Server JMSによるアクセス制御ポリシーの確認頻度(秒単位)に設定してください。
このプロパティの値を0(ゼロ)にすると、認可の確認がJMSリソースに対するsend、receive、getEnumerationアクションのたびに行われます。
次の項で、JMSトランスポート・レベルのセキュリティの構成について説明します。
インバウンドJMSトランスポート・レベル・セキュリティを構成するには:
JMSプロキシ・サービスを作成または編集するときは、トランスポート構成ページの「詳細設定」の下で、「SSLを使用」チェック・ボックスを選択します。
Service Busは、T3Sプロトコルを使用するためにJMSプロキシ・サービスを構成します。
JMS管理者がJMS接続プールへのアクセスを制限するアクセス制御ポリシーを作成した場合、JMSサーバーへの接続時に認証するようプロキシ・サービスを構成してください。
サービス・アカウントを作成して、JMSサーバーで要求するユーザー名とパスワードを指定します。「サービス・アカウントの操作」を参照してください。
プロキシ・サービスのJMSサービス・アカウントは、JMSオブジェクトのアクセスだけでなく、JNDIのルックアップにも使用されます。
サービス・アカウントにユーザー名とパスワードを直接追加する必要があります。JMSは、クライアントのリクエストから受信した資格証明をパススルーしたり、クライアントのユーザー名をService Busユーザーにマップしたりするサービス・アカウントを使用できません。
プロキシ・サービスを作成または編集する場合、JMSトランスポート・ページで、「JMSサービス・アカウント」の横にある「参照」ボタンをクリックします。前述の手順で作成したサービス・アカウントを選択します。
アウトバウンドJMSトランスポート・レベル・セキュリティを構成するには:
JMSビジネス・サービスを作成または編集する場合、「トランスポート構成」ページの「詳細設定」の下で、「SSLを使用」チェック・ボックスを選択します。
Service Busは、T3Sプロトコルを使用するためにJMSビジネス・サービスを構成します。
JMS管理者がJMS接続プールへのアクセスを制限するアクセス制御ポリシーを作成した場合、JMSサーバーへの接続時に認証するようビジネス・サービスを構成してください。
サービス・アカウントを作成して、JMSサーバーで要求するユーザー名とパスワードを指定します。「サービス・アカウントの操作」を参照してください。
プロキシ・サービスのJMSサービス・アカウントは、JMSオブジェクトのアクセスだけでなく、JNDIのルックアップにも使用されます。
サービス・アカウントにユーザー名とパスワードを直接追加する必要があります。JMSは、クライアントのリクエストから受信した資格証明をパススルーしたり、クライアントのユーザー名をService Busユーザーにマップしたりするサービス・アカウントを使用できません。
ビジネス・サービスを作成または編集する場合、JMSトランスポート・ページで、「JMSサービス・アカウント」の横にある「参照」ボタンをクリックします。前述の手順で作成したビジネス・アカウントを選択します。
メッセージを送信するときにService Busで認証されたサブジェクトを渡すには、「呼出し元のサブジェクトを渡す」チェック・ボックスを選択します。
「SFTPトランスポートの使用」の説明にあるように、Service Busはインバウンドおよびアウトバウンドのトランスポート・レベル・セキュリティのSFTPトランスポートをサポートしています。SFTPトランスポートでは、Secure Shell (SSH)バージョン2を使用して、ファイルを転送します。
SFTP認証は双方向で、SFTPサーバーとSFTPクライアント(Service Busサービス)は、異なるメカニズムを使用して互いを認証します。
SFTPサーバーは、「トランスポート構成」ページで指定した認証方法(「ユーザー名パスワード」、「ホスト・ベース」、;「公開鍵」)を使用してSFTPクライアント(Service Busサービス)を認証します。
SFTPクライアント(Service Busサービス)は、known_hostsファイルを使用してSFTPサーバーを認証します。Service Busプロキシ・サービス(インバウンド・リクエスト)またはビジネス・サービス(アウトバウンド・リクエスト)システム上のknown_hostsファイルには、ホスト名とIPアドレス、プロキシ・サービスまたはビジネス・サービスが接続可能なリモートSFTPサーバーの公開鍵が必要です。SSHバージョン2は、この公開鍵を使用して接続を認証します。
SFTPクライアント(Service Busサービス)は、「トランスポート構成」ページで3つの認証方法のうちどれが選択されたかに関係なく、常にknown_hostsファイルを使用して、SFTPサーバーに接続するかどうかを決定します。つまり、どの場合でもSFTPサーバーは、このファイルにある情報を使用してService Busサービスにより認証されます。こうすることで、Service Busサービスが既知のサーバーに接続することを確認します。
たとえば、「ユーザー名パスワード」による認証の場合、SFTPクライアント(Service Busサービス)は、known_hostsファイルにあるSFTPサーバーの公開鍵に対してSFTPサーバーを認証します。SFTPサーバーは、サービス・アカウントのユーザー名とパスワードを使用して、クライアント(Service Busサービス)を認証します。
「トランスポート構成」ページでどの認証方法を選択しても、Service Busプロキシ・サービス(インバウンド・リクエスト)またはビジネス・サービス(アウトバウンド・リクエスト)システム上のknown_hostsファイルには、ホスト名とIPアドレス、プロキシ・サービスまたはビジネス・サービスが接続可能なリモートSFTPサーバーの公開鍵が必要です。
Service Busサービスは、known_hostsファイルにある公開鍵/ホスト/IPの組合せを使用してSFTPサーバーを認証します。
注意:
このSSH認証メカニズムは、一般的な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認証プロセスに適用されます。
接続: Service Busサービス(プロキシおよびビジネス)は、常にSFTPクライアントとして機能し、SFTPサーバーに接続します。
SFTPサーバーによる認証: 公開鍵とホスト・ベースの認証の場合、SFTPサーバーはService Busサービスの公開鍵を使用して接続を認証します。ユーザー名/パスワードの場合、SFTPサーバーはユーザー名とパスワードを使用して接続を認証します。
SFTPクライアントによる認証: Service Busサービスは、常にknown_hostsファイルにある公開鍵/ホスト/IPの組合せを使用してSFTPサーバーを認証します。
接続の確立: サーバー認証とクライアント認証の両方に成功した場合のみ、接続が確立されて転送の準備が完了します。
転送: プロキシ・サービスの場合は、ファイル(メッセージ)がダウンロードされ、ビジネス・サービスの場合はアップロードされます。
プロキシ・サービスのSFTP認証プロセスは、「プロキシ・サービスへの一方向のインバウンド・ダウンロード」で説明しています。ビジネス・サービスのSFTP認証プロセスは、「ビジネス・サービスからの一方向のアウトバウンド・アップロード」で説明しています。
プロキシ・サービスへの一方向のインバウンド・ダウンロードは、次のように説明されています。
SFTPクライアントであるプロキシ・サービスは、SFTPサーバーに接続しようとします。
プロキシ・サービスは、「トランスポート構成」ページで選択された認証メカニズムを使用して、SFTPサーバーから認証されます。
ホスト・ベースと公開鍵による認証の場合、リモートSFTPサーバーはプロキシ・サービスのホスト名と公開鍵を使用してService Busシステムを認証します。ユーザー名/パスワードによる認証の場合、SFTPサーバーは、プロキシ・サービスから(サービス・アカウントを使用して)提供されたユーザー名とパスワードを使用して、Service Busシステムを認証します。
(Service Busプロキシ・サービス・システム上の)known_hostsファイルは、Service Busプロキシ・サービスが接続可能なリモートSFTPサーバーの情報を保持します。
具体的には、このファイルにはホスト名とIPアドレス、認められたリモート・サーバーの公開鍵が含まれます。
SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。
認証が問題なく行われた場合、プロキシ・サービスはリモートSFTPサーバーに接続されたSFTPクライアントになります。
SFTPサーバーから許可された場合、プロキシ・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリをポーリングし、リモート・ディレクトリにあるすべてのファイル(メッセージ)をダウンロードします。
プロキシ・サービスの構成によって、ポーリングするリモート・ディレクトリやポーリングの頻度、ダウンロードされるファイル(メッセージ)の処理が決まります。
ビジネス・サービスからの一方向のアウトバウンド・アップロードは、次のように説明されています。
ビジネス・サービス(SFTPクライアント)は、SFTPサーバーに接続しようとします。
ビジネス・サービスは、「トランスポート構成」ページで選択された認証メカニズムを使用して、SFTPサーバーから認証されます。
ホスト・ベースと公開鍵による認証の場合、SFTPサーバーはビジネス・サービスのホスト名と公開鍵を使用してService Busシステムを認証します。ユーザー名/パスワードによる認証の場合、SFTPサーバーは(サービス・アカウントからの)ユーザー名とパスワードを使用して、Service Busシステムを認証します。
(Service Busビジネス・サービス・システム上の)known_hostsファイルは、Service Busビジネス・サービスが接続可能なSFTPサーバーの情報を保持します。
具体的には、このファイルにはホスト名とIPアドレス、認められたサーバーの公開鍵が含まれます。
SSHバージョン2は、この公開鍵を使用して接続を認証します。known_hostsファイルにリストされていないSFTPサーバーは、認証されません。
認証が問題なく行われた場合、ビジネス・サービスはリモートSFTPサーバーに接続されたSFTPクライアントになります。
SFTPサーバーで許可された場合、ビジネス・サービス(SFTPクライアント)は、SFTPサーバー上のリモート・ディレクトリにファイルをアップロードします。
ビジネス・サービスの構成によって、ファイルをアップロードするリモート・ディレクトリやアップロードの再試行の頻度、アップロードされるファイル名に追加するファイルの接頭辞や接尾辞が決まります。
次のセキュリティ属性は、インポート時に「セキュリティおよびポリシーの構成を保持」オプションが選択された場合に保持されます。
クライアント認証方式
サービス・アカウントへの参照(ユーザー名/パスワード認証の場合)
サービス・キー・プロバイダへの参照(ホスト・ベースおよび公開鍵による認証の場合)
ユーザー名(ホスト・ベースおよび公開鍵による認証の場合)
次の項では、電子メール、FTP、ファイル・プロトコルを介した通信で使用可能なセキュリティ対策について説明します。
電子メールとFTPは、セキュアなプロトコルではありません。これらは通常、セキュアでないチャネルを通して、脆弱な認証をサポートします。電子メールやFTPトランスポートでサポートされているセキュリティ方法は、電子メールやFTPサーバーへの接続に必要とされるユーザー名およびパスワードです。
電子メールを保護するには、ユーザー名およびパスワードの別名としてサービス・アカウントを指定する必要があります。サービスでは、SMTPサーバーに対する認証にユーザー名とパスワードを使用します。
FTPトランスポートを保護するには、external_userを選択し、ユーザー名とパスワードの別名としてサービス・アカウントを指定します。サービスでは、FTPサーバーに対する認証にユーザー名とパスワードを使用します。
電子メールおよびFTPトランスポートにセキュリティを追加する方法の詳細は、「ビジネス・サービスの作成と構成」を参照してください。
ファイル・トランスポートでサポートされているセキュリティ方法は、ファイルがあるコンピュータに対するユーザー・ログインです。
「SFTPトランスポートのトランスポート・レベルでのセキュリティの構成」に説明されているSFTPトランスポートは、FTPを保護する推奨メカニズムです。
Service Bus (SB)トランスポートでは、クライアントのService BusサーバーがRMIを使用してService Busプロキシ・サービスを同期的に呼び出せます。RMIは、クライアントのService BusサーバーがSBトランスポートにアクセスできる唯一のメカニズムです。Service Busのこのリリースでは、関連のAPIは社内使用専用であり、文書化はされていません。
SBプロキシ・サービスには、次の2つの方法のどちらかによりアクセスします。
プロキシ・サービスのService Busサーバーに接続するためにSBビジネス・サービスを使用するクライアントService Busサーバーから、JNDIコンテキストとプロキシ・サービスのURIを使用して。
SBプロキシ・サービスにアクセスするために独自のアーティファクトを使用するOracle WebLogic IntegrationとOracle Data Service Integratorなどの製品を使用して。これらのアーティファクトは製品に対して一意であり、ここでは説明しません。
SBビジネス・サービスは、SBプロキシ・サービスにだけメッセージを送信できます。JNDIプロバイダ(ビジネス・サービスのエンドポイントURIで指定)を使用して、リモートService Busサーバー上でJNDIルックアップを行います。具体的にはJNDIプロバイダは、SBプロキシ・サービスに対応するRMIスタブを取得するためにサービスがデプロイされているService Busサーバーを参照します。
たとえば、ビジネス・サービスで指定するエンドポイントのURIは、sb://some_secured_jndi_provider/some_remote_sb_proxyとなります。
セキュアなJNDIプロバイダは、セキュア・プロトコルを使用したプロバイダURLを持っている必要があります。SBビジネス・サービスの場合は、HTTPSやt3sプロトコルを使用できます。
(ビジネス・サービスの)サービス・アカウントは、リモートSBプロキシ・サービスの呼出しに使用されるユーザー資格証明を指定します。サービス・アカウントが指定されない場合は、このビジネス・サービスのインバウンド・プロキシ・サービス(インバウンド・クライアント)のユーザー資格証明が、セキュリティ・コンテキストの伝播に使用されます。
SBトランスポートは、SSLを使用して協力なサーバーとクライアントの認証を要求できます。SBトランスポートとともにSSLを使用する前に、WebLogic ServerでSSLを構成する必要があります。「Oracle WebLogicセキュリティ・フレームワークの構成:主な手順」を参照してください。
警告:
「SSLを使用」フラグが設定されていると、リクエストをSSL接続経由で送信する必要があります。ただし、SBトランスポートではセキュアでない接続は禁止されていません。プロキシ・サービスはセキュアなURI (sbsとあるもの)を使用して(有効なWSDLファイルまたはUDDI経由で)通知されますが、セキュアなアクセスは強制されません。
Service Busサーバー管理者は、サーバー上のセキュアでないすべてのプロトコル(t3、httpなど)を閉じ、セキュアなクライアント接続を厳密に強制する必要があります。
SBトランスポートでSAMLベースの認証を使用する場合は、次の構成要件に従ってください。
SBクライアント側で、SAML資格証明マッパー・プロバイダを構成し、このクライアントから呼び出す予定がある各SBプロキシ・サービスにSAMLの依存側を作成します。対象のURLフィールドに、http://openuri.org/<OSBProxyServiceURI>と入力します。OSBProxyServiceURIは、SBプロキシ・サービスのサービスURIです。
(SBプロキシ・サービスが存在する) Service Bus側では、SAML IDアサーション・プロバイダを構成して、SAMLのアサーション側を作成します。対象のURLフィールドには、SBプロキシ・サービスのサービスURIを入力します。SBプロトコルやホスト/ポートの情報は含めないでください。たとえば、/<OSBProxyServiceURI>です。
Webサービスの信頼性のあるメッセージング(WS-RM)の機能が、WSトランスポートとしてService Busで使用できます。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 WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミングのWebサービスの信頼性のあるメッセージングの概要に関する項で説明されているとおり、WS-RMはあるアプリケーション・サーバーで実行中のアプリケーションが、別のアプリケーション・サーバーで実行中のWebサービスを安定して呼び出すことができるフレームワークです。この場合、どちらのサーバーもWS-ReliableMessaging仕様を実装していることが前提です。「安定した」とは、2つのWebサービス間でメッセージの配信を保証する能力として定義できます。特に、仕様では相互運用可能なプロトコルと記述され、あるソースのエンドポイント(またはクライアントのWebサービス)から宛先のエンドポイント(または安定して操作を呼び出せるWebサービス)に送信されたメッセージが、1つ以上の配信保証に従って配信されたことが保証されるか、あるいはエラーが発生するというものです。
WSプロキシ・サービスは、Oracle WebLogic Server管理コンソールで表示されますが、WLSからポリシーを割り当てようとしても無視されます。
具体的には、管理者はOracle WebLogic Server管理コンソールで「ホーム」→「セキュリティ・レルムのサマリー」→「myrealm」→「レルム・ロール」ページに移動して、WSプロキシ・サービスのセキュリティ・ポリシーを外見上は編集できます。
ただし、このポリシーには何の効果もなく、実行時に評価されません。
EARアプリケーションはセッションをアクティブ化すると自動的に生成され、Service Busによってデプロイされます。これは、それぞれのWSプロキシ・サービスに対して1つのEARファイルです。
WSトランスポート・セキュリティは、WSDLファイルから、あるいはサービスに直接バインドされる形でWS-Policyファイルを通して構成します。
Service Busは、WS-Policyファイルを使用して、宛先のエンドポイントがそのWS-RM機能および要件を記述、通知できるようにします。WS-Policy仕様は、Webサービスのポリシーを記述および伝達するための一般目的のモデルと構文を提供します。
これらのWS-Policyファイルは、サポートされるWS-ReliableMessaging仕様のバージョン、ソース・エンドポイントの再送信の間隔、宛先エンドポイントの受信確認の間隔などの機能を記述するXMLファイルです。
RMアサーションとWSSPトランスポート・レベルのセキュリティ・アサーションを持つWS-Policyは、WSトランスポートのみでサポートされています。
Service Busには、独自のWS-Policyファイルを作成しない場合に指定できる、2つの単純なWS-RM WS-Policyファイルが用意されています。
DefaultReliability.xml - 信頼性のあるメッセージングのポリシーのアサーションに一般的な値(非アクティブ・タイムアウト10分、確認応答の間隔200ミリ秒、基本的な再送信間隔3秒など)を指定します。
LongRunningReliability.xml - デフォルトの信頼性のあるメッセージングWS-Policyファイルと似ていますが、アクティビティのタイムアウト間隔に、より大きな値(24時間)を指定します。
これらのあらかじめパッケージ化されたファイルを変更することはできません。値がニーズに合わない場合は、独自のWS-Policyファイルを作成する必要があります。
たとえば、次の例は完全なLongRunningReliability.xmlファイル(weblogic.jarから抽出されたもの)を示します。
例 - 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
クライアント証明書(双方向SSL)のHTTPS
表51-1は、これらのモードを実装するあらかじめ構成されたセキュリティ・ポリシーと、それらを使用する状況を示します。
表51-1 WSトランスポートの認証一覧
| HTTPSが必要 | 必要とされる認証 | あらかじめ構成されたトランスポート・セキュリティ・ポリシー |
|---|---|---|
はい |
なし |
Wssp1.2-Https.xml |
はい |
基本 |
Wssp1.2-HttpsBasic.xml |
はい |
クライアント証明書 |
Wssp1.2-HttpsClientCert.xml |
WSプロキシ・サービスは、WS-PolicyのWSSP 1.2トランスポート・レベルのセキュリティ・アサーションで決められているとおり、基本とクライアント証明書(双方向SSL)による認証のどちらもサポートしています。
次の例にある、パッケージされたWssp1.2-Https.xmlポリシーから抽出された、HTTPSトークンとBasic256アルゴリズムの例について考えてみてください。
WS-policyで基本認証が指定されている場合、すべてのHTTPSリクエスト(WSプロキシ・サービスへのRMプロトコル・メッセージを含む)は、有効なユーザー名とパスワードを持っている必要があります。
例 - 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資格証明マッピング・プロバイダを構成します。Service Busをホストする任意のWebLogic Serverドメインで、最大1つのPKI資格証明マッピング・プロバイダを構成できます。
WSプロキシ・サービス(基本認証を使用する)による他の任意のアウトバウンド・トランスポート、またはアウトバウンドWSSユーザー名トークンに対するユーザー名/パスワードのIDの伝播。
ビジネス・サービスでユーザー名とパスワード・トークンを要求する場合は、元のクライアント・リクエストからユーザー資格証明をパススルーするようにビジネス・サービスのサービス・アカウントを構成します。「サービス・アカウントの操作」を参照してください。
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ビジネス・サービスのみ)
Service Busには、ネイティブのメッセージ・キュー(MQ)トランスポートのサポートが備わっています。これは、WebSphere MQとの間でメッセージを送受信できる機能です。この文脈において、MQトランスポートは、MQライブラリを使用してMQサーバーに接続するクライアントです。
MQ接続リソースを作成する際に、トランスポートのセキュリティ関連のプロパティを構成します。続いて、これらのプロパティは、MQプロキシ又はビジネス・サービスによって使用されます。
注意:
「環境へのMQクライアント・ライブラリの追加方法」の説明に従って、環境にMQクライアント・ライブラリを追加してください。
MQ接続リソースには、次の2つのモードが備わっています。
バインド・モード - バインド・モードを使用して、Service Busと同じマシンにあるMQキュー・マネージャに接続します。このモードでは、サービスはネットワークを介して通信するのでなく、既存のキュー・マネージャAPIに直接コールします。このモードは、ローカルのキュー・マネージャに接続する早い方法です。
tcpモード - tcpモードは、MQキュー・マネージャがService Busと同じマシン上にない場合に使用します。
クライアントを認証するためにプロキシ・サービスを構成する場合、クライアントの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要素はありません。
詳細は、「inbound変数とoutbound変数」を参照してください。
