ID マッピング は、2 つのサーバー間のユーザー ID の 1 対 1 のマッピングです。 これにより、ダウンストリーム・サーバーが適切な許可を決定できるようになります。 サーバーの統合が必要な場合、ID マッピングが必要となりますが、 ユーザー・レジストリーは、それぞれ異なり、システム間で共用されません。
ほとんどの場合、要求は、 同一のセキュリティー・ドメインの一部である 2 つのサーバー間でダウンストリームに流れます。 WebSphere Application Server の場合、同一セルのメンバーである 2 つのサーバーは、 同じセキュリティー・ドメインのメンバーでもあります。 同一セル内で、2 つのサーバーは、同一のユーザー・レジストリーを持ち、 トークン暗号化のために同一の Lightweight Third Party Authentication (LTPA) キーを備えています。 これら 2 つの共通点により、他のユーザー属性の中で、2 つのサーバー間に流れる LTPA トークンは、 暗号化解除および検証が可能であるだけではなく、トークン内のユーザー ID を、 許可エンジンによって認識される属性にマップすることもできます。
最も信頼性が高くて推奨される構成は、 同一セル内にある 2 つのサーバーの場合です。 しかし、同一のユーザー・レジストリーを使用できない複数のシステムの統合が必要になることがあります。 ユーザー・レジストリーが、2 つのサーバー間で異なる場合、 ターゲット・サーバーのセキュリティー・ドメインまたはレルムは、 送信サーバーのセキュリティー・ドメインと一致しません。
WebSphere Application Server により、要求をアウトバウンドへ送信する前か、 または既存のセキュリティー・クレデンシャルをターゲット・サーバーに流せるようにする前に、 マッピングを使用可能にできます。信任状は、ターゲット・レルムが信頼できる仕様でインバウンドにマップされます。
マッピングの代替案の 1 つは、ユーザー ID を実際にマッピングせずに、 トークンまたはパスワードのないユーザー ID をターゲット・サーバーに送信することです。 ユーザー ID の使用は、2 つのサーバー間の信頼に基づいています。 Common Secure Interoperability Version 2 (CSIv2) ID アサーションを使用します。使用可能な場合は、 元のクライアントが最初の認証を実行するために何を使用したかに基づき、 サーバーは X.509 証明書、プリンシパル名、または識別名 (DN) を送信するのみです。 CSIv2 ID アサーションの際に、WebSphere Application Server 間に信頼が確立されます。
ID アサーションが機能するには、 ユーザー ID がターゲット・ユーザー・レジストリー内に存在していなければなりません。 このプロセスは、 他の Java 2 Platform, Enterprise Edition (J2EE) バージョン 1.4 以降に準拠するアプリケーション ・サーバー間のインターオペラビリティーも可能にします。 送信サーバーとターゲット・サーバーの両方で ID アサーションが構成済みである場合は、 両方のサーバーが同一のセキュリティー・ドメイン内にある場合でも、 WebSphere Application Server は、常にこの方式の認証を使用します。CSIv2 ID アサーションの詳細については、 ダウンストリーム・サーバーに対する ID アサーション を参照してください。
インバウンド・サーバーのマッピング機能により、インバウンド・マッピングを行う必要がある場合は、 ユーザー ID にアクセスできるように、 両方のサーバーが同一の LTPA 鍵を備えていることを確認する必要があります。 通常、サーバー間のセキュア通信では、クライアント認証の目的で、 LTPA トークンがインバウンド JAAS ログイン構成の WSCredTokenCallback コールバックに送信されます。 LTPA トークンのオープンが有効である場合はこれを可能にし、 マッピングを実行できるようにユーザーの固有 ID へのアクセスを可能にする方法が用意されています。 詳しくは、インバウンド ID マッピングの構成 を参照してください。ID アサーションなどの他のケースでは、 インバウンド・ログイン構成の NameCallback コールバックの中にユーザー名を受信する場合もあります。 これにより、ID をマップすることができます。