|
 |
ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Sametime >
LDD Today
Lotus Instant MessagingとLDAPディレクトリーの統合
|
|
|
by Raj Balasubramanian
Consulting IT Architect, IBM
レベル：中級者
原文の掲載：2004年2月17日
大きなInstant Messagingのサイトの場合には、LDAPのディレクトリー・サービスを使うよいチャンスです。この記事では、どのようにLotus Instant MessagingとLDAPを組み合わせて使うか、またどのようにすればスムースに動作させることができるのかについて紹介していきます。
Lotus Instant Messaging/Web Conferencing (Sametime)は、大企業におけるリアルタイム・コラボレーションを提供しており、この分野におけるリーダー的存在です。これには、インスタント・メッセージング、在席表示、Web会議などの機能がふくまれています。Lotus Instant Messagingを利用しているユーザーは、ユーザーのデータやユーザーの認証についてのシングル・ソースとして、企業全体で使用するLDAPディレクトリーを立てることを考えることが多くあります。ですので、そのようなサイトにとっては、ユーザーやグループの参照や認証において、Lotus Instant MessagingとLDAPディレクトリーが、どのように相互に動作しているかを理解することは是非とも必要と考えます。
この記事では、Lotus Instant MessagingサービスとLDAPディレクトリーを、どうやってうまくつなげて動作させるかについて紹介します。記事では、相互のやりとりがどのようにアプリケーション・レベルで行われ、Lotus Instant Messagingサーバーにセットされた設定にどのようにマップされるのかについてもカバーします。この記事の目標は、これらのやりとりの理解と、Lotus Instant Messagingサービスを設定してカスタマイズしたLDAPディレクトリー・スキーマを組み合わせて動作させことにあります。さらに、ログインや在席確認、参照などで発生する問題解決の方法を習得します。この記事の読者は、経験を積んだLotus Instant Messagingの管理者であり、LDAPを知っていることを前提としています。
以下に示すダイアログボックスは、例にあげたLotus Instant MessagingとLDAP環境のセットアップの状況を示したものです。
図 1. Lotus Instant Messaging/LDAP例のセットアップ
この前の図では、構成として以下のものが使われています。
- Linux (Red Hat 7.2)上で稼働するOpenLDAP version 2.1.21
- Lotus Instant Messaging (Sametime) 3.0 SP1
- Windows 2000 SP4上で稼働するDomino 5.0.10
この例では、Lotus Instant Messaging serverはOpenLDAPディレクトリーをユーザー・リポジトリーとして使用しています。
このLDAPスキーマの例には以下のものが含まれています。
- ユーザー/グループ検索用のBase DN (Distinguished Name)。フォーマットはdc=rajtest,dc=com。
- 有効な全てのユーザーのオブジェクト・クラスはtestPerson。
- 有効な全てのグループのオブジェクト・クラスはgroupOfNames。
ここで使用しているOpenLDAPディレクトリーから引いた、サンプルのエントリーとそれに付随するアトリビュートは以下の通りです。
dn=abcid=w007009,ou=users,dc=rajtest,dc=com
objectClass=testPerson
cn=Raj Bala
sn=Bala
managerName=Albert Einstein
abcid=w007009
uid=rajbala
userPassword=ldaprules
|
|
ここでのテストのセットアップでは、LDAPのユーザー・パスワードはクリアー・テキストで保存されています。実際の環境では通常暗号化されています。
OpenLDAPディレクトリーから引いてきたグループ・ユーザーのサンプル・エントリーは以下の通りです。
dn=cn=group2,dc=rajtest,dc=com
objectClass=groupOfNames
cn=group2
member=abcid=w007009,ou=users,dc=rajtest,dc=com
member=abcid=w007007,ou=users,dc=rajtest,dc=com
|
|
|
|
DominoユーザーがLDAPディレクトリーにログインすると、通常は以下のステップで処理が行われます。
- ユーザーは、ユーザー名/パスワードを使用してDominoにログインします。
- DominoはLDAPに対してBindRequestコールを発行します。BindRequestはLDAPでユーザーを認証するために使われます。(この操作をLDAP用語で"binding"と呼びます)。この例では、最初のBindRequestがDominoによって送信されますが、ユーザー名/パスワード情報は含まれていません。(これは、ディレクトリー・アシスタンス・データベースにて、LDAPサーバーへはユーザー名/パスワード情報を送らないように設定されているためです。) 受け取る側のLDAPサーバー (Anonymousでのアクセスを許可しているものとします) は、成功した旨のBindResultをDominoへ返して、ユーザーをAnonymousでバインドします。
- User IDを使ってDominoはLDAPディレクトリーを検索します。これを行うために、DominoはSearchRequestの文字列をLDAPに発行します。Domino R5では文字列は手を加えることはできませんが、Domino 6ではディレクトリー・アシスタンス・データベースを使ってカスタマイズが可能です。例えば、SearchRequest文字列にはBaseDN引数を含んでいます。これは、ディレクトリー・アシスタンス・データベースのLDAPタブにある"Base DN for search"フィールドから取得したものです。また、SearchRequestには、返してもらうサーチ・フィルターやアトリビュートも含まれています。これらはDominoにより渡されるカスタマイズできない文字列に入っています。
- 検索が成功すると、LDAPはBindResultを発行して、Dominoにユーザーが見つかった旨を通知します。返り値はユーザーのDistinguished Name (DN)とDominoからリクエストされた他のアトリビュートです。
- 操作が終了すると、DominoはUnBindRequestを発行してLDAPから切断します。
- Step 4で取得したユーザーDNとStep 1でユーザーが入力したパスワードを使い、DominoはLDAPに対してユーザーとしてバインドします。これを行うには、DominoはBindRequestを発行して、DNとパスワード情報をLDAPへ送信します。
- LDAPはDNとパスワードを検証して、BindResultを発行して、Dominoに対して成功した旨の結果コードを返します。
- DominoはUnBindRequestを発行して、LDAPから切断します。
このプロセスをグラフィックに示すと以下の通りになります。
図 2: DominoにおけるLDAP認証
この例では、@UserName関数を使ってユーザー名の値を計算した場合は、値は、abcid=w007007/ou=users/dc=rajtest/dc=com.になります。この文字列はACLにセットされユーザーがDominoのリソースにアクセスできるようにしなければなりません。
Lotus Instant MessagingユーザーがLDAP環境にログインすると、LDAPに関連する一連のコールが実行されますが、これはDominoユーザーがログインする場合と似ています。
- ユーザーはLotus Instant Messagingにログインします。
- Lotus Instant Messaging BindRequestコールをLDAPに対して発行します。例えば、この例では、AnonymousでのLDAPへのバインドを許可し、同様にstconfig.nsfで設定していますので、このBindRequestはユーザーIDやパスワード情報は含まれていません。LDAPはAnonymousでバインドします。
- Lotus Instant Messagingは渡されたユーザーIDを使ってLDAPディレクトリーを検索します。これを行うには、SearchRequest文字列をLDAPに対して発行します。SearchRequestには、Base DNの引数が含まれています。このBase DNはstconfig.nsfでのベース・オブジェクトの設定から取得されたものです。SearchRequestには、stconfig.nsfでのベース・オブジェクトの設定から取得されたサーチ・フィルター設定もまた含まれています。他の検索アトリビュートは同じデータベースのSchema Settingsプロパティーから取得されます。
- 検索に成功すると、LDAPはBindResultを発行して、Lotus Instant Messagingにユーザーが見つかった旨を連絡します。返り値は、ユーザーDNと、他の要求されたアトリビュートになります。
- 処理が終了すると、Lotus Instant MessagingはUnBindRequestを発行して、LDAPから切断します。
- Step 4で取得したユーザーDNとStep 1でユーザーが入力したパスワードを使って、Lotus Instant MessagingはLDAPとバインドを行います。
- LDAPはDNとパスワードを検証して、BindResultを発行して成功結果のコードを返します。
- Lotus Instant MessagingはUnBindRequestを発行してLDAPから切断します。
この認証の結果として、Lotus Instant Messagingは認証されたユーザーを、abcid=w007007,ou=users,dc=rajtest,dc=comとして認識します。この文字列は、vpuserinfo.nsfでバディー・リストの作成や管理の目的で使用されます。ユーザーが、uidアトリビュート(前に紹介したDominoインスタンスに似たものです)でLotus Instant Messagingにログインできるように、stconfig.nsfのSearch Filterフィールドを変更して、uidをabcidに追加で含めるようにします。
図 3. stconfig.nsfにおけるサーチ・フィルター情報
ユーザーが他の人物をバディー・リストに加える際のLDAPコールの流れは、ユーザーがLotus Instant Messagingにログインする際のLDAPコールと似ています。例えば、既にユーザーがLotus Instant Messagingにログインしているとします。そして、他のユーザーを、ファーストネーム(名)を使って追加しようとします。Lotus Instant Messagingクライアントは、そのような人物を見つけられない場合には、ラストネーム(姓)を使って検索を行います。ユーザーが見つかると、リストに追加します。内部的に見ると流れは以下の通りです。
- Lotus Instant MessagingはLDAPへBindRequestコールを発行します。ユーザーをDominoとLotus Instant Messagingにログインさせる手順を踏んで、LDAPはAnonumousでユーザーをバインドします。
- Lotus Instant Messagingは、SearchRequest文字列をLDAPに発行して、ユーザーJamesを検索します。SearchRequestにはBaseDNの引数とstconfig.nsf.に含まれるサーチ・フィルターが含まれます。
- 検索が成功しなかった場合には、LDAPはBindResultをnullのリザルトで発行します。ユーザーは、また別のユーザー名のバリエーションで検索を行い、この前に示したステップを繰り返すことができます。成功すると、LDAPは別のSearchResultを発行し、ユーザーDNと他のリクエストしたアトリビュートを返します。
- 処理が完了すると、Lotus Instant MessagingはUnBindRequestを発行して、LDAPから切断します。
ユーザーのファーストネームの検索を行うには、stconfig.nsf内のSearch Filterの設定を変えて、ファーストネームのアトリビュート(例えば、givenname)が含まれるようにしなければなりません。
|
|
Lotus Instant Messagingのミーティングの参加とログインに必要なLDAPコールの手順は、Lotus Instant Messagingへのログインの流れや、バディー・リストへのユーザーの追加に比べると、より複雑です。
- ユーザーがミーティングにログインします。
- Lotus Instant Messagingは、BindRequestコールをLDAPへ発行します。LDAPはAnonymousでバインドします。
- Lotus Instant Messagingは、SearchRequest文字列をLDAPに発行することで、そのユーザーをLDAPディレクトリーで検索を行います。SearchRequestにはBaseDNに対する引数やstconfig.nsfに含まれているサーチ・フィルターが入っています。
- 検索が成功すると、LDAPはBindResultを発行して、Lotus Instant Messagingにユーザーが見つかった旨を通知します。ユーザーのDNとリクエストされたアトリビュートが返されます。
- 操作が終了すると、Lotus Instant MessagingはUnBindRequestを発行してLDAP.から切断します。
- Step 4で取得したユーザーDNとStep 1でユーザーが入力したパスワードを使って、Lotus Instant MessagingはLDAPとバインドを行います。
- LDAPは、DNとパスワードの正当性を確認して、BindResultを発行して処理が成功した結果コードを返します。
- Lotus Instant MessagingはUnBindRequestを発行して、LDAPから切断します。
- ユーザーの正当性が確認されると、Lotus Instant MessagingはLDAPを検索して、ユーザーがどこかのグループに属していないかを確認します。これを行うのに、BindRequestを発行して、ユーザーをAnonymousとしてバインドします。そして、別のSearchRequestをLDAPに対して発行します。このコールにより、ユーザーが属するグループをすべて取得します。これには入れ子になっているグループに含まれます。
- Step 9を繰り返し行い、ユーザーが所属する入れ子となっているグループがないか検索を行います。
- 最後に、Lotus Instant MessagingはLDAPを検索し、そのユーザーが表示用に使用しているキー・アトリビュートがないか確認します。これらのアトリビュートはstconfig.nsf内で規定されています。この場合は正当性が確認された後に、BaseDNはユーザーのDNであるとして、LDAPにより引き継がれます。
前の流れでは、@UserName関数を使って名前の値を計算すると、値は、abcid=w007007/ou=users/dc=rajtest/dc=comとなります。これはDominoで認証されたユーザーと同じでありますが、Domino経由(stconfigデータベース経由)で最初にミーティングにアクセスしている事実があるためです。以下に、ログインしたユーザーを表示しているミーティングの作成ページを示します。(分かりやすい'Common Nameが表示されていないことに注意してください。)
図 4. ミーティング作成ページ
ユーザーがミーティングに参加できたら、LDAPはユーザーのDNをLotus Instant Messagingへ渡します。Lotus Instant Messagingの中では、ユーザーは以下のように認識されます。
|
abcid=w007007,ou=users,dc=rajtest,dc=com
|
|
そして、Mike Rodney として表示されます。(この例では)
ミーティング・センター内で適切なCommon Nameで表示させるには、以下に示す変更をstconfig.nsfデータベースに行う必要があります。この理由は、このLDAPにはCNあるいはUIDトークンがそのDN内にはもっていないからです。
WebTitleLoginサブ・フォームでは、最後にある<Computed Value>(計算結果の値)を以下のように変更します。
userid := @Middle (@UserName; "abcid="; "/");
newsearch := userid + ") (abcid=" + userid;
ldapName := @NameLookup([NoUpdate];newsearch; "cn");
notesName := @Name([CN];@UserName);
@If(@Trim(ldapName)!=""; ldapName; notesName)
|
|
この変更を行った後に、ユーザーがstconfig.nsfにログインすると、以下のものが表示されます。
図 5. Common Nameの表示
Lotus Instant Messaging ServerからのLDAPコールの検索文字列は以下のように表示されます。
(|(cn=w007007)(abcid= w007007)(|(&(sn= w007007))(givenname=(abcid= w007007))
(&(sn=abcid= w007007)(givenname= w007007)))))
|
|
これは暫定的な修正です。もっとよいアプローチとしては、Domino 6でサポートされているLotus Instant Messaging 3.1へアップグレードすることです。Domino 6では属性や検索文字列(stconfig.nsfに似たもの)を、ディレクトリー・アシスタンス・データベースでマッピングできるようになっています。
最後になりますが、Lotus Instant Messagingに既にログインしたユーザーが、会議のモデレーターを変えようとする場合を想定します。Doug Williamsをモデレーターとして指定したいとユーザーは考えています。そのユーザーはディレクトリー・アプレットの検索フィールドでWilliamsと入れます。検索に成功すると、Doug Williamsがモデレーターとして指定されます。以下に示す図は、Lotus Instant MessagingサーバーからLDAPに関連したコールのシーケンスを示したものです。
- Lotus Instant MessagingはBindRequestコールをLDAPに発行します。LDAPはAnonymousでバインドします。
- Lotus Instant Messagingは、SearchRequest コールを使ってWilliamsでLDAPディレクトリーを検索します。SearchRequest文字列にはBaseDNの引数が含まれており、この引数はstconfig.nsfのBase Object設定から取られています。SearchRequestにも、同様に検索フィルターが含まれており、 stconfig.nsfのSearch Filter設定から取られています。他の検索アトリビュートは同じデータベースのSchema Settingsプロパティーから取られています。
- 検索に成功すると、LDAPはBindResultを発行し、Lotus Instant Messagingに対してユーザーが見つかったことを通知します。その際に、ユーザーDNとリクエストされたアトリビュートが返されます。
- ユーザーの正当性が確認されると、Lotus Instant MessagingはLDAPを検索して、そのユーザーが属しているグループがないかどうかの確認を行います。これには、BindRequestリクエストを出して、ユーザーをAnonymousでバインドします。その上で、SearchRequestをLDAPに対して発行します。このコールにより、そのユーザーが所属する全てのグループが取得されます。
- Lotus Instant MessagingはUnBindRequestを発行して、LDAPから切断します。
この記事では、Lotus Instant Messaging やDominoからLDAPに対する、LDAP関連のコールについて見てきました。この中にはユーザーがバディー・リストへユーザーを追加する際に発行するLotus Instant MessagingやDominoのコールや、ユーザーがミーティングへ参加する際に発行するコールや、ミーティングのモデレーターを変更する際に発行するコールなどがありました。このような隠れた部分からの視点は、Lotus Instant MessagingサービスがLDAPとどのようにやりとりをしているのかを理解する上で有益です。また、ディレクトリー・アシスタンス・データベースやstconfig.nsfデータベースで、そのやりとりの中の何が設定変更できるのかを知ることも重要です。そしてstconfig.nsfを変更してLotus Instant Messagingのミーティング作成ページでCommon Nameを表示する方法も学びました。これらの情報で、より効率的にLDAPをLotus Instant Messaging環境で使えるようになれば幸いです。
著者について（原文のまま）
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.
|
|
|
|
|
