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

目次

概要

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

種類

HTTPの認証

匿名アクセス

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

基本認証

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

ダイジェスト認証

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

Windows認証

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

NTLM認証

ケルベロス認証

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

クッキー認証チケット型

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

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

統合認証基盤型

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

ライブラリ型

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

クレームベース認証

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

SAML, WS-FED

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

OpenID / OAuth / OpenID Connect

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

生体認証

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

FIDO2.0

その他

マルチシグ

自己証明型身分証明

選定

HTTPの認証

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

Windwos認証

Windows環境であれば。

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

NTLM認証

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

ケルベロス認証

  • Active Directory」が存在する場合。
  • デスクトップへのログインと連動したSSO認証が可能。
  • ベースクライアント認証でのダブルホップが可能。
  • ADが有るので、各アプリケーションにLDAPを使用した追加の承認の機能を実装できる。

クッキー認証チケット型

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

統合認証基盤型

  • 認証をISAPIレイヤで処理するので、基盤構築作業として対応でき、
    Webアプリケーション側に特別な作り込みは必要ないため、大きなメリットがある。
  • ディレクトリ・サービスと連携している場合、
    各アプリケーションにこの情報を使用した追加の承認の機能を実装できる。

ライブラリ型

  • 各アプリケーション(や、使用しているフレームワーク)に認証処理を実装する場合、こちらの方式になる。
  • 以下、ASP.NETでは、以下の様なライブラリ型のフレームワーク or ライブラリを使用できる。
  • Forms認証
    Webアプリケーション毎に認証Formを作成
  • ASP.NET MembershipProvider?
    LDAPやユーザマスタテーブルなどの資格情報ストアを使用した認証のフレームワーク。
  • ASP.NET Identity
    • Forms認証ではなく、OWINの認証用ミドルウェアを使用している。
    • 新しいミドルウェアのため、B2Cの認証サイトに必要な機能が充実している。

クレームベース認証

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

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

SAMLWS-FED

OpenID / OAuth / OpenID Connect

ベターユース

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

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

  • 基本的に、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

トークン

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

JWT

SAML

LoA(Level of Assurance)

B2C対応の認証サイト構築フレームワーク

B2Cの認証サイトに必要な機能が充実しているASP.NET Identityが有用である。


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-10 (水) 14:11:40 (8d)