ritouです。
「宣伝」2024/05/16(木)にOpenID TechNight vol.21 ~ Shared Signal Framework(SSF)+αの勉強会が開かれるようです。
そもそもSSFって知ってます？勉強会までにSSFについて少し予習しておきましょう。
SSFについて
Tom Satoさんには1月のOpenID Summit Tokyo 2024にてSSFについて講演していただきました。
また、昨年末のアドベントカレンダーでも記事を書いていただきました。
RISCとCAEPをざっくり整理すると、
- RISC : アカウントに関するイベント送信を送信 (IdPでユーザーが退会した、BANされた、乗っ取られた、メアド変更した時などに連携しているサービスに通知)
- CAEP : セッションやトークンに関するイベント情報を送信(APIアクセスの環境が変更されたことなどを検知してポリシーに反していたら通知かつ拒否)
として、送られるイベント情報の表現や送受信方法などが何個かのRFCとして策定され、プロファイルの仕様も策定が進められています。
リソースアクセスにおいても継続的にアクセス評価をしようというCAEPは これまでなかったもの という感じはあるものの、RISCの方はどうでしょう。少し内容をおさらいしてみます。
RISCによるユーザー情報変更時のイベント送信の需要
リスクなんたらというとどうしてもインシデント的なところを思い浮かべてしまうかもしれませんが、ユーザー情報変更時のイベント送信 ぐらいで捉えておくと良いでしょう。
- ユーザー
- アプリケーションA
- アプリケーションB
という登場人物がいて、ユーザーがアプリケーションA/B両方を利用している状態です。 ここでアプリケーションAにてユーザーの属性情報の更新、状態の変更があったときにアプリケーションBに対してイベントを通知する、と言うのが想定されています。
あえてあっさりとしか説明しなかった、アプリケーションA, Bの関係についてID連携と絡めて整理します。
- アプリケーションA: IdP, アプリケーションB: RP
- アプリケーションA: RP, アプリケーションB: IdP
- アプリケーションA, アプリケーションB: どちらもIdP
1は割と想像しやすいでしょう。ID連携で例えばメールアドレスを提供している場合、RP側でそれをどう扱っているかはIdPからそんなにわかりません。 RP側がユーザーのメールアドレス変更に気づくタイミングとして、まずは
- OIDCのUserInfo Endpointなどを用いてメールアドレスを取得
- OIDCの認証フローを通してRPにログインするタイミングでIDTokenに含まれるメールアドレスを取得
と言うRP起点のものがあります。
それに対して、IdP起点のものがあります。ユーザー情報の同期みたいなものといえばSCIMが想像できるかと思いますが、RISCは送られるイベント表現という視点から考えた感じとも言えそうです。3rd partyアプリケーションとの連携というよりは、1st partyアプリケーションとの連携などで有用になるかもしれません。
2について、IdPから受け取ったメールアドレスを補完的に利用しつつ、最終的にはRP側でメールアドレスを保持するケースも考えられます。 ID連携でユーザーIDはわかっているので、RPからIdPに「このユーザーはウチでメアド変えたぞ。お前のところでも変更が必要になるかもしれないから一応連絡しとく」みたいな使い方もあり得るかもしれません。
3はIdP同士という少しイメージしずらいところですが、例えばGAFAのような巨大サービス同士であらかじめ「不正利用対策のための情報連携」みたいなものをユーザーに求め、いずれかのアカウントで情報変更があったときに他のサービスにも通知される、というような使われ方が想像できます。
といったような感じですね。ダマでやられるとなんなん？って思っちゃいますが、ユーザーの同意の元でというのはありそうです。
OIDFの説明文でもProvider間みたいな表現がありますね。
The Risk & Incident Sharing and Collaboration (RISC) provides a standardized way to transmit and receive security alerts about such attacks. It enables providers to prevent attackers from compromising linked accounts across multiple providers and coordinate in restoring accounts in the event of compromise.
これは3あたりも見据えているような印象です。 よって、RISCのイベント送信の方向はわりと柔軟に考えられますよ、というのを覚えておきましょう。
認証基盤におけるイベント送信の需要
上の例で結構書いてしまいましたが、いわゆる認証基盤のようなものを提供していると、このような機能を求められることはたまにあります。
- IdP側でBANや退会してもRPがそのまま使い続けられるのはちょっと困る。RPはログイン時以外にAPIアクセスしてないので、連携ユーザーは退会禁止にしてもらうもしくは退会時にIdPから通知してくれないか？
- IdP側でアカウント乗っ取りなどが起こった場合、RPはどうしたらええんや。リアルタイム検知とかはどうしたって夢物語なのである程度一緒にやられるのは仕方ないとしても、IdP側で検知したらすぐに教えて欲しい
- サービス自体が成長した状態からID連携をしたので、ID連携は任意でメールアドレス管理はRPで行なっている。連携状態のユーザーはメールアドレスを同期したい
RP「うちはID連携のためのデータストアで、メールアドレスをキーにしている。IdPでメールアドレスを変更したらおかしなことになるので、メールアドレス変更できなくする、もしくは変更後に通知して欲しい」
認証基盤としては特定RPのためのロジックをあまり仕込みたくないものですが、イベント通知であればある程度汎用的に実装できますね。
このように、RISCのユースケースは特に新しいものではなく既存の仕組みに存在する要件から来ていると言えるでしょう。 あなたの手がけているサービスや認証基盤でも同じような話、ありませんか？
まとめ
SSFで想定されているRISCについて、このユースケースって結構身近にありそうですよねっていう話を書きました。 認証基盤と呼ばれるものを運用している中であるあるな要件に対応する標準化仕様が考えられているんですよ、ということです。
古い話をすると、元々OAuthだって世の中に存在しない新しい仕組みを考えたわけではなくて既存のサービス(Google, Yahoo! Flickrあたり)が独自で外部サービスへのAPI提供の仕組みを考えて運用していたものをいい感じにまとめようぜ！ってなったものです。
仕様を読んでみて何が定義されているかを理解できてきたら、実サービスへの適用などを考えることでより解像度が上がり、知識として身につくでしょう。自分たちのサービスへの適用を考えたときに「これも欲しい」、「ここもうちょい柔軟にして欲しい」みたいなことが出てきたらコントリビュートのチャンスとなるわけです。
今回はユースケースの話をしましたが、こういうことを考えていると仕様を読んでみたくなりますよね。 どのRFC、どこにどんな仕様が定義されているのかのまとめ記事、JWTの作り方などをZennの方に書こうかなと考えています。
ではまた！
