LDAP にあるユーザー固有情報 (たとえば、電話番号、E メール・アドレスなど) を、認証済み要求の HTTP ヘッダーに付加すると便利な場合が多くあります。これ によって、LDAP サーバーを何度も照会する必要がなくなり、付加された情報に複 数のアプリケーションがアクセスすることができます。この情報は、比較的静的 で、その情報を使用するアプリケーションによって更新されない、という特徴があ ります。このデータは、ivauthn 認証プロセスの一部として、ユーザー信任状に置 かれます。この情報は、ユーザーによってインプリメントされた CDAS 認証モジュ ールを介してユーザー信任状に付加することもできます。
以下のプロセス・フローで、イベントの順序を説明します。
v ユーザーの LDAP レジストリー・アカウントのフィールドにあるユーザー定義の 補助データが、拡張属性データとして、ユーザーの Tivoli Access Manager 信任 状に追加される。
v プラグインが、タグ値を使用する許可後処理用に構成されている場合、LDAP 拡 張属性データを抽出して、要求の HTTP ヘッダーに入れる。
v バックエンド・アプリケーションが、特殊コードまたは Authorization API を必要 とせずに、ヘッダーからデータを抽出する。
1. タグ値による許可後処理を Web プラグインの中に構成する。この構成方法につ いて詳しくは、『タグ値を使用した処理の使用可能化』を参照してください。
2. 拡張属性を、Access Manager 内の /PDWebPI/host オブジェクトに追加する。た とえば、以下のようにします (1 行として入力する)。
pdadmin> object modify /PDWebPI/host
set attribute HTTP-Tag-Value ldap-home-phone=homePhone
また、新しい Tivoli Access Manager 拡張信任状 CDAS を作成し、これを 1 つの 認証メカニズムとしてプラグインの中に指定することができます。たとえば、次の とおりです。
1. [authentication-mechanisms] スタンザの中で、 cred-ext-attrs パラメーター を新規 CDAS にセットする。 たとえば、以下のようにします (1 行として入力 する)。
[authentication-mechanisms]
cred-ext-attrs = /opt/PolicyDirector/lib/libextcredtags.so
& /opt/pdwebpi/etc/pdwebpi.conf
(デフォルトの構成ファイルは pd.conf です)
2. pdwebpi.conf を編集し、新規スタンザ [ldap-ext-attr-cdas-tags] および必要な LDAP 拡張属性を追加する。たとえば、次のとおりです。
[ldap-ext-attr-cdas-tags]
ldap-home-phone = homePhone 3. プラグインを再始動する。
4. 拡張属性を Tivoli Access Manager 内の /PDWebPI/host オブジェクトに追加す る。たとえば、以下のようにします (1 行として入力する)。
pdadmin> object modify /PDWebPI/host
set attribute HTTP-Tag-Value ldap-home-phone=homePhone
タグ値を使用した処理の使用可能化
すべての認証方式の使用は、pdwebpi.conf 構成ファイルの [common-modules] ス タンザで定義します。タグ値を使用して処理を使用可能にするには、post-authzn パラメーターにリファレンス tag-value を割り当てます。
[common-modules]
post-authzn = tag-value
pdwebpi.conf 構成ファイルの [modules] スタンザは、使用可能なすべての認証メ カニズムと、それに関連した共用ライブラリー名を定義します。以下のタグ値の項 目が存在することを確認します。
[modules]
tag-value = pdwpi-tag-value-module
タグ値パラメーターの構成
タグ値パラメーターは、pdwebpi.conf 構成ファイルの [tag-value] スタンザで構成 されます。
[tag-value]
cache-definitions = yes cache-refresh-interval = 60
cache-definitions パラメーターは、オブジェクト・スペースに付加されたタグ値定 義のキャッシングを使用可能または使用不可にします。 cache-refresh-interval は、定義のキャッシュの秒単位の最新表示間隔を定義します。
必要な場合、プレフィックスを構成してタグ値 HTTP ヘッダーで使用する信任状属 性名を追加できます。このプレフィックスは、以下のとおりです。
v 信任状属性の検索時に、tag-value モジュールにより検索ストリングとして使用さ れます。
v セッション ID 信任状属性に追加されます。
v switch-user モジュールによって信任状属性に追加されます。これは、アドミニス
トレーターのユーザー名を保存するのに使用します。
プラグイン構成ファイルの [pdweb-plugins] スタンザにある tag-value-prefix パ ラメーターを使用してプレフィックスを指定します。
このパラメーターは、特定の仮想ホストの [virtual_host] スタンザを使用して、その 仮想ホスト用にオーバーライドできます。デフォルトの動作は、プレフィックスを 持ちません。
Multiplexing Proxy Agent (MPA) のサポート
Tivoli Access Manager は、Multiplexing Proxy Agent (MPA) を使用するネットワー クを保護するためのソリューションを提供します。 Multiplexing Proxy Agent
(MPA) は、複数のクライアント・アクセスを受け入れるゲートウェイです。ゲート
ウェイは、保護された Web サーバーに対する 1 つの認証済みチャネルを確立し、
すべてのクライアント要求および応答とそのチャネルとをつなぐ「トンネル」を開 通させます。プラグインにとってこのチャネルを通過してくる情報は、最初は 1 つ のクライアントからの複数の要求であるかのように見えます。プラグインは、MPA サーバーの認証と、個々のクライアントの追加認証との違いを区別しなければなり ません。その種のゲートウェイの一般的な例として、Wireless Access Protocol (WAP) ゲートウェイがあります。 Tivoli Access Manager WebSEAL は、ホスト Web サーバーと接合するように構成すると、MPA としても機能します。これによ って、WebSEAL とプラグインとの間のシングル・サインオンが可能になります。
そのようなソリューションを構成する際に、iv-header 認証モジュールを使用するこ とができます。 SSO の構成に関して詳しくは、141ページの『第 5 章 Web シン グル・サインオン・ソリューション』を参照してください。
有効なセッション・データ・タイプと認証方式
Tivoli Access Manager Plug-in for Web Servers は MPA に関する認証済みセッショ ンを保守するので、個々のクライアントのセッションも同時に保守する必要があり ます。そのため、MPA では、クライアントとは異なるセッション・データと認証方 式を使用しなければなりません。以下の表は、MPA とクライアントの有効なセッシ ョン・タイプを示しています。
表15. MPA の有効なセッション・データ・タイプ
有効なセッション・タイプ
MPA のプラグイン クライアントのプラグイン
表15. MPA の有効なセッション・データ・タイプ (続き) 有効なセッション・タイプ
MPA のプラグイン クライアントのプラグイン
HTTP ヘッダー HTTP ヘッダー
BA ヘッダー BA ヘッダー
IP アドレス
Cookie Cookie
v クライアントは、セッション・データ・タイプとして SSL セッションを使用す ることはできません。
v たとえば、MPA がセッション・データ・タイプとして BA ヘッダーを使用する 場合、クライアントがセッション・データ・タイプとして選択できるのは HTTP ヘッダーと cookie だけです。
v MPA がセッション・データとして HTTP ヘッダーを使用する場合、クライアン トは別の HTTP ヘッダー・タイプを使用します。
v サーバー固有の cookie に含まれるのはセッション情報だけであり、識別情報は含 まれません。
v MPA サポートが使用可能な場合、セッション状態を保守するための SSL セッシ ョン ID の使用は変わります。セッション状態を保守するように SSL セッショ ン ID を構成した場合、通常、SSL セッション ID だけで HTTPS クライアント のセッションを保守することができます。 MPA は SSL セッション ID を使用 してセッションを保守できるようにし、クライアントは別の方式を使ってセッシ ョンを保守するようにする場合には、この制限は除外されます。
MPA のプラグインが使用する認証方式は、クライアントのプラグインが使用する認 証方式と異なっていなければなりません。以下の表は、MPA とクライアントの有効 な認証方式を示しています。
表16. 有効な MPA 認証タイプ
有効な認証タイプ
MPA のプラグイン クライアントのプラグイン
基本認証 基本認証
フォーム フォーム
トークン トークン
HTTP ヘッダー HTTP ヘッダー
証明書
IP アドレス
v たとえば、MPA が基本認証を使用する場合、クライアントは認証方式として、フ ォーム、トークン、および HTTP ヘッダーを選択できます。
v クライアントは認証方式として証明書と IP アドレスを使用できません。
v 通常、特定のトランスポートでいずれかのフォーム (またはトークン) による認証 が使用可能にされる場合、そのトランスポートでは基本認証は自動的に使用不可 になります。 MPA サポートが使用可能にされる場合、この制限は当てはまりま
せん。これにより、同じトランスポート上でも、 MPA はたとえばフォーム (ま たはトークン) を使用してログオンし、クライアントは基本認証を使用してログ オンすることが可能になります。
MPA および複数クライアントの認証プロセス・フロー
以下のプロセス・フローは、MPA および複数のクライアント認証の場合に発生しま す。
1. 以下の構成を変更します。
v 構成ファイルで Multiplexing Proxy Agent のサポートを使用可能にする。
v 特定の MPA ゲートウェイに Tivoli Access Manager アカウントを作成す る。
v このアカウントに、プロキシー要求の送信先仮想ホストの MPA 保護オブジ ェクトに対する Proxy ([PDWebPI]p) アクセス権を付与する。デフォルト構 成では、これはユーザーを pdwebpi-mpa-servers グループのメンバーにす ることによって行われます。
2. クライアントは MPA ゲートウェイに接続します。
3. ゲートウェイは要求を HTTP 要求に変換します。
4. ゲートウェイはクライアントを認証します。
5. ゲートウェイはクライアント要求を使用してプラグインとの接続を確立しま す。
6. MPA は (クライアントとは異なる方式を使用して) プラグインに対して認証さ
れ、これにより、(すでにプラグイン・アカウントを持つ) MPA 用の識別が派 生されます。
7. プラグインは、pdwebpi-mpa-servers グループ内の MPA のメンバーシップ を検査します。
8. MPA の信任状が作成され、キャッシュ内で特殊 MPA タイプとしてフラグが
立てられます。
この MPA の信任状にはそれぞれ将来のクライアント要求が伴いますが、それ はここでの要求の許可検査では使用されません。
9. ここでプラグインはさらに要求の所有者を識別する必要があります。
MPA は、ログオン・プロンプトの適切なルーティングに関して、複数のクライ アントを見分けることができます。
10. クライアントはログオンし、MPA が使用する認証タイプとは異なる方式を使用 して認証を行います。
11. プラグインは、クライアント認証データから信任状を作成します。
12. 各クライアントが使用するセッション・データ・タイプは、MPA が使用するも のと異なっていなければなりません。
13. 許可サーバー は、ユーザー信任状およびオブジェクトの ACL 許可に基づい て、保護オブジェクトへのアクセスを許可または否認します。
MPA 認証の使用可能化
pdwebpi.conf 構成ファイルの [pdweb-plugins] スタンザ内の mpa-enabled パラ