マイクロソフト系技術情報 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とは異なる)
  • pairwise

※ 以下のGistの記事が参考になる。

sub=email

派生の問題

  • 別に、sub=emailでログインしても問題はない。
  • しかし、ID連携時の、sub = emailは、ダメっぽい。
  • 何故か?と言えば、
    • メアドが乗っ取られると、外部ログイン経由で乗っ取られるため。
    • 従って、ID連携を行う場合は、パーマネントなIDが必要になる。
  • 従って、外部ログイン時は、
    • sub=useridとするか、
    • 別の方法(scopeでclaimを要求するなど)でuseridを連携する。
  • また、sub = email(username)をPairwise化する場合、
    メアドがバイナリ文字列に変更になる訳で、イロイロ実装し難い。
  • Google
    publicを選択しているGoogleでも以下のように言っているらしい。
  • 「Emailはユニークではない可能性があり、
    ユーザーを識別する主キーとしては適さない」

実装

プロトコル別

OIDC

Pairwise Pseudonymous Identifier (PPID)

SAML

SAMLでは、

  • この実装は、

の仕様に関連する。

計算方法

SAMLでは明示されていないが、OIDCでは明示されている。

標準仕様

要件抽出

  • Client毎にユニークになればイイ。
    sub = ハッシュ関数 ( Client毎にユニークな値 || userid || salt )
  • 「Client毎にユニークな値」の要件
  • 一般的には、
    RedirectUri?JwksUri?が使用される(Client側の検証可能なURI)。
  • ClientIDは、
    削除・追加で変わり、変更後、重複しているケースもある。
  • RedirectURIは
    • ドメイン保持すれば変更されない(が、EndPoint?までか?FQDNまでか?など悩ましい問題も)
    • CIBARedirectUri?が無いのでJwksUri?とか言うがFAPIではJwksUri?を使わないなど。
  • saltが必要になる理由
    「Client毎にユニークな値」が漏れ得る場合(ClientID、RedirectUri?)、
    前述の計算方法が解れば、PPID間の紐付け可能になるタメ。

オレオレ

  • 以下の計算式を使用する。
    sub = ハッシュ関数 ( Client毎にユニークな値 || userid || salt )
  • ハッシュ関数 : SHA-256
  • Client毎にユニークな値
  • 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グラント種別
  • Clientに名寄せは無いダロと。

Resource Serverを使う場合、PPIDは不適合。

sub(user)を特定できないので、

  • User Storeを参照できないので、
  • User Resourceを参照できない。

認証用のClientと、Resourceアクセス用のClientを分ける。

  • PPIDは、
    • 認証用のClientに適用し、
    • Resourceアクセス用のClientには適用しない。
  • ただし、認証用のClientも、
    • フェデレーションする必要はあるし、
    • フェデレーション・スタイルを決定する必要もある。
    • PPIDでも、紐付けに必要な、ユーザ名やメアド程度は
      取れるように実装する必要があるケースは多そう。

汎用認証サイト

のケースを考えると。

SPの外部ログイン

  • SPのログインにId連携は必須ではないと言う感じ。
  • IdP/StSから、
    • 取得したトークン検証が済めばログインするなど。
    • 取得したユーザ名やメアドを、そのまま使う。
  • PPIDで、ユーザ名やメアドが取れない場合は、
    ローカル・ログインの機能を実装し、
    ローカルのログイン・アカウントと外部アカウントを紐付ける。
    (となると、ローカルのログインの実装が必要になる。)
  • IdP/StSとの関係次第
  • 関係が密であれば、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国際標準, :認証基盤, :クレームベース認証


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-07-25 (土) 01:41:10 (65d)