連載　ディレクトリサービスの仕組みと活用

第3回　シングルサインオン環境の導入と設定

梁瀬介次
2000/9/27

今回のおもな内容 シングルサインオンの構成 【コラム】X.509証明書とX.500ディレクトリ ユーザーマッピングの実際 【コラム】CA（認証機関）をどのように用意するか？

　前回まで、ディレクトリサービスの概要と実際のサーバ設定例などを見てきました。今回からはシングルサインオン環境の設定を中心に、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.500ディレクトリ

X.509証明書には、主に次のような情報が含まれています（残念ながらASN.1と呼ばれるデータ記述方式で書かれた上にデコードされているため、エディタなどで直接確認することはできません）。 　　・X.500ユーザー名 　　・（必要な場合には）メールアドレス 　　・ユーザーの公開キー 　　・使用する暗号方式情報 　　・この証明書を保証する認証機関（CA）を特定するX.500名 　　・証明書の利用目的 　　・有効期限 　参考として、X.509証明書の例を示しておきます（こちらをクリック）。 　同時に、CAがこの証明書自身を証明している証に、署名がなされています。つまり、公開キーと、それを利用するユーザーを結びつけ、保証していると言えます。 　保証されているユーザー名は、例えば CN=Taro Yamada, OU=People, O=ABC-Syouji といったX.500というディレクトリの標準規格に基づいた書式で表されます。この書式はLDAPディレクトリでも同様に採用されています。 　LDAPディレクトリでは、ユーザーを特定するためにDN（Distinguished Name）というフィールドにユニークなデータを持ちます。そこに上記のような書式を同様に用います。 　場合によっては、X.509証明書とLDAPディレクトリでのユーザーを特定する名前が異なることもあります。これは、CAを外部機関に頼っている、CAとディレクトリのシステム構成が異なっているなどの原因によります。 　両者は、厳密には等しくなければなりません。例えば、証明書で宣言されていたX.500ユーザー名でLDAPを検索するシステムでは、ユーザーを見つけられない、ということもあり得るからです。こうした動作は使用するアプリの仕様によります。 　相互運用性とユーザーマッピングにはこういう問題もあるという点は注意しておいた方がよいでしょう。

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

　では実際にユーザーの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を用います。

https://server1.abc-syouji.co.jp/cca50.nsf

　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ディレクトリに直接一括して証明書を登録することなどが可能です。

【コラム】 CA（認証機関）をどのように用意するか？

CA（Certificate Authority：認証機関）は社内PKIの要となる要素です。CAはサーバやユーザーへ実際にX.509証明書を発行するサーバですが、こうしたリソース管理をCAへ指示するRA（Registration Authority）や運用時に証明書の破棄／無効を確認するためのVA（Validation Authority）機能を含むこともあります。 　取っ付きにくいこともあって、導入に尻込みすることも多いでしょう。しかしこれなくしてPKIシステムは稼働できません。またディレクトリを導入する意味も半減してしまいます。 　CAの設置は、製品を用いて独自に設置することもできますし、外部のサービスを利用することもできます。 　Windows2000のCertificate Serverや本稿でも紹介したロータス ドミノのように、アプリケーションに付属するタイプや、CA／RA／VAを網羅した専用アプリケーションもありますし、アウトソーシングのように証明書のみを提供している企業向けサービスもあります。一般には、専用アプリケーションの方が機能／柔軟性とも高いようですが、小さな組織であれば外部サービスに頼るところから始めるのもよいでしょう。 　PKIシステムは言うなればネットワーク上の「人事／総務／警備部門」です。イントラネットではまさに会社の屋台骨となる機能なのですから、導入するしないではなく、自社ではどのような導入方法が必要か、そうした議論が必要です。

これでディレクトリの設定は終了です。次回はサーバやWebブラウザの設定を行い、 実際に利用する方法を説明していきます。

「Master of IP Network総合インデックス」

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）