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

弊社が扱っているUSOではWebポータルやWebSSOシステムを使うために使用される認証をマスターにして利用することが可能である。

USO/ Webログイン統合

ただUSO自体はwebssoの機能が持たないのであるが、上のページではwebssoをキーワードにして訪問される方も結構いらっしゃるようなのでこちらのほうで非常に簡単ではあるが説明してみたいと思う。

webssoも大きく分けて２種類しかない

webssoとはwebアプリケーションに特化したシングルサインオンシステムのことを指す。シングルサインオンといえばwebssoシステムを指している場合も多い。

シングルサインオンの仕組みについて （基本編）でも説明したとおりwebssoでもざっくりといえば、ユーザーの代わりにパスワードを入力する方法がひとつ、またユーザーが認証したサーバーを信用した場合ログインを許可するといった方式がある。

リバースプロキシー方式

webssoでユーザーの代わりにパスワードを入力する方法といえば、リバースプロキシー方式がある。

利用者から見て透過的に見えるリバースプロキシーでユーザーのIDとパスワードを入れる方式である。この方法は実装は既存のwebサーバーに手を入れる必要がないので簡単であるがアクセスがリバースプロキシーに集中することもあり、大規模のサイトであればパフォーマンス的に問題がある場合があると指摘されている方法である。

認証サーバーとの信頼関係ベース

リバースプロキシーの方式は実装が簡単な反面規模的なところに不安がある点とこの方式だとユーザーが意識するかどうかは別にしてもシングルサインオンと対象アプリごとにIDとパスワードを入力する必要がある。

そこで考えられたのが認証サーバーと対象となるwebサーバーが「信頼関係」を結び、認証サーバーとユーザーの間の認証がされていれば認証が終わるといった方式である。

この方式の場合、歴史があるのでいろいろな方式がある。JavaであればJava Portlet（JSR-168,268)などがある。また、最近だとSAML, OAuth, OpenIDなどの認証連携（フェデレーション）方式も一般的になっている。

上の図はwordpressからgoogle+のアカウントを連携させようとしたときの様子である。このように信頼関係を結ぶことのより毎回認証しなくても連携できるようになっている。

さまざまなインターネットアプリを利用している方はこのような図を何回か見たことがある方もいるのではないだろうか？

これらの標準化された方式とは別にwebssoベンダーが提供するエージェントをアプリケーションに入れる方法もある。

この方式は実装は何らかの方式に対応する必要がありリバースプロキシーよりも難しい部分がある。新規に入れる場合は標準的な方式が採用されているものを選べばいい。

しかし企業で導入を考える場合すべてのアプリをシングルサインオンをするために新規に導入することは考えられないためなんらかの方法で対応することが必要とされる。

この文章の冒頭で挙げた弊社の事例としては「USO/ Webログイン統合」のようにWebSSOでは対応が難しい部分をエンタープライズシングルサインオンで対応する方法になる。

WebSSOとエンタープライズシングルサインオンの組み合わせは世界中で実績がある。

AccessMatrix USO関連

シングルサインオン関連

パスワード関係