Open棟梁Project - マイクロソフト系技術情報 Wiki
...工事中...
目次 †
概要 †
認証基盤の選定や実装について纏めています。
種類 †
HTTPの認証 †
匿名アクセス †
- 匿名アクセスを許可する。
- 通常サービスの実行アカウントで実行される。
- （偽装をおこなえば）匿名アカウントで実行される。
基本認証 †
- ユーザー名とパスワードを入力するためのダイアログ ボックスが表示される。
- アカウント情報は暗号化されないBase64文字列でサーバに送られる。
- 通常サービスの実行アカウントで実行される。
- （偽装をおこなえば）認証されたアカウントで実行される。
ダイジェスト認証 †
- ハッシング テクノロジーを使用し、解読不能な方法でユーザー情報を送信する。
- 通常サービスの実行アカウントで実行される。
- （偽装をおこなえば）認証されたアカウントで実行される。
Windwos認証 †
HTTPやSMBなどの通信ライブラリに組み込まれており、
実行アカウントを使用しオートネゴシエートで認証することが可能。
NTLM認証 †
ケルベロス認証 †
クッキー認証チケット型 †
クッキー認証チケットを発行するタイプ
- 認証されたアカウントを偽装するにはカスタムの実装が必要。
統合認証基盤型 †
- SiteMinder?、IceWall?などの実績のあるSSOをサポートする統合認証基盤
実装ルール型 †
各アプリケーションに認証クッキーの（発行と）認証の機能を実装する。
（Webアプリケーション毎に認証Formを作成する（Forms認証））
認証連携 †
特徴 †
- OpenAM、ADFS
などの実績のあるSSOをサポートする認証連携基盤
- 異なるベンダのアクセス制御製品間の相互運用性を推進し、
企業間の独立したサービスをグローバルなSSOで連携させることが可能。
- 認証されたアカウントを偽装するにはカスタムの実装が必要。
- 認証連携（IDフェデレーション）の利点
http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso02/adfs2sso02_01.html
上記のフェデレーションの動作におけるポイントの1つとしては、サービス・プロバイダ側で直接認証（IDやパスワードの入力）を行っていないので、サービス・プロバイダへのネットワーク経路上をパスワードが流れないという点がある。もう1つ、サービス・プロバイダが直接アイデンティティ・プロバイダと通信を行っていないので、アイデンティティ・プロバイダとサービス・プロバイダは別々のネットワークに存在してもよいという点も挙げられる。
これらにより、イントラネット上のアイデンティティ・プロバイダを利用して、クラウド上のサービス・プロバイダへセキュアなアクセスを行うといったことが可能になる。また同時に、イントラネット上の社内アプリケーションにも同様の仕組みを導入することにより、イントラネットとクラウドにまたがったセキュアなシングル・サインオンという非常に利便性の高いシステムを構築できる。
プロトコル †
- クッキー認証チケットを使用しない。
- クッキーを第三者が不正使用してなりすましを許す可能性がある。
- クッキーはクッキードメインの中でしか有効ではない。
- SAML Core
SAML Assertions
SAML Protocols
- Assertionsには、SAML Assertionsを使用。
- 以下のプロファイルがある。
パッシブリクエスタプロファイル（Webアプリ用）
アクティブリクエスタプロファイル（Webサービス用）
製品 †
選定 †
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認証のクッキー認証チケットを発行すると言う方式の実績もありますが、
要件に合わないようなら、個別に「クッキー認証チケット型」の認証基盤の導入を検討した方が良さそうです。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
