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

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

ID マッピング

ID マッピングとは、セキュリティー・トークンをある形式から別の形式に変換すること、またはある領域の ID を別の領域の等価の ID に統合することです。

ID マッピングを示す図。

WebSphere® Message Broker は、ID マッピング (ID フェデレーションとも呼ばれる) およびトークンの発行と交換をサポートしています。 ID マッピングとは、ある領域の ID を別の領域の ID にマッピングするプロセスです。 例えば、eSellers 領域の User001 を eShipping 領域の eSellerUser01 にマップできます。 トークンの発行と交換には、トークンをあるトークン・タイプから別のトークン・タイプにマッピングすることが関係しています。 例えば、MQ を介してクライアントから着信したユーザー名とパスワードのトークンは、同等の SAML アサーションにマップされ、Web サービス呼び出しに伝搬される場合があります。 また、クライアント・アプリケーションからの SAML 1.1 アサーションを、更新済みバックエンド・サーバーの同等の SAML 2.0 アサーションに交換することもできます。

WS-Trust プロバイダーを使用するマッピング

WebSphere Message Broker セキュリティー・マネージャーは、IBM® Tivoli® Federated Identity Manager (TFIM) V6.2 などの、WS-Trust V1.3 に準拠したセキュリティー・トークン・サーバー (STS) によるマッピング操作をサポートします。 マッピングは、WS-Trust V1.3 STS で構成されたマッピング操作を含む関連付けられたセキュリティー・プロファイルのある、SecurityPEP ノードおよび入力ノードに対して実行されます。

WS-Trust V1.3 (TFIM V6.2) は、プロファイル内で認証および許可用にも選択できます。 ただし、複数のセキュリティー操作がセキュリティー・プロファイルに関連付けられている場合は、1 つの WS-Trust 要求だけが STS に発行されます。 そのため、STS は必要なすべての操作を実行するように構成される必要があります。 例えば、TFIM V 6.2 サーバーを指定した場合は、呼び出す TFIM モジュール・チェーンに、検証、許可、発行の適切なモジュールを組み込む必要があります。 各操作を別々の WS-Trust 呼び出しで実行する必要がある場合、それぞれが 1 つのセキュリティー操作 (認証、許可、またはマッピング) だけのために構成された異なるセキュリティー・プロファイルに関連付けられている、一連の SecurityPEP ノードを使用する必要があります。

セキュリティー・プロファイルが WS-Trust v1.3 STS とのマッピングだけを指定する場合、要求は Issue という要求タイプで送信されますが、複数のセキュリティー操作が混合されたセットは Validate という要求タイプを送信します。 マッピングが含まれるとき、STS はその応答で、それが元のトークンである場合でもトークンを戻す必要があります。 そのようにしないと、エラーが発生します。

WebSphere Message Broker の以前のバージョンとの互換性を提供するために、TFIM V6.1 に対するサポートも提供されています。

ブローカーでは、ID マッピングは入力ノードまたは SecurityPEP ノードで、認証の後、許可の前に実行されます。 ソース ID は、処理のために ID マッパーに渡されます。 マッピングと許可の両方が構成された場合、許可操作はソース・トークンではなくマップされた出力トークンを使用します。 つまり、許可はフェデレーテッド ID で実行されます。

マッピングは、ノードがセキュリティー・プロファイルで構成されているとしても、出力ノードでは実行されません。

WebSphere Message Broker は、構成されたセキュリティー・プロバイダーによってサポートされる任意のタイプのセキュリティー・トークン間でのマッピングをサポートします。 提供されるサポートについて詳しくは、IDを参照してください。

X.509 証明書からマッピングする場合、TFIM は証明書は検証できますが、元の送信側の ID は検証できません。 ただし必要であれば、この整合性検査は SOAPInput ノードにより実行できます。 詳しくは、WS-Security メカニズムを参照してください。

TFIM V6.2 をマッピングに使用する方法の詳細については、TFIM V6.2 および TAM を使用した認証、マッピング、許可を参照してください。

TFIM V6.1 の使用法については、TFIM V6.1 および TAM を使用した認証、マッピング、許可を参照してください。

ユーザー定義マッピング

メッセージ・フローの開発時には、ID 伝搬に使用されるカスタム・トークン・マッピングをインプリメントできます。 例えば、入力ノードの後で計算ノード (Compute ノード、JavaCompute ノード、PHPCompute ノードのいずれか) を使用すれば、カスタム・トークン・マッピングを実装できます。 計算ノードでは、プロパティー・フォルダーからソース ID 値を読み取り、その値を処理してから、その新しい ID 値をマッピング先の ID フィールドに書き込む操作を実行できます。 メッセージの中で ID が指定されていなくても、計算ノードを使用すれば、何らかの ID 資格情報をマッピング先の ID フィールドに挿入することが可能になります。 後続のノードでは、ソース ID フィールドの代わりにマッピング先の ID フィールドを使用します。 計算ノードを使用して、マッピング先の ID フィールドで新しい ID を作成する前は、入力ノードで構成されているあらゆるセキュリティー操作がソース ID に基づいて実行されます。 一方、計算ノードでマッピング先の新しい ID を作成した後であれば、SecurityPEP ノードを組み込めます。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

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

        
        最終更新:
        
        最終更新: 2015-02-28 17:47:53


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