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(以下 RP で統一)が Attribute のユーザー識別子がユニークであることをチェックしても、替え玉を完全に防げない
    • Attribute の所有者が、その RP を利用しない場合、最大1ユーザにその Attribute を譲渡することができる
    • RP の性質によっては、1ユーザの替え玉も許容できない可能性がある
  • RP は Attribute のユーザー識別子だけでは、替え玉か否か判別できない
    • 対策として、AtP が提供する Attribute を増やし、RP が持つ既知の Attribute と突き合わせて、連携の正当性を検証する
      • もはやそれは Attribute Provider ではなく、Identity Provider なのでは?
      • そもそも Attribute を別にして提供するメリットは?
      • AtP と RP が検証に十分な Attribute を持っていない場合は?
    • ユーザー識別子だけでも、後から追跡することはできる
      • AtP の管理者に、本来の所有者を問い合わせる
  • RP が Attribute のユーザー識別子がユニークであることをチェックし、先におこなわれた連携を尊重するとき
    • なんらかの事情で AtP のクレデンシャルが盗まれ、未連携の RP と連携された場合、Attribute の所有者は連携を解除できない
  • RP が Attribute を保存することで、Attribute の変更、認可の取り消しなどが反映されない
    • RP は Attribute を保存せずに都度 AtP に問い合わせるか、短期間のキャッシュにとどめる必要がある