「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
認証基盤の選定や実装について纏めています。
種類 †
HTTPの認証 †
匿名アクセス †
- 匿名アクセスを許可する。
- 通常サービスの実行アカウントで実行される。
- (偽装をおこなえば)匿名アカウントで実行される。
基本認証 †
- ユーザー名とパスワードを入力するためのダイアログ ボックスが表示される。
- アカウント情報は暗号化されないBase64文字列でサーバに送られる。
- 通常サービスの実行アカウントで実行される。
- (偽装をおこなえば)認証されたアカウントで実行される。
ダイジェスト認証 †
- ハッシング テクノロジーを使用し、解読不能な方法でユーザー情報を送信する。
- 通常サービスの実行アカウントで実行される。
- (偽装をおこなえば)認証されたアカウントで実行される。
Windows認証 †
HTTPやSMBなどの通信ライブラリに組み込まれており、
実行アカウントを使用しオートネゴシエートで認証することが可能。
NTLM認証 †
クッキー認証チケット型 †
クッキー認証チケットを発行するタイプ
- 認証されたアカウントを偽装するにはカスタムの実装が必要。
統合認証基盤型 †
ライブラリ型 †
- 各アプリケーション(や、使用しているフレームワーク)に
認証クッキーの発行と認証等の機能を実装している方式。
認証連携(IDフェデレーション)を使用して認証。
SAML, WS-FED †
WIF(Windows Identity Foundation)を使用する。
OpenID / OAuth / OpenID Connect †
- Microsoft.Owin.Security.OpenIdConnect?などを使用する。
- WIF Extension for OAuth(OpenID Connect)などを使用する。
多要素認証 †
- 多要素認証で使われる要素には 3 つの種類がある。
- 多要素認証では、3 要素の中から 2 つ以上の要素で認証する。
- 同じ種類の要素を使用する場合、n 段階認証と呼ばれることがある。
ユーザが知っていること(知識情報) †
- Something You Know – 知識情報
- 例:ID・パスワード、PIN 番号、秘密の質問
ユーザが持っているもの(所持情報) †
- Something You Have – 所持情報
- 例
- IC キャッシュカード、ワンタイムパスワード、USB トークン、
暗号表認証、マトリックス認証、Bluetooth Smart認証デバイス
- E-mail、SMS、ボイスコール、スマホアプリ認証、FIDO認証器
ユーザ自身の特徴(生体情報) †
- Something You Are – 生体情報
- 例:静脈認証、虹彩認証、網膜認証、顔認証、指紋認証
FIDOは「Fast IDentity Online(素早いオンライン認証)」の略。
上記の、知識情報, 所持情報, 生体情報などを組み合わせて利用できる。
生体認証 †
- 指紋認証、虹彩認証、静脈認証などの生体情報を利用した認証
- 前述のFIDOなどのオープン化されている要素技術により、
生体認証を実装利用することは容易になってきている。
その他 †
選定 †
HTTPの認証 †
HTTPの認証なのでWebサーバでサポートされる。
Windwos認証 †
Windows環境であれば。
NTLM認証 †
- ベースクライアント認証でのダブルホップが不可能。
- ADが無いので、別途DBなどを用意して追加の承認の機能を実装できる。
- ベースクライアント認証でのダブルホップが可能。
- ADが有るので、各アプリケーションにLDAPを使用した追加の承認の機能を実装できる。
クッキー認証チケット型 †
- 各アプリケーションに認証情報を使用した承認の機能を実装する。
統合認証基盤型 †
- 認証をISAPIレイヤで処理するので、基盤構築作業として対応でき、
Webアプリケーション側に特別な作り込みは必要ないため、大きなメリットがある。
- ディレクトリ・サービスと連携している場合、
各アプリケーションにこの情報を使用した追加の承認の機能を実装できる。
ライブラリ型 †
- 各アプリケーション(や、使用しているフレームワーク)に認証処理を実装する場合、こちらの方式になる。
- 以下、ASP.NETでは、以下の様なライブラリ型のフレームワーク or ライブラリを使用できる。
- ASP.NET MembershipProvider?
LDAPやユーザマスタテーブルなどの資格情報ストアを使用した認証のフレームワーク。
ライブラリ型で、言語が混在になると、個別の部品を整備する必要があり面倒になる。
また、コレをクリアするには、統合認証基盤型の認証基盤製品を導入する必要があった。
このため、近年、下記のような認証/認可の仕組みのプロトコルレベルでの標準化が進んでいる(クレームベース認証)。
ベターユース †
クレームベース認証の登場により、認証基盤の設計が難しくなりました。
ただ、以下のようにすれば、割りとシンプルなんじゃないかな?と思います。
- 基本的に、STSは、
- これにより、IDフェデレーションやソーシャルログイン対応の実装をするポイントをIdP(CP)・STSの1箇所に集約できる。
- SP(RP)側では、STSと連携した外部ログインを行った後、Forms認証などの枯れた仕組みを使用して認証チケットを発行すれば良い。
- Web APIの認証も、OAuth 2.0等が前提でない限りForms認証のCookie認証チケットを使用すればイイ。
生体認証 †
生体情報を使用して認証を強化できる。
多要素認証 †
多要素認証を使用して認証を強化できる。
ユーザが知っていること(知識情報) †
・・・。
ユーザが持っているもの(所持情報) †
・・・。
ユーザ自身の特徴(生体情報) †
・・・。
- パスワード・レスの認証を実現する。
- また、デバイス+生体認証情報の多要素認証など、
既存のサイトにパスワードに加えたログイン方法を追加する。
その他 †
その他 †
IdP †
- 基本的には、フレームワークに準拠すると良いと思う。
参考 †
認証基盤の開発に使えるトークン。
様々な認証 †
Tags: :認証基盤, :Active Directory, :クレームベース認証