Open棟梁Project - マイクロソフト系技術情報 Wiki
...工事中...
目次 †
概要 †
認証基盤の選定や実装について纏めています。
種類 †
HTTPの認証 †
匿名アクセス †
- 匿名アクセスを許可する。
- 通常サービスの実行アカウントで実行される。
- (偽装をおこなえば)匿名アカウントで実行される。
基本認証 †
- ユーザー名とパスワードを入力するためのダイアログ ボックスが表示される。
- アカウント情報は暗号化されないBase64文字列でサーバに送られる。
- 通常サービスの実行アカウントで実行される。
- (偽装をおこなえば)認証されたアカウントで実行される。
ダイジェスト認証 †
- ハッシング テクノロジーを使用し、解読不能な方法でユーザー情報を送信する。
- 通常サービスの実行アカウントで実行される。
- (偽装をおこなえば)認証されたアカウントで実行される。
Windwos認証 †
HTTPやSMBなどの通信ライブラリに組み込まれており、
実行アカウントを使用しオートネゴシエートで認証することが可能。
NTLM認証 †
ケルベロス認証 †
クッキー認証チケット型 †
クッキー認証チケットを発行するタイプ
- 認証されたアカウントを偽装するにはカスタムの実装が必要。
統合認証基盤型 †
- SiteMinder?、IceWall?などの実績のあるSSOをサポートする統合認証基盤
実装ルール型 †
各アプリケーションに認証クッキーの(発行と)認証の機能を実装する。
(Webアプリケーション毎に認証Formを作成する(Forms認証))
認証連携 †
- OpenAM、ADFS
などの実績のあるSSOをサポートする認証連携基盤
- 異なるベンダのアクセス制御製品間の相互運用性を推進し、
企業間の独立したサービスをグローバルなSSOで連携させることが可能。
- 認証されたアカウントを偽装するにはカスタムの実装が必要。
プロトコル †
- クッキー認証チケットを使用しない。
- クッキーを第三者が不正使用してなりすましを許す可能性がある。
- クッキーはクッキードメインの中でしか有効ではない。
製品 †
選定 †
HTTPの認証 †
HTTPの認証なのでWebサーバでサポートされる。
Windwos認証 †
Windows環境であれば。
- SambaでLinux環境のケルベロス認証も可能。
NTLM認証 †
- ベースクライアント認証でのダブルホップが不可能。
- ADが無いので、別途DBなどを用意して追加の承認の機能を実装できる。
ケルベロス認証 †
- ベースクライアント認証でのダブルホップが可能。
- ADが有るので、各アプリケーションにLDAPを使用した追加の承認の機能を実装できる。
クッキー認証チケット型 †
- 各アプリケーションに認証情報を使用した承認の機能を実装する。
統合認証基盤型 †
- 認証をISAPIレイヤで処理するので、基盤構築作業として対応でき、
Webアプリケーション側に特別な作り込みは必要ないため、大きなメリットになる。
- ディレクトリ・サービスと連携している場合、
各アプリケーションにこの情報を使用した追加の承認の機能を実装できる。
実装ルール型 †
- フレームワークに実装するとすると、こちらの方式になるが。
- Java、.NETなど言語が混在になると、個別の部品を整備する必要があり面倒になる。
- ASP.NETのForms認証
- 独自Frameworkの独自認証
認証連携 †
余談 †
ASP.NETのForms認証では、
- クッキー認証チケットをクロスサイトで使用できる。
- ただし、クロスドメインでの引継は不可能。
クロスドメイン間のサイトで、テンポラリの認証情報をQueryString?等で引き継いで、
連携先サイトで、別途Forms認証のクッキー認証チケットを発行すると言う方式の実績もありますが、
要件に合わないようなら、個別に「クッキー認証チケット型」の認証基盤の導入を検討した方が良さそうです。