なぜ「シングルサインオン」が必要なのか？
企業でのWebサービスの実現が具体的になるにつれ、パスワード／IDマネジメントが重視されるようになり、「シングル・サインオン」がますます注目を集めている。この連載では、シングル・サインオンの実践ステップなど具体的な考え方を紹介する。また、メタディレクトリやLDAPなど「ディレクトリ統合」をキーワードとしてシングル・サインオンを実現するための技術を分かりやすく解説する。（編集部）
シングル・サインオンとは何か
現在、多くの企業の情報システムは、多種多様なプラットフォームを組み合わせて利用しています。そして、それらのプラットフォーム上では多種多様なアプリケーションが動作しています。
通常、ユーザーはクライアントPC上のOSや各アプリケーションに対して、ログインの手続きを行ったうえでそれらを使用します。ユーザーは自分自身を識別するための情報（例えばユーザーIDとパスワードの組み合わせ）を提示し、システムはその情報が正しいことを確認してユーザーを「認証」します。
システムが複雑になりアプリケーションの種類が多くなると、認証手続きの回数が増えて、ユーザーの手間が増えていきます。また、ユーザーが管理するIDやパスワードの数が増えてくると、それらを覚えておくのがだんだん難しくなってきます。高いセキュリティを必要とするアプリケーションに対しては、厳格なパスワード規則が設定されていて、定期的にパスワードを変更しなくてはならない、ということもあるでしょう。
IDやパスワードの管理が複雑になると、ユーザーはやむを得ず、それらを手帳やメモなどに書き留めておかなくてはなりません。しかし、セキュリティを確保するうえで、パスワードのメモは好ましくありません。セキュリティを高めるためには、IDやパスワードを厳格に管理することは重要ですが、必要以上にユーザーの負担を重くすると逆効果になってしまう場合があります。
このような悩みを解決するには、ユーザーに必要以上の負担を掛けないようにしながら、必要かつ十分な安全性を持つ認証を行うための仕組みを導入することが効果的です。
1回の認証手続きで、複数のOSやアプリケーションなどにアクセスできること（またはそれを実現するための機能）を「シングル・サインオン（Single Sign-On）」と呼びます。
シングル・サインオンによってユーザーは複数のIDやパスワードを覚えておく負担から解放されます。パスワードを1つ覚えておくだけで、厳格なパスワード管理も現実的なものとなり、より高いセキュリティを実現することが可能になります。
また、システム管理者やアプリケーションの開発者は、パスワードなど認証情報の管理を一元化することによって、複数の認証情報を管理したりアプリケーションごとに認証機能を開発したりする負担から解放されます。
シングル・サインオンの3大要件
- 利用者の負担の軽減（認証を簡単に）
- より安全な認証機能の実現（認証を厳密に）
- システム管理者やアプリケーション開発者の負担の軽減（認証を共通に）
シングル・サインオン実現のステップ
では早速、シングル・サインオンを実現するための「ステップ」に入りましょう。例えば、複数のアプリケーションそれぞれが独立した認証情報を持っている構成のシステム（図1）があるとします。このようなシステムに対して、シングル・サインオンの考え方を適用する場合に、どのような手順で検討を進めていくべきでしょうか。
図1 シングル・サインオン以前。アプリケーションごとにログイン手続きが必要第1のステップ
ユーザーID／パスワード統一
シングル・サインオンの実現に取り組む際、最初に検討すべきステップは何でしょうか？ まずは、ユーザーの持つ複数IDとパスワードをそれぞれ統一することが一般的です。
しかし、このステップを実現してもログイン手続きの回数が減るわけではないので、厳密には「シングル・サインオン」と呼ぶべきではないものかもしれません。それでもユーザーの負担は確実に改善され、1つのIDとパスワードを覚えておくだけで複数のアプリケーションにアクセスできるようになります。また、ID／パスワードの管理を単純化することによって、管理者や開発者の負担も軽減されます。「シングル・サインオン」に対する要件のかなりの部分はこのステップで実現できるといえます。
このステップを実現するためには、複数のアプリケーションから利用されるIDやパスワードなどの認証情報を、1つのデータベース（またはディレクトリ）上にまとめる、といった方法を取ることができます。あるいは、データベースを1個にまとめることが難しい場合には、複数の認証情報データベースを相互に連携させて同期を取るのも1つの手法です。
最近では、認証情報を格納するために「ディレクトリ」と呼ばれる技術を用いるケースが増えています。ディレクトリとは一種のデータベースであり、ユーザーのID、パスワード、その他の属性情報などを管理することに向いています。ディレクトリにアクセスするための通信プロトコルの標準の1つとして、LDAP（Lightweight Directory Access Protocol）が広く知られています。統合しようとする各アプリケーションが“LDAP対応”であれば、認証情報の統合は比較的容易に実現できる可能性があります。
図2 ステップ1完了後。複数のアプリケーションの認証情報を１箇所で管理第2のステップ
認証インターフェイスの統合
シングル・サインオンの第2のステップは、複数のアプリケーションの認証インターフェイス（ユーザーIDやパスワードなどの受け渡し方法）を統合することです。このステップを実現すると、ユーザーが最初に1度だけユーザーID／パスワードを入力すれば、後はログインの手続きを一切行わずに複数のアプリケーションにアクセスできるようになります。
しかし、ここでアプリケーションごとに認証のためのインターフェイスが異なることに注意しなくてはなりません。アプリケーションの認証の統合には、さまざまなテクニックが必要とされます。
最近では、多くのアプリケーションがWebブラウザを介して利用されるようになっているので、Webアプリケーションの範囲に限定すればそれほど難しいことではなくなってきています。
認証の統合の検討で最も気を付けなくてはならないことは、統合された認証機能にセキュリティ上の問題があると、さまざまなアプリケーションに対してセキュリティの危険が及んでしまうことです。
統合された認証は、単に利用者の負担を取り除けばよいというものではありません。不正な利用者による「なりすまし」やパスワードの盗難などを防ぐために、十分に安全なセキュリティを施さなくてはなりません。一般に、統合された認証の機能に対しては、統合前の認証よりも高いセキュリティが求められるようになるといえます。
図3 ステップ2完了後。複数のアプリケーションの認証インターフェイスを統合第3のステップ
アクセス制御の統合
「第2のステップ」の実現によって、ユーザーは1回の認証で以前より多くのアプリケーションにアクセスできるようになります。ただし、各アプリケーションに対するアクセス制御がきちんと行われていないと、本来権限を持つべきでないユーザーがアプリケーションを利用できてしまう、といったトラブルが発生しかねません。
シングル・サインオンを実現する際には、各アプリケーションによるアクセスの管理をより適切に行えるよう、アクセス制御に関する基盤機能を整備しておくことも重要です。
管理者や開発者の手間から見ると、アクセス制御を行うための機能は企業システム内で共通化されていることが望ましいといえます。しかし、アクセス制御を行うに当たっては、ユーザーの認証と異なり各アプリケーション固有の要件があることも多いため、基盤の共通化と管理の分散化を両立できるように機能を設計するのがよいでしょう。
アプリケーション単位のアクセス制御の方法としては、ユーザーIDごとにリソースへのアクセスの可否を制御するといった処理のほかに、ログインセッションのタイムアウトを厳密に管理する処理（例えば、ユーザーが5分間何も操作しなければ、いったんそのログインセッションを停止し、再度のアクセスに対しては、あらためてログインを求める）があります。
あるいは、特にセキュリティ機能の高いアプリケーションに対してはアクセスするたびに必ず再度の認証を求める、といった処理が必要になるかもしれません。このように高度なセッション管理を行う場合には、アクセス制御の機能と統合認証の機能が連携して動作するように設計を行わなくてはなりません。
図4 ステップ3完了後。認証情報とアクセス制御情報を統合して、より高度なアクセス管理を実現シングル・サインオン実現のパターン
〜直列／並列〜
簡単に、シングル・サインオン実現の3ステップを見てきました。ここで、アプリケーションの並び方に注目してみましょう。これまで参照してきたのは、すべて「並列」に並んだアプリケーションに対する認証を統合する場合のシナリオでした。
図5 「並列」認証統合多くの業務システムでは、複数のアプリケーションが「並列」に並ぶだけでなく、「直列」に並んでいることもあります。「直列」接続のアプリケーション間の認証を統合することも、シングル・サインオンの重要な要素です。
図6 「直列」認証統合例えば、ユーザーがアクセスするWebアプリケーションがあり、その背後に、メインフレームで構築された基幹システム資源があるとします。このような場合には、Webアプリケーション上の認証と、メインフレーム上のアプリケーションに対する認証を、何らかの方法で統合する必要があります。
「直列」接続された、複数のアプリケーション間で、1つのユーザーID／パスワードに統合した体系にできれば、それが望ましいのはいうまでもありませんが、既存の業務システムを流用している場合などは、ID体系の変更が事実上不可能であることも多いでしょう。そのような場合には、ユーザーID／パスワードを変換するためのテーブルなどを用意してID体系の違いを吸収します。
ほかのシングル・サインオンの機能と同様に、「直列」接続の統合に関するユーザーID／パスワードの変換を行う機能についても、企業システムの基盤機能としての共通化を検討すべきでしょう。それによって、システム管理者やアプリケーション開発者の負担を軽減できます。
また、アプリケーション間の統合だけでなく、ユーザーが使用するクライアントOSとアプリケーションの認証の統合が必要になる場合もあるでしょう。この場合には、アプリケーションの認証情報と、OSの認証情報の管理とを統合することになります。
ここまで述べたように、一口に「シングル・サインオン」といっても、その実現にはさまざまなパターンがあります。そして、シングル・サインオンを実現するためにはさまざまな技術や製品を組み合わせて利用することになります。
次回予告
次回は、シングル・サインオンを行ううえで非常に重要な役割を果たすディレクトリの技術について、LDAPというキーワードを中心に解説します。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。