- 追加された行はこの色です。
- 削除された行はこの色です。
Open棟梁Project - マイクロソフト系技術情報 Wiki
...工事中...
* 目次 [#kd1172d7]
#contents
*概要 [#jc8e8ef1]
認証基盤の選定や実装について纏めています。
*種類 [#o815c7c4]
**HTTPの認証 [#gf2d8060]
***匿名アクセス [#eed67f54]
-匿名アクセスを許可する。
-通常サービスの実行アカウントで実行される。
-（偽装をおこなえば）匿名アカウントで実行される。
***基本認証 [#mb2c8e20]
-ユーザー名とパスワードを入力するためのダイアログ ボックスが表示される。
-アカウント情報は暗号化されないBase64文字列でサーバに送られる。
-通常サービスの実行アカウントで実行される。
-（偽装をおこなえば）認証されたアカウントで実行される。
***ダイジェスト認証 [#tda3ddf0]
-ハッシング テクノロジーを使用し、解読不能な方法でユーザー情報を送信する。
-通常サービスの実行アカウントで実行される。
-（偽装をおこなえば）認証されたアカウントで実行される。
**Windwos認証 [#m4be745d]
HTTPやSMBなどの通信ライブラリに組み込まれており、~
実行アカウントを使用しオートネゴシエートで認証することが可能。
***NTLM認証 [#zb3340de]
-[[ミラーアカウント]]でも、[[Active Directory]]でも可能。
-（偽装をおこなえば）認証されたアカウントで実行される。
***ケルベロス認証 [#o8a80b4b]
-「[[Active Directory]]」が必要、インターネットに拡大できない。
-（偽装をおこなえば）認証されたアカウントで実行される。
**クッキー認証チケット型 [#la8f4c73]
クッキー認証チケットを発行するタイプ
-認証されたアカウントを偽装するにはカスタムの実装が必要。
***統合認証基盤型 [#mf25a493]
-SiteMinder、IceWallなどの実績のあるSSOをサポートする統合認証基盤
***実装ルール型 [#f5c72a77]
各アプリケーションに認証クッキーの（発行と）認証の機能を実装する。~
（Webアプリケーション毎に認証Formを作成する（Forms認証））
各アプリケーションに認証クッキーの（発行と）認証の機能を実装する。
**認証連携 [#z111c7bd]
以下、ASP.NETの認証の変遷
-Forms認証~
Webアプリケーション毎に認証Formを作成する
-ASP.NET MembershipProvider~
LDAPやユーザマスタテーブルなどの資格情報ストアを使用した認証のフレームワーク。
-ASP.NET Identity
--フォーム認証ではなく、OWINの認証用ミドルウェア（？）を使用
--資格情報ストアとして、Microsoftアカウント、Facebook、Twitter、Google等のソーシャルアカウントを利用可能
-WIF(Windows Identity Foundation)~
認証連携（IDフェデレーション）をサポート。
-OpenId Connect
--Microsoft.Owin.Security.OpenIdConnect
--WIF Extension for OAuth(OpenID Connect)
-参考
--「ASP.NET Identity」の登場背景と実際の使い方 （1-4）：CodeZine~
http://codezine.jp/article/detail/7709
--特集：ASP.NET 4.5新機能概説（3）- ＠IT~
ASP.NET MVCの新機能（OAuth／OpenIDによるログイン認証）~
http://www.atmarkit.co.jp/ait/articles/1304/23/news056_6.html
--新しい認証の仕組み ー ASP.NET Identity どっとねっとふぁん~
https://blogonos.wordpress.com/2013/11/29/%E6%96%B0%E3%81%97%E3%81%84%E8%AA%8D%E8%A8%BC%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF-%E3%83%BC-asp-net-identity/
**認証連携（IDフェデレーション） [#z111c7bd]
***特徴 [#j361796e]
-OpenAM、[[ADFS>フェデレーション サービス (AD FS)]]
などの実績のあるSSOをサポートする認証連携基盤
などの実績のある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 Metadata
--[[WS-Federation]]
---Assertionsには、SAML Assertionsを使用。
---以下のプロファイルがある。~
パッシブリクエスタプロファイル（Webアプリ用）~
アクティブリクエスタプロファイル（Webサービス用）
--[[OpenID / OAuth]]
--[[OpenID]]
***製品 [#ccf56f5a]
-OpenAM
-[[ADFS>フェデレーション サービス (AD FS)]]
*選定 [#i8941f0c]
**HTTPの認証 [#eb58ce03]
HTTPの認証なのでWebサーバでサポートされる。
**Windwos認証 [#m0ad1078]
Windows環境であれば。
-NTLM認証をサポートするクライアントも多い。
-SambaでLinux環境のケルベロス認証も可能。
--Samba4でのActive Directory構築 - OSSでLinuxサーバ構築~
http://www.oss-d.net/samba4/ad
***NTLM認証 [#zf1dd267]
-[[ミラーアカウント]]でも、[[Active Directory]]でも可能。
-デスクトップへのログインと連動したSSO認証が可能。~
ただし、[[ミラーアカウント]]の場合は、アカウントの管理が面倒。
-ベースクライアント認証でのダブルホップが不可能。
-ADが無いので、別途DBなどを用意して追加の承認の機能を実装できる。
***ケルベロス認証 [#a8d0341c]
-「[[Active Directory]]」が存在する場合。
-デスクトップへのログインと連動したSSO認証が可能。
-ベースクライアント認証でのダブルホップが可能。
-ADが有るので、各アプリケーションにLDAPを使用した追加の承認の機能を実装できる。
**クッキー認証チケット型 [#q11063ab]
-各アプリケーションに認証情報を使用した承認の機能を実装する。
***統合認証基盤型 [#bcd2a481]
-認証をISAPIレイヤで処理するので、基盤構築作業として対応でき、~
Webアプリケーション側に特別な作り込みは必要ないため、大きなメリットになる。
Webアプリケーション側に特別な作り込みは必要ないため、大きなメリットがある。
-ディレクトリ・サービスと連携している場合、~
各アプリケーションにこの情報を使用した追加の承認の機能を実装できる。
***実装ルール型 [#t68197e3]
-フレームワークに実装するとすると、こちらの方式になるが。
--Java、.NETなど言語が混在になると、個別の部品を整備する必要があり面倒になる。
---ASP.NETのForms認証
---独自Frameworkの独自認証
フレームワークに実装するとすると、こちらの方式になる。
**認証連携 [#tf6b40d2]
-Java、.NETなど言語が混在になると、個別の部品を整備する必要があり面倒になる。
--ASP.NETのForms認証
--独自Frameworkの独自認証
-このため、近年、下記のような認証/認可の仕組みの~
プロトコルレベルでの標準化が進んでいる。
--[[OpenID / OAuth]]
--認証連携（IDフェデレーション）
---[[SAML]]
---[[WS-Federation]]
---[[フェデレーション サービス (AD FS)]]
**認証連携（IDフェデレーション） [#tf6b40d2]
・・・
*余談 [#zf3414e4]
ASP.NETのForms認証では、
-クッキー認証チケットをクロスサイトで使用できる。
-ただし、クロスドメインでの引継は不可能。
クロスドメイン間のサイトで、テンポラリの認証情報をQueryString等で引き継いで、~
連携先サイトで、別途Forms認証のクッキー認証チケットを発行すると言う方式の実績もありますが、~
要件に合わないようなら、個別に「クッキー認証チケット型」の認証基盤の導入を検討した方が良さそうです。
*IdM実験室 [#j2ebb61a]
IdM実験室の情報をまとめて勉強してみます。
-WIF Extension for OAuth を使って OpenID Connect を体験~
http://idmlab.eidentity.jp/2012/03/wif-extension-for-oauth-openid-connect.html
-slideshare
--Ad（microsoftの方）のOpenId Connect対応~
http://www.slideshare.net/naohiro.fujie/admicrosoftopen-id-connect
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
