マイクロソフト系技術情報 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メインなので結局 ClientID を使っている。

汎用認証サイト

のケースを考えると。

SPの外部ログイン

SPの汎用認証サイトを使用したログイン

  • 関係が密であれば、Id連携(≒useridの要求)は不要。
    (トークン検証が済めばログインするなど)
  • 関係が疎であれば、Id連携(≒useridの要求)をする。
    (トークン検証後、ローカルuseridと連携useridを紐付ける)

※ SPのログインにId連携は要らないなと言う感じ。

IdPの外部ログイン

汎用認証サイト同士(のHybrid-IdPとして)の外部ログイン

  • STSとして機能する場合に関しては、
    scopeで要求する事でuseridをクレームに含めることはできるので、
    以下の様に、emailの特性毎に使い分ける必要がある。
    • 企業メアド前提なら、sub = emailで実装しても良い。
    • フリーメール等が許容されるなら、
      • scopeでuseridも要求する。
      • 更に必要なら、PPID化する。

Issue

参考

OpenID Connect

OSSコンソーシアム


Tags: :IT国際標準, :認証基盤, :クレームベース認証


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-12-18 (水) 10:55:33 (38d)