「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- Pairwise Pseudonymous Identifier (PPID)
- ある SP (Service Provider), RP (Relying Party) に対してのみ, ある Entity の識別子として提供される値.
- 他の SP, RP には, 当該 PPID を当該 Entity と関連付けることはできない.
- pairwise の対義語は publicになる。
詳細 †
目的 †
一般的に、結託したSP, RPによる名寄せを防ぐ目的で導入される。
※ なお、PPID渡している時に本人を特定できそうなclaimを一緒に渡したら無意味。
効果 †
public †
以下のように実装しなければ、publicでもそれほど問題は無さそう。
- 「userid のみを送信して認証とみなす。」の様な実装をしない。
- トークンに署名する。できればクレームセットにも署名する。
pairwise †
- しかし、実際は、プライバシー保護で使用された事例はなく、
セキュリティを高める副作用が確認されたことはある（らしい）。
- userid のみを送信して認証とみなす。
みたいな非推奨をやってしまう人たちの
アプリのセキュリティを高めてはいる。
考察 †
Pairwise Pseudonymous Identifier (PPID)の方がセキュア。
（...当たり前と言えば、当たり前だが。）
トレンド †
ウェブサービス事業者のトレンドを分析しても五分五分かなと。
- public
- Twitter
認証ではなく認可目的のためPPIDにするモチベーションは無さそう。
- Google
昔、PairwiseだったものをOIDC対応時にpublicに変更した。
- Yahoo
アプリ横断の共通ID（Yahoo IDとは異なる）
※ 以下のGistの記事が参考になる。
sub=email †
派生の問題
- 別に、sub=emailでログインしても問題はない。
- しかし、ID連携時の、sub = emailは、ダメっぽい。
- 何故か？と言えば、
- メアドが乗っ取られると、外部ログイン経由で乗っ取られるため。
- 従って、ID連携を行う場合は、パーマネントなIDが必要になる。
- 従って、外部ログイン時は、
- sub=useridとするか、
- 別の方法（scopeでclaimを要求するなど）でuseridを連携する。
- また、sub = email（username）をPairwise化する場合、
メアドがバイナリ文字列に変更になる訳で、イロイロ実装し難い。
- Google
publicを選択しているGoogleでも以下のように言っているらしい。
- 「Emailはユニークではない可能性があり、
ユーザーを識別する主キーとしては適さない」
実装 †
プロトコル別 †
Pairwise Pseudonymous Identifier (PPID)
SAMLでは、
の仕様に関連する。
計算方法 †
SAMLでは明示されていないが、OIDCでは明示されている。
要件抽出 †
- 一般的には、
RedirectUri?やJwksUri?が使用される（Client側の検証可能なURI）。
- ClientIDは、
削除・追加で変わり、変更後、重複しているケースもある。
- RedirectURIは
- ドメイン保持すれば変更されない（が、EndPoint?までか？FQDNまでか？など悩ましい問題も）
- CIBAはRedirectUri?が無いのでJwksUri?とか言うがFAPIではJwksUri?を使わないなど。
- saltが必要になる理由
「Client毎にユニークな値」が漏れ得る場合（ClientID、RedirectUri?）、
前述の計算方法が解れば、PPID間の紐付け可能になるタメ。
オレオレ †
- OIDC
ClientIDに統一する（CIBAにはRedirectUri?が無いので）
- SAML
- samlp:AuthnRequest?のIssuerを利用する。
- 汎用認証サイトは、OAuth/OIDCメインなので結局、
samlp:AuthnRequest?のIssuerにClientID を使っている。
設計・実装のメモ †
備忘録
PPIDで名寄せできる属性を返したら意味ない。 †
...と言うことで、
- /userinfoでは、sub以外の値を返さない。
- そもそも、IdP側が、PPIDで、sub(user)を特定できないので。
Client認証の場合、PPIDは無効で良い。 †
- Client認証とは、
- Client Credentialsグラント種別
- JWT bearer token authorizationグラント種別
Resource Serverを使う場合、PPIDは不適合。 †
sub(user)を特定できないので、
- User Storeを参照できないので、
- User Resourceを参照できない。
認証用のClientと、Resourceアクセス用のClientを分ける。 †
- PPIDは、
- 認証用のClientに適用し、
- Resourceアクセス用のClientには適用しない。
- ただし、認証用のClientも、
- フェデレーションする必要はあるし、
- フェデレーション・スタイルを決定する必要もある。
- PPIDでも、紐付けに必要な、ユーザ名やメアド程度は
取れるように実装する必要があるケースは多そう。
のケースを考えると。
SPの外部ログイン †
- SPのログインにId連携は必須ではないと言う感じ。
- IdP/StSから、
- 取得したトークン検証が済めばログインするなど。
- 取得したユーザ名やメアドを、そのまま使う。
- PPIDで、ユーザ名やメアドが取れない場合は、
ローカル・ログインの機能を実装し、
ローカルのログイン・アカウントと外部アカウントを紐付ける。
（となると、ローカルのログインの実装が必要になる。）
- 関係が密であれば、Id連携は不要。
- トークン検証が済めばログインするなど。
- そもそも、PPIDも不要で、ユーザ名やメアドが取得できるハズ。
- 関係が疎であれば、Id連携をする。
- トークン検証後、ローカルのuseridと、連携先のuserid or ppidを紐付ける。
- 若しくは、関係が密になるように、自前のIdPを建てて、Hybrid-IdPする。
- 前者は、アプリでやるには面倒なので、やるなら、後者が良さそうではある。
IdPの外部ログイン・ID連携（Hybrid-IdP） †
汎用認証サイトのHybrid-IdPとしての外部ログイン・ID連携
- 著名ウェブサービス事業者の場合、
（これは、≒、外部ログイン、ソーシャル・ログインの実装）
- トークン検証後、
- UserLoginInfo? （IdP名＋userid or ppid）を永続化して記憶し、
- ローカル・アカウントとは、メアド一致で紐付けている。
（異なるメアド同士のアカウントを紐付けるのもなんかアレなので）
- 関係が疎 or フリーメール可能なIdPとの場合は、
前述（の著名ウェブサービス事業者の場合）と同じ。
- 関係が密 or 企業メールが前提なIdPとの場合は、
（これは、≒、IDフェデレーションの実装）
- トークン検証後、
- UserLoginInfo? （IdP名＋userid or ppid）を永続化して記憶し、
- そのまま、ログイン・アカウントと紐付けなどでも良い。
- ただ、O356へId連携するOktaもメアド同士だったよな。と。
（となると、結局、ローカル・アカウントと、メアド一致で紐付けになりそう。）
- また、アカウント同期の方式なども検討しておく必要がある。
（特に、PPIDを採用するようなケースでは、別で同期を行う必要がある）
参考 †
OpenID Connect †
OSSコンソーシアム †
Tags: :IT国際標準, :認証基盤, :クレームベース認証
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
