シングルサインオンの仕組みについて （基本編）

シングルサインオンといっても手法がさまざまあるので一口に言ってもわかりにくいと思うのでこれを機会に説明を行いたいと思う。

シングルサインオンはかなり歴史がある分野なのであるが、その分さまざまな手法があり一概にシングルサインオンといっても多くの人に理解されていないのではないだろうかと考えている。

弊社ではシングルサインオンの製品を結構前からあつかっており、いくつかの事例がある。

弊社の長年の経験から申し上げれば、弊社で扱っているAccessMatrix™ Universal Sign-On (USO)が採用している代行入力型シングルサインオン製品の導入を推薦する。

理由は、既存の環境を全く変えることなく導入ができ導入コストが他の方式と比較して大幅に安価であるからだ。

以下にシングルサインオン製品のの基本的な考え方について説明する。

シングルサインオンはなぜ必要か？

そもそもシングルサインオンはなぜ必要なのだろうか

理由は非常に簡単でいろいろなサービスでそれぞれ異なるIDとパスワードを登録するが、一つであれば問題がないが、数が増えるととてもじゃないけど管理しきれなくなるからだ。

パスワードをメモで残す危険性

パスワードが覚えきれない場合、対応方法としては以下の2点がある。

• 複数サイトで使っているパスワードの使いまわし
• オープンな場所でパスワードをメモしておくこと

個人宅ならともかく企業内ではパスワード漏えいのリスクが格段に高まるので、このようなパスワード運用はお勧めしない。しかしながら、このような対応をしない限りパスワードを覚えれないのでろくにシステムにログインができなくなる可能性が高くなる。

パスワードロックの恐怖

いままでパスワードを何回か入れているうちにシステムが使えなくなったことはないだろうか？

そうなると再度利用できるまでに時間がかかるので人間の代わりにパスワードを覚えてくれるかそもそも複数のパスワードが必要がない仕組みが必要になる。

シングルサインオンの仕組み

シングルサインオンの仕組みにはいろいろあるが、大雑把に分けると２種類である。またさらにそれに対していろいろな手法がありさまざまな言い方で各ベンダーがいっているのでさらにわかりにくくなっていると思う。

ひとつの方法とはユーザーの代わりにパスワードを入力してくれるものである。ここでは便宜上、代行入力方式という。

もうひとつの方法とはシステムにアクセスをしたときに、指定された認証サービスで認証が終わっていればそのシステムへのアクセスが可能になるものである。ここでは便宜上、信頼認証方式という。

代行入力型の例

代行入力型で一番広く利用されている方法といえば、IE/ Firefox/ Chromeなどのブラウザーでユーザーの代わりにパスワードを記憶してログイン画面が出てくるときにブラウザーが人間の代わりにID/パスワードを入力するのは多くの人が知っていると思う。

ブラウザーに限らずいろいろなアプリに対応している製品もあると思うが、弊社で扱っているAccessMatrix USOの場合は、それだけにとどまらずサーバーを利用するタイプである。

サーバーで利用者の各アプリケーションのパスワードが登録してあるだけでなく、管理者がユーザーごとに利用できるアプリケーションの登録ができるためである。USOのようなシングルサインオン製品はエンタープライズシングルサインオンといわれることもある。

もうひとつの代表的な例で言えばリバースプロキシーを利用したシングルサインオンも代理入力型といえるだろう。

サーバーとクライアントの間にプロキシーをおくが、プロキシーのほうでログイン画面を検知してそれに対してログイン情報を入れていくものである。

これらの手法は対象となるアプリケーションに手を加える必要がないことであり、導入までの時間はそれほどかからないのが特長である。

エンタープライズシングルサインオンはクライアントアプリをインストールする必要があるがブラウザーに限らずいろいろなデスクトップアプリをはじめターミナルエミュレーターなど多くのアプリケーションで利用できることが利点としてあげられる。

一方リバースプロキシーは基本的にはブラウザーだけだがクライアントソフトをインストールする必要がないのと、いろいろなOSでも動作する可能性が高いことが利点としてあげられるだろう。

また、最近だと特権アカウント管理にもシングルサインオンを使うことが増えてきた。エンタープライズシングルサインオンでは利用端末のクライアントソフトを使うが、特権アカウントの場合リモートデスクトップサービスを経由してシングルサインオンを実現する。詳しくは下記リンクを確認ください。

危険なパスワードを見せない ～ 特権アカウントシングルサインオン

信頼認証方式

Google, Facebook, Twitterを利用しているとそのほかのサービスを利用するときにあらためてユーザーIDを登録せずに利用できるようになることがある。OpenIDなどの規格により実現しており、すでに多くの人が利用しているだろう。

また企業ユーザーであればWindows のADの認証でログインした端末からはわざわざログイン情報を入れなくてもシステムが利用できることは経験された方も多いと思う。（ただし、ログイン情報を入れなくていいので多くの人はその仕組みについては気づいていないと思う）

これらの方法は代行入力型と比較すると運用は楽である。ただし、対象アプリケーションがすべてマスターとなる認証システムに対応する必要がある。

たとえばFacebookを利用していてもすべてのアプリをFacebook IDで運用するのは現実的には難しい。というのもすべてのアプリがFacebookの認証方式に対応する必要があるからだ。

企業ユースでも昔からこの方式はあるが、対象となるアプリケーションにその仕組みを入れる必要があり、新規のアプリなら問題はないが既存のものであればその改修に手間取り、思ったように普及しなかったことも事実としてある。

また、クラウド利用が一般的になりつつあるが、OpenIDのような仕組みがあっても企業ユーザーはその方式を採用せず結局別IDの管理をするような気がする。というのもクラウドの採用を決める人とADなどのマスターIDを管理している担当者は別々であり、それを統合するのは技術的な話しだけでなくいろいろと調整する必要がでてくるからだ。

代行入力型は当面残る

コンシューマーはたぶんブラウザーによるパスワードの代行入力＋OpenIDのような仕組みに集約されるだろう。

エンタープライズでは、導入するさまざまなシステムごとに担当者が違うのでなかなかID統合すら難しいという現実があり、AD認証、OpenIDなどの方式に統一するのが理想的とは思われているが、エンタープライズシングルサインオンやリバースプロキシーに代表される代行入力型シングルサインオンはこれからもずっと残るのは間違いないだろう。

最後に

シングルサインオンについてはそれこそ２０年前から存在しているが、その時代や方式によって説明のしかたがまちまちで普通の人には理解ができないだろうと思っていました。

この記事では極力技術的には深い話しはせずにシングルサインオンの技術に興味を持っていただけるように書いたつもりである。

AccessMatrix USO関連

シングルサインオン関連

パスワード関係