「マイクロソフト系技術情報 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 を使っている。
のケースを考えると。
SPの外部ログイン †
SPの汎用認証サイトを使用したログイン
- 関係が密であれば、Id連携（≒useridの要求）は不要。
（トークン検証が済めばログインするなど）
- 関係が疎であれば、Id連携（≒useridの要求）をする。
（トークン検証後、ローカルuseridと連携useridを紐付ける）
※ SPのログインにId連携は要らないなと言う感じ。
IdPの外部ログイン †
汎用認証サイト同士（のHybrid-IdPとして）の外部ログイン
- STSとして機能する場合に関しては、
scopeで要求する事でuseridをクレームに含めることはできるので、
以下の様に、emailの特性毎に使い分ける必要がある。
- 企業メアド前提なら、sub = emailで実装しても良い。
- フリーメール等が許容されるなら、
- scopeでuseridも要求する。
- 更に必要なら、PPID化する。
Issue †
メモ †
備忘録
PPIDで名寄せできる属性を返したら意味ない。 †
...と言うことで、
- /userinfoでは、sub以外の値を返さない。
- そもそも、IdP側が、PPIDで、sub(user)を特定できないので。
クライアント認証の場合、PPIDは無効で良い。 †
- クライアント認証とは、
- Client Credentialsグラント種別
- JWT bearer token authorizationグラント種別
参考 †
OpenID Connect †
OSSコンソーシアム †
Tags: :IT国際標準, :認証基盤, :クレームベース認証
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
