OpenAM 13の新機能を試してみた(2) - Stateless Session
前回に続いてOpenAM 13の新機能の紹介、その2です。今回は Stateless Sessionという新しい認証セッション方式について紹介。
従来のOpenAMの認証セッションの仕組み
Stateless Sessionの前に、従来のOpenAMの認証セッションの仕組みについて説明しておきます。
OpenAMにログインすると、その認証情報(ユーザIDなど)はセッションとしてメモリ上に保存されています。ブラウザにはデフォルトだとiPlanetDirectoryProというキー名でCookieにセッションIDが格納され、サーバ上のメモリと紐付けられてログイン状態を維持し続けます。セッション情報をサーバ側で保持するこの方式を、Stateful SessionとOpenAMでは呼んでいます。
OpenAM一台構成だとこれでよいが、OpenAM複数台構成だと、サーバダウンなどが起きてしまうとメモリ上にセッション情報がないサーバにリクエストが振り分けられてしまい、ユーザは再ログインが必要になります。一部のサーバがダウンしても再ログイン不要で継続可能にするためには、セッション情報をOpenAMサーバ間で共有する必要があります。
セッションフェイルオーバー (OpenAM 10.0以前)
そこで出てくるのがOpenAMのセッションフェイルオーバーの機能。セッション情報を複数台のOpenAMサーバで自動的に共有することで、たとえ別のサーバにリクエストが振り分けられてもログイン状態を維持し続けることができるようになります。
しかしながら、OpenAM 10.0 以前だとこの機能を利用するのはとても大変。下図はOpenAMのフォーク元のOpenSSOのドキュメントにあるものですが、セッション情報を格納するBerkeley DBとMessage Queue Brokerを用意するといった大掛かりな仕組みが必要でした。
なお、この方式のセッションフェイルオーバーの検証を2012年にSCSK社が行っています(報告書はこちら https://www.scsk.jp/lib/product/oss/pdf/oss_6.pdf )。報告書の中で、この方式について「構成要素が複雑になる、OpenAM を3台以上に増やした際にスケールするかなどの懸念もある」とコメントされています。
新しいセッションフェイルオーバー(OpenAM 10.1.0-Xpressより)
そこでOpenAM 10.1.0-Xpressでは、より簡単に扱えるセッションフェイルオーバーの仕組みが導入されています。OpenAMには元々設定情報の格納用に組み込みOpenDJ(OpenDSのフォーク)が同梱されていました。OpenAMを起動すると内部で一緒に起動しています。この組み込みOpenDJのマルチマスタレプリケーション機能を利用して、セッション情報を共有する方式が追加されました。というわけで追加のソフトウェアセットアップは不要で、チェックボックス1つの設定で簡単にセッションフェイルオーバー機能を利用できるようになりました。
クラウド・IoT時代の新たな課題
従来のSSOの要件として使う分にはそこまでOpenAMサーバは必要なくこれで十分ですが、グローバル企業がクラウドを活用して大規模なSSOを行いたい(リージョンまたがり)とか、PC・モバイルだけでなく様々なデバイスからの接続も今後増えるIoTを考えると、この方式では限界が来そうです。OpenAMのドキュメントでは、より大規模な構成だとOpenDJサーバを別途立てて、レプリケーションの通信先を減らすような構成案が提示されています。レプリケーション用のOpenDJを別途たてて負荷分散をするという方式です。
でもこれだと管理するサーバも増えてしまい、運用がとても大変。クラウドを活用して柔軟にスケールさせるのも辛そうですし、OpenDJもそこまでスケールするのか不安です。
そこでStateless Sessionですよ
そこでOpenAM 13から新たに追加された方式の、Stateless Sessionの出番。こいつはサーバ側でセッション情報をメモリで持ち続けません。OpenAMサーバはステートレスになります。代わりにユーザのCookieにセッション情報を持ちます。元々Cookieに認証セッションのIDを持っていました。ここに、サーバ側で持っていた認証セッション情報が埋め込まれるようになります。下図はStateful SessionとStateless SessionのCookieで持つ値の違いを示した物ですが、Stateless Sessionの場合は、ey....fQ. の部分が追加されており、これがセッション情報なわけです。
出所：http://openam.forgerock.org/doc/bootstrap/admin-guide/index.html#chap-session-state
従来の方式のように、セッションフェイルオーバのためにレプリケーションを行う必要もなくなりますので、容易にスケールさせることができます。
タイムリーなことに、ForgeRockより性能を検証した情報が昨日出ました。ちょうど今開催中のIdentity Summitのセッションスライドとして公開されています。このスライドのp.15から性能に関する記述があります。
OpenAM2台構成でStateful SessionとStateless Sessionの比較を行っており、
- Stateful Session： 3000ログイン/秒
- Stateless Session：5000ログイン/秒
セキュリティは大丈夫？
Cookieは簡単に中身を覗いたり、改ざんができてしまうのでセキュリティは大丈夫か気になるところですが、その点は大丈夫。保存形式にはRFC化されたJWTが使われます。デジタル署名による改ざんチェックや暗号化もサポートされます。
ただし、動作を試したNightly Build版だと、署名や暗号化を有効にしたとしてもJWTのalgがnoneとなっていました･･･。正式版を待ちましょう。
その他注意点
Stateless Sessionも万能ではなく、上で紹介したスライドでも述べられているように、同時ログイン数制御なんかはできなくなります。また、OpenAMのクロスドメインSSO機能とSAMLでも制約があるようで、その場合はStateless Sessionは非推奨とのことです。
あと、言及が見られないですが、OAuth2のアクセストークンは従来通りレプリケーションが必要と思われます。これはMSなどのサービスのように、アクセストークン自体をJWT化する対応が必要になってくるかと、、、ここは是非対応してほしいですね。
