シングルサインオンとは、

インターネットで使用するアプリは年々増加しユーザーはシステムごとに対してID/パスワードを覚える必要があります。

シングルサインオンは一回システムログインに成功すれば、そのあとは改めてログイン情報を入力しなくてもいいシステムのことを言います。方法としてはシングルサインオンはユーザーが覚えきれないパスワードを管理するために、ユーザーの代わりにパスワードを覚えるか、または覚えるパスワードを少なくするシステムのことをさしています。ただ、アプリケーションによってログインの扱い方は異なるので様々な方式があります。

シングルサインオンの必要性

現在は、インターネットなどではOAuthなどの技術が浸透してきたのでたとえばSNSのアカウントと他のアプリのアカウントをユーザーが自分で統合することで覚えなければいけないID/パスワードの数を減らすことが出来るようになったことが一般的になりました。といってもユーザーはいくつかのパスワードを覚えることは必要になります。

一方企業等においてはインターネットだけでなく、メールなどwebアプリケーションではないものもたくさんあることでしょう。またOAuthのような仕組みがあっても既存のアプリはその仕組みができる前から存在するため簡単にそれを使用することなどできません。

実際には複数のアプリがあっても以下のような対策をしていないでしょうか?

  • IDが登録できる場合できるだけ同じものを使う
  • パスワードは同じものを利用する
  • パスワードは覚えやすいように辞書に載っている単語と数字をベースにして作る

このような対策をされている方が多いと思いますが、それだとあるひとつのサイトからパスワードが流出したとき、他のサイトも悪用される可能性が高くなります。(詳細については あなたの重要なパスワードはなぜ盗まれるか?そしてどうすればいいのかを考える。 を参照してください)

パスワードはアプリケーションごとにパスワードは別にし、できるだけランダムなパスワードを作成したほうがパスワードを盗まれる確率は大幅に下がるようになりますが、そのように運用するとパスワードを覚えることができなくなります。

毎日のように利用しているアプリであればパスワードは覚えられますが、普段使わないアプリだと忘れる可能性が高くなります。

ユーザーが多くのパスワードを覚えていないことによる不具合を修正するようにシングルサインオンは設計されています。

様々な方式のシングルサインオン

パスワードの数を減らす方法については実はいくつかの方式がありますが、大きく分けて二つのアプローチが一般的です。

  1. ユーザーの代わりにID/パスワードを入力する方法
  2. 認証方式を登録する方法

どちらも一長一短があります。1の方法はユーザーはとりあえず覚えるのは一つのパスワードだけになりユーザーの利便性は上がります。対象となるアプリは何も手を加える必要があり導入は楽です。

2の方法の利点としては認証システムが一つになるためユーザーだけでなく管理者にとっても管理が楽になります。しかしながらアプリケーションがその認証システムに対応する必要があり、古くから使われているシステムには何らかの手を加えないかぎり適応しないので導入が難しい場合があります。

このあたりの詳細については シングルサインオンの仕組みについて (基本編) にも書いたのでぜひ参考にしてみたください。

ユーザーの代わりにログイン情報を入力

Webリバースプロキシー方式

Webアプリケーションの前にリバースプロキシーを配置します。シングルサインオンシステムにログインした後リバースプロキシー経由でシステムを利用するとWebアプリケーションに対してID/パスワードなどのログイン情報を負荷してリクエストします。その結果ユーザーはシングルサインオン用のパスワードのみ覚えるだけですみます。実際に運用するパスワード数は減らない代わりに対象アプリの改修も必要が無いのでエージェント方式ほど導入時にはたいした工事は必要ありません。

エンタープライズシングルサインオン

この方式では端末にクライアントをインストールする必要があります。

クライアントは定期的に画面の動作をチェックしており学習したログイン画面、パスワード変更画面を検知したときにそれにあわせてID/パスワードをユーザーのかわりに入力します。クライアントを各端末に入れる手間はありますが、対象アプリケーションに変更がまったくいらないため導入はもっとも容易な方法の一つです。弊社では エンタープライズシングルサインオン AccessMatrix™ Universal Sign-On (USO) を扱っております。

端末にクライアントを導入するのは敷居が高いですが、Web以外のアプリケーションにも対応できるためWebリバースプロキシー方式よりも適応範囲が広くなることが大きな利点になります。

認証方式を統一する方法

Windows Active Directory/ LDAP 方式

認証方式にWindows Active Directory/ LDAPを導入した場合、アプリケーションがそれらの認証方式に対応していればログイン後、各アプリケーションはID/ パスワード入力をすることなく利用することが可能になります。Windows の場合はNTML認証と呼ばれることもあります。また、Web以外のアプリケーションにも対応しています。

エージェント/Webポータル/WebAPI方式

ポートレットに代表されるように対象のアプリケーションに必要なAPIなどを組み込むことにより、Webポータルのログイン後は各アプリケーションにID/パスワード入力が不要になります

Javaポートレットが広く知られていますが、WEBシングルサインオン用のエージェントを組み込む方法もあります。対象アプリに対してエージェントを組み込むなどの工事が必要となります。

また最近WebアプリだとOAuth, OpenID, SAMLのような仕組みを一般的になるコンシューマーでも利用されるようになってきているので一般に人でも利用していることが多いと思います。

エージェントを組み込むのはWebだけでなくWindowsアプリでも利用することが可能になります。

どの方式がベストか?

企業ユースであるならばWindowsのActive Directoryで認証方式を統一することがベストだと考えます。しかしながらAD利用の一番の課題は対象となるアプリケーションサーバーがAD認証に対応することが前提になります。

古くからあるアプリケーションの多くはAD認証を意識しておらず対応するには、ソフトをアップグレードするかもしくはリプレイスが必要となるため、莫大な費用が掛かります。

そのようなニーズにマッチするのが「エンタープライズシングルサインオン」になります。他の方式はWebにしか対応できませんが、画面遷移を認識してユーザーの代わりにログイン作業を行うため、あらゆるアプリケーションに対応できること、アプリケーション側を変更することなど余計な作業は必要としないからです。

今までの経験から言うとAD + 「エンタープライズシングルサインオン」がベストの組み合わせになります。新規のアプリケーションはADに合わせて開発導入し、既存のアプリケーションやどうしてもADに対応できないアプリケーションは「エンタープライズシングルサインオン」することをお薦めしています。

実際に、大規模エンタープライズでこのように使われているお客様もおります。導入をお考えのお客様がいればお気軽にお問い合わせください。

関連ページ