連載第3回：ディレクトリ統合

「並列」と「直列」から「統合型」の認証サーバへ

日本アイ・ビー・エム
山本秀宣
日本アイ・ビー・エム システムズ・エンジニアリング
高橋悟史

2003/2/13

「シングルサインオン」実現へのユーザー認証の一元化

　「ディレクトリを導入すること」イコール「シングル・サインオンを実現すること」と考えられている場合がよくあるようです。しかし、この両者は技術的には独立したものです。シングル・サインオンを実現するうえで、ユーザーの認証情報などを効率よく管理するためにディレクトリを利用することはよくあります。しかし決して、ディレクトリを導入するだけで、自動的にシングル・サインオンが実現されるということはありません。

　第2回「『シングル・サインオン』へのファーストステップ｣では、ディレクトリの技術、特に最近注目されているLDAPというキーワードに焦点を当てての概要をご紹介しました。今回は、シングル・サインオンを実現する際にどのようにディレクトリが利用されるのかその技術的な概要を説明します。

統合認証サーバによる“並列”シングル・サインオン

　連載第１回「なぜシングル・サインオン」が必要なのか？では、シングル・サインオンには“並列”の方向と“直列”の方向の2つがあると述べました。まずは、“並列”方向のシングル・サインオンを実現するための具体的な方法とディレクトリとのかかわりを見ていきましょう。

　最近では、多くのアプリケーションがWebの技術をベースにしています。Webへのアクセスに用いられるHTTPプロトコルには、複数のWebサーバ間で認証情報を互いに受け渡すための方法は用意されていません。複数のWebサーバ間でユーザーの認証を統合するためには、通常のWebサーバの仕組みに加えて何らかの特別な仕組みが必要になります。最近では、Webシングル・サインオンを実現するための「統合認証サーバ」製品が広く利用されるようになっています。

　例えば次のような製品があります。

• IBM Tivoli Access Manager for e-business
• Netegrity SiteMinder
• Entrust GetAccess
• hp IceWall SSO
• RSA ClearTrust
• Sun ONE Identity Server
  

　（なお、本稿では統合認証サーバの基本的な機能について述べるうえで、IBM Tivoli Access Manager for e-businessで利用可能な機能を題材にします。）

　統合認証サーバの実現方式には、大きく分けて2つあるといえます。ここでは、それぞれを「リバース・プロキシ方式」（図1-A）および「エージェント方式」（図1-B）と呼ぶことにします。

　リバース・プロキシ方式では、統合認証サーバがWebサーバに対するリクエストをすべてチェックして、認証済みのリクエストをWebサーバに送ります。エージェント方式では、ユーザーはまず統合認証サーバにアクセスし、すでに認証済みであるということを表す“チケット”を受け取ります。次にそのチケットを、各エージェント・モジュールに提示して、エージェント・モジュールによるチケットの検査を受けた後、Webサーバにアクセスします。エージェント方式の実装には、図のように独立した統合認証サーバが存在するものと各エージェントが統合認証サーバの役割も兼ねているものがあります。

図1-A　　統合認証サーバがWebサーバに対するリクエストをすべてチェックし、認証済みのリクエストをWebサーバに送るリバース・プロキシ方式

図1-B　　ユーザーがまず統合認証サーバにアクセスし、すでに認証済みであるということを表す“チケット”を受け取るエージェント方式

　統合認証サーバの製品によって、上の図のような「リバース・プロキシ方式」と「エージェント方式」のうちどちらか一方の方式のみ利用可能なものと、両方の方式を利用可能なものとがあります。IBM Tivoli Access Manager for e-businessは両方の方式をサポートする製品です。

　2つの方式は、それぞれ一長一短がありますが、いずれの場合もシングル・サインオンのための処理の大まかな流れは同様です。

　まず、ユーザーがWebブラウザを用いて統合認証サーバにアクセスし、認証情報（ユーザーIDとパスワードの組み合わせなど）を送信します。統合認証サーバは、ディレクトリに問い合わせるなどの方法でユーザーを認証します。

　統合認証サーバは、ユーザーの認証が済むとブラウザから送られたリクエストに対して、必要に応じてURLに基づくアクセス制御を行うなどした後に、適切なWebサーバに転送します。その際、ユーザーを識別することができる認証情報を併せてWebサーバに送ります（図2）。

　多くのアプリケーションは、ユーザーが誰であるかを認識してその振る舞いを制御しますので、そのアプリケーションが稼働するWebサーバでは、あらためてユーザー認証の処理が必要になります。このWebサーバ上で行われる「内部的な認証」にはさまざまな方法がありますが、大抵の場合はその処理に伴ってディレクトリ上に格納されたユーザー情報が参照されます。Webサーバによる認証が済んだ後に、適切なアクセス制御とともにアプリケーションの処理が行われていきます。

図2　統合認証サーバを用いたシングル・サインオン処理。 一般に、統合認証サーバだけでなく、各Webサーバ上でも内部的な認証処理が行われその際にディレクトリが参照される

　統合認証サーバ製品を用いることにより、安全かつ容易に“並列”シングル・サインオンを実現することができます。

　一方、既製品を使わずに同様の仕組みを独自に開発することも、原理的にはもちろん可能です。実際、複数サーバに対する認証を透過的に行わせるだけの単純な機能であれば、さほどの時間をかけずに作成できるかもしれません。ただし、その場合には統合された認証はシステム全体のセキュリティのかなめであるということに、特に注意すべきです。

　 セキュリティ・プロトコルにさまざまな脅威に対する十分な耐性を持たせるためには、多大な労力を投じる必要があります。不十分で安易な設計・開発によって、セキュリティ上の欠陥を生み出すようなことがあってはなりませんし、また十分なセキュリティを維持するために、完成後も継続的にメンテナンスを行っていく必要があるでしょう。

統合認証サーバとディレクトリ

　統合認証サーバが参照するディレクトリと後段のWebサーバ群が参照するディレクトリは、共通のものである場合もあるでしょうし別のものである場合もあります。もちろん、一般的には複数のディレクトリを、物理的に1つのディレクトリにまとめて統合する（図3）ことができればそれに越したことはない、といえるでしょう。しかし現実には、そのようにできない場合も多々あるものです。

　たとえすべてのサーバやアプリケーションが“LDAP対応”をうたっていたとしても、期待どおりにうまく統合できないことがあります。その大きな理由の1つは、前回説明したようにLDAPスキーマやサーバ間の通信に関する互換性の問題が存在するという点です。

　ある1つのベンダの製品だけで認証サーバからWebサーバからすべてをそろえることができれば、恐らく、LDAPスキーマの問題などは発生せず何ら問題は発生しないでしょう。しかし実際の多くの企業では、複数ベンダの製品が混在している状況が一般的です。そのような状況で、ディレクトリを統合しようとする場合には、LDAPのスキーマなどに関する互換性の問題に注意しなくてはなりません。また、そもそもLDAPに対応できないアプリケーションに配慮しなければならないことも多いでしょう。

図3　1つのディレクトリにまとめる場合。LDAPスキーマなどの互換性に注意する

　LDAPスキーマの非互換の問題が起きたり、アプリケーションがLDAPに対応していないなどの理由で、ディレクトリを物理的に1つにまとめられないときには異なるディレクトリの間で何らかの方法で情報の同期を取り、それぞれのディレクトリに"同じ内容"が保持されているように管理する必要があります（図4）。いわば、“ディレクトリの論理的な統合”です。異なるディレクトリ間での情報を同期させるためには、IBM Tivoli Identity ManagerやIBM Directory Integratorなどのディレクトリを統合するための汎用ツールが利用できます。

図4　2つのディレクトリを利用。ディレクトリ間で、何らかの方法で同期を取り情報が整合しているように保つ（＝ディレクトリを論理的に統合する）

　また、ユーザーが多数登録されたディレクトリがすでにあって、それを利用するアプリケーションが本番稼働中であったり、アプリケーションごとにユーザーIDの体系が異なるといった状況を考えてみましょう。ユーザーIDを新たに振り直してディレクトリを共通化するといったことは、現実的にまったく不可能ということもあるでしょう。

　そのような状況に対処するため、オープンで複合的な環境に配慮した統合認証サーバでは、ユーザーIDやパスワードなど認証情報の変換を行う機能が備わっているものがあります。ディレクトリを1つにまとめられないという制約を統合認証サーバの側の機能を使って吸収してしまおうというわけです。

　統合認証サーバ上で認証されたユーザーIDに対し、後段のWebサーバに対してユーザーID・パスワードを適切に変換してからそれを引き渡すという機能を使えば、既存のユーザーID体系をそのままにしながらシングル・サインオンを実現することができます（図5）。ただしこの方法を取る場合、管理しなければならない情報の分量が増えるため運用の負荷も増大してしまう可能性があることに注意する必要があります。

図5　統合認証サーバ上で、認証情報の変換を行うことによって既存のディレクトリを変更せずにそのまま使う

　シングル・サインオンを実現するに当たっては、ビジネス上の要件によって、さまざまな選択肢があります。ディレクトリの統合と統合認証サーバの導入とは、併せて検討されることが最も多いでしょうが、“ディレクトリを整理・統合してユーザーID・パスワードを統一するが、統合認証サーバは導入しない”という選択肢もあれば、逆に"統合認証サーバを導入してシングル・サインオンを実現するが既存のディレクトリはできるだけそのまま使い続ける"という選択肢もあるのです。

“直列”シングル・サインオンの実現

“直列”のシングル・サインオン（図6）は、どのように実現されるのでしょうか？

図6　直列のシングル・サインオン

　上で述べた統合認証サーバによる認証情報の変換（図5）は、直列のシングル・サインオンを実現する方法の一種といえるでしょう。しかし、一般の“直列”接続では、後段がWebであるとは限りません。

　例えば“直列”接続の典型的な例として、企業内のWebポータルサイトを構築する場合を考えてみます。ポータル画面上に、各個人の電子メールを読み書きするポートレット（ポータル上で稼働するアプリケーション・コード）を配置する場合、ポータル・サーバの後段にはメールサーバが必要です。メールサーバとの通信にはHTTPではなく、POP3やIMAP4といった専用のプロトコルが用いられます。

　ポートレットは、ポータル・サーバ上で認証されたユーザーのIDを参考にして、後段のサーバで使うためのユーザーIDやパスワードを準備しメールサーバ用のプロトコルを使ってメールサーバにログインすることになります。また、ポータルの後段には、電子メール以外にもさまざまなサービスが登場する可能性があります。従って、Web専用の統合認証サーバの持つ認証情報の変換機能だけでは、一般的な“直列”シングル・サインオンの機能は実現できません。

　ポータルを構築するためのプラットフォームの1つ、IBM WebSphere Portalは、汎用な認証情報変換機能を備えており、変換の対象となるユーザーIDやパスワードなどの認証情報をディレクトリに格納して管理することができます。また、ポートレットのコードからその機能を利用するためのAPIが提供されています。

　これらを用いることによって、認証情報の変換やポートレットからポータル後段のメールサーバへの認証情報の引き渡しといった“直列”シングル・サインオンを行うための複雑な処理を容易にコーディングすることができます（図7）。

図7　ポータル・サーバの認証情報変換機能による“直列”シングル・サインオン

　多くの場合、ポータルに統合されるアプリケーションとポータルには載らないアプリケーションが混在することになるでしょう。従って、“並列”のシングル・サインオンと “直列”のシングル・サインオンはどちらか一方だけが使われるということではなく組み合わせて利用されることになるでしょう（図8）。

図8 “並列”と“直列”のシングル・サインオンの組み合わせ

シングル・サインオンとディレクトリの今後

　最近では、1つの企業内のアプリケーションを統合するだけでなくさまざまな企業のシステムを連携させる、といった取り組みが広く行われるようになってきています。これに伴って、企業内でのシングル・サインオンだけでなく、インターネット上のさまざまな企業のシステム間を連携させるためのシングル・サインオンの技術が必要になってきています。特にWebサービスを成功させるためにはこのような技術が不可欠です。

　インターネット上で認証するアイデアの1つは、ユーザーの認証に必要な情報を1カ所にまとめて置き、認証をその1カ所で行うというものです。本稿で紹介したような統合認証サーバの考え方の応用といえます。しかしその場合、その認証システムを運営する企業・組織があらゆるユーザーから信頼されているということが前提となり、また、ユーザー情報の管理や認証の処理には、極めて高い安全性が求められることになります。　

　 もし外部からの攻撃によって情報の漏えいなどの事故が起これば、そこに参加するインターネット上のあらゆるユーザーが被害に遭うことになってしまうのです。この仕組みは、確かに便利かもしれませんが、ビジネス上の取引などを行ううえで必要な安全性を備えているとは言い難いものです。

　上のアイデアを一歩進めた「フェデレーテッド（連盟された）・アイデンティティ」と呼ばれる考え方があります。これは、インターネット上での企業間（組織間）でのシングル・サインオンを実現しつつユーザー情報の管理の安全性を両立するものです。ユーザーの認証に必要な情報はそのユーザーが所属する企業のシステムが管理します（図9）。

図9　フェデレーテッド・アイデンティティに基づくシングル・サインオン

　ユーザーが、ほかの企業・組織のシステムを利用する際にはそのユーザーの所属する企業のシステムから他方のシステムに、そのユーザーの認証情報が送られます。認証情報は、企業・組織間で構築された信頼関係に基づき、暗号や電子署名を用いた安全な方法で受け渡されます。互いに信頼し合う企業・組織を、「フェデレーション（連盟）」と呼びます。フェデレーションの中では、ユーザーの管理は分散したままでユーザーの認証は透過的に行われ、シングル・サインオンが実現されます。

　異なるベンダの統合認証サーバ同士を結合し、フェデレーテッド・アイデンティティの管理やシングル・サインオンを実現するためにOASISにより標準化されたSAML （Security Assertion Markup Language）V1.0や、Microsoft社のPassportなどの技術が注目されています。これらの技術に対応した統合認証サーバ製品も次々に発表されてきています。

　ただし現在のところ、異なるベンダの統合認証サーバ同士の相互接続性については、実験で確認できているレベルで、広く実用に供されるまでにはまだしばらく時間がかかると思われます。

ディレクトリの混在環境への課題

　ディレクトリとは、あくまでもデータの入れ物であって、それ以上のものではありません。ディレクトリを導入するだけでまるで手品のようにユーザー管理が容易になったり、あるいはシングル・サインオンが可能になるわけではないのです。

　しかし、シングル・サインオンの処理に必要な、ユーザーの認証情報を効率よく管理するためには、ディレクトリの技術、特にLDAPの接続性の良さ・使いやすさはとても重要な役割を果たしています。

　一方で、LDAPは、その使いやすさが災いしてというべきか、LDAPスキーマの非互換性などの問題が発生してしまうことがあります。さまざまな製品が混在する大規模かつ複雑なシステムで1つのLDAPディレクトリにすべてを載せて統合しようとすることは、今日の技術を使う範囲においては、かなり困難な取り組みになりそうです。

　ある程度長期的なメリットを求めてLDAPの技術を機軸にしディレクトリ・インフラストラクチャの完全な統合を検討することはもちろん価値があるでしょう。しかし、その場合においても短期的ないし中期的な視点からは異種のディレクトリが混在する環境を肯定し、そしてそれをうまく管理していくための現実的なソリューションを検討することも重要なのではないでしょうか。

最終回予告 いよいよ最終回の次回は、企業システム全体をどのように管理するかという視点でのディレクトリやユーザー・アイデンティティの統合管理について述べたいと思います。

次回は3月中旬公開の予定です

関連リンク
	連載：ディレクトリ・サービスの仕組と活用

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

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