WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

セキュリティーの有効な入力ノードを使用するメッセージ・フロー・セキュリティーの起動

セキュリティーの有効な入力ノードを構成することにより、メッセージ・フロー・セキュリティー・マネージャーを起動できます。

次の図は、メッセージ・フローの例を示して、メッセージ・フロー内でセキュリティーの有効な入力ノードが入力メッセージを受け取るときに生じる一連のイベントの概要を示しています。

メッセージ・フロー内のセキュリティーの有効な入力ノードにメッセージが到達したときに発生する一連のイベントを示す図。
以下のステップは、メッセージ・フロー内のセキュリティーの有効な入力ノードにメッセージが到達したときに起きる一連のイベントを説明しています。 番号は、前掲の図中の番号と対応しています。
  1. セキュリティーの有効な入力ノード (MQ、HTTP、SCA、または SOAP) にメッセージが着信するとき、ノードに関連付けられたセキュリティー・プロファイルの存在は、メッセージ・フロー・セキュリティーが構成されているかどうかを示します。 SOAP ノードは、ブローカーのセキュリティー・マネージャーを使用しないで、いくつかの WS-Security 機能を実装できます。 詳しくは、WS-Security のインプリメントを参照してください。 ブローカーのセキュリティー・マネージャーがプロファイルを読み取るために呼び出されます。プロファイルでは、メッセージの ID で実行される伝搬、認証、許可、およびマッピングの組み合わせが指定されます。 これにより、使用する外部セキュリティー・プロバイダー (ポリシー決定ポイントまたは PDP とも呼ばれる) も指定されます。

    mqsicreateconfigurableservice コマンドを使用するか、WebSphere® Message Broker Explorer にあるエディターを使用して、セキュリティー・プロファイルを作成できます。 次いでブローカー・アーカイブ・エディターを使用して、個別のノードまたはメッセージ・フロー全体に対してセキュリティー・プロファイルを構成します。 セキュリティー・プロファイルをメッセージ・フローに関連付ける場合、セキュリティー・プロファイルは、メッセージ・フロー内のセキュリティーの有効なすべての入出力ノード、および SecurityPEP ノードに適用されます。 ただし、個別のノードに関連付けられたセキュリティー・プロファイルが、メッセージ・フローに関連付けられたセキュリティー・プロファイルに優先します。 「デフォルト伝搬」という名前の事前定義されたセキュリティー・プロファイルが、ID の伝搬を設定するために提供されています。 ノードに明示的にセキュリティーを設定しない場合には、セキュリティー・プロファイルを「セキュリティーなし」に設定します。

  2. セキュリティー・プロファイルがノードまたはメッセージ・フローに関連付けられている場合、セキュリティーの有効な入力ノードは (ノードの「セキュリティー」プロパティー・ページの構成に基づいて) 入力メッセージから ID 情報を抽出し、「プロパティー」フォルダー内のソース ID エレメントを設定します。 セキュリティー・トークンを正常に抽出できない場合、セキュリティー例外が出されます。

    SOAPInput ノードで (基礎のトランスポート ID の代わりに) WS-Security ヘッダーの ID を使用することが必要な場合は、関連するトークン・プロファイルのための適切なポリシー・セットおよびバインディングも定義および指定する必要があります。 詳しくは、ポリシー・セットを参照してください。

    MQ、HTTP、または SCA 入力ノードでは、「セキュリティー」プロパティー・ページを使用して、ID の抽出を構成します。 このデフォルトは、Transport Default です。 例えば、HTTPInput ノードはユーザー名およびパスワードを HTTP BasicAuth ヘッダーから抽出します。 「セキュリティー」プロパティー・ページにより、ID トークンのタイプとその場所を明示的に構成して抽出を制御できます。 このソース ID 情報は、メッセージ・ヘッダー、メッセージ本体、またはその両方の中に入れることができます。

    各ノードでサポートされるトークンについて詳しくは、IDを参照してください。

  3. 認証がセキュリティー・プロファイル内で指定されている場合、セキュリティー・マネージャーは構成されたセキュリティー・プロバイダーを呼び出して、ID を認証します。 これに失敗すると、セキュリティー例外がノードに戻されます。 メッセージ・ブローカー によって認証用にサポートされるセキュリティー・プロバイダーは、LDAP、WS-Trust v1.3 準拠のセキュリティー・トークン・サーバー (TFIM V6.2 など)、および TFIM V6.1 です。

    認証の結果を格納するためのセキュリティー・キャッシュが用意されています。これにより、メッセージ・フローに届く後続の (同じ資格情報を持つ) メッセージは、キャッシュされた結果を使用して実行されます (キャッシュの有効期限が切れていない場合)。

  4. ID マッピングがセキュリティー・プロファイル内で指定されている場合、セキュリティー・マネージャーは構成されたセキュリティー・プロバイダーを呼び出して、ID を代替 ID にマップします。 これに失敗すると、セキュリティー例外がノードに戻されます。 そうでない場合、マップ済み ID 情報が「プロパティー」フォルダー内のマップ済み ID エレメントに設定されます。

    メッセージ・ブローカー によって ID マッピング用にサポートされるセキュリティー・プロバイダーは、WS-Trust V1.3 準拠のセキュリティー・トークン・サーバー (TFIM V6.2 など)、および TFIM V6.1 です。

    ID マッピングの結果を格納するためのセキュリティー・キャッシュが用意されています。

    代わりに、SecurityPEP ノードをメッセージ・フロー内の任意のポイントで使用して、セキュリティーの有効な入力ノードで認証された ID をマップすることもできます。 詳しくは、SecurityPEP ノードを使用するメッセージ・フロー・セキュリティーの起動を参照してください。

  5. 許可がセキュリティー・プロファイル内で指定されている場合、セキュリティー・マネージャーは構成されたセキュリティー・プロバイダーを呼び出して、ID (マップされたものまたはソース) がこのメッセージ・フローへのアクセス権を持つことを許可します。 これに失敗すると、セキュリティー例外がノードに戻されます。

    メッセージ・ブローカー によって許可用にサポートされるセキュリティー・プロバイダーは、LDAP、WS-Trust V1.3 準拠のセキュリティー・トークン・サーバー (TFIM V6.2 など)、および TFIM V6.1 です。

    許可の結果を格納するためのセキュリティー・キャッシュが用意されています。

    代わりに、SecurityPEP ノードをメッセージ・フロー内の任意のポイントで使用して、セキュリティーの有効な入力ノードで認証された ID を許可することもできます。 詳しくは、SecurityPEP ノードを使用するメッセージ・フロー・セキュリティーの起動を参照してください。

  6. すべてのセキュリティー処理が完了したとき、またはメッセージ・フロー・セキュリティー・マネージャーがセキュリティー例外を出したときに、制御は入力ノードに戻ります。

    セキュリティー例外は、セキュリティーの有効な入力ノードに戻されると、適切なトランスポート処理を実行してメッセージ・フロー・トランザクションを終了します。 例えば、HTTPInput ノードは HTTP ヘッダーを出力ターミナルに伝搬しないで、401 HTTP 応答コードと共に戻します。 SOAPInput ノードは SOAP 障害を戻して、セキュリティー例外を報告します。 あるいは、「セキュリティー例外を通常の例外として扱う」プロパティーが、セキュリティーの有効な入力ノードで設定されている場合は、セキュリティー例外がノードの Failure ターミナルに伝搬されます。 セキュリティーの有効な入力ノードがその Out ターミナルに伝搬するのは、関連付けられたセキュリティー・プロファイルで構成されたすべての操作が正常に完了した場合だけです。

  7. 「プロパティー」フォルダーと、そのソースおよびマップ済み ID 情報を含むメッセージは、メッセージ・フローに伝搬されます。
  8. メッセージ・フロー内の後続ノードでは、データベースなどのリソースへのアクセスで、ID が必要になる場合があります。 そのようなリソースへのアクセスに使用される ID はプロキシー ID であり、ブローカーの ID であるか、または mqsisetdbparms コマンドを使用して特定のリソースに対して構成される ID であるかのいずれかです。
  9. メッセージ・フローを開発するとき、アプリケーション処理 (例えば、ID ベースのルーティングまたは ID ベースの内容構築など) に「プロパティー」フォルダー内の ID フィールドを使用できます。 さらに、WS-Trust V1.3 が使用可能な STS (TFIM V6.2 など) または TFIM V6.1 からのマッピング呼び出しの代替方法として、ComputeJavaComputePHPComputeMapping ノードなどの計算ノードでマップ済み ID フィールドを設定できます。
  10. セキュリティーの有効な出力または要求ノード (MQOutputHTTPRequestSOAPRequest、または SOAPAsyncRequest) にメッセージが着信すると、ノードに関連付けられた (伝搬が使用可能な) セキュリティー・プロファイルは、メッセージを送信するときに現在の ID トークンを伝搬するように指示します。

    セキュリティー・プロファイルで伝搬が必要なことが指示される場合、マップ済み ID が使用されます。 マップ ID が設定されていない場合、またはそのトークン・タイプがノードによってサポートされない場合には、ソース ID が使用されます。 ID が設定されていない場合、またはマップ ID もソース ID もトークン・タイプがノードによってサポートされない場合には、セキュリティー例外がノードに戻されます。

    SOAP ノードでは、トークン・プロファイルをノードに関連付けるために、適切なポリシー・セットおよびバインディングも必要となります。

    セキュリティー・トークンを出力ノードで発行されたメッセージに組み込む場合、出力ノードがそのタイプのトークンを伝搬できないときには、計算ノードを (出力ノードの前に) 使用して、トークンをプロパティー・ツリーから関連するメッセージの場所に入れることができます。

    各ノードでサポートされるトークンについて詳しくは、ID およびセキュリティー・トークンの伝搬を参照してください。

  11. 送信時には、伝搬される ID が、該当するメッセージ・ヘッダー内に組み込まれます。
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:49:27


概念トピック概念トピック | バージョン 8.0.0.5 | bp28150_