Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
認証連携(IDフェデレーション)とか、OpenID / OAuth / OpenID Connectとか、
大体、認証で発行するクレーム(トークン)的なものを使用して認可する仕掛けになっている。
- 認証は、Idp(Identity Provider)が行う。
- クレーム(トークン)の発行はSTS(Security Token Service)が行う。
- 認可は、SP(Service Provider)が行う。
このSTS(Security Token Service)が発行する
クレーム(トークン)的なものにより、認証(Idp)と認可(SP)を分離できるのが醍醐味。
従って、分散型の認証方式を提供するオープンな認証システムと言える。
用語 †
各用語については下記を参照。
Microsoft Platform †
Active Directory Federation ServicesやWIF(Windows Identity Foundation)に関連する用語。
- WIF
Windows Identity Foundation
- ADDS
Active Directory Domain Services
- ADFS
Active Directory Federation Services
- AZAD
Azure Active Directory
Claims-based identity term definitions †
- IdP & CP
- IdP : Identity Provider ( = ADDS )
- CP : Claim Provider( = Idp at WS-Federation model)
- STS : Security Token Service ( = ADFS or AZAD )
- SP & RP
- SP : Service Provider( = ASP.NET WebSite?)
- RP : Relying Party( = SP at WS-Federation model)
その他 †
- Federation Trust
- 要求プロバイダー信頼
Claim Provider Trust(CP Trust)
- 証明書利用者信頼
Relying Party Trust(RP Trust)
- Consumer
- End Userが入力したID(Identifier)を使用し、IdP(Identify Provider)に対して認証要求するWebサービス
- ConsumerはいずれのIdP(Identify Provider)に対しても認証要求を遂行する必要がある。
- OpenID 2.0からはRelying Party(RP)と名称が変更されている。
OpenIDでは、STS相当が独立しておらず、当該機能がRPとIdp内に同梱されている。
- End User
- Consumerに対して自分のIdentityの認証を要求しようとするユーザ
- 自分のIdentityを認証しConsumerに紹介状を送るIdPに加入する必要がある。
- Identifier
- End Userが所有するURL(httpまたはhttpsをschemeとするURI)を使用して認証
- OpenID 2.0からはXRIというURIを拡張した形式で表されたものを指す。
- Claimed Identifier
- End Userが自分で所有していると主張するIdentifier
- Consumerによってまだ確認されていないIdentifier
- Verified Identifier
ConsumerがEnd Userが所有していると認めたIdentifier
- User-Supplied Identifier
OpenID 2.0からの用語で、
- End UserによってRPに対して提示されるIdentifier
- Claimed IdentifierまたはOP Identifierの総称
- Identify Provider(Idp)
- End Userが所有するClaimed Identifierの暗号化された証明(紹介状)を発行。
- OpenID 2.0からはOpenID Provider(OP)とも呼ばれる。
- OpenID 2.0から追加されたOpenID Provider(OP)用語
- OP Identifier
OPを表すIdentifier
- OP EndPoint? URL
OPのエンドポイントのURL
- OP-Local Identifier
- 使用するOPが内部的に使用するユーザID。
- OPがOP上の認証処理等で使用する。
OpenIDと≒。
- Resource Owner (User)
アクセス権限の付与を行うユーザー自身
- OAuth Server (OAuth Service Provider)
OAuthをサポートしたAPIを提供しているサービス
- OAuth Client (旧 OAuth Consumer)
OAuth Serverが提供するAPIを利用する側のサービス
- Instagram
- Foursquare
- Pinterest
種類 †
認証連携(IDフェデレーション) †
特徴 †
- OpenAM、ADFS
などの実績のあるSSOをサポートする認証連携(IDフェデレーション)基盤
- 異なるベンダのアクセス制御製品間の相互運用性を推進し、
企業間の独立したサービスをグローバルなSSOで連携させることが可能。
- 認証されたアカウントを偽装するにはカスタムの実装が必要。
- 認証連携(IDフェデレーション)の利点
http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso02/adfs2sso02_01.html
- 上記のフェデレーションの動作におけるポイントの1つとしては、サービス・プロバイダ側で直接認証(IDやパスワードの入力)を行っていないので、サービス・プロバイダへのネットワーク経路上をパスワードが流れないという点がある。
もう1つ、サービス・プロバイダが直接アイデンティティ・プロバイダと通信を行っていないので、アイデンティティ・プロバイダとサービス・プロバイダは別々のネットワークに存在してもよいという点も挙げられる。
- これらにより、イントラネット上のアイデンティティ・プロバイダを利用して、クラウド上のサービス・プロバイダへセキュアなアクセスを行うといったことが可能になる。
また同時に、イントラネット上の社内アプリケーションにも同様の仕組みを導入することにより、イントラネットとクラウドにまたがったセキュアなシングル・サインオンという非常に利便性の高いシステムを構築できる。
プロトコル †
- クッキー認証チケットを使用しない。
- クッキーを第三者が不正使用してなりすましを許す可能性がある。
- クッキーはクッキードメインの中でしか有効ではない。
- SAML Core
- SAML Assertions
- SAML Protocols
- SAML Profiles
- SAML Assertions
- SAML Protocols
- SAML Bindings
- Assertionsには、SAML Assertionsを使用。
- 以下のプロファイルがある。
パッシブリクエスタプロファイル(Webアプリ用)
アクティブリクエスタプロファイル(Webサービス用)
製品 †
中央集権型でない、分散ID認証システムのオープン仕様。
- 認可するクレーム(トークン)として、
紹介状を受け取るか、合鍵を受け取るかの違いがある。
OpenID財団の登録商標。
代表的な使用例として、
- OpenID Authentication 2.0
- OpenID Connect
- OpenID Foundation
などがあるが、
ここでは、OpenID Authentication 1.1, 2.0を指す。
要求元であるWebサイトに対して、
- あるユーザが認証された旨の情報、
- 認証をどのように行ったかの情報、
- 当該ユーザの属性情報を、
紹介状として、提供元となるIdpが転送するプロトコル。
- OpenID 1.1?:Consumer経由で紹介状を作成して送信する公証人Idpを呼び出す。
- OpenID 2.0?:RP経由で紹介状を作成して送信する公証人OPを呼び出す。
- OpenIDの仕様上、誰でもConsumer(RP)やIdp(OP)になれるという点から、
特にConsumer(RP)はどのIdp(OP)を信用したらよいかという問題が残る。
紹介状ではなく、合鍵を渡すプロトコル(≒認証+権限付与を行う)。
- ユーザが外部サービスにパスワードを教えることなく、
サービス間でユーザの同意のもとにセキュアにユーザの権限情報(合鍵)を受け渡しする。
- エンドユーザはサービスAに対してあるサービスB上のリソースや機能に
取得/追加/更新/削除などのアクセス許可を与える。
- サービスAは、エンドユーザの許可を受けたサービスB上のリソースや機能にアクセスする。
- OpenIDよりもOAuth認証をしたいというサイトが増えてきている。
OAuthで正しく認証する次世代OpenID。
- OpenID Authentication 2.0 は、OpenID Connectによって置換えられた。
- サイトにアクセスする方法はOAuthのResource Access と同じ。
- 違いは、紹介状のコピーだけが入っているロッカーの鍵を渡す所。
- 紹介状:OpenIDトークン
- ロッカー:UserInfo? (ユーザ情報)Endpoint
- 鍵は、OAuthと異なり、UserInfo? Endpoint が発行する。
- SP(Service Provider)はこの鍵の発行者を信頼し、鍵の正統性の検証が可能。
参考 †
選定 †
SAML †
WS-Federation †
- OpenID 2.0とOAuth 1.0
- 仕様は、同時期に策定された。
- ユーザから見た画面遷移もほぼ同じ
- 開発者の間で機能が比較された。
OpenID 2.0
- メリット
- 一度の実装で複数のOPに対応できる。
- 新たなOPが増えた場合もコストをかけずに対応が可能
- デメリット
- OAuth 1.0のように、サービス上のAPIに権限を付与する機能はない。
OAuth 1.0
- メリット
- 認証+APIに対する権限付与ができる。
- プロフィール情報を取得できるAPIが提供されれば認証+認可ができる。
- デメリット
- 認証結果と属性情報(クレーム)から認可するポリシーの指定方法が存在しない。
- 開発者がOAuth Client側の実装を作りこむ必要がある。
次世代OpenID
- OpenID 2.0からリクエスト/レスポンスを引き継ぐことをせず、
- OAuth 2.0をベースにして、これまで足りなかった以下のような機能を拡張。
- 認証結果のやりとり
- 統一的な属性情報の提供
- OP探索、動的なRP登録
- RPに戻った後のセッション管理
参考 †
デジタル・アイデンティティ †