ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino >

LDD Today

Netegrity SiteMinder と Dominoベースのコラボレーション・サービス

by Raj Balasubramanian
レベル：初級
対象： Consulting IT Architect, IBM
原文の掲載：2003年12月22日

LDD Todayの原文（US）

インデックス

	SiteMinderの紹介
	Domino認証
	Webエージェント用にSiteMinderポリシー・サーバーを設定する
	Domino特有のWebエージェントの設定
	Domino環境にSiteMinderを導入するシナリオ
	まとめ
	参考資料

SiteMinderを使用して、DominoやLotus Team Workplace(QuickPlace)やLotus Instant Messaging/Web Conferencing(Sametime)のシングル・サインオン(SSO)を実現したいが、どのようにしたらよいか分からないといったことはありませんか?この記事では、実際の作業のロードマップを解説します。

全社規模でSSOを利用する企業はどんどん増えつつあります。SSOを利用すると、ログインを繰り返さずとも、同日セッションにおいて複数のアプリケーションを利用できるようになります。そのひとつの方法として、Netegrity SiteMinderを使う方法があります。これを使えば様々なWebアプリケーションでSSOを実現できます。しかし、実際にそうするまえに、SSOがどのようにDominoの環境に作用するのか、影響を及ぼすのかについて知っておく必要があります。Netegrity SiteMinderをWebアプリケーションのSSOソリューションとして使う場合、DominoとLotusの関連製品がそのSSO環境で動作することを確認しておく必要があります。

この記事では、SiteMinderがDomino上でどのようにSSOを実装されるのかを、最適な活用を行うための判断材料のもとを提供しながら解説していきます。まず最初は、SiteMinderの紹介から始めます。それから、Domino、Lotus Team Workplace (QuickPlace)、Lotus Instant Messaging and/Web Conferencing (Sametime)とSiteMinderを使用する場合のガイドラインを示します。この記事は、読者が経験を積んだDomino管理者、あるいはLotusのコラボレーション製品の管理者であることが前提となっています。

SiteMinderの紹介

Netegrity SiteMinderは、ディレクトリー対応の標準規格に準拠した製品で、様々なWeb/アプリケーションサーバーやOSやアプリケーション開発プラットフォームの混在環境でうまく動作するように考えられた製品です。SiteMinderを使用すれば、Webアプリケーションやリソースを防御するセキュリティー・ポリシーを容易に実装できます。また、認証および認可権限をポリシー・ベースで実行することで安全性を高めることもできます。開発者は、Webアプリケーションでも複雑なセキュリティーと管理の要求を、SiteMinderを使って実現することもできます。

SiteMinderには、SSOを実装するためのインフラとなる部分に、キーとなるコンポーネントが2つ入っています。一つ目はポリシー・サーバーです。ルールや、ディレクトリーやユーザーやリソースに関する関連情報がすべてここに収められています。二つ目のコンポーネントはWebエージェントです。これはSSOを実装するWebサーバー/アプリケーションサーバー上にインストールされるソフトウェアになります。以下に示す図は、これらのコンポーネントがどのように機能し、どのようにお互いに関連しているかを示したものです。

図1. SiteMinderの環境

SiteMinderは様々なWebサーバーをサポートしており、その中にはWindows NT/2000上やSolaris上で動作するDominoがあります。(OS/390上で動作するGo Webサーバーも含まれています。)

今日現在、最新のSiteMinderのバーションは5.5です。が、この記事で紹介する設定情報の殆どはバージョン4にも適用できます。(バージョン間で違いがある場合には記載します。) SiteMinderに関する詳細な技術情報については、SiteMinder Web pageをご覧ください。

上に戻る

Domino認証

DominoはC APIやDSAPI(Domino Server API)を使って、HTTPアクセスの認証を行うことができます。以下の図は、DSAPIを使ってカスタム認証を行う場合のものです。

図2. DSAPIを使ったカスタム認証

DSAPIは共有ライブラリーとして実装、登録されていて(Windows 2000/NTではDLL、UNIX/Linuxでは共有オブジェクト)、Domino HTTPプロセスにより実行されます。HTTPタスクと関連づけられたキーとなるイベントがありますが、DSAPIで書かれたカスタム・コードでこれらのイベントはオーバーライトされます。その結果、DSAPIはDominoの認証モデルと置き換えることができるため、以下のことに適しています。

DSAPIを使えば、幅広い様々なカスタム認証に関する要求に対応することができます。
HTTPリクエストは、DSAPIにより毎回インターセプトされ、処理されます。

Netegrity SiteMinderのDomino用WebエージェントはDSAPIで実装されています。
SiteMinderは、SMSessionクッキーをユーザーセッションに対して発行することでSSOを実現しています。他のWeb/アプリケーションサーバーでSiteMinderの環境で動作するように設定されていれば、クッキーでクレデンシャルの確認ができ、関係づけられているユーザーを認証することができます。クッキーの内容は秘密鍵で暗号化されています。また、基本ユーザーアイデンティティーを提供すること以外にも、HTTPリクエストヘッダーからユーザーアイデンティティーを参照するようにエージェントを設定することもできます。SiteMinderのDomino用Webエージェントは、ユーザーから送られるHTTPリクエストヘッダーから、ある特定の値に基づいてユーザーアイデンティティーを提供できる機能が備わっています。

SSOを提供することに加えて、Webエージェントでクロスサイトスクリプティング(CSS)アタックの防御機能を備えたセキュアーな環境を提供するように設定することも可能です。また、指定した信頼できるIPやホストのみを許可するようにルールを設定することや、Webリソースに対して洗練された認証を確立することでリソースの認証ができます。また、不正なURLのチェックやその他様々なセキュリティー機能の提供が可能です。これらの設定は通常、対象サーバーのWebエージェント設定ファイルで行います。(SiteMinder Version 4.x/5.x)あるいは、ポリシー・サーバー上でも行えます。(Version 5.x)対象となるサーバーのWebエージェントの設定が含まれているファイル名はwebagent.confになります。

SiteMinderを使い、DominoサーバーをSSO対応にしつつ、またDominoのACL機能を利用して認証を行ったり、SiteMinderにおける認可リストを組み立てたりすることができます。経験からは、SiteMinderはよく(サイトの)認証に用いられ、DominoのACL機能はアプリケーションの認証に用いられます。つまり、SiteMinderを使ってSSOを実現させつつも、ACLをフルに使って、サーバー、データベース・ビュー、文書レベルに至るまでフルにACLの機能を引き続き活用できます。

上に戻る

Webエージェント用にSiteMinder ポリシー・サーバーを設定する

SiteMinder環境においてSSOを実施する際に、ポリシー・サーバーがどのように使われているかを見ていきましょう。ポリシー・サーバーはWebエージェント用のポリシー定義が格納されている中心的な場所になります。対象となるWebサーバー上にWebエージェントを展開するに先立ち、様々なポリシーやエージェント特有のオブジェクトをポリシー・サーバーに定義する必要があります。

ポリシー・サーバーには、インストールされているWebエージェントがどのように振る舞うべきかを規定するオプションがあります。各Webエージェントは、ポリシー・サーバー上で定義された以下の内容を必ず持っています。

エージェント・プロフィールは、エージェントのIPアドレスかホスト名に関する情報で構成されています。
SiteMinder 5.xから利用可能なエージェント設定オブジェクトには、エージェントのIPアドレスかホスト名が含まれています。
SiteMinder 5.xから利用可能なホスト設定オブジェクトにはポリシー・ホストとポリシー・サーバーに関連する設定が含まれています。
ポリシー・ドメインは、関連する領域、ルール、レスポンス、ポリシー(以下の項目をご覧ください)の集合体です。
領域は、認証スキームの定義により、リソースを保護あるいは非保護にするかを定義します。
ルールは、保護/非保護のリソースに対する特定のWebアクションを定義します。また、アクセスの可否も定義します。
レスポンスはオプショナルな機能で、対象となるWebサーバーに対して送信されるHTTPヘッダーを定義します。リクエスト毎にカスタムで作成することもできますし、静的なものにもできます。
ユーザー・ディレクトリーは、ユーザーのリポジトリーを定義します。(ほぼ全てのケースにおいてLDAPベース)
ポリシーは、ルール、領域、ユーザー・ディレクトリー、レスポンスを定義します。

以下の図は、Webエージェント用に、ポリシー・サーバー上で設定されたコンポーネント間の関係を示しています。

図3. Webエージェント用ポリシー・サーバー上で設定されたコンポーネント間の関係図

この例では、Dominoのユーザー名のフォーマットで、CN=Albert Einstein/OU=Physicists/O=Scientistsを使用し、LDAPの識別名(DN)のフォーマットで、uid=emc2,ou=physicists,o=scientistsを使用しています。

上に戻る

Domino特有のWebエージェントの設定

SiteMinderのDomino用Webエージェントは特別なパラメーターを持っており、Dominoサーバー上でWebエージェントの動作に柔軟性を持たせています。パラメーターの詳細なリストについては、SiteMinderのWebエージェントガイドを参照してください。この記事でキーとなるパラメーターは以下の通りです。

SkipDominoAuthは、Yesにセットされた場合はDominoの認証をスキップします。DominoでWebエージェントが正常に動作させるためには、Noに設定します。
DominoSuperUserは、全てのリソースにアクセスするユーザー名を明示します。Noにセットされた場合には、このパラメーターは滅多に使用されることはなくなります。(何はともあれ、そのようにセットするのはよいお手本ではありますが)このパラメーター値は暗号化されています。
DominoDefaultUserは、そのセッションにおけるSiteMinderの認証において、有効なユーザー・アイデンティティーを取得できない、あるいは名前解決できない場合に使うデフォルトのDominoユーザーとして使用するユーザー名を指定します。このパラメーターの値も暗号化されています。AnonymousかNobadyを指定します。
DominoUseHeaderForLoginは、Domino環境内においてユーザーを識別するための、SiteMinderのヘッダー値です。これは極めて強力なパラメーターで、様々なファクターによりダイナミックにユーザーのアイデンティティーを変更することが可能です。
DominoLookupHeaderForLoginは、Yesにセットすると、WebエージェントはDominoUseHeaderForLogingで指定された値に基づいて、ローカルのDominoディレクトリーの参照を実施して、Dominoのユーザー名を取得します。このパラメーターの取りうる値は、Yes/Noです。

上に戻る

Domino環境にSiteMinderを導入するシナリオ

既存のDomino環境にSSOを導入する際の、最も中核となる問題は、SSOエンジンではLDAPを活用しているのに対して、DominoのアプリケーションのACLや認証はすべてDominoディレクトリーを使用しているということです。このような状況では、セットアップによっては、異なるユーザー・アイデンティティーを持ち込むことになります。従ってDominoの環境にSiteMinderを導入する際には、可能なオプションを理解しておくことが非常に重要になってきます。

Domino環境に置いて考慮すべき、キーとなるメカニズムが3つあります。

Authentication (認証：ユーザーのクレデンシャルが本当に本人のものであるかを確認すること)
Authorization (認可：どの操作の実行を許可するかの確認)
Awareness (存在確認(在席確認)：認証したユーザーがオンラインであるかのステータスの確認)

前のセクションで述べてきたように、認証はDominoサーバー上のWebエージェントにより実行されます。認可はアプリケーションごとにDomino ACLにより実行されます。存在確認はLotus Instant Messaging/Web Conferencingにより実行されます。認可と存在確認は、認証が済んだ後で設定されるユーザー・アイデンティティーに依存しています。従って、認証が済んだユーザーのアイデンティティーはどのDominoサーバー、Lotus Team Workplace、Lotus Instant Messaging/Web Conferencingサーバー(これらのサーバーはSSOに参加しており、Dominoベースの認証とInstant Messaging/Web Conferencingベースの存在確認/在席確認が必要となります)の利用において、同一でなければなりません。

Dominoの環境にSiteMinderを導入する方法は、以下の質問により異なってきます。

既存のDominoインフラがありますか?
SiteMinderのインフラとしてDomino LDAPを使いますか?
SiteMinderを使った既存のDominoディレクトリーはありますか?
Dominoのユーザー名を使用してアプリケーションを使用したいですか?
ローカルのDominoディレクトリーでユーザー名を参照しますか?
LDAPディレクトリーにアトリビュートを追加できますか?
Dominoディレクトリーに変更を加えられますか?

以下のセクションでは、様々な質問を組み合わせながら、様々なシナリオにおけるガイドラインを紹介していきます。2つのタイプのアイデンティティーとディレクトリーパターンがあることに気を付けてください。単一アイデンティティーと単一ディレクトリーのパターンと、複数アイデンティティーと複数ディレクトリーのパターンです。単一アイデンティティーと単一ディレクトリーのパターンでは、(Dominoまたは非Dominoベースの)LDAPディレクトリーをひとつだけ使って、Lotus Workplaceと
Lotus Instant Messaging/Web ConferencingとSiteMinder環境をサポートします。
この認証では、SiteMinder、Lotus WorkplaceやLotus Instant Messaging/Web Conferencingや認可リスト、ユーザー・アイデンティティーに基づいた在席情報など、全てにわたって標準的なDNを使います。

図4. 単一アイデンティティーと単一ディレクトリーのパターン

複数アイデンティティーと複数ディレクトリーのパターンでは、SiteMinder用にLDAPディレクトリー(Domino/非Domino)を使用しながら、Lotus Team WorkplaceとLotus Instant MessagingとWeb Conferencingを使うことがサポートされます。認証を行うことにより、Lotus Team Workplace、Lotus Instant Messaging/Web ConferencingにいついてはDomino DNが供給され、非LotusプラットフォームにはLDAP DNが供給されます。認可リストと存在確認についてはDomino DNがベースとなります。つまり、Dominoディレクトリーがベースとなります。

図5. 複数アイデンティティーと複数ディレクトリーのパターン

シナリオ1
以下のことが該当する場合に、このシナリオが当てはまります。

既存のDominoインフラがある。
SiteMinderインフラ用にDomino LDAPを使いたい。

SiteMinderはDomino LDAPをサポートしていますので、DominoディレクトリーをSiteMinderのSSO環境におけるユーザー・ディレクトリーとして使用することができます。また、デフォルトの状態では、Dominoのグループは階層化されていませんので、階層を伴った形でリネームするか再作成するようにした方がいいでしょう。この場合、ポリシー・サーバー内でグループに対してベースDNが提供されるようになります。

Dominoディレクトリーが対象となるWebサーバー(Domino、Lotus Team Workplace、Lotus Instant Messaging/Web Conferencing)と異なるドメインに所属している場合には、ディレクトリー・アシスタンスをそれらのサーバー上にセットアップして名前解決ができるようにします。

SiteMinder Webエージェントで認証されたユーザー名はDominoのフォーマットを使用します。Webエージェントのセットアップに関しては特に追加の作業は不要です。Domino上でのWebエージェントの設定に進んでください。詳細については、前のセクションで紹介した単一アイデンティティーと単一ディレクトリーのパターンに関する説明を参照してください。

シナリオ2
以下のことが該当する場合に、このシナリオが当てはまります。

既存のDominoインフラはあるが、SiteMinderに対してはDomino LDAPはない、あるいはDominoインフラがない。
SiteMinderを利用した既存のLDAPディレクトリーはない。

環境にLDAPディレクトリーがありませんので、Domino、Lotus Team Workplace、Lotus Instant Messaging/Web ConferencingやSiteMinderでサポートされているLDAPディレクトリーを構築します。リレーショナル・データベースを使うと、環境のカスタマイズがさらに必要になります。これは、Domino、Lotus Team Workplace、Lotus Instant Messaging/Web Conferencingがリレーショナル・データベースをユーザー登録目的ではサポートしていないためです。詳細については、前のセクションで紹介した複数アイデンティティーと複数ディレクトリーのパターンを参照してください。

シナリオ 3
以下のことが該当する場合に、このシナリオが当てはまります。

既存のDominoインフラはあるが、SiteMinderのインフラに対応したDomino LDAPはない。あるいは、Dominoのインフラがない場合。
SiteMinderが利用している既存LDAPディレクトリーがない場合。
Dominoのユーザー名を使ってアプリケーションを利用しない場合。

つまり、Dominoのユーザー名フォーマットを使わないことを選択したことになります。ユーザー文書をへ変更を入れたり、メールファイルのACLをLDAP DNに変更しない限り、このSSO環境ではDominoメールファイルにアクセスされることはありませんことを是非とも明記しておかなければなりません。

Domino、Lotus Team Workplace、Lotus Instant Messaging/Web Conferencingは、同一のLDAPディレクトリーにマップされている限りは動作します。これは、LDAP DNを使って内部的にはユーザーの識別を行っているからです。また、前のセクションの単一アイデンティティーと単一ディレクトリーのパターンも参照してください。

シナリオ4
以下のことが該当する場合に、このシナリオが当てはまります。

既存のDominoインフラがあるがSiteMinderインフラ用にDomino LDAPはない。あるいは、Dominoインフラがない。
SiteMinderを使用している既存のLDAPディレクトリーがある。
Dominoのユーザー名を使ってアプリケーションを使う。
ローカルのDominoディレクトリーを使って名前の参照を行う。

この選択は、ローカルのDominoディレクトリーの参照を許可するために行われますので、結果として出てくるアイデンティティーはDominoのユーザー名の形式になります。これは通常、対象のDominoサーバー上の、特定のWebエージェントのパラメーター設定で行います(SiteMinder 4.x/5.x)。あるいは、ポリシー・サーバーで集中的に行います。(SiteMinder 5.x)このパラメーターはDominoLookupHeaderForLoginで、以下のように記述して設定します。

DominoLookupHeaderForLogin="Yes"

このパラメーターは、WebエージェントがDominoディレクトリーに対して名前参照を行う際に、DominoUseHeaderForLoginで指定された値をキーとして使うようにするためのものです。LDAPディレクトリーとDominoディレクトリーの双方がEmployeeIDを持っている場合、以下のことを行うとユーザー参照を行う上でのキーとして使えるようになります。

ユーザーがEmployeeIDでSiteMinderにログインを行うならば、レスポンスをセットする必要はありません。そうでなくレスポンスを返したい場合には、ポリシー・サーバー上に、Dominoに関連づけられた領域に対してレスポンスを設定します。レスポンスはLDAPのアトリビュートになるように設定します。例えば、EmployeeIDです。
(オプショナル)Domino Webエージェントに対するポリシーで、領域と新規作成したレスポンスを関連づけます。
対象となるDominoサーバー上で、以下のパラメーターをWebエージェント設定ファイル(webagent.conf)に追加します。
DominoUseHeaderForLogin="HTTP_EMPLOYEEID" (EmployeeIDがレスポンスの場合)
DominoUseHeaderForLogin="HTTP_SMUSER" (EnployeeIDでSiteMinderにログインした場合)
対象となるDominoサーバー上で、以下のパラメーターをWebエージェント設定ファイル (webagent.conf)に追加します。
DominoLookupHeaderForLogin="YES"
Dominoディレクトリーのユーザー文書に、EmployeeIDの値が表示されていることを確認します。
アイデンティティーはDominoベースであり、DominoやLotus Team WorkplaceやLotus Instant Messaging/Web Conferencingは必然的にDominoディレクトリーを使う必要が出てきます。これはACLや在席確認のためにユーザー登録情報を参照する必要があるからです。アイデンティティー/ディレクトリーパターンについて解説された前のセクションもご覧ください。

シナリオ5
このシナリオは、以下の条件の場合に該当します。

既存のDominoインフラはあるが、SiteMinderインフラに対応したDomino LDAPがない、またはDominoインフラがない場合。
SiteMinderを利用する既存のLDAPディレクトリーがある場合。
Dominoのユーザー名を使ってアプリケーションを使いたい場合。
ローカルのDominoディレクトリーで名前参照を行わない場合。
LDAPディレクトリーにアトリビュートを追加できる。

LDAPディレクトリーを変更できることになっていますので、LDAPスキーマを拡張して以下のものを入れるようにします。

Dominoの名前を、CN=Albert Einstein/OU=Physicists/O=Scientistsのフォーマットで、LDAPの各ユーザー文書にアトリビュートとして保存します。Lotus Team WorkplaceやLotus Instant MessagingやWeb ConferencingをSiteMinderのSSOで動かしたいサーバーで実施します。
Lotus Instant Messaging/Web Conferenceのホーム・サーバー名は、CN=LIM/O=Scientistsの形式です。Lotus Instant Messaging/Web Conferencingサーバーでユーザー登録としてLDAPディレクトリーを使用している場合や、複数のLotus Instant Messaging/Web Conferencingサーバーを使用している場合には、これが必須となります。

Dominoでの名前(この例では、Domino DN)がLDAPのユーザー文書に対して正しく入った後で、以下のことを実行して対象となるDominoのサーバー毎にWebエージェントレベルでのLDAP DNの代わりにDomino特有の名前に名前の変換を行います。

Dominoが関連する領域に対して、レスポンスを設定します。(ポリシー・サーバー上)レスポンスがLDAPアトリビュートになるようにセットします。この例では、Domino DNになります。
Domino Webエージェントに対する設定されたポリシーの領域と、新に作成されたレスポンスを関連づけます。
対象となるDominoサーバー上で、以下に示すパラメーターをWebエージェントの設定ファイル (webagent.conf)に設定します。
DominoUseHeaderForLogin="HTTP_DOMINODN"

このシナリオにおいては、LDAP DN (例えば、uid=emc2,ou=physicists,o=scientists) としてSiteMinderに認証されました。Dominoリソースにアクセスする場合には、WebエージェントによりDomino名として識別されます。(例えば、CN=Albert Einstein/OU=Physicists/O=Scientists)
識別名がDominoベースであるため、DominoやLotus Team WorkplaceやLotus Instant MessagingやWeb Conferencingは必然的にDominoディレクトリーを使う必要が出てきます。これはACLや在席確認のためにユーザー登録情報を参照する必要があるからです。

シナリオ6
最後に、シナリオ6ですが、当てはまる条件は以下の通りです。

既存DominoインフラがあるがSiteMinder用のDomino LDAPがない場合、あるいはDominoインフラが全くない場合。
SiteMinderが使用するLDAPディレクトリーが既にある場合。
Dominoユーザー名をアプリケーションで使用したい場合。
名前解決にローカルのDominoディレクトリーを参照していない場合。
アトリビュートをLDAPディレクトリーに追加できる場合。
Dominoディレクトリーを変更できる場合。

名前解決のためにDominoディレクトリーに変更を加えたいという意図がありますので、既存のユーザー文書に変更を加えて、LDAP DNをDominoのフォーマットで追加します。DN uid=emc2,ou=physicists,o=scientistsというユーザーは、uid=emc2/ou=physicists/o=scientistsという形式で入力します。このエントリーは既存のユーザー名(FullNameフィールド)のエントリーの次に記述します。これにより、Webエージェントは認証したユーザーをLDAP DNで認識しますが、DominoはDominoディレクトリーのユーザー文書のFullNameフィールドの最初の名前で名前を解決できるようになります。

図6. ユーザー文書

識別名はDominoベースとなっています。つまり、DominoやLotus Team WorkplaceやLotus Instant MessagingやWeb Conferencingは必然的にDominoディレクトリーを使う必要が出てきます。これはACLや在席確認のためにユーザー登録情報を参照する必要があるからです。

このシナリオの中で前に示した条件が、あなたの環境において全て合致する場合には(Dominoディレクトリーの変更は行いますが)、この記事で紹介した6つのシナリオの中から最適なものを、考慮の上選択する必要があります。

上に戻る

まとめ

SiteMinderは企業全体にわたってSSOの環境を提供します。これにはDominoやその他のLotusコラボレーション製品が含まれます。現在のDomino環境においてSiteMinderを使ってSSOにしたいと考えている場合には、実行に移す前に取りうるオプションについて評価する必要があります。検討する際にキーとなるファクターは、ユーザー・ディレクトリーやユーザー・アイデンティティーや、SSO環境においてアイデンティティーが異なるものではないかどうかを確認することです。この記事では、Domino、Lotus Team Workplace、Lotus Instant Messaging、Web ConferencingについてSiteMinderを使ってSSO環境を構築する複数のパターンについて解説しました。

上に戻る

参考資料

LDD TIPS "SSO-enabling Sametime with Netegrity SiteMinder" 2台のサーバー環境で、SiteMinderを使ってSSOの認証環境を設定する方法が記されています。
SiteMinderに関わる詳細な技術情報については、SiteMinder Webページを参照してください。
"New features in Notes/Domino 6.5" では最新のNotes/Dominoの新機能が要約されて説明されています。

著者について（原文のまま）
Raj Balasubramanian is a Consulting IT Architect for IBM Software Services for Lotus (ISSL). He works on customer engagements delivering application and infrastructure related projects. His interests range from anything technical to history and physics. During his copious spare time, he enjoys talking about robots with his sons.

上に戻る