![[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] -HTTPのライブラリに組み込まれている。 -通常サービスの実行アカウントで実行される。 -（偽装を設定すれば）匿名の実行アカウントで実行される。 ***匿名アクセス [#eed67f54] 匿名アクセスを許可する。 ***基本認証 [#mb2c8e20] -ユーザー名とパスワードを入力するためのダイアログ ボックスが表示される。 -アカウント情報は暗号化されないBase64文字列でサーバに送られる。 ***ダイジェスト認証 [#tda3ddf0] -ハッシング テクノロジーを使用し、解読不能な方法でユーザー情報を送信する。 -[[チャレンジ & レスポンス認証>#zb3340de]]と異なり、サーバ側に平文は不要。 **Windows認証 [#m4be745d] -HTTPやSMBなどの通信ライブラリに組み込まれており、~ 実行アカウントを使用しオートネゴシエートで認証することが可能。 -通常サービスの実行アカウントで実行される。 -（偽装を設定すれば）匿名の実行アカウントで実行される。 ***NTLM認証 [#zb3340de] -[[チャレンジ & レスポンス認証>#p28cc188]]方式を利用する。 -[[ミラーアカウント]]でも、[[Active Directory]]でも可能。 -（偽装をおこなえば）認証されたアカウントで実行される。 ***[[ケルベロス認証]] [#o8a80b4b] -「[[Active Directory]]」が必要、インターネットに拡大できない。 -（偽装をおこなえば）認証されたアカウントで実行される。 **クッキー認証チケット型 [#la8f4c73] クッキー認証チケットを発行するタイプ ***統合認証基盤型 [#mf25a493] -SiteMinder、IceWallなど。 -「エージェント型」の統合認証基盤 ***ライブラリ型 [#f5c72a77] 各アプリケーション（や、使用しているフレームワーク）に~ 認証クッキーの発行と認証等の機能を実装している方式。 **[[クレームベース認証]] [#gf1f2d37] 認証連携（IDフェデレーション）を使用して認証。 ***[[SAML / WS-FED]] [#u38db7ac] ***[[OpenID / OAuth / OpenID Connect]] [#qb9e82f5] ***[[Pairwise Pseudonymous Identifier (PPID)>PPID]] [#yb6d9b10] **多要素認証 [#o540099e] -多要素認証で使われる要素には 3 つの種類がある。 -多要素認証では、3 要素の中から 2 つ以上の要素で認証する。 -同じ種類の要素を使用する場合、n 段階認証と呼ばれることがある。 ***ユーザが知っていること（知識情報） [#j4d41e24] -Something You Know – 知識情報 -例：ID・パスワード、PIN 番号、秘密の質問 ***ユーザが持っているもの（所持情報） [#fca25ae8] -Something You Have – 所持情報 -例 --IC キャッシュカード、ワンタイムパスワード、USB トークン、~ 暗号表認証、マトリックス認証、Bluetooth Smart認証デバイス --E-mail、SMS、ボイスコール、スマホアプリ認証、FIDO認証器 ***ユーザ自身の特徴（[[生体情報>#t71a546b]]） [#qc50eb89] -Something You Are – [[生体情報>#t71a546b]] -例：静脈認証、虹彩認証、網膜認証、顔認証、指紋認証 **[[FIDO]]認証 [#re880812] [[FIDO]]は「Fast IDentity Online（素早いオンライン認証）」の略。~ 上記の、知識情報, 所持情報, [[生体情報>#t71a546b]]などを組み合わせて利用できる。 -[[FIDO]] --[[FIDO1]], [[FIDO2]], [[FIDO認証器]] --[[Web Authentication API]] -[[Windows Hello + Microsoft Passport]] --[[Windows Hello]] --[[Microsoft Passport]] ---[[TPM（Trusted Platform Module）]] ---[[Web Authentication API（旧）]] ---[[Windows.Security.Credentials]] **生体認証 [#t71a546b] -指紋認証、虹彩認証、静脈認証などの生体情報を利用した認証 -前述の[[FIDO>#re880812]]などのオープン化されている要素技術により、~ 生体認証を%%実装%%利用することは容易になってきている。 **[[その他>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E9%AB%98%E5%BA%A6%E5%8D%88%E5%89%8D%20-%20%E6%8A%80%E8%A1%93%E8%A6%81%E7%B4%A0%20-%20%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%20-%20%E6%9A%97%E5%8F%B7%E3%83%BB%E8%AA%8D%E8%A8%BC#rd6d0193]] [#z76d01d9] *選定 [#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]]、[[ASP.NET Core 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] 生体情報を使用して認証を強化できる。 **多要素認証 [#a4d05444] 多要素認証を使用して認証を強化できる。 ***ユーザが知っていること（知識情報） [#a8694b89] ・・・。 ***ユーザが持っているもの（所持情報） [#pa011db0] ・・・。 ***ユーザ自身の特徴（生体情報） [#m6b3dc25] ・・・。 **[[FIDO]]認証 [#i4274bb6] -パスワード・レスの認証を実現する。 -また、デバイス＋生体認証情報の多要素認証など、~ 既存のサイトにパスワードに加えたログイン方法を追加する。 **[[その他>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E9%AB%98%E5%BA%A6%E5%8D%88%E5%89%8D%20-%20%E6%8A%80%E8%A1%93%E8%A6%81%E7%B4%A0%20-%20%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%20-%20%E6%9A%97%E5%8F%B7%E3%83%BB%E8%AA%8D%E8%A8%BC#rd6d0193]] [#r47eb615] *ユーザストア [#j28bf39e] **Identity Provider (IdP) [#c7e22065] IDを格納するユーザストアで、~ IDを提供するため、Identity Provider (IdP)と呼ばれる。 -基本的には、フレームワークに準拠すると良いと思う。 --[[ASP.NET Identity]] --[[ASP.NET Core Identity]] -参考 --Qiita ---独自パスワード認証でやってきたサービスが~ Google、Facebookのようなアカウントと連携する際の基本的な考え方~ https://qiita.com/ritou/items/42dc774e348cfb0d8255 ---アプリ時代のメールアドレス確認処理について考えたメモ~ https://qiita.com/ritou/items/1ead46f7c7ec1db60641 ---アカウント登録時に後からメールアドレス確認を行うために必要な処理~ https://qiita.com/ritou/items/2fbf9bc9232c52598474 **IDプロビジョニング [#xcd0b866] IDを格納するユーザストア間のマッピングと同期を行う。 ***[[FIM/MIM]] [#z633d288] ***[[Azure AD Connect>Microsoft Azure Active Directory#k86844c3]] [#sc072243] *参考 [#e8f99b0e] **[[チャレンジ & レスポンス認証>暗号化アルゴリズム#d34b7bfa]] [#p28cc188] **[[LoA(Level of Assurance)]] [#m2f11c97] **[[トークン]] [#i0670f8d] 認証基盤の開発に使える[[トークン]]。 ***[[JWT]] [#n3fb7eb7] ***[[SAML]] [#s940ae86] **様々な認証 [#l135f823] ***[[WebAPIの認証]] [#hdbd1aa2] ***[[ASP.NET Core における 認証]] [#k5b554be] ***[[ASP.NETとSSRSの連携と認証]] [#d860bede] ***[[SQL Server の認証]] [#y28e14b5] ---- Tags: [[:認証基盤]], [[:Active Directory]], [[:クレームベース認証]]
