Webでのシングルサインオンの利用：ディレクトリサービスの仕組みと活用（4）

　今回は前回まででセットアップしたシングルサインオン環境を、実際にWebブラウザからのログインやマルチサーバからの利用で活用してみましょう。

WebサーバとLDAPディレクトリ

　LDAPディレクトリ側の設定は終わりましたが、今度はアプリケーションサーバ側でLDAPディレクトリを参照するための設定を行う必要があります。ここではWebサーバの設定を行うことにします。

　下の図はWebサーバがLDAPディレクトリを参照して、ログインを承認する様子です。

　通常、Webサーバは独自のユーザー管理システムを持っています。例えば、UserDBと呼ばれるUNIXのpasswdファイルのようなレコード型ファイルであったり、ロータスドミノのドミノディレクトリのように専用のデータベースであったり、Oracleのシステムテーブルであるなど、構造はさまざまです。

　LDAPディレクトリで認証を行う機能とは、そうしたアプリケーション依存の認証システム以外に、共通して「外部の」LDAPディレクトリを使用する機能が付加されていることを指します。そのため、LDAPディレクトリでは認証に必要な情報を標準化しています。

　下のリスト1は、LDAPディレクトリが保持するユーザー情報のフィールド（正式にはアトリビュートと呼ばれます）の一部です。

dn: CN=Taro Yamada,O=ABC-Syouji,C=JP
cn: Taro Yamada
cn: MAIL=Taro Yamada
cn:: jlKTYyCRvphZ
shortname: TYamada
uid: TYamada
mail: Taro.Yamada@ABC-Syouji.co.jp
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
usercertificate;binary:: MIICRzCCAbCgAwIBAgIgfUj
thIVHwGCBBbravo9sy/AesRm5x3c2JQLRWT16LGowDQYJKoZI
 
                    （略）
 
wtyQlHjUk3Z42WChImCLZC1vhl10FInYbxC0rcYVqqU42yA=
title: Manager
employeeid: 00000001
givenname: Taro
sn: Yamada
commonname;lang-ja:: jlKTYyCRvphZ
givenname;lang-ja:: kb6YWQ==
sn;lang-ja:: jlKTYw==

　DN（Distinguished Name）は1ユーザー（正確には1エントリ）の名前だと考えてください。前回述べたように、X.500ディレクトリ規格に沿った名前の付け方になっています。userCertificateというのがユーザーX.509証明書の格納先です。このDNが示す「ユーザー」が、Webブラウザアクセス時に示されるはずの証明書の持ち主ということになります。前回述べたユーザーマッピングはLDAPアクセスからはこのように確認することができます。

Webサーバの設定

　では、WebサーバからLDAPディレクトリを参照するように設定してみましょう。

　まずはロータス ドミノでの設定です。話がややこしくなっているかもしれませんが、ここではあくまでドミノをWebサーバとしてのみ使用するものと考えてください。前回のように、ドミノをCA（認証機関）やLDAPサーバとして使用していることもあるかもしれませんが、ここでは考えないこととします。

　ドミノでは「ディレクトリアシスタンス」という機能で、外部LDAPディレクトリを認証に用いることが可能です。「da50.ntfテンプレート」でDBを作成します。ノーツクライアントからこのDBを開き、次のように設定します。

画面1　ディレクトリアシスタントの「基本情報タブ」設定画面（画面をクリックすると拡大表示します）

画面2　ディレクトリアシスタントの「規則タブ」設定画面（画面をクリックすると拡大表示します）

画面3　ディレクトリアシスタントの「LDAPタブ」設定画面（画面をクリックすると拡大表示します）

　詳しくはマニュアルにもありますが、まず「ドメインタイプ」として「LDAP」を選択します。「規則」にはそのLDAPディレクトリにどのような情報が登録されているかを指定します。これはディレクトリツリー構造（DIT：Directory Information Tree）をo（Organization）、ou（Organization Unit）、c（Country）といった要素別に指定します。通常はすべて「＊（アスタリスク）」でも構いません。また、「証明書を信用」を「はい」としておきます。

　「LDAP設定」→「ホスト名」にはLDAPサーバ名を入力します。「認証」の「ユーザー」「パスワード」はLDAPサーバにログインして検索する必要がある場合に設定します。入力しなければAnonymous（匿名）ユーザーとして検索することになります。Anonymousユーザーでは必要な情報が検索できないこともあります。そうした場合には管理者ユーザーでログインするようにします。

　「検索するベース」は「検索場所」「Base DN」などとも呼ばれるLDAP検索では必要な指定です。検索を開始するLDAPディレクトリツリーを指定します。例えば「cn=Taro Yamada. o=ABC-Syouji, c=JP」といったユーザーが登録されている場合では、このエントリは「o=ABC-Syouji, c=JP」という場所の下に格納されていることになります。そこでこの検索ベースとして「o=ABC-Syouji, c=JP」を指定します。これを指定しないと検索できない、つまり認証を確認できないこともありますので注意してください。

　「チャネルの暗号化」はできる限り「SSL」を選択します。選択するには当然LDAPディレクトリサーバでSSLが使用できなくてはなりません。「SSL」とすることで、ドミノサーバからの検索がすべて暗号化され、ネットワーク盗聴などによる情報漏洩のリスクが避けられます。

　この設定文書を保存して、次にドミノディレクトリの「サーバー文書」に、先ほど作成したディレクトリアシスタンスDB名を設定し、サーバを再起動します。

画面4　ドミノディレクトリ「サーバー文書」の設定

　以上で設定は終了ですが、もちろん、ドミノWebサーバでSSLが利用できるようにしておいて下さい。「クライアント認証」を行えるようにもしておきます。

画面5　「サーバー文書」SSLの設定

　同様の設定はiPlanet（Netscape）Enterprise Serverでも行えます。要領や考え方はドミノと同じです。管理サーバへWebブラウザからアクセスし、「Global Settings」を選択します。「Configure Directory Service」でLDAPサーバの「Host Name」「Base DN」（検索を開始するベース）「Bind DN」（検索時にログインするユーザー名）などを設定します。「OK」ボタンで反映します。

画面6　iPlanet（Netscape）Enterprise ServerでのLDAPサーバ設定（画面をクリックすると拡大表示します）

　同じく、SSLを利用できるようにし、「Restrict Access」（アクセス制限 ACL）の設定でコンテンツへのアクセスにクライアント認証とLDAPへの確認が必要とするようにします。

Webブラウザからの利用

　ではいよいよ、Webブラウザから実際にWebサーバへアクセスしてみましょう。

　操作自体は特別なことはありません。まずドミノWebサーバへアクセスしてみます。アクセスはSSLで行うことになります。アクセス時に、使用する証明書を選択する場合もあります。

画面7　IE5での証明書の選択（画面をクリックすると拡大表示します）

　IE（Internet Explorer）では、Windowsログオン時にユーザー名／パスワードを設定していれば聞いてくることはありませんが、Netscapeの場合には、最初に一度だけ証明書ストアのパスワードを尋ねられます。

　普通にサーバにアクセスできれば成功です。テストのためにperlのCGIプログラムで表示してみました。$REMOTE_USER変数などを出力してみると、正しくユーザー名が表示されているのが分かります。

画面8　ユーザー名が正しく表示されたことを確認（画面をクリックすると拡大表示します）

　ほかのWebサーバへURLを切り替えても、同一のユーザー（同一のクライアント証明書）で認証できるようになります。