idnetworks

関連項目

シングルサインオンの仕組みについて (基本編)  シングルサインオンの仕組みについて (WEBSSO編)
 パスワード管理とシングルサインオンについて

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

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

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

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

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

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

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

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

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

シングルサインオンはユーザーが覚えきれないパスワードを管理するために、ユーザーの代わりにパスワードを覚えるか、または覚えるパスワードを少なくするシステムのことをさしています。

実はいろいろな仕組みがあるシングルサインオン

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

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

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

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

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

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

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

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

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

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

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

認証方式を統一する方法

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アプリでも利用することが可能になります。

どちらの方式がいいか?

パスワードをユーザーの代わりに入力してくれるタイプのほうは対象となるアプリケーションを改修したりする必要がないので導入時間は短くできます。ただしID統合といった方法ではないのでプロビジョニングとかフェデレーションという概念からはちょっと離れています。

一方認証システムを統一する方法は扱うIDとパスワードが少なくなるため、ID統合と組み合わせの導入になるとは思うのですが、対象アプリに手を入れる必要があるためいきなりすべてのアプリに対して適応するのは現実的ではないといわれています。

混在導入が一般的

一昔前まではどちらの方式がいいか検討されることも多かったが、最近ではどちらの方式にも一長一短があるためお互いを組み合わせて利用することが一般的になっています。たとえば AccessMatrix™ Universal Sign-On (USO)  の場合規模が大きくなるほど、Windows Active Directory, プロビジョニングシステムとの連携の事例が多くなります。

この傾向は最近だと一般的になされている方法なので導入の機会があったときにはどちらがいいかではなくどのように使うのが効率的かを考えていただければと思います。