[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]] * 目次 [#m08b54ac] #contents *概要 [#f64b233c] [[SAML / WS-FED>#z111c7bd]]とか、[[OpenID / OAuth / OpenID Connect>#bd876705]]など、~ 大体、認証後に発行するトークン(クレーム)的なものを使用して認可(認証)する仕掛けになっている。 -認証は、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)を分離できる。 -分散型の認証方式を提供するオープンな認証システムと言える~ (これを世の中では[[認証連携(IDフェデレーション)>#i5c2d8e8]]と呼んでいる)。 -OAuthに関しては、トークンとクレームの発行が分離されている。~ トークン発行までがOAuthの仕様なので、認証用のクレーム発行は拡張仕様を実装する必要がある。 以下が参考になる。 -IdM実験室: 早わかり!クレイムベースのアイデンティティ&アクセス管理~ http://idmlab.eidentity.jp/2010/04/blog-post.html *用語 [#h4a44b62] 各用語については下記を参照。 **認証連携(IDフェデレーション) [#i5c2d8e8] IDやパスワードの発行者(IdP:Identity Provider)と、~ IDの利用者(RP:Relying Party)の2つに役割を分担する。 それによって、以下の様な利点が発生する。 -サービス・プロバイダ側で直接認証(IDやパスワードの入力)を行っていない。~ ∴ サービス・プロバイダへのネットワーク経路上をパスワードが流れない。 -サービス・プロバイダが直接アイデンティティ・プロバイダと通信を行っていない。~ ∴ アイデンティティ・プロバイダとサービス・プロバイダは別々のネットワークに存在してもよい。~ イントラネット上のアイデンティティ・プロバイダを利用して、 --クラウド上のサービス・プロバイダへセキュアなアクセスを行うといったことが可能になり、~ --イントラネット上の社内アプリケーションにも同様の仕組みを導入することにより、~ セキュアなシングル・サインオンという非常に利便性の高いシステムを構築できる。 -ITproまとめ - 認証連携:ITpro~ http://itpro.nikkeibp.co.jp/article/COLUMN/20140122/531443/ **[[SAML / WS-FED>#z111c7bd]] [#o0d18ba5] -Service Providers, Identity Providers & Security Token Services~ https://www2.empowerid.com/learningcenter/technologies/service-identity-providers ***Microsoft Platform [#x529dcd7] Active Directory Federation ServicesやWIF(Windows Identity Foundation)に関連する用語。 -[[WIF]]~ Windows Identity Foundation -[[ADDS>ドメイン サービス (AD DS)]]~ Active Directory Domain Services -[[ADFS>フェデレーション サービス (AD FS)]]~ Active Directory Federation Services -AZAD~ Azure Active Directory ***Claims-based identity term definitions [#xc4899e2] -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) ***その他 [#s5d7cb56] -Federation Trust --要求プロバイダー信頼~ Claim Provider Trust(CP Trust) --証明書利用者信頼~ Relying Party Trust(RP Trust) --要求プロバイダー信頼と証明書利用者信頼~ http://azuread.net/2014/02/19/%E8%A6%81%E6%B1%82%E3%83%97%E3%83%AD%E3%83%90%E3%82%A4%E3%83%80%E3%83%BC%E4%BF%A1%E9%A0%BC%E3%81%A8%E8%A8%BC%E6%98%8E%E6%9B%B8%E5%88%A9%E7%94%A8%E8%80%85%E4%BF%A1%E9%A0%BC/ -Claim Rules~ [[要求規則(クレーム ルール)>フェデレーション サービス (AD FS)#w4002b44]] **[[OpenID / OAuth / OpenID Connect>#bd876705]] [#sdca2e87] -OpenIDの仕様と技術(1):仕様から学ぶOpenIDのキホン (3/3) - @IT~ http://www.atmarkit.co.jp/ait/articles/0707/06/news135_3.html -OpenIDの仕様と技術(5):OpenID Authentication 2.0時代の幕開け (1/3) - @IT~ http://www.atmarkit.co.jp/ait/articles/0802/19/news133.html -誰にも頼まれてないのに次世代Identifier用語集を勝手に定義してみた - 豆無日記~ http://nobeans.hatenablog.com/entry/20090202/1233585856 ***[[OpenID]] [#w507f337] -End User --Consumerに対して自分のIdentityの認証を要求しようとするユーザ --Consumerに紹介状(OpenID Token)を送るIdP(Identify Provider)に加入する必要がある。 -User-Agent --End Userが所有するWebブラウザ --特別なプラグインやJavaScriptは不要 -Consumer --End Userが入力したID(Identifier)を使用し、IdP(Identify Provider)に対して認証要求するWebサービス --ConsumerはいずれのIdP(Identify Provider)に対しても認証要求を遂行する必要がある。 --&color(red){OpenID 2.0};からはRelying Party(RP)と名称が変更されている。~ OpenIDでは、STS相当が独立しておらず、当該機能がRPとIdp内に同梱されている。 -Identifier --End Userが所有するURL(httpまたはhttpsをschemeとするURI) --IdP(Identify Provider)は、Identifierを使用して認証する。 --&color(red){OpenID 2.0};からはXRIというURIを拡張した形式で表されたものを指す。 --Claimed Identifier ---End Userが自分で所有していると主張するIdentifier ---Consumerによってまだ確認されていないIdentifier --Verified Identifier~ ConsumerがEnd Userが所有していると認めたIdentifier --User-Supplied Identifier~ &color(red){OpenID 2.0};からの用語で、 ---End UserによってRPに対して提示されるIdentifier ---Claimed IdentifierまたはOP Identifierの総称 -Identify Provider(Idp) --End Userが所有するClaimed Identifierの暗号化された証明(紹介状)を発行。 --&color(red){OpenID 2.0};からはOpenID Provider(OP)とも呼ばれる。 -&color(red){OpenID 2.0};から追加されたOpenID Provider(OP)用語 --OP Identifier~ OPを表すIdentifier --OP EndPoint URL~ OPのエンドポイントのURL --OP-Local Identifier ---使用するOPが内部的に使用するユーザID。 ---OPがOP上の認証処理等で使用する。 ***[[OAuth]] [#qa5b24ca] 用語に関しては、[[OpenID]]と≒。 -Resource Owner (User) --Clientにアクセス権限の付与を行うユーザ自身 --ClientにAccess Tokenを送るOAuth Service Provider(AuthorizationServer)に加入する必要がある。 -User-Agent --End Userが所有するWebブラウザ --特別なプラグインやJavaScriptは不要 -OAuth Client (旧 OAuth Consumer)~ OAuth Serverが提供するAPIを利用する側のサービス --Instagram --Foursquare --Pinterest -OAuth Server (OAuth Service Provider) --OAuthをサポートしたAPIを提供しているサービス ---Twitter ---Facebook --OAuth Service Providerは更に以下の2つに分類される。 ---AuthorizationServer~ 認証・認可のサーバー機能(認証チケットとAccess Tokenの発行) ---ResourceServer~ Access Tokenを受けてリソースアクセスを提供する ***[[OpenID Connect]] [#q37553ef] OpenID Authentication 2.0の置き換えであるため、OPなどの用語を使用しているので、~ [[OpenID Authentication 2.0の用語>#w507f337]]を使用する(ただし実装は、OAuthの拡張)。 *種類 [#pa0ef406] **SAML / WS-FED [#z111c7bd] ***特徴 [#j361796e] -認証連携(IDフェデレーション)プロトコル -異なるベンダのアクセス制御製品間の相互運用性を推進し、~ 企業間の独立したサービスをグローバルなSSOで連携させることが可能。 -OpenAM、[[ADFS>フェデレーション サービス (AD FS)]]などのミドルウェアでサポートされている。 ***プロトコル [#sa6cf928] -クッキー認証チケットを使用しない。 --クッキーを第三者が不正使用してなりすましを許す可能性がある。 --クッキーはクッキードメインの中でしか有効ではない。 -[[SAML]] --SAML Core ---SAML Assertions ---SAML Protocols --SAML Bindings --SAML Profiles ---SAML Assertions ---SAML Protocols ---SAML Bindings --SAML Metadata -[[WS-Federation]] --Assertionsには、SAML Assertionsを使用。 --以下のプロファイルがある。~ パッシブリクエスタプロファイル(Webアプリ用)~ アクティブリクエスタプロファイル(Webサービス用) ***製品 [#ccf56f5a] -OpenAM -[[ADFS>フェデレーション サービス (AD FS)]] ***ライブラリ [#i89b5ff2] -[[WIF]] **[[OpenID]] / [[OAuth]] / [[OpenID Connect]] [#bd876705] 中央集権型でない、分散ID認証システムのオープン仕様。 -ブラウザベースの認証APIの標準化から始まった。 -トークン(クレーム)として、 --紹介状(OpenID Token)を受け取るか? --合鍵(Bearer Token)を受け取るか? >の違いがある。 ***[[OpenID]] [#td7a8a84] OpenID財団の登録商標。 代表的な使用例として、 -OpenID Authentication 2.0 -OpenID Connect -OpenID Foundation などがあるが、 ここでは、OpenID Authentication 1.1, 2.0を指す。 要求元であるWebサイトに対して、 -あるユーザが認証された旨の情報、 -認証をどのように行ったかの情報、 -当該ユーザの属性情報を、 紹介状(OpenID Token)として、提供元となるIdpが転送するプロトコル。 -OpenID 1.1:Consumer経由で紹介状を作成して送信する公証人Idpを呼び出す。 -&color(red){OpenID 2.0};:RP経由で紹介状を作成して送信する公証人OPを呼び出す。 -[[OpenID]]の仕様上、誰でもConsumer(RP)やIdp(OP)になれるという点から、~ 特にConsumer(RP)はどのIdp(OP)を信用したらよいかという問題が残る。 ***[[OAuth]] [#k66961ce] -紹介状(OpenID Token)ではなく、合鍵(Bearer Token)を渡し、権限付与を行うプロトコル。 -ユーザが外部サービスにパスワードを教えることなく、~ サービス間でユーザの同意のもとにセキュアにユーザの権限情報(合鍵)を受け渡しする。 --エンドユーザはサービスAに対してあるサービスB上のリソースや機能に~ 取得/追加/更新/削除などのアクセス許可を与える。 --サービスAは、エンドユーザの許可を受けたサービスB上のリソースや機能にアクセスする。 -[[OpenID]]よりもOAuth認証をしたいというサイトが増えてきている。~ ただし、認証機能は無いとされているので、拡張仕様で、~ "安全な"紹介状(クレーム)を発行する仕組みを追加で作り込む必要がある。 ***[[OpenID Connect]] [#ya3d2a7b] -OpenID Authentication 2.0 のプロトコルを引き継ぐことをせず、~ [[OAuth]] 2.0を拡張し、正しく認証する次世代のOpenID。 -OpenID Authentication 2.0 は、[[OpenID Connect]]によって置換えられた。 -サイトにアクセスする方法は[[OAuth]]のResource Access と同じ。 -違いは、紹介状(OpenID Token)のコピーだけが入っているロッカーの鍵を渡す所。 --ロッカー:UserInfo (ユーザ情報)Endpoint --鍵は、[[OAuth]]と異なり、UserInfo Endpoint が発行する。 --SP(Service Provider)はこの鍵の発行者を信頼し、鍵の正統性の検証が可能。 -NIST SP 800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。~ 金融システムや電子政府/行政システムにも利用できることを意味している。 -設計思想 --モジュラーデザイン --簡単なことは簡単に --難しいことも可能に *選定 [#uc590139] 以下の辺りを読むと、 -SAMLとOAuth/OpenID Connect:~ 新たな「アイデンティティ戦争」とIdMaaSとしてのSalesforce - @IT~ http://www.atmarkit.co.jp/ait/articles/1402/10/news074.html **[[SAML /WS-FED>#z111c7bd]] [#tf6b40d2] エンタープライズにフォーカスした技術と言える(SOAP/XMLベース)。 ***SAML [#j6f22d8d] ***WS-Federation [#fa1f759b] **[[OpenID / OAuth / OpenID Connect>#bd876705]] [#h2bbea7c] コンシューマー向け技術と言える。~ (REST/JSONベースで、Webアプリケーションに組み込みやすい)。 -OpenID 2.0とOAuth 1.0 --仕様は、同時期に策定された。 --ユーザから見た画面遷移もほぼ同じ --開発者の間で機能が比較された。 -OAuth 2.0 --合鍵(Bearer Token)を渡し、認可する仕組み。 --認証機能は無いとされているので、拡張仕様で、~ "安全な"紹介状(クレーム)を発行する仕組みを追加で作り込む必要がある。 -OpenID Connect~ OAuth 2.0を拡張して、OpenID 2.0を置き換えたもの。 ***[[OpenID]] [#m176502c] -OpenID 2.0 (OAuthとの比較)~ OpenID 2.0とOAuth 1.0の仕様は、同時期に策定された。 -メリット --一度の実装で複数のOPに対応できる。 --新たなOPが増えた場合もコストをかけずに対応が可能 --ユーザー認証を実装でき、その上サービス独自のAPIを利用できる。 -デメリット --OAuth 1.0のように、サービス上のAPIに権限を付与する機能はない。 ***[[OAuth]] [#o4faf978] -OAuth 1.0 (OpenIDとの比較)~ OpenID 2.0とOAuth 1.0の仕様は、同時期に策定された。 --メリット ---Access Tokenを返すことで、(認証+)APIに対する権限付与ができる。 ---上記のAccess Tokenを使用して、プロフィール情報(=クレーム的なもの)~ を取得できるAPIが提供されれば、認証の処理を実装できる。 --デメリット ---認証結果の定義や認証ポリシーの指定方法が存在しない。 ---従って、OAuth の Clientと、Resources Serverに追加実装が必要になる。 -OAuth 2.0~ OAuth 1.0に以下の改良を加えている。 --HTTPSを必須にし、署名をなくし、Access Token取得も簡略化 --Request Tokenを無くし、Access Tokenのみでリソース取得が可能に --Webアプリも含め、4つのクライアントプロファイルを仕様化 --詳しくは「[[OAuth 1.0とOAuth 2.0の違い>OAuth#s44d10cb]]」を参照。 ***[[OpenID Connect]] [#ad991e4a] 次世代OpenID -OpenID 2.0のプロトコルを引き継ぐことをせず、~ OAuth 2.0を拡張して、OpenID 2.0を置き換えたもの。 --これまで足りなかった以下のような機能拡張がされている。 ---認証結果のやりとり ---統一的な属性情報の提供 ---OP探索、動的なRP登録 ---RPに戻った後のセッション管理 -実装(RP) --RPはOAuth 2.0のリクエストを少し変更するだけで、利用できる。~ OAuth 2.0のリクエストパラメータに特定の値を指定するだけ。 --複数のクライント・フローを実装するのは手間。~ しかし、Idpを開発するのに比べれば、RPを開発する方が楽。 -用途 --NIST SP 800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。 --金融システムや電子政府/行政システムにも利用できることを意味している。 ***参考 [#zf9f7982] -OpenIDやOAuthやらの比較 - Carpe Diem~ http://christina04.hatenablog.com/entry/2015/01/26/194841 -非技術者のためのOAuth認証(?)とOpenIDの違い入門~ @_Nat Zone - Identity, Privacy and Music~ http://www.sakimura.org/2011/05/1087/ -デジタル・アイデンティティ技術最新動向(3):~ OpenIDが果たす役割を知る (2-2) - @IT~ http://www.atmarkit.co.jp/ait/articles/1209/20/news140_2.html *デジタル・アイデンティティ [#ra858f1a] -デジタルアイデンティティ - Wikipedia~ https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%82%A2%E3%82%A4%E3%83%87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%86%E3%82%A3 -デジタルアイデンティティ Digital Identity~ http://shop.oreilly.com/product/9780596008789.do **TakahikoKawasaki - Qiita [#p6b71a1e] http://qiita.com/TakahikoKawasaki -OAuth & OpenID Connect 関連仕様まとめ - Qiita~ http://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3 -OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る - Qiita~ http://qiita.com/TakahikoKawasaki/items/f2a0d25a4f05790b3baa -【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る - Qiita~ http://qiita.com/TakahikoKawasaki/items/30fbd546935cea914e4f -OAuth & OpenID Connect の不適切実装まとめ - Qiita~ http://qiita.com/TakahikoKawasaki/items/efbbd2c5875577c911a3 -OAuth 1.0 のほうが OAuth 2.0 より安全なの? - Qiita~ http://qiita.com/TakahikoKawasaki/items/3600b28af7b63671b968 **Identity | @_Nat Zone [#h35c4901] http://www.sakimura.org/category/identity/ -非技術者のためのデジタル・アイデンティティ入門~ http://www.sakimura.org/2011/06/1124/ **デジタル・アイデンティティ技術最新動向 [#y7d9a75c] -デジタル・アイデンティティ技術最新動向 連載インデックス - @IT~ http://www.atmarkit.co.jp/fsecurity/index/index_digid.html --「OAuth」の基本動作を知る~ http://www.atmarkit.co.jp/fsecurity/rensai/digid01/01.html --RFCとなった「OAuth 2.0」――その要点は?~ http://www.atmarkit.co.jp/fsecurity/rensai/digid02/01.html --OpenIDが果たす役割を知る~ http://www.atmarkit.co.jp/fsecurity/rensai/digid03/01.html --「OpenID Connect」を理解する~ http://www.atmarkit.co.jp/fsecurity/rensai/digid04/01.html --UDIDにおけるセキュリティ&プライバシー問題~ http://www.atmarkit.co.jp/ait/articles/1211/06/news004.html --UDIDがはらむプライバシー問題~ http://www.atmarkit.co.jp/ait/articles/1212/18/news007.html --認証UX標準化を目指すAccount Chooser~ http://www.atmarkit.co.jp/ait/articles/1301/28/news010.html --ユーザー中心のアクセス管理を目指すプロトコル~ http://www.atmarkit.co.jp/ait/articles/1305/09/news003.html **Windowsで構築する、クラウド・サービスと社内システムのSSO環境 [#j88d036c] -Windowsで構築する、クラウド・サービスと社内システムのSSO環境 - @IT --第1回 クラウド・コンピューティングとアイデンティティ管理の概要~ http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso02/adfs2sso02_01.html --第2回 クラウド・コンピューティング時代の認証技術~ ---1.アイデンティティ連携(フェデレーション)の要素技術~ http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso02/adfs2sso02_01.html --第3回 クラウド・サービスと社内ADとのSSOを実現する(前)~ http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso03/adfs2sso03_01.html --第4回 クラウド・サービスと社内ADとのSSOを実現する(後)~ http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso04/adfs2sso04_01.html ---- Tags: [[:認証基盤]], [[:クレームベース認証]]