OpenSSO の技術概要からわかること
(Translate to English)Friday Sep 09, 2005
以前からアナウンスされていた通り, 先週 OpenSSO のシステム・アーキテクチャとユースケースの概要がリリースされた.
The high-level System Architecture and Use Cases documents for OpenSSO project are now available in the documents section of the project web site.
Availability of Architecture and Use-Case Documents
Sun Java System Access Manager (SJS AM) という商用製品をどういったかたちで再パッケージし公開していくのかは個人的にも興味があったのだけど, 今回出てきた文書を斜め読みした感じでは, どうやら SJS AM の Web シングル・サインオンのコア実装をそっくりそのまま世界にシェアするつもりっぽい.
System Architecture の 3.6 Service Client View に加筆してみた.
一般的な処理フローはこんな感じ:
- ユーザはまず OpenSSO の認証サービスにアクセスし認証をうける.
認証に成功した場合, OpenSSO のセッション・サービスがユーザのログイン・セッションを生成する.
セッション・サービスはログイン・セッションに紐づくトークンを生成し, 認証サービスがそれをユーザに返却する. - ユーザは認証済みの状態で Web コンテンツにアクセスを試みる. このときユーザはトークンを (典型的には Cookie や URL パラメータのようなかたちで) 提示する.
- Web アプリケーション, あるいは Web アプリケーションを保護する
SSO エージェントは, ユーザのリクエストからトークンを取り出す.
そして, それに紐づくユーザのログイン・セッションをクライアント・ライブラリのセッション・クライアントに確認する. - セッション・クライアントはユーザのログイン・セッションの確認を行なうにあたり, いきなりセッション・サービスに問い合わせるのではなく, まずネーミング・クライアントにセッション・サービスの場所を問い合わせる.
- ネーミング・クライアントは OpenSSO のネーミング・サービスに, そのユーザのログイン・セッションを管理しているセッション・サービスの場所を問い合わせる.
- ネーミング・クライアントから得た当該セッション・サービスに対し, セッション・クライアントはユーザのログイン・セッションのステートを問い合わせる.
- セッション・クライアントは取得したユーザのログイン・セッションのステートをセッション・キャッシュとしてクライアント・ライブラリに格納する.
このキャッシュはクライアント・ライブラリ内のセッション・ポーラーからのポーリング (P1 / P2), もしくは OpenSSO のセッション・サービスからの通知 (N1 / N2) により更新される. - ログイン・セッションのステートの確認後, Web アプリケーション, あるいは Web アプリケーションを保護する SSO エージェントは, アクセスを認可しユーザのリクエストを Web コンテンツに送る.
ということで OpenSSO は, SJS AM の Web SSO コアがもともと実装している拡張性とパフォーマンス向上のための仕組み, つまり
- セッション・サービスを複数のマシンに配置して負荷分散を実現したり
- セッション・キャッシュによってシステム間の XML / HTTP 通信を減らし, 認可決定処理のオーバーヘッドを最小化したり
といったアーキテクチャをそのまま受け継ぐ模様. Web SSO の概念実証レベルのコードではなく, 見方によっては製品のコアをそのまま公開するに等しいわけで, 弊社もなかなかやるなー.
|
|
|
|
Tags: identitymanagement opensso
Posted by tkudo's weblog on April 17, 2006 at 12:16 PM JST #
Posted by tkudo's weblog on April 17, 2006 at 12:18 PM JST #
Posted by tkudo's weblog on September 28, 2006 at 04:30 PM JST #