デジタル技術の発展に伴い、ビジネスシーンでクラウドサービスを利用することが多くなりました。多くのユーザーは、これに加えて社内システムを使いこなして日々の業務を遂行しています。そして、ビジネスパーソンの多くはシステムにログインするために複数のIDとパスワードを管理することに疲弊しているのではないでしょうか。
Webサービス・社内システムごとに異なるパスワードを設定することも多く、パスワードを忘れてしまった場合には、都度再設定したりという経験もあるでしょう。ユーザーにとってみればシステムごとに設定するパスワードに多くのストレスを抱えていることでしょうし、システム管理者にとってみれば複数に散財するパスワード管理や権限管理が複雑になります。
こうした問題を解消するための仕組み・技術が「シングルサインオン（Single Signe On：SSO）」です。本記事では、知っているようで意外と知らない、シングルサインオンの仕組みや種類についてご紹介します。
シングルサインオンとは？
Webサービスや社内システムにアクセスするためのパスワードは、いわば家に入るため、自動車に乗るため、オフィスのロッカーを開けるため、スマートフォンにアクセスするための鍵と言えます。通常、鍵はそれぞれに合わせて作られるものであり、使い分けなければいけません。Webサービスや社内システムにおいても同様です。
ただし、Webサービスや社内システムが物理的な鍵と異なる点は、まったく同じ鍵を作成できることです。すべてのWebサービスや社内システムに同一のパスワードを作成するのは大変便利ですが、それでは漏えいによって悪用されるリスクが非常に高くなってしまいます。事実、複数のWebサービス等で同じパスワードを作成し、あるWebサービスで漏えいしたことから全体的に影響を及ぼす事件が少なくありません。
そうした複数の異なるパスワードを簡単に管理するための技術・仕組みがシングルサインオンです。Webサービスやシステムごとに異なるパスワードを設定しつつ、1つのパスワードさえ覚えておけば多数のWebサービス等にアクセスできます。
シングルサインオンの仕組み
具体的にシングルサインオンを実装するための仕組みをご紹介します。シングルサインオンの仕組みは大きく分けて4つ。「エージェント方式」「リバースプロキシ方式」「代理認証方式」「フェデレーション方式」です。
1. エージェント方式
Webアプリケーションサーバーに対して、認証を代行するエージェントモジュールを組み込む方式となります。Webサービス等にアクセスするためのリクエストはWebサーバーが受け取り、組み込まれたエージェントモジュールがシングルサインオンサーバーにユーザーのログイン状態とアクセス権限を問い合わせ、認証状態を確認することにより、シングルサインオンを実現できます。
2. リバースプロキシ方式
Webアプリケーションサーバーとブラウザの間にリバースプロキシサーバーを設置し、すべての連携先サーバーへのアクセスがリバースプロキシサーバー経由になります。サーバーに一度アクセスすると、認証済みのCookie情報が発行されて、それを提示すれば後はリバースプロキシサーバーが連携先サーバーへ認証情報を送ってくれるため、パスワードを複数入力することなくログイン状態が保持されます。
3. 代理認証方式
ログイン対象となるWebサービスや社内システムに対して、ユーザーの代わりにIDとパスワードを送信してアクセスすることでシングルサインオンを実現できる方式です。古い社内システムを利用している場合、シングルサインオンを実現するための修正対応ができない場合があります。そのような場合に対応するための方式として使われています。ただし、社内システム等で管理しているIDとパスワードが、アクセス管理システムなどが管理しているIDとパスワードが完全に同期されている必要があるため、社内システム側が対応できない可能性があります。
4. フェデレーション方式
パスワードに代わりにチケットと呼ばれる情報を受け渡し、Webサービス間でシングルサインオンを可能にする方法です。Office 365やBoxなど、海外Webサービスの多くが対応しているため、Webサービス間のシングルサインオン実装に使われています。フェデレーション方式は標準化が進められており、SAML（Security Assertion Markup Language）やOpen ID Connectが主流になっています。
SAMLとは？
フェデレーション方式以外のシングルサインオンには大きく2つの課題があります。1つ目は、連携先サーバーが自ドメイン（1企業内）に限られることです。Office 365やBoxのようなWebサービスを、社内に構築した認証サーバー（Active DirectoryやLDAPなど）で認証させるようなことは、セキュリティ上の理由から避けるケースが大半です（Cookie情報を外部ドメインのWebサーバーに送信しないよう制限するため）。
しかし、昨今はWebサービスの利用シーンが拡大し、社内システムと混在しているビジネス環境が多くなったことからシームレスな連携が求められています。そこで、異なるドメイン間でのシングルサインオンへの需要が高まりました。
そして2つ目の課題は、規格化が進んでいないことによる適合の不確実性です。エージェント方式では社内システムの認証モジュールのカスタマイズ可否が不明確であり、リバースプロキシ方式では動的なリンク・ディレクトリ構成に対応できるか否かが不明確です。
これらの課題解決策として登場した規格がSAMLです。SAMLの主要コンポーネントはIdP（ID Provider）とSP（Service Provider）です。IdPとは、ユーザーの認証成功後にAssertion（認証ユーザーとその属性・属性値、期限情報、発行IdPとその署名などから構成されるトークン）を発行するサーバーのことです。一方、SPとはログイン後に見せるWebコンテンツを保持しているWebサーバーのことであり、認証方式がSAMLに対応したものを指します。有効なAssertionを提示された場合、そのユーザーに対して適したコンテンツを閲覧させます。
Microsoft Azureとは何か？入門から応用まで徹底解説
シングルサインオンのメリット
シングルサインオンのメリットはユーザーの利便性向上とセキュリティの強化です。複数のWebサービスは社内システムを使用している環境においても、たった1つのIDとパスワードさえ覚えておけばよく、かつ1回の認証作業ですべてのWebサービス等にアクセスできます。さらに、パスワード管理の複雑性を排除できることから複雑かつユニークなパスワードを設定できるため、パスワード管理によるセキュリティの強化が実現できます。IT管理者としても「パスワードを忘れてしまったから再設定して欲しい」「ログインできない」などの問い合わせ件数が減少するので、業務効率が大幅に向上します。
シングルサインオンを実装するための方法はいろいろと用意されています。そして、マイクロソフトが提供するAzure Active Directoryは、それぞれの方法でシングルサインオンを実装することが可能です。ユーザーの利便性向上と組織全体のセキュリティ強化のために、ぜひ自社におけるシングルサインオン実装を検討してみてはいかがでしょうか。
