セキュリティー属性の伝搬
セキュリティー属性の伝搬 により、WebSphere® Application Server は、セキュリティー属性 (認証済みサブジェクト内容およびセキュリティー・コンテキスト情報) を、構成内のサーバー間でトランスポートできます。WebSphere Application Server は、これらのセキュリティー属性を、静的属性を照会するエンタープライズ・ユーザー・レジストリーか、静的属性も動的属性も照会できるカスタム・ログイン・モジュールかのいずれかから取得します。現実にカスタムである動的セキュリティー属性には、 接続に使用される認証強度、元の呼び出し元の ID、元の呼び出し元の場所、 元の呼び出し元の IP アドレスなどがあります。
セキュリティー属性の伝搬は、Java™ シリアライゼーションを使用して、 サブジェクト内に格納されているすべてのオブジェクトに伝搬サービスを提供します。ただし、Java コードでこれらのオブジェクトをシリアライズおよびデシリアライズできる必要があります。Java プログラム言語では、Java コードでオブジェクトをシリアライズする方法の規則が指定されています。プラットフォームやバージョンが異なるソフトウェアを扱う際に問題が起きる場合もあるため、 WebSphere Application Server には、 カスタム・シリアライゼーション機能を使用可能にするトークン・フレームワークも用意されています。 トークン・フレームワークには、これ以外の利点も含まれていますが、 その中にはトークンの固有性を識別する機能もあります。 この固有性により、サブジェクトをキャッシュに入れる方法、 およびトークンの目的が判別されます。 トークン・フレームワークは、4 つのマーカー・トークン・インターフェースを定義します。これにより、WebSphere Application Server ランタイムがトークンを伝搬する方法を決定できます。
WebSphere Application Server バージョン 6.0 以降では、 Java Platform, Enterprise Edition (Java EE) アプリケーションに対してアクセス制御を実行するよう、 カスタム Java Authorization Contract for Container (JACC) プロバイダーを 構成できます。カスタム JACC プロバイダーは、アクセス制御の決定において、呼び出し側の JAAS サブジェクト内のカスタム・セキュリティー属性を探索できます。
要求の認証中に、この要求がイニシャル・ログイン または伝搬ログイン のいずれであるかが、ログイン・モジュールによって判別されます。 イニシャル・ログインは、ユーザー情報、特にユーザー ID とパスワードを認証するプロセスであり、 ユーザー・アクセス権を表すセキュア属性を検索するための、 リモート・ユーザー・レジストリーのアプリケーション・プログラミング・インターフェース (API) を呼び出します。伝搬ログインのプロセスでは、ユーザー情報、特に Lightweight Third Party Authentication (LTPA) トークンを検証した後、WebSphere Application Server に既知のカスタム・オブジェクトとトークン・フレームワーク・オブジェクトの両方で構成される一連のトークンをデシリアライズします。
- 許可トークン
- 許可トークンは、伝搬されるほとんどの許可関連セキュリティー属性を含んでいます。 デフォルトの許可トークンは、 Java Platform, Enterprise Edition (Java EE) 許可決定を行うために、 WebSphere Application Server 許可エンジンによって使用されます。サービス・プロバイダーは、適宜、トークン内の情報により、 カスタム許可トークン実装を使用して、 異なるトークン内のデータの分離、 カスタム・シリアライゼーションとデシリアライゼーションの実行、 およびカスタム許可決定の実行を行うことができます。 このトークン・タイプの使用と実装の方法についての詳細は、 デフォルトの伝搬トークンを使用したセキュリティー属性の伝搬およびセキュリティー属性伝搬のカスタム伝搬トークンの実装を参照してください。
- シングル・サインオン (SSO) トークン
- サブジェクトに追加されたカスタム SingleSignonToken トークンは、自動的に HTTP Cookie として応答に追加され、Web ブラウザーに戻された属性を格納しています。トークン・インターフェース getName メソッドは、getVersion メソッドとともに Cookie 名を定義します。
WebSphere Application Server は、LtpaToken 名およびバージョン 2 を使用してデフォルトの SingleSignonToken トークンを定義します。追加された Cookie 名は LtpaToken2 です。応答 Cookie には、機密情報や暗号化されていないデータを追加しないでください。
また、Cookie を使用するときは常に、 Secure Sockets Layer (SSL) プロトコルを使用して要求を保護することを推奨します。 SSO トークンを使用すると、Web ユーザーは、複数の WebSphere Application Server を介して Web リソースにアクセスする際に、 一度だけ認証を受ければよいことになります。カスタム SSO トークンは、カスタム処理をシングル・サインオン・シナリオに追加することによって、この機能を拡張します。 SSO トークンの詳細については、 Web ユーザー認証を最小化するためのシングル・サインオンの実装を参照してください。 このトークン・タイプの使用と実装の方法についての詳細は、 デフォルトのシングル・サインオン・トークンをデフォルトまたはカスタム・トークン・ファクトリーで使用したセキュリティー属性の伝搬およびセキュリティー属性伝搬のカスタム・シングル・サインオン・トークンの実装を参照してください。
- 伝搬トークン
- 伝搬トークンは、認証済みのユーザーに関連付けられませんので、
サブジェクト内には保管されません。
その代わりに、伝搬トークンはスレッド上に保管され、
どこに送信される場合でも呼び出しに従います。
要求が別のサーバーへアウトバウンドで送信される場合、
そのスレッド上の伝搬トークンがその要求とともに送信され、そのトークンがターゲット・サーバーによって実行されます。スレッド上に保管された属性は、
Java Platform, Enterprise Edition (Java EE) RunAs ユーザー・スイッチとは関係なく伝搬されます。
デフォルトの伝搬トークンは、 すべてのユーザー・スイッチおよびホスト・スイッチをモニターしてログに記録します。 ユーザーは、WSSecurityHelper アプリケーション・プログラミング・インターフェース (API) を使用して、 追加情報をデフォルトの伝搬トークンに追加できます。 伝搬トークンのカスタム実装を検索および設定するには、 WSSecurityPropagationHelper クラスを使用できます。 このトークン・タイプの使用と実装の方法についての詳細は、 デフォルトの伝搬トークンを使用したセキュリティー属性の伝搬およびセキュリティー属性伝搬のカスタム伝搬トークンの実装を参照してください。
- 認証トークン
- 認証トークンは、ダウンストリーム・サーバーへ流れ、
ユーザーの ID を格納しています。
このトークン・タイプは、
これまでのバージョンの Lightweight Third Party Authentication (LTPA) トークンと同じ機能を提供します。
このトークン・タイプは通常、WebSphere Application Server の内部目的のために予約されていますが、ユーザーはこのトークンをサブジェクトに追加することができます。このトークンは、トークン・インターフェースの getBytes メソッドを使用して伝搬されます。
カスタム認証トークンは、 それをサブジェクトに追加するサービス・プロバイダーの目的のためだけに使用されます。 WebSphere Application Server 認証に使用されるデフォルトの認証トークンが存在するため、WebSphere Application Server は、認証目的でカスタム認証トークンを使用することはありません。 サービス・プロバイダーは、このトークン・タイプを使用して、 カスタム・データによるトークンの使用法を識別し、カスタム認証決定を実行することができます。このトークン・タイプの使用と実装の方法についての詳細は、 デフォルトの認証トークンおよびセキュリティー属性伝搬のカスタム認証トークンの実装を参照してください。
- Kerberos 認証トークン
- Kerberos 認証トークンには、Kerberos プリンシパル名、GSSCredential および Kerberos 代行クレデンシャルなどの Kerberos クレデンシャルが含まれます。このトークンはダウンストリーム・サーバーに伝搬されます。このトークン・タイプは通常、WebSphere Application Server の内部目的のために予約されていますが、GSSCredential が含まれている場合には、ユーザーは getGSSCredential メソッドを使用して GSSCredential を抽出することができます。抽出後、サブジェクトに置いて、アプリケーションで使用することが可能です。 このトークンは、WebSphere Application Server に対して、SPNEGO Web 認証または Kerberos 認証を使用して認証を行う際に作成されます。
水平伝搬とダウンストリーム伝搬の関係
WebSphere Application Server では、Web 要求のシングル・サインオンを使用する水平伝搬、およびエンタープライズ Bean にアクセスするために Remote Method Invocation over the Internet Inter-ORB Protocol (RMI/IIOP) を使用するダウンストリーム伝搬の両方が使用可能です。
水平伝搬
水平伝搬では、 セキュリティー属性は、フロントエンド・サーバー間で伝搬されます。サブジェクトの内容および伝搬トークンであるシリアライズされたセキュリティー属性は、静的属性と動的属性の両方を含むことができます。 シングル・サインオン (SSO) トークンは、水平伝搬に必要な追加のシステム固有情報を保管します。 SSO トークンに含まれる情報は、 発信サーバーの場所、およびそのサーバーとの通信方法を受信サーバーに知らせます。 さらに、SSO トークンはシリアライズされた属性を検索する鍵も含んでいます。 水平伝搬を使用可能にするためには、シングル・サインオン・トークンおよび Web インバウンド・セキュリティー属性伝搬フィーチャーを構成する必要があります。 管理コンソールを使用して、これらのフィーチャーの両方を構成することができます。
フロントエンド・サーバーが 同じデータ複製サービス (DRS) の複製ドメインで構成されると、 シリアライズされた情報が、 アプリケーション・サーバーによって、 同じドメイン内のすべてのサーバーに自動的に伝搬されます。 図 1 では、アプリケーション 1 がサーバー 1 およびサーバー 2 にデプロイされ、 両方のサーバーが同じ DRS 複製ドメインのメンバーです。 要求がサーバー 1 のアプリケーション 1 から発信され、サーバー 2 のアプリケーション 1 にリダイレクトされると、 元のログイン属性は追加のリモート要求なしでサーバー 2 で検出されます。
- 発信サーバーからログイン情報を検索する機能を取得します。
- アプリケーション・サーバーがシリアライズされた情報からサブジェクトを再生成できるため、 リモート・ユーザー・レジストリー呼び出しを実行する必要がありません。 この機能を使用しない場合、アプリケーション・サーバーは 5 から 6 個の個別のリモート呼び出しを行います。

水平伝搬のパフォーマンスへの影響
DRS または JMX リモート呼び出しの パフォーマンスへの影響はご使用の環境に依存します。 DRS または JMX リモート呼び出しは、 元のログイン属性を取得するのに使用されます。 リモート・ユーザー・レジストリー呼び出しが、ほとんどのアプリケーション・パフォーマンス上の問題を起こしている場合は、水平伝搬がその呼び出しの多くを減らします。 ただし、これらのオブジェクトのデシリアライゼーションもパフォーマンスの低下の原因となっている可能性がありますが、 この低下はリモート・ユーザー・レジストリー呼び出しによるものよりは小さいことがあります。 水平伝搬を使用可能や使用不可にして、ご使用の環境をテストしてみることをお勧めします。 元のログイン属性を保存するために水平伝搬を使用する必要がある場合は、 DRS または JMX がご使用の環境に良いパフォーマンスを提供するかどうかをテストしてください。 通常、フェイルオーバーおよびパフォーマンス上の理由のために、DRS を構成することをお勧めします。 ただし、DRS は同じ複製ドメインのすべてのサーバーに対して (サーバーのアクセス状況に関する) 情報を伝搬するため、 あまりに多くのサーバーが同じ複製ドメインにある場合は、パフォーマンスが低下する可能性があります。 この場合、複製ドメインのサーバー数を減らすか、DRS 複製ドメインのサーバーを構成しないでください。 後者の場合は、必要に応じて、JMX リモート呼び出しが属性を検索し、全体的に早くなる可能性があります。
セキュリティー・キャッシュ (WSSecureMap)
図 1 で、セキュリティー・キャッシュ (WSSecureMap) は、 セキュリティー属性の伝搬のために使用される動的キャッシュです。WSSecureMap キャッシュは、 ユーザー・クレデンシャルを再作成するために使用されるセキュリティー属性を保管し、 ログインするユーザーの数に応じた大きさになります。WSSecureMap のデフォルト存続時間は LTPA トークンのタイムアウトと同じです。つまり、ユーザーがログアウトすると WSSecureMap キャッシュ項目は解放されます。この WSSecureMap 使用パターンが通常使用されます。
管理コンソールで WSSecureMap キャッシュのサイズを設定します。
を選択し、キャッシュがどのように使用されるかを制御するために、com.ibm.ws.security.WSSecureMapInitAtStartup および com.ibm.ws.security.WSSecureMapSizeを定義します。ダウンストリーム伝搬
ダウンストリーム伝搬 では、 サブジェクトは、Web フロントエンド・サーバーにおいて、 伝搬ログインまたはユーザー・レジストリー・ログインのいずれかで生成されます。 Remote Method Invocation (RMI) のアウトバウンド伝搬とインバウンド伝搬が両方とも使用可能になっている場合、WebSphere Application Server は、エンタープライズ Bean を呼び出すためのセキュリティー情報をダウンストリームに伝搬します。
セキュリティー属性の伝搬の利点
WebSphere Application Server のセキュリティー属性の伝搬機能には、以下の利点があります。
WebSphere Application Server による、 認証と許可のためのセキュリティー属性情報の使用を可能にします。 セキュリティー属性の伝搬は、 呼び出しに伴う個々のリモート・ホップでのユーザー・レジストリー呼び出しの必要性を除去することができます。 WebSphere Application Server の前のバージョンでは、 認証済みユーザーのユーザー名だけを伝搬し、その他のセキュリティー属性情報は無視していました。この属性情報は、リモート・ユーザー・レジストリー呼び出しを使用してダウンストリームで再生成する必要がありました。 この新機能の利点を際立たせるために、次の例を考えてみます。
これまでのリリースでは、WebSEAL などのリバース・プロキシー・サーバー (RPSS) を使用して、ユーザーの認証、グループ情報の収集、および他のセキュリティー属性の収集を行いました。 既に説明しているように、WebSphere Application Server は、 認証済みユーザーの ID を受け入れましたが、その他のセキュリティー属性情報を無視しました。 必要な WSCredential および WSPrincipal オブジェクトを格納している Java Authentication and Authorization Service (JAAS) サブジェクトを作成するため、 WebSphere Application Server は、 ユーザー・レジストリーに 5 回から 6 回の呼び出しを行いました。WSCredential オブジェクトは、 Java EE リソースを許可するために必要なさまざまなセキュリティー情報を格納しています。WSPrincipal オブジェクトは、サブジェクトのプリンシパルを表すレルム名とユーザーを格納しています。
Application Server の現行リリースでは、リバース・プロキシー・サーバーから得られた情報を WebSphere Application Server で使用して、ユーザー・レジストリーへの追加の呼び出しを行うことなく、他のサーバー・リソースへのダウンストリームに伝搬できます。セキュリティー属性情報を保持していると、 適切な許可およびトラスト・ベースの決定を行うことにより、 サーバー・リソースを適切に保護することができます。 Java EE RunAs 構成により起きるユーザー・スイッチは、 アプリケーション・サーバーが元の呼び出し元情報を失う原因とはなりません。この情報は、実行スレッド上にある PropagationToken に保管されます。
- サード・パーティー・プロバイダーによるカスタム・トークンへのプラグインを可能にします。 トークン・インターフェースには、getBytes メソッドが含まれており、 このメソッドは、トークン実装による、 カスタム・シリアライゼーション、暗号化方法、あるいはその両方の定義を可能にします。
- 異なるプロバイダーによって作成されたサブジェクト内に、 同一タイプの複数のトークンを保持する機能を提供します。 WebSphere Application Server は、同じ目的で複数のトークンを処理できます。例えば、サブジェクト内に複数の許可トークンを持ち、 それぞれのトークンが、 異なるプロバイダーによって生成されたまったく異なった許可属性を持つことができます。
- 各トークン・タイプごとに固有の ID を持つ機能を提供します。 この ID は、動的属性がユーザー・ログインのコンテキストを変更する可能性がある場合に備えて、単なるユーザー名よりもっと固有なサブジェクト ID を形成するために使用されます。 トークン・タイプには、getUniqueId() メソッドがあり、 このメソッドは、キャッシング目的の固有のストリングを戻すために使用されます。 例えば、ユーザーがシステムに記録した場所を示すロケーション ID を伝搬することが必要になる場合があります。 このロケーション ID は、リバース・プロキシー・サーバーまたは WEB_INBOUND ログイン構成のいずれかを使用して、最初のログインの際に生成し、シリアライゼーションの前にサブジェクトに追加できます。 他の属性もサブジェクトに追加して、固有の ID を使用することができます。 すべての固有 ID は、サブジェクト全体での固有性を考慮する必要があります。 WebSphere Application Server には、サブジェクト内に固有の情報を指定する機能があり、これが以降のユーザーによるサブジェクトへのアクセス方法に影響を与える場合があります。