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

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

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

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

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

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

利用は簡単でいろいろなサービスでそれぞれIDとパスワードを登録することが必要なのであるが、その数が3つまでならなんてことはないが、数が増えるととてもじゃないけど管理しきれなくなるからだ。

odoroita3

いままでパスワードを何回か入れているうちにシステムが使えなくなったことはないだろうか?そうなると再度利用できるまでに時間がかかるので人間の代わりにパスワードを覚えてくれるかそもそも複数のパスワードが必要がない仕組みが必要になる。

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

シングルサインオンの仕組みにはいろいろあるが、大雑把に分けると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などの方式に統一するのが理想的とは思われているが、エンタープライズシングルサインオンやリバースプロキシーに代表される代行入力型シングルサインオンはこれからもずっと残るのは間違いないだろう。

最後に

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

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