「マイクロソフト系技術情報 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コンソーシアム †
開発基盤部会 Blog †
Tags: :IT国際標準, :認証基盤, :クレームベース認証