「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- Pairwise Pseudonymous Identifier (PPID)
- pairwise の対義語は publicになる。
詳細 †
導入の目的 †
- 一般的に、結託したRPによる名寄せを防ぐ目的で導入される。
- Pairwise Pseudonymous Identifier (PPID)とは、
- ある Relying Party(RP) に対してのみ, ある Entity の識別子として提供される値.
- 他の RP には, 当該 PPID を当該 Entity と関連付けることはできない.
効果と事例 †
public †
以下のように実装しなければ、publicでもそれほど問題は無さそう。
- 「userid のみを送信して認証とみなす。」の様な実装をしない。
- トークンに署名する。できればクレームセットにも署名する。
pairwise †
- しかし、実際は、プライバシー保護で使用された事例はなく、
セキュリティを高める副作用が確認されたことはある（らしい）。
- userid のみを送信して認証とみなす。
みたいな非推奨をやってしまう人たちの
アプリのセキュリティを高めてはいる。
導入の考察 †
Pairwise Pseudonymous Identifier (PPID)の方がセキュア。
（...当たり前と言えば、当たり前だが。）
トレンド †
ウェブサービス事業者のトレンドを分析しても五分五分かなと。
- public
- Twitter
- Google
昔、PairwiseだったものをOIDC対応時にpublicに変更した。
- Yahoo
アプリ横断の共通ID（Yahoo IDとは異なる）
※ 以下のGistの記事が参考になる。
sub=email †
派生の問題
- 別に、sub=emailでログインしても問題はない。
- しかし、ID連携時の、sub = emailは、ダメっぽい。
- 何故か？と言えば、メアドが乗っ取られると、
外部ログイン経由で乗っ取られるため。
- 従って、外部ログイン時は、
- sub=useridとするか、
- 別の方法（scopeでclaimを要求するなど）でuseridを連携する。
- また、sub = email（username）だと、Pairwiseを実装し難い。
- Google
publicを選択しているGoogleでも以下のように言っているらしい。
- 「Emailはユニークではない可能性があり、
ユーザーを識別する主キーとしては適さない」
実装 †
プロトコル別 †
Pairwise Pseudonymous Identifier (PPID)
SAMLでは、Persistent Identifier が PPIDに該当する。
計算方法 †
SAMLでは明示されていないが、OIDCでは明示されている。
オレオレ †
- Client毎にユニークな値 || userid ||
- saltが必要になる理由
Client毎にユニークな値が漏れ得る場合、
アルゴリズムが解れば、紐付け可能になる。
のケースを考えると。
SPの外部ログイン †
SPの汎用認証サイトを使用したログイン
- 関係が密であれば、Id連携（≒useridの要求）は不要。
（トークン検証が済めばログインするなど）
- 関係が疎であれば、Id連携（≒useridの要求）をする。
（トークン検証後、ローカルuseridと連携useridを紐付ける）
※ SPのログインにId連携は要らないなと言う感じ。
IdPの外部ログイン †
汎用認証サイト同士（のHybrid-IdPとして）の外部ログイン
- STSとして機能する場合に関しては、
scopeで要求する事でuseridをクレームに含めることはできるので、
以下の様に、emailの特性毎に使い分ける必要がある。
- 企業メアド前提なら、sub = emailで実装しても良い。
- フリーメール等が許容されるなら、
- scopeでuseridも要求する。
- 更に必要なら、PPID化する。
参考 †
OpenID Connect †
OSSコンソーシアム †
Tags: :IT国際標準, :認証基盤, :クレームベース認証
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
