認証基盤のバックアップ(No.33) - マイクロソフト系技術情報 Wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る

目次 †

目次
概要
種類
選定
その他

概要 †

認証基盤の選定や実装について纏めています。

種類 †

HTTPの認証 †

匿名アクセス †

匿名アクセスを許可する。
通常サービスの実行アカウントで実行される。
（偽装をおこなえば）匿名アカウントで実行される。

基本認証 †

ユーザー名とパスワードを入力するためのダイアログボックスが表示される。
アカウント情報は暗号化されないBase64文字列でサーバに送られる。
通常サービスの実行アカウントで実行される。
（偽装をおこなえば）認証されたアカウントで実行される。

ダイジェスト認証 †

ハッシングテクノロジーを使用し、解読不能な方法でユーザー情報を送信する。
通常サービスの実行アカウントで実行される。
（偽装をおこなえば）認証されたアカウントで実行される。

Windows認証 †

HTTPやSMBなどの通信ライブラリに組み込まれており、
実行アカウントを使用しオートネゴシエートで認証することが可能。

NTLM認証 †

ミラーアカウントでも、Active Directoryでも可能。
（偽装をおこなえば）認証されたアカウントで実行される。

ケルベロス認証 †

「Active Directory」が必要、インターネットに拡大できない。
（偽装をおこなえば）認証されたアカウントで実行される。

クッキー認証チケット型 †

クッキー認証チケットを発行するタイプ

認証されたアカウントを偽装するにはカスタムの実装が必要。

統合認証基盤型 †

SiteMinder?、IceWall?などの実績のあるSSOをサポートする統合認証基盤製品。
これらは、下記HPで言う所の、「エージェント型」の統合認証基盤である。
基礎から学ぶ！シングルサインオン - IT、IT製品の情報なら【キーマンズネット】
http://www.keyman.or.jp/at/30001292/

ライブラリ型 †

各アプリケーション（や、使用しているフレームワーク）に
認証クッキーの発行と認証等の機能を実装している方式。

昨今、OpenID系のクレームベース認証の機能を実装しているケースもある。

クレームベース認証 †

認証連携（IDフェデレーション）を使用して認証。

SAML, WS-FED †

WIF(Windows Identity Foundation)を使用する。

OpenID / OAuth / OpenID Connect †

Microsoft.Owin.Security.OpenIdConnect?などを使用する。
WIF Extension for OAuth(OpenID Connect)などを使用する。

生体認証 †

以下のオープン化されている要素技術により、
生体認証を実装することは用意になってきている。

FIDO2.0 †

Windows Hello + Microsoft Passport
- Windows Hello
- Microsoft Passport

その他 †

マルチシグ †

自己証明型身分証明 †

選定 †

HTTPの認証 †

HTTPの認証なのでWebサーバでサポートされる。

Windwos認証 †

Windows環境であれば。

NTLM認証をサポートするクライアントも多い。

SambaでLinux環境のケルベロス認証も可能。
- Samba4でのActive Directory構築 - OSSでLinuxサーバ構築
  http://www.oss-d.net/samba4/ad

NTLM認証 †

ミラーアカウントでも、Active Directoryでも可能。
デスクトップへのログインと連動したSSO認証が可能。
ただし、ミラーアカウントの場合は、アカウントの管理が面倒。

ベースクライアント認証でのダブルホップが不可能。
ADが無いので、別途DBなどを用意して追加の承認の機能を実装できる。

ケルベロス認証 †

「Active Directory」が存在する場合。
デスクトップへのログインと連動したSSO認証が可能。

ベースクライアント認証でのダブルホップが可能。
ADが有るので、各アプリケーションにLDAPを使用した追加の承認の機能を実装できる。

クッキー認証チケット型 †

各アプリケーションに認証情報を使用した承認の機能を実装する。

統合認証基盤型 †

認証をISAPIレイヤで処理するので、基盤構築作業として対応でき、
Webアプリケーション側に特別な作り込みは必要ないため、大きなメリットがある。

ディレクトリ・サービスと連携している場合、
各アプリケーションにこの情報を使用した追加の承認の機能を実装できる。

ライブラリ型 †

各アプリケーション（や、使用しているフレームワーク）に認証処理を実装する場合、こちらの方式になる。

昨今、OpenID系のクレームベース認証の機能を実装しているケースもある。

以下、ASP.NETでは、以下の様なライブラリ型のフレームワーク or ライブラリを使用できる。

Forms認証
Webアプリケーション毎に認証Formを作成

ASP.NET MembershipProvider?
LDAPやユーザマスタテーブルなどの資格情報ストアを使用した認証のフレームワーク。

ASP.NET Identity
- Forms認証ではなく、OWINの認証用ミドルウェアを使用している。
- 新しいミドルウェアのため、B2Cの認証サイトに必要な機能が充実している。

参考
- ASP.NET Forms認証 vs ASP.NET Identity

クレームベース認証 †

ライブラリ型で、言語が混在になると、個別の部品を整備する必要があり面倒になる。

ASP.NET Forms認証
独自Frameworkの独自認証

また、コレをクリアするには、統合認証基盤型の認証基盤製品を導入する必要があった。
このため、近年、下記のような認証/認可の仕組みのプロトコルレベルでの標準化が進んでいる（クレームベース認証）。

SAML、WS-FED †

OpenID / OAuth / OpenID Connect †

ベターユース †

クレームベース認証の登場により、認証基盤の設計が難しくなりました。

ただ、以下のようにすれば、割りとシンプルなんじゃないかな？と思います。

IdP(CP)、STSを1つに集約してSP(RP)側から連携するのが良い。

基本的に、STSは、
- 開発するものではなく、構築するもの。
- ASP.NET Identityなどを使用すればOAuth2対応のSTSを開発可能だが、難易度が高い。
これにより、IDフェデレーションやソーシャルログイン対応の実装をするポイントをIdP(CP)・STSの1箇所に集約できる。

SP(RP)側では、STSと連携した外部ログインを行った後、Forms認証などの枯れた仕組みを使用して認証チケットを発行すれば良い。
Web APIの認証も、OAuth 2.0等が前提でない限りForms認証のCookie認証チケットを使用すればイイ。

生体認証 †

FIDO2.0 †

デバイス＋生体認証情報のに2要素認証として、
既存のサイトにパスワードに加えたログイン方法を追加する。

その他 †

マルチシグ †

自己証明型身分証明 †

その他 †

IdP †

FIM/MIM †

IdP仕様 †

基本的には、フレームワークに準拠すると良いと思う。
- ASP.NET Identity
- ASP.NET Core Identity

参考
- Qiita
  - 独自パスワード認証でやってきたサービスが
    Google、Facebookのようなアカウントと連携する際の基本的な考え方
    https://qiita.com/ritou/items/42dc774e348cfb0d8255
  - アプリ時代のメールアドレス確認処理について考えたメモ
    https://qiita.com/ritou/items/1ead46f7c7ec1db60641
  - アカウント登録時に後からメールアドレス確認を行うために必要な処理
    https://qiita.com/ritou/items/2fbf9bc9232c52598474

トークン †

認証基盤の開発に使えるトークン。

JWT †

SAML †

LoA(Level of Assurance) †

Tags: :認証基盤, :Active Directory, :クレームベース認証