「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>クレームベース認証]]
* 目次 [#d1de29ba]
#contents
*概要 [#wa4d6f37]
-Pairwise Pseudonymous Identifier (PPID)
--ある SP (Service Provider), RP (Relying Party) に対してのみ, ある Entity の識別子として提供される値.
--他の SP, RP には, 当該 PPID を当該 Entity と関連付けることはできない.
-[[SAML]]や、[[OIDC>OpenID Connect]]にある概念。
-pairwise の対義語は publicになる。
*詳細 [#l5a21788]
**目的 [#h359d738]
一般的に、結託したSP, RPによる名寄せを防ぐ目的で導入される。
※ なお、PPID渡している時に本人を特定できそうなclaimを一緒に渡したら無意味。
**効果 [#e94a7297]
***public [#g192955f]
以下のように実装しなければ、publicでもそれほど問題は無さそう。
-「userid のみを送信して認証とみなす。」の様な実装をしない。
-トークンに署名する。できればクレームセットにも署名する。
***pairwise [#qb880d2d]
-名寄せを防止する目的（プライバシー保護）。
-しかし、実際は、プライバシー保護で使用された事例はなく、~
セキュリティを高める副作用が確認されたことはある（らしい）。
--https://twitter.com/nov/status/1151135731575771136
---トークン置換攻撃を緩和させる副作用
---userid のみを送信して認証とみなす。~
みたいな非推奨をやってしまう人たちの~
アプリのセキュリティを高めてはいる。
**考察 [#i3d6c5d9]
Pairwise Pseudonymous Identifier (PPID)の方がセキュア。
（...当たり前と言えば、当たり前だが。）
***トレンド [#te919d5e]
ウェブサービス事業者のトレンドを分析しても五分五分かなと。
-public
--Twitter~
認証ではなく認可目的のためPPIDにするモチベーションは無さそう。
--Google~
昔、PairwiseだったものをOIDC対応時にpublicに変更した。
--Yahoo~
アプリ横断の共通ID（Yahoo IDとは異なる）
-pairwise
--[[Apple>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?Sign%20in%20with%20Apple]]
--Facebook
--LINE
※ 以下の[[Gistの記事>#h9b0adbd]]が参考になる。
***sub=email [#r836c198]
派生の問題
-別に、sub=emailでログインしても問題はない。
-しかし、ID連携時の、sub = emailは、ダメっぽい。
--何故か？と言えば、
---メアドが乗っ取られると、外部ログイン経由で乗っ取られるため。
---従って、ID連携を行う場合は、パーマネントなIDが必要になる。
--従って、外部ログイン時は、
---sub=useridとするか、
---別の方法（scopeでclaimを要求するなど）でuseridを連携する。
--また、sub = email（username）をPairwise化する場合、~
メアドがバイナリ文字列に変更になる訳で、イロイロ実装し難い。
--Google~
publicを選択しているGoogleでも以下のように言っているらしい。
---「Emailはユニークではない可能性があり、~
ユーザーを識別する主キーとしては適さない」
---参考~
OpenID Connect | Google Identity Platform | Google Developers~
5. Obtain user information from the ID token~
https://developers.google.com/identity/protocols/OpenIDConnect#obtainuserinfo
*実装 [#fc36a827]
**プロトコル別 [#c9a99132]
***[[OIDC>OpenID Connect#cf801b20]] [#k7b7f963]
Pairwise Pseudonymous Identifier (PPID)
***[[SAML>SAML Core#wf653d3e]] [#kbecd153]
SAMLでは、
-[[Persistent Pseudonym Identifiers>SAMLの仕様を読む。#o15eda62]] が PPIDに該当する。
-この実装は、
--[[SAMLメタデータ>SAML Metadata#wec052a4]]のNameID
--[[SAMLリクエスト>SAMLを実装する。#aaddb118]]のNameIDPolicy
>の仕様に関連する。
**計算方法 [#xfd03c10]
[[SAML>SAML Core#wf653d3e]]では明示されていないが、[[OIDC>OpenID Connect#cf801b20]]では明示されている。
***[[標準仕様>OpenID Connect#m3999d6f]] [#k2d6ed0a]
***要件抽出 [#ve20da0a]
-Client毎にユニークになればイイ。
sub = ハッシュ関数 ( Client毎にユニークな値 || userid || salt )
-「Client毎にユニークな値」の要件
--一般的には、~
RedirectUriやJwksUriが使用される（Client側の検証可能なURI）。
--ClientIDは、~
削除・追加で変わり、変更後、重複しているケースもある。
--RedirectURIは
---ドメイン保持すれば変更されない（が、EndPointまでか？FQDNまでか？など悩ましい問題も）
---[[CIBA>CIBA(Client Initiated Backchannel Authentication)]]はRedirectUriが無いのでJwksUriとか言うがFAPIではJwksUriを使わないなど。
-saltが必要になる理由~
「Client毎にユニークな値」が漏れ得る場合（ClientID、RedirectUri）、~
前述の[[計算方法>#xfd03c10]]が解れば、PPID間の紐付け可能になるタメ。
***オレオレ [#t3173920]
-以下の計算式を使用する。
sub = ハッシュ関数 ( Client毎にユニークな値 || userid || salt )
-ハッシュ関数 : SHA-256
-Client毎にユニークな値
--[[OIDC>OpenID Connect#cf801b20]]~
ClientIDに統一する（CIBAにはRedirectUriが無いので）
--[[SAML>SAML Core#wf653d3e]]
---samlp:AuthnRequestのIssuerを利用する。
---[[汎用認証サイト>#i27c493d]]は、OAuth/OIDCメインなので結局、~
samlp:AuthnRequestのIssuerにClientID を使っている。
**設計・実装のメモ [#nd9623a2]
備忘録
***PPIDで名寄せできる属性を返したら意味ない。 [#nd4bb532]
...と言うことで、
-/userinfoでは、sub以外の値を返さない。
-そもそも、IdP側が、PPIDで、sub(user)を特定できないので。
***Client認証の場合、PPIDは無効で良い。 [#w21e294f]
-Client認証とは、
--Client Credentialsグラント種別
--JWT bearer token authorizationグラント種別
-Clientに名寄せは無いダロと。
***Resource Serverを使う場合、PPIDは不適合。 [#k60ec335]
sub(user)を特定できないので、
-User Storeを参照できないので、
-User Resourceを参照できない。
***認証用のClientと、Resourceアクセス用のClientを分ける。 [#a347adad]
-PPIDは、
--認証用のClientに適用し、
--Resourceアクセス用のClientには適用しない。
-ただし、認証用のClientも、
--フェデレーションする必要はあるし、
--[[フェデレーション・スタイルを決定>SAMLの仕様を読む。#b76fc656]]する必要もある。
--PPIDでも、紐付けに必要な、ユーザ名やメアド程度は~
取れるように実装する必要があるケースは多そう。
**[[汎用認証サイト>https://opentouryo.osscons.jp/index.php?%E6%B1%8E%E7%94%A8%E8%AA%8D%E8%A8%BC%E3%82%B5%E3%82%A4%E3%83%88%EF%BC%88Multi-purpose%20Authentication%20Site%EF%BC%89]] [#i27c493d]
のケースを考えると。
***SPの外部ログイン [#wf73f732]
-SPのログインにId連携は必須ではないと言う感じ。
--IdP/StSから、
---取得したトークン検証が済めばログインするなど。
---取得したユーザ名やメアドを、そのまま使う。
--PPIDで、ユーザ名やメアドが取れない場合は、~
ローカル・ログインの機能を実装し、~
ローカルのログイン・アカウントと外部アカウントを紐付ける。~
（となると、ローカルのログインの実装が必要になる。）
-IdP/StSとの関係次第
--関係が密であれば、Id連携は不要。~
---トークン検証が済めばログインするなど。
---そもそも、PPIDも不要で、ユーザ名やメアドが取得できるハズ。
--関係が疎であれば、Id連携をする。
---トークン検証後、ローカルのuseridと、連携先のuserid or ppidを紐付ける。
---若しくは、関係が密になるように、自前のIdPを建てて、[[Hybrid-IdP>#o26063d4]]する。
---前者は、アプリでやるには面倒なので、やるなら、後者が良さそうではある。
***IdPの外部ログイン・ID連携（Hybrid-IdP） [#o26063d4]
汎用認証サイトのHybrid-IdPとしての外部ログイン・ID連携
-[[Owin.Securityライブラリを使用した外部ログイン>ASP.NET Identityの外部ログイン#j7ec63cb]]に関しては、~
AspNet.Identityの補助輪パワーで一応、適切に実装が出来てるっポイ。~
UserLoginInfoがLoginProviderとProviderKeyを含んでいる。
-[[フェデレーション・スタイルを決定>SAMLの仕様を読む。#b76fc656]]に関する考察。
--[[著名ウェブサービス事業者>#te919d5e]]の場合、~
（これは、≒、外部ログイン、ソーシャル・ログインの実装）
---トークン検証後、
---UserLoginInfo （IdP名＋userid or ppid）を永続化して記憶し、
---ローカル・アカウントとは、メアド一致で紐付けている。~
（異なるメアド同士のアカウントを紐付けるのもなんかアレなので）
--関係が疎 or フリーメール可能なIdPとの場合は、~
前述（の著名ウェブサービス事業者の場合）と同じ。
--関係が密 or 企業メールが前提なIdPとの場合は、~
（これは、≒、IDフェデレーションの実装）
---トークン検証後、
---UserLoginInfo （IdP名＋userid or ppid）を永続化して記憶し、
---そのまま、ログイン・アカウントと紐付けなどでも良い。
---ただ、O356へId連携するOktaもメアド同士だったよな。と。~
（となると、結局、ローカル・アカウントと、メアド一致で紐付けになりそう。）
---また、アカウント同期の方式なども検討しておく必要がある。~
（特に、PPIDを採用するようなケースでは、別で同期を行う必要がある）
*参考 [#h9b0adbd]
-各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について~
https://gist.github.com/mala/a01e543bdc54ff476868baa58fdcc9a9
-OpenIDでPPIDの実装方法を確認した。 - r-weblife~
https://ritou.hatenablog.com/entry/20100609/1276019940
**OpenID Connect [#i1ea3237]
-Final: OpenID Connect Core 1.0 incorporating errata set 1~
https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html
-エンタープライズITでのOpenID Connect利用ガイドライン~
https://www.slideshare.net/tkudo/openid-connect-for-enterprise
**OSSコンソーシアム [#s47ae438]
***開発基盤部会 Blog [#bf8c23c0]
-某ペイの件でPPIDが話題になっていたので調べてみた。~
https://www.osscons.jp/joaobcik3-537/
-PPIDを考えていたら、その周辺まで考えることになった。~
https://www.osscons.jp/joxow0mh8-537/
----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
