「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ID連携・クレームベース認証とは †
ID連携とは、
- アイデンティティ（ID）
& フェデレーション（ID連携）
- クレームベース認証
クレームセットを使用して認証する。
アイデンティティ（ID） †
- ＝ ユーザを特徴づける属性情報
- ≠ ユーザID（Identifier）
フェデレーション（ID連携） †
このユーザ属性情報をクレームセットに
同梱してユーザに渡す（ ＝ ID連携）。
ID連携・クレームベース認証の目的 †
IDの一元管理 †
- アプリ側に重複したユーザストアを持たせない。
- 同期不要。一元管理された、最新のIDを利用する。
SSO（シングルサインオン） †
- パスワードをユーザに分散管理させたくない。
- クラウド上のサービスを自社内で認証したい。
- コンシューマー向けアプリをSNS認証で利用させたい。
クレームベース認証の仕組み †
SAML / WS-FEDとか、OpenID / OAuth / OpenID Connectなど、
大体、認証後に発行するトークン（クレーム）的なものを使用して認可（認証）する仕掛けになっている。
役割 †
- Idp（Identity Provider）
認証を行う。
- STS（Security Token Service）
トークン（クレーム）の発行を行う。クレームは、
- Idp（Identity Provider）によって発行され、
- STS（Security Token Service）によって
- 1 つ以上の値が指定されてから、
- STSが発行するセキュリティ トークンにパッケージ化される。
- SP（Service Provider）
認可を行う。
特徴 †
このSTS（Security Token Service）が発行する
トークン（クレーム）的なものにより、認証（Idp）と認可/認証（SP）を分離できる。
- OAuthに関しては、トークンとクレームの発行が分離されている。
トークン発行までがOAuthの仕様なので、認証用のクレーム発行は拡張仕様を実装する必要がある。
参考 †
以下が参考になる。
用語 †
各用語については下記を参照。
真正性 (authenticity) †
ある「主体」（subject）又は資源が、
「主張」（claim）どおりであることを
確実にする特性。
主体（subject） †
UserID、メアド、ユーザ名等。
主張（claim） †
主体の主張、主体の属性。
認証/認可 †
認証（Authentication） †
- 本人性を確認する
- ID/パスワード認証、生体認証、ワンタイム・パスワード認証
認可（Authorization） †
あるリソースへアクセスするための権限を与える（認証後のアクセス制御）
ID連携（IDフェデレーション） †
意味 †
フェデレーションは、「連携」の意味。
- SAML、OpenIDなどの認証・認可に関わるプロトコルやその仕組みの総称として使われることがある。
- IDやパスワードの発行者（IdP：Identity Provider）と、IDの利用者（RP：Relying Party）の2つに役割を分担する。
- ID連携（IDフェデレーション）
- IdP と SP の間でユーザーアカウントを紐付けることを意味する。
- IdP と SP は信頼関係を結んだ後、アカウント連携を行う必要がある。
利点 †
それによって、以下の様な利点が発生する。
- サービス・プロバイダ側で直接認証（IDやパスワードの入力）を行っていない。
∴ サービス・プロバイダへのネットワーク経路上をパスワードが流れない。
- サービス・プロバイダが直接アイデンティティ・プロバイダと通信を行っていない。
∴ アイデンティティ・プロバイダとサービス・プロバイダは別々のネットワークに存在してもよい。
イントラネット上のアイデンティティ・プロバイダを利用して、
- クラウド上のサービス・プロバイダへセキュアなアクセスを行うといったことが可能になり、
- イントラネット上の社内アプリケーションにも同様の仕組みを導入することにより、
セキュアなシングル・サインオンという非常に利便性の高いシステムを構築できる。
クレームベース認証界隈のコンテキストでは、
SAMLやJWTなどのフォーマットが使用される。
トークン †
IdP/STSが発行する認証・認可の情報
（認証情報やユーザーや属性、アクセス権限等の情報）。
クレームセット †
認証連携（IDフェデレーション）で連携されるユーザ属性情報
プロトコル †
役割関連用語の対応表 †
紛らわしい、クレームベース認証の役割関連用語の対応表をまとめてみた。
| # | XML系 | OpenID系 | OAuth2.0/OIDC系 |
| SAML | WS-FED | OpenID1.0 | OpenID2.0 | OAuth1.0 | 認可の４役割 | OIDCの認証を考慮した呼称 |
| 1 | Subject | End User | User | Resource Owner |
| 2 | SP (Service Provider), RP (Relying Party) | RP (Relying Party) | Consumer | OAuth Consumer | Client (Public Client, Confidential Client) | Client, RP (Relying Party) |
| 3 | IdP (Identity Provider), CP (Claim Provider)
STS (Security Token Service ) | IdP (Identity Provider) | OP (OpenID Provider) | OAuth Service Provider | Authorization Server (AuthZ) | Authentication Server (AuthN)、
若しくは、IdP/STS（OP:OpenID Provider） |
| 4 | －認証のみなので対応する概念が存在しない－ | Resource Server |
- 一般向けには、SAML系の用語が良く使われる（IdP/STS、SP、RP辺りは、結局OIDCでも使われているので）。
- 最近は、OAuth2/OIDCの隆盛に伴い、上記表中の「認可の４役割」用語も利用される。
- 説明資料によって、上記表中の横並びの役割は混同されていることが多い（意味も同じ）。
- 「#3」は、ユーザストア機能とトークン発行機能に分けて表現されることがある（IdP/STSなど、CPも≒STSか。）。
詳細 †
プロトコル †
選定 †
プロトコル †
その他 †
参考 †
デジタル・アイデンティティ †
slideshare.net/matake †
Identity | @_Nat Zone †
http://www.sakimura.org/category/identity/
Windowsで構築する、クラウド・サービスと社内システムのSSO環境 †
- Windowsで構築する、クラウド・サービスと社内システムのSSO環境 - ＠IT
Tags: :認証基盤, :クレームベース認証
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
OAuth_And_OIDC.png