Open棟梁Project - マイクロソフト系技術情報 Wiki * 目次 [#m08b54ac] #contents *概要 [#f64b233c] [[認証連携(IDフェデレーション)>#z111c7bd]]とか、[[OpenID / OAuth / OpenID Connect>#bd876705]]とか、 大体、認証で発行するクレーム(トークン)的なものを使用して認可する仕掛けになっている。 -認証は、Idp(Identity Provider)が行う。 -クレーム(トークン)の発行はSTS(Security Token Service)が行う。 -認可は、SP(Service Provider)が行う。 このSTS(Security Token Service)が発行する~ クレーム(トークン)的なものにより、認証(Idp)と認可(SP)を分離できるのが醍醐味。 従って、分散型の認証方式を提供するオープンな認証システムと言える。 *用語 [#h4a44b62] 各用語については下記を参照。 **[[認証連携(IDフェデレーション)>#z111c7bd]] [#o0d18ba5] -Service Providers, Identity Providers & Security Token Services~ http://www.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] -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内に同梱されている。 -End User --Consumerに対して自分のIdentityの認証を要求しようとするユーザ --自分のIdentityを認証しConsumerに紹介状を送るIdPに加入する必要がある。 -User-Agent~ --End Userが所有するWebブラウザ --特別なプラグインやJavaScriptは不要 -Identifier~ --End Userが所有するURL(httpまたはhttpsをschemeとするURI)を使用して認証 --&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 Connect]] [#q37553ef] *種類 [#pa0ef406] **認証連携(IDフェデレーション) [#z111c7bd] ***特徴 [#j361796e] -OpenAM、[[ADFS>フェデレーション サービス (AD FS)]] などの実績のあるSSOをサポートする認証連携(IDフェデレーション)基盤 -異なるベンダのアクセス制御製品間の相互運用性を推進し、~ 企業間の独立したサービスをグローバルなSSOで連携させることが可能。 -認証されたアカウントを偽装するにはカスタムの実装が必要。 -認証連携(IDフェデレーション)の利点~ http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso02/adfs2sso02_01.html --上記のフェデレーションの動作におけるポイントの1つとしては、サービス・プロバイダ側で直接認証(IDやパスワードの入力)を行っていないので、サービス・プロバイダへのネットワーク経路上をパスワードが流れないという点がある。~ もう1つ、サービス・プロバイダが直接アイデンティティ・プロバイダと通信を行っていないので、アイデンティティ・プロバイダとサービス・プロバイダは別々のネットワークに存在してもよいという点も挙げられる。 --これらにより、イントラネット上のアイデンティティ・プロバイダを利用して、クラウド上のサービス・プロバイダへセキュアなアクセスを行うといったことが可能になる。~ また同時に、イントラネット上の社内アプリケーションにも同様の仕組みを導入することにより、イントラネットとクラウドにまたがったセキュアなシングル・サインオンという非常に利便性の高いシステムを構築できる。 ***プロトコル [#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)]] **[[OpenID]] / [[OAuth]] / [[OpenID Connect]] [#bd876705] 中央集権型でない、分散ID認証システム -ブラウザベースの認証APIの標準化から始まった。 -認可するクレーム(トークン)として、~ 紹介状を受け取るか、合鍵を受け取るかの違いがある。 ***[[OpenID]] [#td7a8a84] 紹介状を受け取る。 -[[OpenID 1.1]]:Consumer経由で紹介状を作成して送信する公証人Idpを呼び出す。 -[[OpenID 2.0]]:RP経由で紹介状を作成して送信する公証人OPを呼び出す。 -[[OpenID]]の仕様上、誰でもConsumer(RP)やIdp(OP)になれるという点から、~ 特にConsumer(RP)はどのIdp(OP)を信用したらよいかという問題が残る。 ***[[OAuth]] [#k66961ce] -エンドユーザはサービスAに対してあるサービスB上のリソースや機能にのアクセス許可を与える。 -サービスBは、エンドユーザの許可を受けたサービスA上のリソースや機能にアクセスする。 -OAuthでは、紹介状ではなく、合鍵を受け取る。 --[[OAuth]]で合鍵を作成して送信するXをYと呼ぶ。 --合鍵をもらったほうが色々とサービス提供に便利。 --[[OpenID]]よりもOAuth認証をしたいというサイトが増えてきている。 --合鍵として、JSON Web Token というAccess Tokenを使用する。 ***[[OpenID Connect]] [#ya3d2a7b] [[OAuth]]で正しく認証する。 -サイトにアクセスする方法は[[OAuth]]のResource Access と同じ。 -違いは、紹介状のコピーだけが入っているロッカーの鍵を渡す所。 --紹介状:OpenIDトークン --ロッカー:UserInfo (ユーザ情報)Endpoint --鍵は、[[OAuth]]と異なり、UserInfo Endpoint が発行する。 --SP(Service Provider)はこの鍵の発行者を信頼し、鍵の正統性の検証が可能。 ***参考 [#z1b67156] -非技術者のためのOAuth認証(?)とOpenIDの違い入門~ @_Nat Zone - Identity, Privacy and Music~ http://www.sakimura.org/2011/05/1087/ -[[OpenID]] --OpenIDの仕様と技術 連載インデックス - @IT~ http://www.atmarkit.co.jp/fsecurity/index/index_openid.html -[[OAuth]] --デジタル・アイデンティティ技術最新動向(1):~ 「OAuth」の基本動作を知る (1/2) - @IT http://www.atmarkit.co.jp/ait/articles/1208/27/news129.html --第1回 OAuthとは?―OAuthの概念とOAuthでできること:~ ゼロから学ぶOAuth|gihyo.jp … 技術評論社~ http://gihyo.jp/dev/feature/01/oauth/0001 -- *選定 [#uc590139] **[[認証連携(IDフェデレーション)>#z111c7bd]] [#tf6b40d2] ***SAML [#j6f22d8d] ***WS-Federation [#fa1f759b] **[[OpenID / OAuth / OpenID Connect>#bd876705]] [#h2bbea7c] ***[[OpenID]] [#m176502c] ***[[OAuth]] [#o4faf978] ***[[OpenID Connect]] [#ad991e4a]