![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>セキュリティ]] * 目次 [#kd1172d7] #contents *概要 [#jc8e8ef1] 認証基盤の選定や実装について纏めています。 *種類 [#o815c7c4] **HTTPの認証 [#gf2d8060] ***匿名アクセス [#eed67f54] -匿名アクセスを許可する。 -通常サービスの実行アカウントで実行される。 -（偽装をおこなえば）匿名アカウントで実行される。 ***基本認証 [#mb2c8e20] -ユーザー名とパスワードを入力するためのダイアログ ボックスが表示される。 -アカウント情報は暗号化されないBase64文字列でサーバに送られる。 -通常サービスの実行アカウントで実行される。 -（偽装をおこなえば）認証されたアカウントで実行される。 ***ダイジェスト認証 [#tda3ddf0] -ハッシング テクノロジーを使用し、解読不能な方法でユーザー情報を送信する。 -通常サービスの実行アカウントで実行される。 -（偽装をおこなえば）認証されたアカウントで実行される。 **Windows認証 [#m4be745d] HTTPやSMBなどの通信ライブラリに組み込まれており、~ 実行アカウントを使用しオートネゴシエートで認証することが可能。 ***NTLM認証 [#zb3340de] -[[ミラーアカウント]]でも、[[Active Directory]]でも可能。 -（偽装をおこなえば）認証されたアカウントで実行される。 ***[[ケルベロス認証]] [#o8a80b4b] -「[[Active Directory]]」が必要、インターネットに拡大できない。 -（偽装をおこなえば）認証されたアカウントで実行される。 **クッキー認証チケット型 [#la8f4c73] クッキー認証チケットを発行するタイプ -認証されたアカウントを偽装するにはカスタムの実装が必要。 ***統合認証基盤型 [#mf25a493] -SiteMinder、IceWallなどの実績のあるSSOをサポートする統合認証基盤製品。 -これらは、下記HPで言う所の、「エージェント型」の統合認証基盤である。 -基礎から学ぶ！シングルサインオン - IT、IT製品の情報なら【キーマンズネット】~ http://www.keyman.or.jp/at/30001292/ ***ライブラリ型 [#f5c72a77] -各アプリケーション（や、使用しているフレームワーク）に~ 認証クッキーの発行と認証等の機能を実装している方式。 -昨今、OpenID系の[[クレームベース認証>#gf1f2d37]]の機能を実装しているケースもある。 **[[クレームベース認証]] [#gf1f2d37] 認証連携（IDフェデレーション）を使用して認証。 ***SAML, WS-FED [#u38db7ac] WIF(Windows Identity Foundation)を使用する。 ***OpenID / OAuth / OpenID Connect [#qb9e82f5] -Microsoft.Owin.Security.OpenIdConnectなどを使用する。 -WIF Extension for OAuth(OpenID Connect)などを使用する。 **生体認証 [#t71a546b] 以下のオープン化されている要素技術により、~ 生体認証を実装することは用意になってきている。 ***[[FIDO]]2.0 [#re880812] -[[Windows Hello + Microsoft Passport]] --[[Windows Hello]] --[[Microsoft Passport]] ---[[TPM（Trusted Platform Module）]] ---[[Web Authentication API]] ---[[Windows.Security.Credentials]] **その他 [#z76d01d9] ***[[マルチシグ>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B7%E3%82%B0]] [#td531ff2] ***[[自己証明型身分証明>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E8%87%AA%E5%B7%B1%E8%A8%BC%E6%98%8E%E5%9E%8B%E8%BA%AB%E5%88%86%E8%A8%BC%E6%98%8E]] [#oe5d3141] *選定 [#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アプリケーション側に特別な作り込みは必要ないため、大きなメリットがある。 -ディレクトリ・サービスと連携している場合、~ 各アプリケーションにこの情報を使用した追加の承認の機能を実装できる。 ***ライブラリ型 [#t68197e3] -各アプリケーション（や、使用しているフレームワーク）に認証処理を実装する場合、こちらの方式になる。 -昨今、OpenID系の[[クレームベース認証>#if326ed5]]の機能を実装しているケースもある。 -以下、[[ASP.NET]]では、以下の様なライブラリ型のフレームワーク or ライブラリを使用できる。 --[[Forms認証>ASP.NET Forms認証]]~ Webアプリケーション毎に認証Formを作成 --ASP.NET MembershipProvider~ LDAPやユーザマスタテーブルなどの資格情報ストアを使用した認証のフレームワーク。 --[[ASP.NET Identity]] ---Forms認証ではなく、[[OWIN]]の認証用ミドルウェアを使用している。 ---新しいミドルウェアのため、B2Cの認証サイトに必要な機能が充実している。 -参考 --[[ASP.NET Forms認証 vs ASP.NET Identity]] **[[クレームベース認証]] [#if326ed5] [[ライブラリ型>#t68197e3]]で、言語が混在になると、個別の部品を整備する必要があり面倒になる。 -[[ASP.NET Forms認証]] -独自Frameworkの独自認証 また、コレをクリアするには、[[統合認証基盤型>#bcd2a481]]の認証基盤製品を導入する必要があった。~ このため、近年、下記のような認証/認可の仕組みのプロトコルレベルでの標準化が進んでいる（[[クレームベース認証]]）。 ***[[SAML]]、[[WS-FED>WS-Federation]] [#j4fa72a7] -[[SAML]] -[[WS-Federation]] ***[[OpenID / OAuth / OpenID Connect>クレームベース認証#bd876705]] [#gcb8bfd9] -[[OpenID]] -[[OAuth]] -[[OpenID Connect]] ***ベターユース [#d46629ec] クレームベース認証の登場により、認証基盤の設計が難しくなりました。 ただ、以下のようにすれば、割りとシンプルなんじゃないかな？と思います。 -[[IdP(CP)>クレームベース認証#h4a44b62]]、[[STS>クレームベース認証#h4a44b62]]を1つに集約して[[SP(RP)>クレームベース認証#h4a44b62]]側から連携するのが良い。 --基本的に、[[STS>クレームベース認証#h4a44b62]]は、 ---開発するものではなく、構築するもの。 ---[[ASP.NET Identity>https://techinfoofmicrosofttech.osscons.jp/index.php?ASP.NET%20Identity]]などを使用すればOAuth2対応の[[STS>クレームベース認証#h4a44b62]]を開発可能だが、難易度が高い。 --これにより、IDフェデレーションやソーシャルログイン対応の実装をするポイントを[[IdP(CP)>クレームベース認証#h4a44b62]]・[[STS>クレームベース認証#h4a44b62]]の1箇所に集約できる。 -[[SP(RP)>クレームベース認証#h4a44b62]]側では、[[STS>クレームベース認証#h4a44b62]]と連携した外部ログインを行った後、Forms認証などの枯れた仕組みを使用して認証チケットを発行すれば良い。 -Web APIの認証も、[[OAuth]] 2.0等が前提でない限りForms認証のCookie認証チケットを使用すればイイ。 **生体認証 [#ibdedc4b] ***[[FIDO]]2.0 [#i4274bb6] デバイス＋生体認証情報のに2要素認証として、~ 既存のサイトにパスワードに加えたログイン方法を追加する。 **その他 [#r47eb615] ***[[マルチシグ>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B7%E3%82%B0]] [#x72f6fdf] ***[[自己証明型身分証明>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E8%87%AA%E5%B7%B1%E8%A8%BC%E6%98%8E%E5%9E%8B%E8%BA%AB%E5%88%86%E8%A8%BC%E6%98%8E]] [#u864e229] *その他 [#j28bf39e] **IdP [#rec743ac] ***[[FIM/MIM]] [#z633d288] **[[トークン]] [#i0670f8d] 認証基盤の開発に使える[[トークン]]。 ***[[JWT]] [#n3fb7eb7] ***[[SAML]] [#s940ae86] *B2C対応の認証サイト構築フレームワーク [#m0e95e60] B2Cの認証サイトに必要な機能が充実している[[ASP.NET Identity]]が有用である。 ---- Tags: [[:認証基盤]], [[:Active Directory]], [[:クレームベース認証]]
