シングルサインオン環境の導入と設定：ディレクトリサービスの仕組みと活用（3）

　前回まで、ディレクトリサービスの概要と実際のサーバ設定例などを見てきました。今回からはシングルサインオン環境の設定を中心に、PKI（Public Key Infrastructure：公開キー暗号方式を用いた情報基盤システム）との統合、Webブラウザやメーラからの利用例を説明していきます。

シングルサインオンの構成

　一言でシングルサインオンと言っても、その実現にはいくつかの要素が存在します。

1. ディレクトリへのPKI情報の格納と統合
2. アプリケーションサーバのディレクトリ／PKI対応と設定
3. Webブラウザやメーラ、その他デスクトップアプリケーションのディレクトリ／PKI対応と設定

　これらがすべて整って、初めてシングルサインオンは実現するといえます。

図1　ドミノディレクトリへのユーザーX.509証明書マッピング

　実例を挙げてみましょう。上の図1は、ドミノディレクトリにおける、ディレクトリ情報とPKIの関係を示した図です。

　ドミノディレクトリ（LDAPサーバとしても使用します）には、社内などで管理しているユーザー情報などが格納されています。このユーザー情報はLDAPなどを介して自由にサーバやユーザーからアクセス可能です。このユーザー情報自身に、各ユーザーの保持するユーザーX.509証明書が格納されている、つまりマッピングされています。

　あるX.509証明書をサーバが受け取れば、LDAPサーバに問い合わせてどのユーザーにマッピングされているものかを確認することで、サーバはそのリクエストがそのユーザーからのものと信じることになります。

　または、ユーザー名からLDAPを検索して、そのユーザーの正しい証明書を入手することも可能です。

　もしこうした共通ディレクトリが存在しないと、サーバやユーザーはたとえX.509証明書を手にしてもそれを検証したり、詳細なユーザー情報を入手できないため、セキュリティ上の不安を残したまま運用を続けざるを得ません。

　PKI機能はサーバやユーザーに暗号化や署名によってセキュリティ上のメリットをもたらしますが、単独ではアプリケーションサーバなどに「ユーザー」という概念をもたらすのは困難です。ディレクトリと組み合わせることで、社内／異種システムを横断した「ユーザーレポジトリ」を構築できると言えるのです。

　同時にディレクトリから見た場合にも、もともとディレクトリは、誰もが参照できるサービスで、本当に正しい情報かどうかの保証はありません。PKIと結びつくことで初めて業務での使用に堪える情報になり得ると言えます。

　1点注意しなくてはならないのは、ディレクトリが提供するのは、両者をマッピングすることでユーザー確認を行わせることだけだ、ということです。これをAuthentication（認証）と言います。

　これに対し、ユーザーがあるWebコンテンツを参照したり変更したりする権限を認めるかどうかはアプリケーションサーバ（Web、メールなど）側で実装／設定しなくてはなりません。これをAuthorization（認可）と呼びます。アクセスコントロールと呼ばれることもあります。

　両者の連携もシングルサインオンにおける大事な要素です。

ユーザーマッピングの実際ユーザーマッピングの実際

　では実際にユーザーのX.509証明書をディレクトリのユーザー情報にマッピングしてみましょう。

　まずユーザーX.509証明書が取得されていることを前提とします。ここで取得とは、ブラウザに個人のX.509証明書がすでにインストールされていることを意味しています。

画面1　WebブラウザにインストールされているX.509証明書（IE5の場合、画面をクリックすると拡大表示します）

　この証明書は、社内にあるCA（認証機関）から発行されたものでも、Web上のパブリックなサービスから入手したものでもかまわないこととしておきます。証明書とディレクトリの関係についてはコラムを参照してください。CAについて、本稿では詳しくは説明しませんが、コラムで補足しておきます。

　ここではロータス ドミノのドミノディレクトリへのマッピングを例に説明します。

　ドミノのユーザーマッピングでは「認証機関」DBを使用します。このDBはドミノをCAサーバとして使用するためのDBですが、ドミノをCAとして使用しない場合にも、ユーザーマッピングのためには用いることになります。

　まず、この「認証機関」DB（「cca50.ntf」テンプレート）を登録に使用するサーバ上に作成します。同時にサーバでSSLが可能になるように「サーバー証明書管理」DB（「ccert50.ntf」テンプレート）でセットアップし、ドミノディレクトリのサーバ文書の「ポート」→「インターネットポート」→「Web」でSSLポートステータスを「有効」にします。また、クライアント認証を「はい」にしておきます。Webブラウザからアクセスする必要がありますので、httpタスクを起動、または再起動します。

画面2　ドミノディレクトリの設定（画面をクリックすると拡大表示します）

　「サーバー証明書管理」DBのセットアップではサーバーX.509証明書を取得することになります。この証明書はこれからマッピングするユーザーX.509証明書を取得したのと同じCAからの方が望ましいでしょう。詳細はマニュアルなどを参照してください。

　次にユーザー証明書を取得済みのWebブラウザから、このサーバにSSLでアクセスします。具体的には、例えば次のURLを用います。

　cca50.nsfは実際に作成した「認証機関」DB名です。

　場合によっては、アクセスする際に使用するユーザー証明書の選択を求められることがあります。マッピングしたい証明書を選択してください。

　アクセスしたトップページの「クライアント証明書の登録」を選択します。すると以下のような画面が現れますので、名前やメールアドレスを入力して、ボタンを押します。これで自身の証明書をディレクトリに登録する「リクエスト」が行われたことになります。

画面3　登録画面（画面をクリックすると拡大表示します）

画面4　リクエストした内容の確認（画面をクリックすると拡大表示します）

　WebブラウザでSSLv3にアクセスした場合には、サーバは（設定にもよりますが）WebブラウザからユーザーX.509証明書の提出を実は受け付けているのです。そのためこのマッピングの要求処理は必ずSSLアクセス（https://〜 のURLでのアクセス）で行わなければなりません。

　続いて、管理者の作業になります。管理者はノーツクライアントから「認証機関」DBを開きます。「クライアント登録要求」を選択し、一覧から先ほど申し込まれたリクエストを見つけて開きます。このリクエストに「ドミノディレクトリでの名前」という欄があります。ここにマッピングしたいドミノのユーザーを指定します。

画面5　リクエストした内容を管理者側で確認する（画面をクリックすると拡大表示します）

　「受理」ボタンを押すと、自動的にドミノディレクトリの指定したユーザー文書に、ユーザーX.509証明書が格納されます。

　以下はノーツからユーザー文書を確認したところです。先ほど登録したユーザーX.509証明書が登録されているのが分かります。

画面6　ユーザー文書でのユーザーX.509証明書の確認（画面をクリックすると拡大表示します）

　以上で、ユーザーマッピングは終了です。必要であれば必要なユーザー分のマッピングを行います。

　あるいは、ドミノの場合、ドミノの「認証機関」DBをCAとして用いるのであれば、CAからのユーザーX.509証明書の発行時に同時にマッピングをしたり、管理者が管理クライアントからドミノディレクトリに登録されているユーザーへ一括で証明書を発行することも可能です。

　同じような機能はほかのCA製品でも存在します。LDAPディレクトリに直接一括して証明書を登録することなどが可能です。