今日やること
OpenAMのセッションについてです。調べたことをまとめた備忘録的な記事になります。
OpenAMのセッション
OpenAMは、ユーザーがOpenAMで認証に成功すると、ユーザーがリソースにアクセスすることができる権限をもったセッションを作って管理します。このセッションに格納されている情報を見て、OpenAMはユーザーのセッションが有効かどうかであるとかを判断しています。
ステートフルとステートレス
このセッションですが、OpenAMはステートフルな構成にすること、また、ステートレスな構成にすることの双方をサポートしています。
設定の切り替え
OpenAMで発行されるセッションは、デフォルトで、ステートフルなセッションを払い出します。この設定は以下の場所で切り替えをすることができます。
OpenAMの管理コンソール（ユーザー名amadmin）でサインインします。
Top Level Realm => Dashiboard => Propertiesにアクセスします。
Use Stateless Sessionsのパラメータになります。
このパラメータの説明のところにも書いてありますが、ステートレスなセッションを有効にすることで、Elasticなスケーラビリティを提供することができるとあります。
ステートフルって？
ステートフルなセッションは、OpenAM上のメモリに常駐するセッションです。ゆえに、冗長構成を組んでいる場合は、障害発生時にセッションフェイルオーバーを行う必要があり、LDAPのレプリケーションを仕込む必要があります。
回りくどいですが、いわゆる一般的なアプリケーションと同様に、このセッションに紐づくCookie（SSO Token）をOpenAMはクライアントに配布します。SSO Token自体に意味は無く、ただのキー値となっています。
以下は認証時に配布されるステートフルなSSO Tokenです。
iPlanetDirectoryPro=AQIC5wM2LY4SfcwmxU5IimBZfmQY8prI84LMdh_GWBD-PK4.*AAJTSQACMDEAAlNLABQtNDY2NDA1MDY0Nzg4MDQyMTc3MgACUzEAAA..*
ステートフルなセッションの場合、このCookieの値のサイズは約100バイトとなります。
ステートレスって？
ステートレスなセッションとは、さきほどのSSO Tokenとは異なり、セッションに格納されている情報がencodeされて、SSO Tokenとしてクライアントに配布されます。そのため、OpenAMはそれらの情報をメモリに保持しません。OpenAMは様々なクライアントから送信されるステートレスなセッションをdecodeし、セッションに関連する情報を取り出します。つまるところ、本来OpenAM側で保持していたセッション情報をクライアント側に持たせて、リクエストの度に、そのセッション情報を解析して、判断するといったものです。それゆえ、ステートレスなセッションの場合は、そのセッションが無効（ログアウトや有効期限がきれるなど）になるまでセッションの情報を更新することはできません。
以下は認証時に配布されるステートレスなSSO Tokenです。（長い・・・）
iPlanetDirectoryPro=*AAJTSQACMDEAAlMxAAA.*eyJ0eXAiOiJKV1QiLCJjdHkiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.ZXlKMGVYQWlPaUpLVjFRaUxDSjZhWEFpT2lKT1QwNUZJaXdpWlc1aklqb2lRVEV5T0VOQ1F5MUlVekkxTmlJc0ltRnNaeUk2SW1ScGNpSjkuLm5LQTBjaXI2MW1IZS1XSVBGejFBR2cuVXZyNE9NU2hXUTBJUDhVYjg2WjZvUW1URjJFcXdieG92bk94T0hhT2x2TEE3cm9lQ2Zya3hNTmxQaHByd25Pcl9EWUYtTjRaaWMxYTkweEFKOHhBdy1kX2ZYQTcxc05HSVRfeWJkajdFNzhBeXBMYXhjUkc1TzRTRjM0V3MzaFRUWTRnSHZBcEJxbkF5WUVHUFJJc3FxZlBoT1F0clk1N0w1MzdEZldRd2xtb2hTVTFaemUzUUhxMUZST01TOFh4YlRjRThXOVFWRXFVRl9kYkFaVWkwbTIwclp2WjNWWnlJbUlfeDJ6MlJkU2JrX3JaMXNwNmNNdW02dEpsV2NLTlVfTWIxRTZTcnFlenZJZFRPUkdXdl93YVlKVVQtWFY1cnI0ZXJWSS1neldmQ2taNHdmNEZ0VmhkcHFZMUVzV2FpakJaUWhKa05rb1dHWk1ZN0lPMHZUb2N0S0swYTBjNW04bFBIQTNnY29QQm9CdG1PaVpDMkY0RHJ3T2ZFaEd1WDlDaF9GX0l6dE5wak5xeTJJR1Bpb0VqZWpnWkFlMUZfYnBIeEEzdFJUaUp2dG9DVENmN09ZaUkxLWpNMWp5UFVGY2Z2ZnBOV0l3TEV6aXJQeHlTQlV1TTB1SWFoa3NFaDh4cmFHSEFwOW40dU1DNGRtdjNrRl9FVEdyakdGTlFNYUlhLVJBX3ZiTmJpMlJhR1ZYbGhVSHpVTnNuaU5XVjgwU1VCRDFPREJ5QURnQlpHQnl4NDNnT3JONHdPRHFaMENnOE1UcU1yU0V6cXotQTBWXzd4N091bGJzRjl0QUZKbWJWNDVPWU5hcUM1MUdDQzJfZnNhUktIQk9lUldMdlIxM1ZCcENwZkRqSTQtQlZWX1NRNnZlTGNPZ1lkT0hxRlBZUDZBZEk3aDYzNE55R1R5RlViVVNfMmFtOEJFc3NBZkl0NjFrRlg2ZGdhb2ZUc1kzMkFlRWNVMGlpZW82cm5JdW9GR2hfR051UlpSa3ZwcFR2dlVxcFpfdTVEWi05anZRa1VmQUlRNWZ5T2tWWHozSERlLXlNUUZQd0dOZFN0SDBUVzZMa2EwSS1aWkhGUENlbFpCcTJLY2lISExqWHhWYWZMOWNqZXVncGNaZUxLYmNTWUNhcGE5ZkZHYWtDanpDWEZJMlIzdnRDRWlSemtBdVdOUUxTcjFuUVFyUWdiQ05ZeTh3NjJ4RnlIWXRydHlseWV0NGU0MWlWQzM4VDlUSTlrNm1xYVo0d1NfRW5mMTB0bjhhT29QTk5lMDBuZmMzWlVHaFZjSFg2QnFNaC1TZVo5RGt0eGRPR1l1TXYwNVBnTm5yMnFSQkJkMmhMOGZpNGp4dWd4SVZmRGpVd2RXbmhUVVNRWFBHTWt3RVZrUVhVWmc1UnlCNllXOEtzSlBIYjhFdE9KbWpSTGsxQldyY2ZTZi1McU5XTnJiN3lZN2ZWaGphTjV5RGFSTUdCM0oxdlVmREZONnNQU2xZWVFCci0yR0xjb3gxWWMxSlV2QmVNa0JDb1ZsdGdaU1R0NHhkWWtRZFNHaEFVR2M1UENGR3dOSUVVel9zeWUtamlSYVFtWlZ5aXhyXzBoakZSOWdIRkpKc2Q1XzBicHcwSjl2bklNZnZ4RWw1UUNibWx5dFZMeEVJTWhDRHJra25UVF9hZEpKNXdVYTRHSzV5OXZBSUljU3piN0IyMS12aF9nYm1xeHY2WllGcjk2aTZOQ0hBR193dFFNRjNwVlgwc3B1MlpSNkc3azRnLjNpNms0S3BCLUxjdVM1UzlUWEpaS2c.b8cs3nZX6DVSm70vQAauXHK9UNhFtlV3Z3qoRoDmXNA
ステートレスなセッションの場合、iPlanetDirectoryProクッキーは約2000バイト以上となります。RFC 6265では、1つ当たりのCookieのサイズ上限が書かれたりもしますし、注意が必要ですね。ブラウザによっては欠損したりしないのでしょうか？
Practical user agent implementations have limits on the number and size of cookies that they can store. General-use user agents SHOULD provide each of the following minimum capabilities: At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes).
また、ステートレスなセッションの一部は**JWT（JSON Web Token）形式ぽいんですが、うまくdecodeできないですね...Signatureがあってないっていわれるし...
ステートレスセッションのいいところと使う上での注意点
いいところは何といっても、セッション情報をOpenAM上で保持しなくていいので、セッションのフェイルオーバー（LDAPのレプリケーション）が不要になることです。OpenAM1号機で発行されたSSO TokenをOpenAM2号機に持ち込んでも認証された状態が継続することができます。（使っている署名鍵が同じなら）
このあたりは、JWTの特徴を活用したユースケースのお話だと思います。わたしがこれらを踏まえたJWTの概要を抑えるのに役立ったjwt.ioというサイトがあります。なかでもIntroductionに記載の下記の図は、ステートレスなセッションの概要を知るのに良いシーケンスだと思いました。
ただし、これらの機能を使う上で、注意しないといけない点がOpenAMの開発元から列挙されています。
9.10. Limitations When Using Stateless Sessions
- Authentication Levels and Session Upgrade Session upgrade
- Configuring Session Quotas Session quotas
- Configuring Policies Using the OpenAM Console Authorization policies with conditions that reference current session properties
- Configuring Cross-Domain Single Sign-On Cross-domain single sign-on
- SAML v2.0 and Session State SAML v2.0 single sign-on and single logout
- Managing SAML v1.x Single Sign-On SAML 1.x single sign-on
- SNMP Monitoring for Sessions SNMP session monitoring
- Session Management Session management by using the OpenAM console
- Session notification
SSO Tokenが持つ（OpenAM側で保持された）情報をアップデートして何かをする系のユースケース、あとは単純にCookieを見て、動作を決めていた実装が少し未対応といった感じですね～。（適当
ステートレスなセッションを払い出す機能は非機能面でとても魅力的ではありますが、使ってたらなんだかはめられそうな匂いがします。保守的なわたしはきっと使わないと思います。Web Policy Agentを使うだけならよいでしょうが、Federationするときに使うToken（id tokenとかaccess/refresh tokenとかauthorization code）もステートレスにできるんでしょうかねぇ？
〆
今日はなんだか説明臭い感じになりましたね。
JWTに関してのユースケースとして、ID Federation(OpenID Connect)は代表的な例だと思いますが、単純にCookieやBearer Tokenで持ちまわってもらうっていうのはカッコいいですね。今風だと思いました（小並感
ただ、OpenAM側で情報を持たないので、無効化が必要なユースケースでは要注意ですね。証明書の世界で言う、Revocation Listみたいなものを提供してあげないと辛そう。
まとめとしては、
- OpenAMで発行するSSO Tokenはステートレスとステートフル両方の形式で発行できる
- 発行したものはJWTっぽい
- ステートレスなセッションを発行する機能を使うときは色々注意が必要
あと一週間ですねー。なにしようかなー？
ばい！