Attribute Provider と替え玉問題の後日談
(2012/06/10 : 1つのSITF APアカウントに対し連携できるSITF IDPのアカウントを1つだけという仕様にしました。)
http://sitf-idp.openidconnect.info/sitfap
- 書き足りなかったことと、その後の考察です
By shiokuma - 替え玉プレート(2007) / CC BY-NC 2.0]
- http://sitf-idp.openidconnect.info/ 特有の問題ではなく、Attribute が Identity とは別に提供される場合、この問題は発生する
- RP + IdP + AtP という構成に限らず、OAuth 2.0 による一般的な構成で、Resource Server が AtP 的な使われ方をしているものは該当する
- Resource Server が、Identity になり得ない Attribute のみを提供している
- Client が、Attribute のみを利用している
- RP + IdP + AtP という構成に限らず、OAuth 2.0 による一般的な構成で、Resource Server が AtP 的な使われ方をしているものは該当する
- RP または IdP(以下 RP で統一)が Attribute のユーザー識別子がユニークであることをチェックしても、替え玉を完全に防げない
- Attribute の所有者が、その RP を利用しない場合、最大1ユーザにその Attribute を譲渡することができる
- RP の性質によっては、1ユーザの替え玉も許容できない可能性がある
- RP は Attribute のユーザー識別子だけでは、替え玉か否か判別できない
- 対策として、AtP が提供する Attribute を増やし、RP が持つ既知の Attribute と突き合わせて、連携の正当性を検証する
- もはやそれは Attribute Provider ではなく、Identity Provider なのでは?
- そもそも Attribute を別にして提供するメリットは?
- AtP と RP が検証に十分な Attribute を持っていない場合は?
- ユーザー識別子だけでも、後から追跡することはできる
- AtP の管理者に、本来の所有者を問い合わせる
- 対策として、AtP が提供する Attribute を増やし、RP が持つ既知の Attribute と突き合わせて、連携の正当性を検証する
- RP が Attribute のユーザー識別子がユニークであることをチェックし、先におこなわれた連携を尊重するとき
- なんらかの事情で AtP のクレデンシャルが盗まれ、未連携の RP と連携された場合、Attribute の所有者は連携を解除できない
- RP が Attribute を保存することで、Attribute の変更、認可の取り消しなどが反映されない
- RP は Attribute を保存せずに都度 AtP に問い合わせるか、短期間のキャッシュにとどめる必要がある