Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
認証基盤の選定や実装について纏めています。
種類 †
HTTPの認証 †
匿名アクセス †
- 匿名アクセスを許可する。
- 通常サービスの実行アカウントで実行される。
- （偽装をおこなえば）匿名アカウントで実行される。
基本認証 †
- ユーザー名とパスワードを入力するためのダイアログ ボックスが表示される。
- アカウント情報は暗号化されないBase64文字列でサーバに送られる。
- 通常サービスの実行アカウントで実行される。
- （偽装をおこなえば）認証されたアカウントで実行される。
ダイジェスト認証 †
- ハッシング テクノロジーを使用し、解読不能な方法でユーザー情報を送信する。
- 通常サービスの実行アカウントで実行される。
- （偽装をおこなえば）認証されたアカウントで実行される。
Windwos認証 †
HTTPやSMBなどの通信ライブラリに組み込まれており、
実行アカウントを使用しオートネゴシエートで認証することが可能。
NTLM認証 †
ケルベロス認証 †
クッキー認証チケット型 †
クッキー認証チケットを発行するタイプ
- 認証されたアカウントを偽装するにはカスタムの実装が必要。
統合認証基盤型 †
- SiteMinder?、IceWall?などの実績のあるSSOをサポートする統合認証基盤
実装ルール型 †
各アプリケーションに認証クッキーの（発行と）認証の機能を実装する。
以下、ASP.NETの認証の変遷
- Forms認証
Webアプリケーション毎に認証Formを作成する
- ASP.NET MembershipProvider?
LDAPやユーザマスタテーブルなどの資格情報ストアを使用した認証のフレームワーク。
- ASP.NET Identity
- フォーム認証ではなく、OWINの認証用ミドルウェア（？）を使用
- 資格情報ストアとして、Microsoftアカウント、Facebook、Twitter、Google等のソーシャルアカウントを利用可能
- WIF(Windows Identity Foundation)
- OpenId? Connectをサポート。
- Microsoft.Owin.Security.OpenIdConnect?
- WIF Extension for OAuth(OpenID Connect)
選定 †
HTTPの認証 †
HTTPの認証なのでWebサーバでサポートされる。
Windwos認証 †
Windows環境であれば。
- SambaでLinux環境のケルベロス認証も可能。
NTLM認証 †
- ベースクライアント認証でのダブルホップが不可能。
- ADが無いので、別途DBなどを用意して追加の承認の機能を実装できる。
ケルベロス認証 †
- ベースクライアント認証でのダブルホップが可能。
- ADが有るので、各アプリケーションにLDAPを使用した追加の承認の機能を実装できる。
クッキー認証チケット型 †
- 各アプリケーションに認証情報を使用した承認の機能を実装する。
統合認証基盤型 †
- 認証をISAPIレイヤで処理するので、基盤構築作業として対応でき、
Webアプリケーション側に特別な作り込みは必要ないため、大きなメリットがある。
- ディレクトリ・サービスと連携している場合、
各アプリケーションにこの情報を使用した追加の承認の機能を実装できる。
実装ルール型 †
フレームワークに実装するとすると、こちらの方式になる。
実装ルール型で、言語が混在になると、個別の部品を整備する必要があり面倒になる。
- ASP.NETのForms認証
- 独自Frameworkの独自認証
このため、近年、下記のような認証/認可の仕組みの
プロトコルレベルでの標準化が進んでいる（クレームベース認証）。
余談 †
ASP.NETのForms認証では、
- クッキー認証チケットをクロスサイトで使用できる。
- ただし、クロスドメインでの引継は不可能。
クロスドメイン間のサイトで、テンポラリの認証情報をQueryString?等で引き継いで、
連携先サイトで、別途Forms認証のクッキー認証チケットを発行すると言う方式の実績もありますが、
要件に合わないようなら、個別に「クッキー認証チケット型」の認証基盤の導入を検討した方が良さそうです。
IdM実験室 †
IdM実験室の情報をまとめて勉強してみます。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
