MS_AuthenticationInfrastructure

認証基盤

• TOP > インフラストラクチャ > アカウント
  • 認証基盤
  • ケルベロス認証
  • 証明書

※ 開発基盤部会 Wiki 側にも「認証基盤」ページがあるため、ファイル名は MS_AuthenticationInfrastructure.md とした。
※ 元 Wiki の「戻る」は セキュリティ（MS_Security.md）。

概要

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

種類

HTTPの認証

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

方式	内容
匿名アクセス	匿名アクセスを許可する
基本認証	ユーザー名とパスワードのダイアログを表示。アカウント情報は暗号化されない Base64 文字列でサーバに送られる
ダイジェスト認証	ハッシングを使用し、解読不能な方法でユーザー情報を送信する。チャレンジ & レスポンス認証と異なり、サーバ側に平文は不要

補足（最新化）: 基本認証は必ずSSL/TLSと併用する（単体では平文同然）。 ダイジェスト認証は MD5 ベースで現在は非推奨。 現行の Web では Bearer トークン（OAuth 2.0 / OIDC） が標準。

Windows認証

• HTTP や SMB などの通信ライブラリに組み込まれており、
  実行アカウントを使用しオートネゴシエートで認証することが可能。
• 通常サービスの実行アカウントで実行される。
• （偽装を設定すれば）匿名の実行アカウントで実行される。

方式	内容
NTLM認証	チャレンジ & レスポンス認証方式を利用する。ミラーアカウントでも、Active Directoryでも可能
ケルベロス認証	「Active Directory」が必要、インターネットに拡大できない

いずれも（偽装をおこなえば）認証されたアカウントで実行される
（ベース クライアント セキュリティ モデル）。

※ NTLM は段階的に廃止の方向。Windows 11 24H2 以降で NTLMv1 は削除され、
NTLMv2 も監査・ブロックのポリシーが整備されている。新規は Kerberos を前提にする。

Cookie認証チケット型

Cookie 認証チケットを発行するタイプ

方式	内容
統合認証基盤型	企業ドメイン内の SSO を実装できる。エージェント型（ISAPI や mod_isapi）、リバース・プロキシ型。製品としては SiteMinder、IceWall が有名
ライブラリ型	各アプリケーション（や、使用しているフレームワーク）に認証クッキーの発行と認証等の機能を実装している方式

クレームベース認証型

クレームベース認証

• 認証連携（ID フェデレーション）を使用して認証。
• クロスドメインの SSO を実現できる。
  • SAML / WS-FED
  • OpenID / OAuth / OpenID Connect
  • Pairwise Pseudonymous Identifier (PPID)
• Web 標準ではあるものの、プロダクト毎に方言が在る。
  汎用的に実装するにはプロトコル知識とプロダクト仕様を知る必要がある。
  このため、IdP/STS 毎（や言語毎）にライブラリは別になっているケースが多い。

多要素認証

多要素認証で使われる要素には 3 つの種類がある。

• 多要素認証では、3 要素の中から 2 つ以上の要素で認証する。
• 2 要素の場合が多く、2 要素認証（2FA : Two Factor Authentication）と呼ばれる。
• 同じ種類の要素を使用する場合、n 段階認証と、多要素認証と区別して呼ばれることがある。

要素	英語	例
ユーザが知っていること（知識情報）	Something You Know	ID・パスワード、PIN 番号、秘密の質問
ユーザが持っているもの（所持情報）	Something You Have	IC キャッシュカード、ワンタイム・パスワード、暗号表認証、USB トークン、FIDO 認証器、プッシュ通知
ユーザ自身の特徴（生体情報）	Something You Are	静脈認証、虹彩認証、網膜認証、顔認証、指紋認証

※ 多要素認証と多段階認証

パスワード・ログイン後に別の要素での認証を求めるケースは、
二要素認証（多要素認証）ではなく、二段階認証（多段階認証）と区別して呼ばれることがある。

• E-mail、SMS、ボイスコールなどが該当。
  • E-mail は、Something You Have ではなく、≒ メアドの PWD で、
    ログインの PWD と同じ Something You Know と言う説もある。
  • SMS は、非推奨の流れと、標準化の流れがある模様。
• 二要素認証のトリガとしては、以下がある。
  • 二要素認証用のブラウザ・クッキーを未所持
  • リスクベース認証による不審なログインの検出

※ NIST SP 800-63B では SMS による OTP は「制限付き」 と位置付けられている
（SIM スワップや SS7 の問題があるため）。

その他

• ワンタイム・パスワード
• 生体認証
• FIDO 認証
  FIDO は「Fast IDentity Online（素早いオンライン認証）」の略。
  知識情報・所持情報・生体情報などを組み合わせて利用できる。
  • FIDO1、FIDO2、FIDO 認証器
  • Web Authentication API（WebAuthn）
  • Windows Hello + Microsoft Passport（TPM（Trusted Platform Module））
• リスクベース認証

補足（最新化）: FIDO2 / WebAuthn を基盤にした パスキー（Passkeys） が普及期に入り、 「パスワードレス＋フィッシング耐性」を両立する標準として、 Microsoft / Google / Apple のいずれもが既定の方向に舵を切っている。 認証基盤の新規設計では、まずパスキー対応を検討するのがよい。

選定

HTTPの認証

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

Windows認証

Windows 環境であれば。NTLM 認証をサポートするクライアントも多い。
Samba で Linux 環境のケルベロス認証も可能。

方式	特徴
NTLM認証	ミラーアカウントでも AD でも可能。デスクトップへのログインと連動した SSO 認証が可能。ベースクライアント認証でのダブルホップが不可能。AD が無いので、別途 DB などを用意して追加の承認機能を実装できる
ケルベロス認証	AD が存在する場合。SSO 認証が可能。ダブルホップが可能（委任）。AD が有るので、各アプリに LDAP を使用した追加の承認機能を実装できる

Cookie認証チケット型

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

• 統合認証基盤型
  認証を ISAPI レイヤで処理するので、基盤構築作業として対応でき、
  Web アプリケーション側に特別な作り込みは必要ないため、大きなメリットがある。
  ディレクトリ・サービスと連携している場合、各アプリケーションに追加の承認機能を実装できる。
• ライブラリ型
  各アプリケーション（や、使用しているフレームワーク）に認証処理を実装する場合、こちらの方式になる。
  ASP.NET（MS_ASPNET.md）では、以下の様なライブラリ型を使用できる。
  • Forms認証
  • ASP.NET MembershipProvider
  • ASP.NET Identity、ASP.NET Core Identity
    Forms 認証ではなく、OWIN の認証用ミドルウェアを使用している。

クレームベース認証

ライブラリ型で、言語が混在になると、個別の部品を整備する必要があり面倒になる。
これをクリアするには、統合認証基盤型の認証基盤製品を導入する必要があった。
このため、近年、認証/認可の仕組みのプロトコルレベルでの標準化が進んでいる。

• SAML、WS-Federation
• OpenID / OAuth / OpenID Connect

ベターユース

クレームベース認証の登場により、認証基盤の設計が難しくなりました。
ただ、以下のようにすれば、割りとシンプルなんじゃないかな？と思います。

• IdP(CP)、STS を1つに集約して SP(RP) 側から連携するのが良い。
  • 基本的に、STS は、開発するものではなく、構築するもの。
  • これにより、ID フェデレーションやソーシャルログイン対応の実装をするポイントを
    IdP(CP)・STS の1箇所に集約できる。
• SP(RP) 側では、STS と連携した外部ログインを行った後、
  Forms 認証などの枯れた仕組みを使用して Cookie 認証チケットを発行すれば良い。
• Web API の認証も、OAuth 2.0 等が前提でない限り Forms 認証の Cookie 認証チケットを使用すればイイ。

※ 「IdP は構築するもので、開発するものではない」という指摘は現在も有効。
クラウドなら Microsoft Entra ID / Entra External ID、
OSS なら Keycloak を使うのが定石。

その他の強化

• ワンタイム・パスワード … 多要素認証として使用される他、単品利用でパスワードレスも一部実現。
• 生体認証 … 情報の機密性や認証の精度によるが、単品利用でパスワードレスも一部実現。
• FIDO 認証 … デバイス＋生体認証情報などが一般的認識。
  デバイスとセットで必要になるので、認証の精度は低めでも機密性の高い情報に利用できる。

ユーザストア

Identity Provider (IdP)

ID を格納するユーザストアで、ID を提供するため Identity Provider (IdP) と呼ばれる。
基本的には、フレームワークに準拠すると良いと思う（ASP.NET Identity / ASP.NET Core Identity）。

IDプロビジョニング

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

• FIM/MIM
• Azure AD Connect（現 Microsoft Entra Connect）

参考

• チャレンジ & レスポンス認証（暗号化アルゴリズム）
• LoA(Level of Assurance)
• トークン… JWT、SAML
• 様々な認証
  • WebAPIの認証
  • SQL Server の認証（MS_SQLServerAuthentication.md）

---

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