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