今回は前回まででセットアップしたシングルサインオン環境を、実際に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を開き、次のように設定します。
詳しくはマニュアルにもありますが、まず「ドメインタイプ」として「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名を設定し、サーバを再起動します。
以上で設定は終了ですが、もちろん、ドミノWebサーバでSSLが利用できるようにしておいて下さい。「クライアント認証」を行えるようにもしておきます。
同様の設定はiPlanet（Netscape）Enterprise Serverでも行えます。要領や考え方はドミノと同じです。管理サーバへWebブラウザからアクセスし、「Global Settings」を選択します。「Configure Directory Service」でLDAPサーバの「Host Name」「Base DN」（検索を開始するベース）「Bind DN」（検索時にログインするユーザー名）などを設定します。「OK」ボタンで反映します。
同じく、SSLを利用できるようにし、「Restrict Access」（アクセス制限 ACL）の設定でコンテンツへのアクセスにクライアント認証とLDAPへの確認が必要とするようにします。
【コラム】 アクセスコントロール
Webサーバでのユーザー認証により、ユーザーが特定のコンテンツを参照したり、書き込んだり、あるいは禁止したりといったセキュリティ機能が利用できるようになります。こうした機能を「アクセスコントロール」と呼びます。または日本語では「認可」と呼ばれることもあります。
「アクセスコントロール」は通常、個々のWebサーバ製品の固有の機能です。ユーザー情報は共通化することはできても、実際の設定方法は製品ごとに異なり、サーバ単位でコンテンツに設定しなければなりません。
しかし、ここまで設定をこなしてきた方なら、「LDAPディレクトリのような仕組みで統一化や一元管理はできないか」と考えるのも自然でしょう。
ところが、現在のLDAP対応製品では残念ながらそうした機能は提供されていません。統一的なアクセスコントロール手法は、実は現在も標準化作業中なのです。IETFで、ようやく今年になり標準ドラフトがまとまりました。今後、各社で対応が論議され、実際の製品に反映されるにはおそらくまだ1〜2年はかかるでしょう。
どうしても今すぐにアクセスコントロールの一元化を行いたい場合には、Webサーバのプラグインとして導入することで、ユーザーのアクセスできる範囲を制限できるソフトなどもありますので、これらを利用するのも手です。
Webブラウザからの利用
ではいよいよ、Webブラウザから実際にWebサーバへアクセスしてみましょう。
操作自体は特別なことはありません。まずドミノWebサーバへアクセスしてみます。アクセスはSSLで行うことになります。アクセス時に、使用する証明書を選択する場合もあります。
IE（Internet Explorer）では、Windowsログオン時にユーザー名／パスワードを設定していれば聞いてくることはありませんが、Netscapeの場合には、最初に一度だけ証明書ストアのパスワードを尋ねられます。
普通にサーバにアクセスできれば成功です。テストのためにperlのCGIプログラムで表示してみました。$REMOTE_USER変数などを出力してみると、正しくユーザー名が表示されているのが分かります。
ほかのWebサーバへURLを切り替えても、同一のユーザー（同一のクライアント証明書）で認証できるようになります。
【コラム】 BASIC認証でシングルサインオン？
いわゆるX.509証明書を用いた認証以外に、Webブラウザからは「BASIC認証」と呼ばれる認証方法も使用可能です。普段インターネットなどでは最も多く用いられている、だれもが経験したことがある方法でしょう。ただしユーザー名とパスワードがそのままネットワークに流れてしまうことと、パスワードを推測されてしまうとだれでも簡単に「なりすまし」が可能なため、セキュリティ保持の観点からはX.509認証に比べると劣るとされます。
実は、LDAPディレクトリもBASIC認証のためのパスワードを保持できるのですが、シングルサインオンを行うのは難しいのです。これは、Webサーバ側はLDAPディレクトリによってユーザー名／パスワードを共通化できるものの、Webブラウザは異なるサーバにログインする際には必ずユーザー名／パスワードを尋ねる仕様になっていることが多いためです。こうした仕様がないと不用意に別のサーバにユーザーのパスワード情報を流してしまう恐れがあるからです。
そのため、BASIC認証でシングルサインオンを行おうとすると、どうしてもクッキー（Cookie）やJavaScriptを駆使することになります。BASIC認証自体は高度なセキュリティを要求されるネットワークには必ずしも向いているとは言えませんが、インターネット全体での利用を考えると利用したい場合もあるかもしれません。
ところが、IE5や最近新しく発表されたNetscape6では「オートコンプリード」や「パスワードマネージャー」と呼ばれる機能があります。最初に一度でもログインすれば、その次からは自動的にそのサーバに合わせたユーザー名／パスワードを使用してくれるという機能です。
完全なものではありませんが、見かけ上のシングルサインオン程度には利用できそうです。
次回予告
今回までで既存製品を用いたシングルサインオンの方法を具体的に述べてきました。すでにディレクトリ活用の基盤は整ったと言えます。次回からはディレクトリのさらなる活用を目指し、簡単なプログラミングを通して、もう少し深くLDAPディレクトリを解説していきます。
Copyright © ITmedia, Inc. All Rights Reserved.