この章では、IBM Tivoli Access Manager (Tivoli Access Manager) Plug-in for Web
Servers がセッション状態を維持し、認証プロセスを処理し、許可済みセッションで
必要になる許可後処理を実行する方法について説明します。
この章には、以下のトピックがあります。
v 『要求処理プロセス』
v 45ページの『認証の構成』
v 53ページの『セッション状態の管理』
v 60ページの『認証構成の概要』
v 64ページの『基本認証の構成』
v 67ページの『フォーム認証の構成』
v 70ページの『証明書認証の構成』
v 72ページの『トークン認証の構成』
v 76ページの『SPNEGO 認証の構成』
v 85ページの『NTLM 認証の構成 (IIS プラットフォームのみ)』
v 86ページの『Web サーバー認証の構成 (IIS プラットフォームのみ)』
v 87ページの『フェイルオーバー認証の構成』
v 104ページの『IV ヘッダー認証の構成』
v 107ページの『HTTP ヘッダー認証の構成』
v 109ページの『IP アドレス認証の構成』
v 110ページの『LTPA 認証の構成』
v 111ページの『ログオン後のユーザーのリダイレクトの構成』
v 112ページの『信任状の拡張属性の追加』
v 115ページの『HTTP ヘッダーへの LDAP 拡張属性の追加 (タグ値)』
v 117ページの『Multiplexing Proxy Agent (MPA) のサポート』
要求処理プロセス
Tivoli Access Manager Plug-in for Web Servers は、各 Web 要求が Web サーバー に着信するとこれを処理します。要求処理プロセスには、次のように 8 つのステッ プがあります。
1. 仮想ホストの識別
要求プロセスの最初のステップは、要求の対象となる仮想ホストの識別です。仮 想ホストの識別については、13ページの『仮想ホスト・サーバーの構成』で説 明します。
セッションの識別
いったん仮想ホストが判別されたら、既存の認証セッション情報に対して要求が 検査されます。この情報は、セッション cookie または SSL セッション ID の いずれかです。セッションの識別に使用される情報は、構成済みのセッション・
モジュールによって判別されます。53ページの『セッション状態の管理』で、
使用可能なセッション・モジュールについてそれぞれ説明しています。
3. 認証
既存のセッションが確認できない場合、要求は認証情報について検査されます。
これは、基本認証のユーザー名とパスワード、ログイン・フォームのサブミッ ト、またはクライアント証明書などの情報です。クライアントの認証に使用され る情報は、構成済みの認証モジュールで識別されます。45ページの『認証プロ セス』で、使用可能な認証モジュールについてそれぞれ説明しています。
有効な認証情報が要求内に存在する場合、新しい認証済みユーザー・セッション が作成されます。認証情報がない場合、要求は未認証として扱われます。要求に 無効な認証情報が含まれており、認証方式が認証情報の再入力をサポートしてい
る場合 (たとえば、基本認証) は、ユーザーは再び認証を提供するように要求さ
れます。認証方式が再入力をサポートしていない場合 (たとえば、クライアント 証明書) は、エラーがクライアントに戻されます。
4. 事前許可
要求されたリソースへのアクセスが許可される前に初期要求処理が必要な場合が あります。 この処理は、構成済みの事前許可モジュールで実行されます。事前 許可モジュールは、許可が不要な機能を提供したり、許可決定の前に要求へのア クセスが必要な機能をサポートします。
5. 許可
許可中に、セッションに関連する信任状情報を使用して Tivoli Access Manager ポリシーが参照され、要求リソースに対するアクセスを許可するかどうか、許可 する場合はどのような条件にするかを判断します。リソースへのアクセスを制御 するために定義されたポリシーについては、123ページの『第 4 章 IBM Tivoli Access Manager Plug-in for Web Servers セキュリティー・ポリシー』で定義さ れています。
6. 認証アップグレード
ユーザーの認証レベルが要求リソースのアクセスには不適切か、または要求が認 証されていない場合、必要とされる認証レベルでユーザーを認証するための認証 情報について、要求が再び検査されます。そのような情報がなく、必要とされる 認証レベルでユーザーに情報を要求する機能をサポートする認証モジュールが構 成されている場合、ユーザーはそのような情報を提供するよう要求されます。リ ソースへアクセスするのに十分なレベルに認証済みのユーザー・セッションをア ップグレードする手段がない場合は、リソースのアクセスは拒否されます。
7. 許可後
場合によっては、許可決定が行われた後、以下の目的で何らかの処理が必要にな ることがあります。
v ヘッダーを挿入するためなどで、Web サーバーで処理される前に Web 要求 を変更する
v cookie の設定など、Web サーバーで生成された Web 応答を変更する
v たとえば、ログオンの成功後にユーザーを特定のページにリダイレクトするな ど、Web サーバーで要求を処理せずに完全な応答を生成する
これらの操作は、決定が要求の処理方法に影響するので、許可プロセスの結果が 分かった後で行われます。これらの機能は、許可後モジュールによって提供され ます。
8. 応答処理
フォーム・シングル・サインオン (FSSO) や外部認証インターフェース (EAI) 処理などの機能では、クライアントに送信されるのではなくプラグインで処理さ れる、Web サーバーで生成された応答が必要です。一般的に、応答処理では、
代替応答をユーザーに渡す前にプラグイン・プロセスが Web サーバーからの要 求に応答します。この機能が必要なモジュールを応答モジュールと呼びます。
認証プロセス
認証とは、セキュア・ドメインにログオンしようとする個々のプロセスまたはエン ティティーを識別する方式です。認証に成功すると、ユーザーを表す Tivoli Access
Manager 識別が得られます。プラグインはこの識別を使用してそのユーザーの信任
状を取得します。信任状は、各リソースのポリシーを支配する ACL 許可、POP 条 件、および許可規則を評価した後で、保護リソースへのアクセスを許可または拒否 するために、Authorization Server によって使用されます。
注: ACL = アクセス・コントロール・リスト・ポリシー
POP = 保護オブジェクト・ポリシー
Tivoli Access Manager Plug-in for Web Servers は、デフォルトでいくつかの認証方 式をサポートします。また、他の方式を使用するようカスタマイズすることもでき ます。
認証の構成
すべての使用可能な認証方式は、関連する共用ライブラリー名と共に pdwebpi.conf 構成ファイルの [modules] スタンザに定義されています。 [modules] スタンザに は、セッション識別と許可後処理に使用されるモジュールもリストされています。
これらのモジュールについてはのちほど説明します。共用ライブラリーは、
pdwebpi/lib ディレクトリーに存在していなければなりません。共用ライブラリー
名は、オペレーティング・システムに固有なプレフィックス (たとえば lib) とオペ レーティング・システムに固有な接尾部 (たとえば dll) は付けずに指定されます。
たとえば、以下のようにします。
BA = pdwpi-ba-module
上記の例では、BA モジュール・ライブラリーが pdwpi-ba-module として指定され ています。プラグインは、Windows では pdwpi-ba-module.dll というファイルを 探し、 Solaris では libpdwpi-ba-module.so というファイルを探し、 AIX では libpdwpi-ba-module.a というファイルを探します。
注: [module-mgr] スタンザでは、ライブラリー・ファイルのデフォルト検索パス に代わる検索パスが定義できます。
[modules] スタンザで定義された各ラベルは、対応する独自のスタンザ (たとえば
[BA]、[cert]、および [token] など) を持ちます。各認証方式に対する特定の構成情
位で特別な構成が必要な場合は、モジュール・ラベルを仮想ホスト・ラベルで修飾 するスタンザを使用してデフォルトの構成をオーバーライドできます。たとえば、
以下のようにします。
[BA]
basic-auth-realm = "Access Manager"
[BA:ibm.com]
basic-auth-realm = "ibm.com"
上記の例で、基本認証を使用して仮想ホスト ibm.com にアクセスしているユーザー は、スタンザ [BA:ibm.com] に指定されている構成パラメーターによって制約され ます。
モジュールの標準構成では、特定の認証方式に対して、次の例のように、モジュー ル・ライブラリーの 1 つのインスタンスしか指定できません。
[modules]
BA = pdwpi-ba-module
インストールの一部では、認証ライブラリーの複数インスタンスの指定が必要で す。これは、さまざまな認証レベルに、モジュールのさまざまな振る舞いが必要な 場合です。次の例は、フォーム認証モジュールの 2 つのインスタンスの構成を示し ます。
[modules]
BA = pdwpi-ba-module
forms-authn-level1 = pdwpi-forms-module forms-authn-level2 = pdwpi-forms-module [common-modules]
authentication = forms-authn-level1 authentication = forms-authn-level2 authentication = BA
[forms-authn-level1]
login-form = level1-form [forms-authn-level2]
login-form = level2-form [BA]
...
認証方式の構成における最後のステップは、認証方式の指定です。これらは、構成 ファイルの [common-modules] スタンザで優先度順に設定されます。たとえば、
以下のようにします。
[common-modules]
session = ssl-id session = BA
session = session-cookie authentication = cert authentication = BA post-authzn = ltpa
上記の例の構成設定では、以下のようになります。
v セッション情報の保守には、最初の選択として SSL セッション ID が使用され る。
v SSL セッション ID が使用不可の場合は、 BA ヘッダー (使用可能な場合) を使 用してセッション情報が保守される。
v SSL セッション ID または BA ヘッダーがいずれも使用不可の場合、セッション 情報の保守には、最後の手段として cookie が使用される。
v 最初の選択としては、証明書が認証方式として使用される。
v 証明書が使用不可の場合は、BA が認証に使用される。
v LTPA cookie は、許可後処理の一環として要求に追加される。
仮想ホストの認証の構成
認証方式の構成は、方式を各仮想ホストのスタンザに直接指定することによって、
仮想ホストごとに行えます。たとえば、以下のようにします。
[pdweb-plugins]
virtual-host = ibm.com [ibm.com]
....
session = ssl-id session = BA
session = session-cookie authentication = cert authentication = BA post-authzn = ltpa
仮想ホストの認証方式を指定するもう 1 つの方法は、認証方式の構成用のスタンザ を定義することです。この場合は、複数の仮想ホストが 1 つのモジュール構成を共 用することができます。モジュール構成スタンザは、仮想ホスト・スタンザの中の
modules パラメーターで指定されます。たとえば、以下のようにします。
[pdweb-plugins]
virtual-host = ibm.com virtual-host = lotus.com [ibm.com]
modules = ibm-lotus-module-stanza [lotus.com]
modules = ibm-lotus-module-stanza [ibm-lotus-module-stanza]
authentication = BA session = BA post-authzn = ltpa
構成ファイルに、認証方式構成用のスタンザが各仮想ホストごとに別々に定義され ていない場合、すべての仮想ホストが [common-modules] スタンザに構成されて いるパラメーターを使用します。すなわち、modules パラメーターのデフォルト値 は common modules になります。
以下の例では、使用可能な場合は SSL セッション ID を使用し、SSL セッション ID を使用できず BA ヘッダーがある場合は BA ヘッダーを使用するよう構成され た、ibm.com という仮想ホストをセットアップし、セッション情報を保持するため の最後の手段としてセッション cookie を使用します。これは、基本認証の前に証明