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

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

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

戻る

目次 †

目次
概要
種類
選定
ユーザストア
- Identity Provider (IdP)
- IDプロビジョニング
  - FIM/MIM
  - Azure AD Connect
参考

概要 †

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

種類 †

HTTPの認証 †

HTTPのライブラリに組み込まれている。
通常サービスの実行アカウントで実行される。
（偽装を設定すれば）匿名の実行アカウントで実行される。

匿名アクセス †

匿名アクセスを許可する。

基本認証 †

ユーザー名とパスワードを入力するためのダイアログボックスが表示される。
アカウント情報は暗号化されないBase64文字列でサーバに送られる。

ダイジェスト認証 †

ハッシングテクノロジーを使用し、解読不能な方法でユーザー情報を送信する。
チャレンジ & レスポンス認証と異なり、サーバ側に平文は不要。

Windows認証 †

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

通常サービスの実行アカウントで実行される。
（偽装を設定すれば）匿名の実行アカウントで実行される。

NTLM認証 †

チャレンジ & レスポンス認証方式を利用する。
ミラーアカウントでも、Active Directoryでも可能。
（偽装をおこなえば）認証されたアカウントで実行される。

ケルベロス認証 †

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

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

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

統合認証基盤型 †

SiteMinder?、IceWall?など。
「エージェント型」の統合認証基盤

ライブラリ型 †

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

クレームベース認証 †

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

SAML / WS-FED †

OpenID / OAuth / OpenID Connect †

多要素認証 †

多要素認証で使われる要素には 3 つの種類がある。
多要素認証では、3 要素の中から 2 つ以上の要素で認証する。
同じ種類の要素を使用する場合、n 段階認証と呼ばれることがある。

ユーザが知っていること（知識情報） †

Something You Know – 知識情報
例：ID・パスワード、PIN 番号、秘密の質問

ユーザが持っているもの（所持情報） †

Something You Have – 所持情報

例
- IC キャッシュカード、ワンタイムパスワード、USB トークン、
  暗号表認証、マトリックス認証、Bluetooth Smart認証デバイス
- E-mail、SMS、ボイスコール、スマホアプリ認証、FIDO認証器

ユーザ自身の特徴（生体情報） †

Something You Are – 生体情報
例：静脈認証、虹彩認証、網膜認証、顔認証、指紋認証

FIDO認証 †

FIDOは「Fast IDentity Online（素早いオンライン認証）」の略。
上記の、知識情報, 所持情報, 生体情報などを組み合わせて利用できる。

FIDO
- FIDO1, FIDO2, FIDO認証器
- Web Authentication API

Windows Hello + Microsoft Passport
- Windows Hello
- Microsoft Passport

生体認証 †

指紋認証、虹彩認証、静脈認証などの生体情報を利用した認証
前述のFIDOなどのオープン化されている要素技術により、
生体認証を実装利用することは容易になってきている。

その他 †

選定 †

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、ASP.NET Core 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認証チケットを使用すればイイ。

生体認証 †

生体情報を使用して認証を強化できる。

多要素認証 †

多要素認証を使用して認証を強化できる。

ユーザが知っていること（知識情報） †

・・・。

ユーザが持っているもの（所持情報） †

・・・。

ユーザ自身の特徴（生体情報） †

・・・。

FIDO認証 †

パスワード・レスの認証を実現する。
また、デバイス＋生体認証情報の多要素認証など、
既存のサイトにパスワードに加えたログイン方法を追加する。

その他 †

ユーザストア †

Identity Provider (IdP) †

IDを格納するユーザストアで、
IDを提供するため、Identity Provider (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

IDプロビジョニング †

IDを格納するユーザストア間のマッピングと同期を行う。

FIM/MIM †

Azure AD Connect †

参考 †

チャレンジ & レスポンス認証 †

LoA(Level of Assurance) †

トークン †

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

JWT †

SAML †

様々な認証 †

WebAPIの認証 †

ASP.NET Core における認証 †

ASP.NETとSSRSの連携と認証 †

SQL Server の認証 †

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