Tivoli Access Manager Plug-in for Web Servers が、セキュア・ドメインの保護を提 供するための許可サービスとしてインプリメントされている場合、そのドメイン内 のリソースへのシングル・サインオンのためのソリューションの提供が必要となる ことがあります。この章では、Tivoli Access Manager Plug-in for Web Servers によ って保護されている Web スペースのシングル・サインオン・ソリューションにつ いて説明します。
この章には、以下のトピックがあります。
v 『シングル・サインオンの概念』
v 142ページの『セキュア・アプリケーションへの自動サインオン』
v 145ページの『WebSEAL または他のプロキシーからのプラグインへのシング ル・サインオン』
v 146ページの『シングル・サインオン用のフェイルオーバー cookie の使用』
v 147ページの『グローバル・シングル・サインオン (GSO) の使用』
v 150ページの『Security Provider NEGOtiation (SPNEGO) のシングル・サインオ ン』
v 150ページの『フォームを使用したシングル・サインオン』
シングル・サインオンの概念
保護リソースがプラグイン拡張 Web アプリケーション・サーバーに配置されてい るとき、そのリソースを要求するクライアントがさまざまなセキュア・アプリケー ションにアクセスする際に、複数のログオンの実行が必要になります。ログオンに はそれぞれ異なるログオン識別が必要になる可能性があります。
複数のログオン識別の管理と保守の問題は、ほとんどシングル・サインオン (SSO) メカニズムによって解決できます。 SSO を使用すると、ユーザーは初回の 1 度の ログオンだけでリソースにアクセスできます。 Web サーバー上のリソースに関す るそれ以上のログオン要件は、ユーザーに対して透過的に処理されます。
Tivoli Access Manager Plug-in for Web Servers によってサポートされている、さま ざまなシングル・サインオン・アーキテクチャーがあります。これらは、以下のと おりです。
1. サーバー上の複数のセキュア・アプリケーションへのシングル・サインオンを提 供する 1 つのプラグイン・インスタンス。
2. WebSEAL またはその他のプロキシー・エージェント (WAP ゲートウェイなど)
からのプラグインへのシングル・サインオン。
3. 異なるドメイン間のシングル・サインオンを提供するためのフェイルオーバー cookie の使用。
4. 保管されたユーザー信任状情報を使用するアプリケーションへのアクセスを提供
5. IIS ベースの Web サーバー上のリソースにアクセスを許可するための Security Provider NEGOtiation (SPNEGO) の使用。
6. SSO のメカニズムとしてのフォーム・ベースの認証。
7. 複数のセキュア・ドメイン間でユーザー信任状を転送するためのメカニズムを提 供する、クロスドメイン・シングル・サインオン (CDSSO)。
8. e-Community シングル・サインオン。ユーザーが 1 度認証を行うと、再認証の
必要なしにドメインの仮想コミュニティー内の他のドメインへのアクセスを可能 にするトークンが発行されます。
最初の 6 つの SSO シナリオについてはこの章で説明します。 7 番目のシナリオ は、次の章のトピックで説明します。
セキュア・アプリケーションへの自動サインオン
(アプリケーションが WebSphere Application Server の場合) HTTP ヘッダーと
LTPA cookie を使用することにより、 1 つのプラグイン・インスタンスによって保
護されるサーバー上のアプリケーションへの SSO を行うことができます。
初期のクライアントの認証を行った後、プラグインは、サーバー上で実行するセキ ュア・アプリケーションの自動認証で使用できるクライアント識別情報を含む HTTP ヘッダーを作成できます。同様に、LTPA cookie を使用することにより、
WebSphere などの Web アプリケーション・サーバーへの SSO を行うことができ
ます。
HTTP ヘッダーを使用したセキュア・アプリケーションへのシング ル・サインオンの構成
アプリケーションへのサインオンで使用される HTTP ヘッダーは、iv-header 許可後 モジュールによって生成されます。生成されるヘッダーのセットは、集合的に IV ヘッダーと呼ばれます。
ユーザー要求の許可に成功した後、プラグインは、クライアントの識別を定義する IV ヘッダーを、アプリケーションで処理するための要求に挿入できます。このヘッ ダー情報は、セキュア Web サーバーによってホストされるアプリケーションによ って要求が処理される際に、ユーザーの識別を証明するものとして使用されます。
ユーザーは、新たにセキュア・アプリケーションにアクセスするたびにログオンし なくても済むようになります。
許可後処理用に構成された IV ヘッダーは、 iv-user、 iv-user-l、 iv-creds、
iv-groups、 iv-remote-address という HTTP ヘッダー・タイプのいずれか、またはい くつか、あるいはそのすべてを使用して挿入されます。以下の表では、これらのヘ ッダー・タイプについて説明されています。
表23. IV ヘッダー・フィールドの説明
IV ヘッダー・フィールド 説明
iv-user Tivoli Access Manager ユーザーの短縮名。 デフォルトでは、
クライアントが非認証 (不明) の場合は非認証になります。
iv-user-l ユーザーの完全ドメイン名 (長形式)、たとえば、LDAP 識別
名。
表23. IV ヘッダー・フィールドの説明 (続き) IV ヘッダー・フィールド 説明
iv-groups ユーザーが所属するグループのリスト。
iv-creds ユーザーの Tivoli Access Manager 信任状を表す、エンコード
された不透明なデータ構造。
iv-remote-address クライアントの IP アドレス。この値は、プロキシー・サーバ
ーまたはネットワーク・アドレス変換機構 (NAT) の IP アド レスを表す場合もあります。
IV ヘッダー生成の使用可能化および使用不可
プラグインが IV ヘッダーを許可要求に挿入できるようにするには、許可後処理で IV ヘッダーを使用するようにプラグインを構成する必要があります。すべての認証 方式の使用は、pdwebpi.conf 構成ファイルの [common-modules] スタンザで定義 します。許可後処理のために IV ヘッダーを使用可能にするには、以下のように、
pdwebpi.conf 構成ファイルの [common-modules] スタンザで、 post-authzn パラ メーターにキーワード値 iv-headers を割り当てます。以下のようにします。
[common-modules]
post-authzn = iv-headers
IV ヘッダー・パラメーターの構成
IV ヘッダー認証パラメーターは、pdwebpi.conf 構成ファイルの [iv-headers] スタ ンザで構成されます。
generate パラメーターは、プロキシー要求を転送する際に生成する IV ヘッダーの
タイプを指定します。デフォルトでは、プラグインは、プロキシー要求を転送する 際にすべての IV ヘッダー・タイプを生成します。有効なオプションは、
all、iv-creds、 iv-user、 iv-user-l、 iv-remote-address です。複数のヘッダー・タイプ を入力する場合は、値をコンマで区切ります。
たとえば、以下のようにします。
[iv-headers]
generate = iv-creds,iv-user,iv-user-1
LTPA cookie を使用した WebSphere Application Server への シングル・サインオン
WebSphere Application Server 上でプラグインが保護層としてインストールされる場 合、アクセス中のクライアントは、プラグイン、WebSphere がそのサーバーとなる セキュア・アプリケーションという 2 つの潜在的ログオン・ポイントに直面しま す。この状況でログオンのシングル・ポイントを提供するには、 cookie ベースの Lightweight Third Party Authentication (LTPA) メカニズムを生成し、それを LTPA
cookie をサポートする Web アプリケーション・サーバーに渡すようにプラグイン
を構成します。
ユーザーがサーバー上のリソースに対して要求を行う際、ユーザーはまずプラグイ ンに対して認証されなければなりません。認証が成功すると、プラグインはユーザ ーに代わって LTPA cookie を生成します。 Web アプリケーション・サーバーの認
まれます。この情報は、プラグインとアプリケーション・サーバーの間で共用され るパスワード保護秘密鍵を使って暗号化されます。
プラグインは、Web アプリケーション・サーバーに送信される要求の HTTP ヘッ
ダーに cookie を挿入します。アプリケーション・サーバーは要求を受け取り、
cookie を暗号化解除し、 cookie 内で提供されている識別情報に基づいてユーザー
を認証します。
パフォーマンスを向上させるために、プラグインはセッション・キャッシュに LTPA cookie を保管し、そのキャッシュされた LTPA cookie を、同じユーザー・
セッション中の次の要求の際に使用します。セッション・キャッシュのパラメータ ーの設定に関する詳細は、54ページの『プラグインのセッション / 信用状キャッシ ュの構成』を参照してください。
LTPA cookie を使用した WebSphere へのシングル・サインオンの 構成
LTPA cookie をサポートするアプリケーション・サーバーへのシングル・サインオ
ンを実現するために LTPA cookie を使用することは、プラグインの許可後処理の一 部です。この機能を使用可能にするには、pdwebpi.conf 構成ファイルの
[common-modules] スタンザ内のパラメーター post-authzn に、キー値 ltpa を 以下のように入力します。
[common-modules]
post-authzn = ltpa
LTPA cookie の構成は、pdwebpi.conf 構成ファイルの [ltpa] スタンザ内で実行さ れます。以下のパラメーターを構成する必要があります。
表24. LTPA 構成パラメーター
パラメーター 説明
ltpa-keyfile cookie に入れる識別情報を暗号化するために使用される鍵
ファイルの絶対パス名。
ltpa-stash-file パスワード stash ファイルの場所。パスワード stash ファ
イルが存在しない場合は、このエントリーをコメント化す る必要があります。
ltpa-password パスワード stash ファイルが存在しない場合に使用するパ
スワード。
ltpa-lifetime LTPA cookie の存続時間 (秒単位)。
LTPA シングル・サインオンに関する技術上の注意点
v 鍵ファイルには、特定の Web アプリケーション・サーバーについての情報が入 っています。複数のアプリケーション・サーバーを同じプラグインに追加する と、すべてのサーバーが同じ鍵ファイルを共用するようになります。
v シングル・サインオンが成功するためには、プラグインとアプリケーション・サ ーバーが、何らかの方法で同じレジストリー情報を共用する必要があります。
v アプリケーション・サーバーは、LTPA の設定と共有秘密鍵の作成を担当しま す。