シングルサインオン(Single Sign On)の仕組みとSSOサーバの役割

あまり良く分かっていなかったシングルサインオン(以下SSO)についてのまとめ。
そもそもSSOとは、IT用語辞典によると

ユーザが一度認証を受けるだけで、許可されているすべての機能を利用できるようになるシステム。

のことだ。つまり、

図1のようにアプリが1つの場合には不要である。また

図2のようにアプリが複数でも認証情報(Session)を共有する場合には、SSOサーバは必要ない。各アプリの依存度が高い場合や、負荷分散のための複数プロセス構成のケースではこれで充分。そもそもRailsを使うのならSessionの内容はCookieのなかだし（デフォルトでは）。

独立性の高い各アプリの間で認証情報を共有したい場合にSSOサーバは初めて有効となる。

ここで認証画面を各アプリで持つことも可能であるが、SSOサーバに任せた方が実装の手間も省けるし、セキュリティ的にもパスワードを取得するサーバが一箇所ですむので安全だ。
注意すべきは（というか私がよくわかっていなくてもやもやしていたのは）、認証の処理自体を行うのはSSOサーバのみだが、その認証状態を保持するのはWebアプリとSSOサーバの両方だと言うこと。たとえば、あるWebアプリからSSOサーバを通して認証を行ったとする。

まずSSOサーバは認証状態を保持していなければならない。そうでないと、別のアプリから要求があったときに再度ユーザにパスワードを要求しなきゃいけなくなり、シングルサインオンの要件を満たすことができない。
また、Webアプリ側でも認証状態は保持するべきである。ユーザからの要求ごとにSSOサーバに問い合わせを行うのでは、パフォーマンスが低下するし煩わしい。ここでWebアプリが認証状態を保持するのにはなんら特別な技術を必要としない。最初の問い合わせでSSOサーバからOKが出た段階で、ユーザ向けに自前のSession管理機構で新しいSessionIDを振ってやればよいだけだ。

このSession保持についての仕組みが、下手な記事だとあまりよくわからず書かれているし、良く分かってる人はこんなの当たり前の大前提で話しているしで、概念をつかむのに苦労したところであった。

さて、上記をまとめるとSSOサーバが持つべき主な機能は

Webアプリからの認証状態問い合わせに対する応答機能
ユーザに対する認証機能
Session保持機能
WebアプリからのValidation要求への応答機能

というところ。

また、Webアプリ側がSSOのために新たに実装すべき主な機能は

Webアプリで未認証のユーザについてSSOサーバへ認証状態の問い合わせ機能
WebアプリでもSSOサーバでも認証状態にないユーザからのリクエストをSSOサーバにリダイレクトする機能
SSOサーバから認証を受けてリダイレクトされた際のValidation問い合わせ機能

といったところである。

パッケージとしてSSOをサポートしたい場合、SSOサーバの受け口にあわせなければいけないのだが、私には現在の標準仕様がまだ見えていないので、CASに対応するのかSAMLに対応するのか、あるいはOpenSSOやRubyCAS等の具体的なアプリケーションに対応すればよいのかがさっぱりわからない。全てに対応するのはリソース的に論外だ。

とりあえずruby_hankanでは認証部分の機能を入れ替え可能にしておくにとどめ、具体的な対応は後回しにしたいと思います。

（2008/12/19 追記）
上記の説明はエージェント型の仕組みを想定しています。

エージェント型の仕組みを実現するためには、Webアプリ側でSSOエージェントモジュールを組み込む必要があります。SSOサーバとSSOエージェントはセットとなって初めて機能します。RubyアプリからSSOサーバを利用するためには、Ruby用のSSOエージェントモジュールが提供されている必要があります。
他のサイトさんの説明図を見ると、本稿で「SSOサーバ」と表現しているものは単に「認証サーバ」と表記されているケースが多いようです。それでも間違いではないと思うのですが、上で書いたとおりSessionの保持やVailidation機能を持つ必要があるものを単に「認証サーバ」と呼ぶのは個人的には違和感があります。図にすると

と言うイメージです。