こんばんは、ritouです。
さっきまで、このセミナーに参加していました。
http://www.openid.or.jp/modules/news/details.php?bid=49
OpenIDファウンデーション・ジャパンとその他の企業で構成されたWGでは、学認が持つ学生情報を民間サービスに流通させるために技術面/ポリシー面の検討を進めてきたというわけです。
私もこのWGに参加させていただいて、デモを裏で操りました。残念ながらUSTやらなかったので残っていませんが。。。
デモ作った以外に、下記の検討等を行いました。
- ユースケースに対して技術的に厳しい部分がないか
- 既存の標準化仕様をどのように適用すると実装コストを抑えられそうか
- デモ作成から実装面の課題を洗い出し
実際はポリシーから決めていこうか的な空気の中で違う方向いて実装どうするか考えていった感もありますが、結果としてユースケース検討の材料とデモそのものを使えて良かったかなと思っています。
ユースケース検討とともに上がってきた要件
説明には含まれていませんでしたが、こんな要件が出てきました。
- データのやりとりに関わる登場人物はAtP(Attribute Provider), IdP(Identity Provider), RP(Relying Party), End Userの4者
- End Userの許可のもと、AtPの属性情報をIdP経由でRPに渡す
- IdPとRP一緒でもいい
- RPは複数のIdPと接続できる
- RPはいつでもAtPの最新の属性情報を取得できる
今後細かいいろいろが出てくると思いますが、プロトコルレベルの話でいうと、それほど難しいものではありません。
なぜAtPからRPに直接属性を渡さずにIdPが間に挟まっているのかが気になるかもしれませんが、
単純に学認経由の大学をIdPとして利用してね!よりも、既にOPになっているところに属性を提供することで敷居を下げる狙いなどいろいろあります。
デモ時点で考えたこと
OpenID Connectを多段にして接続
シーケンス
まずはAtP-IdP間
次はIdP-RP間
ConnectのSpec的には、IdPからDistributed Attributesを使い、RPからAtPのAPIをたたく方式もありかと思いました。
しかし、あえてRP-AtP間を直接結び付けない2段構成が良いのかなと思って提案しました。
デモ
今回、こんな感じのデモ環境を用意しました。
- 1. SITF Sample AP(Attribute Provider) : http://sitf-ap.openidconnect.info/
- 2. SITF Sample IdP(Identity Provider) : http://sitf-idp.openidconnect.info/
- 3. SITF Sample RP(Relying Party) : http://sitf-rp.openidconnect.info/ : SITF IdP経由でログインも属性取得も行うパターン
- 4. SITF Sample RP2(Relying Party) : http://sitf-rp2.openidconnect.info/ : 外部IdPでログインしつつSITF IdP経由で属性取得するパターン
デモでは1,2,4あたりを使いました。
くわしくはこちらhttps://gist.github.com/2520183
WGでこれから決めていくこと
データの流れや細かいリクエスト/レスポンスに関しては、トラストフレームワークの要であるポリシー面の精査とともに決めていかなければなりません。
あまりにガチガチに決めてもIdPの持つそもそものポリシーと合わずに参入の障壁となってしまうだろうし、あまりにフリーダムだとIdP単位で実装が変わる残念仕様となる。
ConnectのSpec的にはOpenID Request Objectを利用すれば認証のポリシーから欲しい属性の指定まで細かい指定ができるわけだけど、RPの実装コストを考えると落としどころを見つけてScopeでなんとかする方が良いのかもしれません。
デモの後の質問やパネルディスカッションの質問にもありましたが、このあたりはもう少し詰めが必要です。
学生属性の新鮮度
今回のWGではリアルタイムにAccess Tokenを用いて最新の属性情報を取得するような前提条件で進めました。
ただし、大学側のSLAにも関わってきます。
基本的にリアルタイムにアクセスしつつ返答がない場合はキャッシュしようというやりかたもあるかと思います。
ユーザー識別子の扱い
崎村さんからの質問にもありましたが、ユーザー識別子の扱いは検討が必要です。
- AtPから一意なユーザー識別子が提供される : おひとり様1アカウントのみというサービスが可能
- AtPからIdP単位で一意(PPID)なユーザー識別子が提供される : 名寄せができない
- AtPからユーザー識別子が提供されない