認証フレームワーク

Kerberos、LDAP、SAML、WebAuthn、RADIUS は、順次置き換わる5世代のログインプロトコルではありません。これらはそれぞれ、チケット、ディレクトリ操作、システム間アサーション、公開鍵資格証明、ネットワークアクセスを整理するものであり、同じシステム内で協調して動作することができます。比較する際には、まず「誰が資格証明を検証し、誰が認可の決定を行い、どのコンポーネントが最終的にその決定を実行するのか？」という問いを立ててください。

パスワードが存在するかどうかは、比較の次元の一つに過ぎません。鍵の登録方法や失効方法、アカウントの復旧方法、確立されたセッションの無効化方法も、システム動作を決定する重要な要素です。

Kerberos：チケットは再送可能な完全なログイン証明ではない

KDC には、AS（Authentication Server）と TGS（Ticket Granting Server）という2つの論理的な役割が含まれます。クライアントはまず AS との交換で TGT（Ticket Granting Ticket）を取得し、次に TGT を使用して TGS にターゲットサービスのチケットを要求し、最後にサービスに AP（Application Server）リクエストを送信します。チケットは有効期間中はキャッシュされ、ファイルにアクセスするたびに TGS に再アクセスする必要はありません。

パスワードベースの初期交換では、生パスワードは送信されませんが、パスワードから派生した長期鍵が使用され、通常は事前認証が含まれます。Kerberos は PKINIT などの公開鍵初期認証もサポートしており、「すべてのログインでパスワード鍵が1回だけ派生される」というのはプロトコルの法則ではありません。RFC 4120、PKINIT

サービスはチケットを復号した後、ターゲットプリンシパル、有効期限、authenticator 内の身元と時刻などを照合し、同一認証器の再利用を防ぐ必要があります。⁠タイムスタンプは許容可能なウィンドウを制限するだけであり、ウィンドウ内ではリプレイが可能であるため、「タイムスタンプが期限切れていない」という理由だけでリプレイキャッシュやプロトコルが許可する他のリプレイ防止策に代えることはできません。許容される時計のずれは、実装とポリシーによって制御され、世界中で一律に5分固定というわけではありません。

AP-REP は双方向認証を提供し、サービスもセッションキーを掌握していることを証明します。基本的な検証では KDC へのオンラインアクセスは不要ですが、具体的なデプロイメントでは認可データの検証やその他の依存関係がある場合があります。対称鍵はサービス自体が使用できるため、「復号できれば暗号学的に KDC のみが発行可能と証明される」という主張も正確ではありません。

キャッシュは可用性を向上させますが、失効の遅延ももたらします。KDC が一時的に到達不能な場合、有効なサービスチケットは引き続き使用される可能性がありますが、新しいチケットの申請や更新は影響を受けます。サービスの長期鍵が漏洩すると、そのサービスのチケットの信頼性が損なわれます。TGS 鍵の漏洩の影響範囲はさらに大きくなります。チケット認証が完了した後、サービスは依然としてプリンシパルと認可データに基づいて、特定のディレクトリを読み取れるか、特定のアクションを実行できるかを判断する必要があります。

許容時間内なのに、なぜ2回目は拒否されるのか？

同一の時刻に2回送信した場合、2回目は時刻が正しくてもリプレイとなります。新しい認証器を生成しても、プリンシパルは依然として alice であり、再度検証することができます。受信時刻をずらすと、別の時刻チェックがトリガーされ、2つの拒否理由は別々に記録されるべきです。

LDAP：ディレクトリ照会と接続アイデンティティは2層の状態

LDAP エントリには DN（Distinguished Name）があります。例：uid=alice,ou=people,dc=example,dc=com。search はベース DN、スコープ、フィルター、属性セットを指定します。DN はディレクトリの位置識別子であり、リネームや移動に伴って変更される可能性があります。ディレクトリアカウントの長期関連付けは、デプロイメントが提供する安定した識別子に基づいて設計する必要があります。RFC 4511

一般的な「search-then-bind」フローは、アプリケーションが制限付き権限を持つサービスIDでユーザーを検索し、正確に1件のレコードに一致することを確認し、その後、返された DN とユーザーパスワードを使用して認証を行うものです。ユーザー入力を直接 DN に連結すると、ディレクトリ構造に適合しない可能性があります。検索結果が複数件返された場合、任意に最初の結果を選択することはできません。

ログイン画面では、空パスワードによるユーザー名/パスワード認証パスへの進入を拒否する必要があります。StartTLS を使用する際は、アップグレードとサーバー証明書検証が完了してから資格証明を送信することを確認してください。アップグレード失敗後に引き続き bind を行うことを同等のパスとして扱ってはなりません。EXTERNAL は外部で既に確立された安全なアイデンティティを利用できますが、証明書アイデンティティからディレクトリ認可アイデンティティへのマッピングは依然として必要です。RFC 4513

bind は接続の認証状態を変更します。共有検索接続で一時的に特定のユーザーに bind すると、後続のリクエストに影響を与えます。認証接続とサービス照会接続には明確なライフサイクルが必要です。再 bind に失敗しても、元のサービスアカウントの権限が保持されていると仮定してはなりません。

フィルターエスケープと DN エスケープは同一のルールではない

(uid=alice*) におけるアスタリスクにはパターン意味があります。ユーザー名に実際にアスタリスクが含まれている場合、フィルター構文に従ってエンコードする必要があります。以下では、UTF-8 値の各バイトをエスケープし、形式は冗長ですが、フィルター構造への注入がないことを直接確認しやすくなります。実際のアプリケーションでは、LDAP ライブラリのフィルター値エンコード関数を使用します。

def filter_value(text):
    return ''.join('\\' + format(b, '02x') for b in text.encode('utf-8'))

assert filter_value('a*(b)\\') == r'\61\2a\28\62\29\5c'
assert filter_value('中') == r'\e4\b8\ad'
assert filter_value('\0') == r'\00'
query = '(uid=' + filter_value('alice*') + ')'
assert query == r'(uid=\61\6c\69\63\65\2a)'
print('フィルター値はバイトエンコーディングで通過；DN や属性名には使用しない')

この関数は属性値のみを処理し、ユーザーが検索ベース、属性名、またはフィルター演算子を任意に選択できるようにするものではありません。RFC 4515

SAML：どの署名要素、どのリクエストを信頼するか

一般的な SP 開始型 Web SSO では、SP はリクエスト ID を保存し、ブラウザ経由で AuthnRequest を IdP に送信します。IdP は適切なユーザー認証を完了した後、通常、ブラウザ POST 経由で Response を SP の ACS（Assertion Consumer Service）に送信します。SP は応答とアサーションを検証し、独自のセッションを作成します。ブラウザが運ぶ Base64 XML は、本質的に信頼できるコンテンツではなく、暗号化されている意味でもありません。SAML Profiles

XML Signature Wrapping の核心的な問題は、「検証チェック A を行い、ビジネスロジックでは B を読み取る」ことです。ドキュメント内に有効な署名が1つ存在するだけでは不十分です。成熟した SAML ライブラリを使用し、消費されるアサーションと署名検証結果が同じ構造オブジェクトであることを確保する必要があります。要素 ID、解析、および許可される署名構造についても、ライブラリとプロファイルの要件に従って処理する必要があります。

NameID は主体の識別子であり、一回性消費されるログイン乱数ではありません。 その形式や issuer などの制限は、アイデンティティマッピングに影響を与えます。永続的な NameID は複数のログインに使用できます。リプレイ防止は、リクエスト ID、アサーション/レスポンス ID、有効期限に関連付ける必要があり、あるユーザーが最初にログインした後に「NameID が使用済み」と永久にマークすることはできません。

IdP 開始型の非要求応答ログインでは、一致する元の SP リクエストが存在しないため、そのプロファイルの処理ポリシーを明示的に採用する必要があります。互換性のためにすべてのコールバックの InResponseTo チェックをオフにするのは不適切です。RelayState はアプリケーション状態の回復に一般的に使用されますが、任意の外部サイトへのジャンプアドレスとして直接使用することはできません。SAML Core

以下では、署名検証およびその他の条件検証が完了した後の一回性消費のみを示します。実際のサービスでは、共有ストレージ内でアトミックにチェックして登録し、対応する受け入れウィンドウの終了まで保持する必要があります。

seen = set()
def consume(issuer, assertion_id, expires, now):
    key = (issuer, assertion_id)
    if now >= expires or key in seen:
        return False
    seen.add(key)
    return True

assert consume('idp-a', 'assertion-1', 200, 100)
assert not consume('idp-a', 'assertion-1', 200, 101)
assert consume('idp-a', 'assertion-2', 200, 101)  # 同一ユーザーは再ログイン可能。
assert not consume('idp-a', 'assertion-3', 200, 200)
print('アサーションの重複と期限切れの境界を通過；NameID は一回性消費に関与しない')

WebAuthn：資格証明のスコープ、バイト署名、ユーザー検証

登録時、RP は challenge を発行し、ブラウザと認証器が navigator.credentials.create() を完了します。RP は登録結果を検証し、credential ID、公開鍵、ユーザーハンドル、および必要な状態を関連付けて保存します。認証時には navigator.credentials.get() を使用し、認証器は当該資格証明がどのローカルアカウントに属するかを知る必要があります。新しい資格証明の追加にも、信頼性の高い登録認可が必要です。

認証署名の入力は、authenticatorData || SHA256(clientDataJSON) の生バイトです。clientDataJSON には、ceremony 種別、challenge、origin などを含みます。authenticatorData には、RP ID ハッシュ、flags、カウンターなどが含まれます。生 JSON を解析して再シリアライズしてからダイジェストを計算してはなりません。空白やフィールド順序の変化はバイト列を変更するためです。

RP は、期待される challenge、許可された origin、RP ID ハッシュ、資格証明とアカウントの関連付け、およびポリシーで要求される UP/UV フラグを照合し、その後、資格証明の公開鍵とアルゴリズムに基づいて署名を検証する必要があります。UP はユーザーの対話的存在を示し、UV はローカルユーザー検証の完了を示します。デバイスをタッチすることが必ずしも指紋や PIN 検証に相当するわけではありません。WebAuthn 検証プロセス

import hashlib
import json
import struct
rp_id = 'example.com'
raw_client_data = json.dumps({
    'type': 'webauthn.get', 'challenge': 'example-only',
    'origin': 'https://login.example.com'
}, separators=(',', ':')).encode()
# 拡張機能なしの最小限の authenticatorData：32 バイトハッシュ + 1 バイト flags + 4 バイトカウンター。
auth_data = hashlib.sha256(rp_id.encode()).digest() + bytes([0x05])
auth_data += struct.pack('>I', 0)
signed_bytes = auth_data + hashlib.sha256(raw_client_data).digest()
assert len(auth_data) == 37 and len(signed_bytes) == 69
assert auth_data[32] & 0x01 and auth_data[32] & 0x04  # UP、UV
assert hashlib.sha256(raw_client_data).digest() != hashlib.sha256(
    json.dumps(json.loads(raw_client_data), indent=2).encode()).digest()
print('署名入力 69 バイト；ここではエンコーディングのみをチェックし、実際の署名検証とトランザクション検証に代わるものではない')

RP ID は通常、有効なドメイン名です。origin にはプロトコル、ホスト、および適用可能なポートが含まれます。login.example.com は規則に適合する場合、example.com を RP ID として使用できますが、RP は依然として許可された origin を制限する必要があります。これらを単なる文字列の完全一致として唯一のチェックとすることはできません。

Passkey は「常に1台のハードウェアに閉じ込められる」わけではない

Passkey は同期資格証明也可以是、単一デバイスにバインドされます。同期プロバイダーは、その保護メカニズムの下で、複数のデバイスで資格証明を使用します。これはデバイスバインド鍵のライフサイクルとは異なります。WebAuthn は、すべての秘密鍵がエクスポート不可能なハードウェアセキュリティモジュール（HSM）に存在しなければならないことを規定していません。生体認証も必須条件ではなく、ユーザー検証はデバイスの PIN 等方式で完了でき、RP は通常、生体特徴の生データを取得しません。FIDO Passkeys

カウンターを実装していない認証器は、常に 0 を返す可能性があります。その他の場合、増加しないことは、複製、故障、または並列応答の順序入れ替えに関与している可能性があり、仕様とリスクポリシーに従って処理する必要があります。challenge の一回性使用は、トランザクションの新鮮性の核心の一つです。

ドメイン名スコープにより、偽装サイトは、パスワードや OTP を収集する場合のように、実際の RP 用の認証結果を取得できません。ただし、アカウント復旧、既にログイン中のセッション、および端末環境には、独自の信頼境界があります。パスワードを削除しても、脆弱な復旧フローが強力になるわけではありません。

署名は正しいのに、なぜログインできないのか？

初期の RP ID は example.com ですが、origin はそのログインサブドメインであり、両者が直接文字列一致することを要求するものではありません。UV を取消しして UP を保持することは、タッチによる存在が、このポリシーで要求されるユーザー検証の完了に等しくないことを示しています。他のフィールドが正しくても、これを補完することはできません。

RADIUS と EAP：認証サーバーが決定し、NAS が実行する

典型的な 802.1X では、端末は EAPOL を介して AP/スイッチと対話し、NAS は EAP メッセージを RADIUS 属性にラップして認証サーバーに送信します。EAP は拡張可能な認証フレームワークであり、EAP-TLS はその中で TLS を使用するメソッドです。すべての EAP を暗号化トンネルと呼ぶことはできません。RADIUS/EAP、EAP-TLS 1.3

RADIUS Access-Request には、Access-Challenge、Access-Accept、または Access-Reject が返されます。複数ラウンドの challenge は、State などの属性を使用して認証プロセスに関連付けられます。Accept には、VLAN、フィルタリング、またはセッションタイムアウトなどの認可属性が含まれる場合があります。認証は通過したが VLAN が正しく適用されていない場合、パスワードを再入力するだけでなく、NAS の実行と属性サポートを確認する必要があります。

古典的な RADIUS/UDP では、1812 番ポートが認証、1813 番ポートが課金に一般的に使用され、基本ヘッダーは 20 バイトで、Code、Identifier、Length、および 16 バイトの Authenticator を含みます。Authenticator の具体的な構成はメッセージタイプに依存し、「乱数」や「全体暗号化」と一律に呼ぶことはできません。共有シークレットと従来の属性保護は、メッセージ全体に現代的な通信の機密性があることを意味しません。RFC 2865

RADIUS/TLS または DTLS は、NAS/プロキシとサーバー間の転送を保護しますが、これは端末から EAP サーバーへの EAP-TLS とは別の境界です。RFC 9765 で定義されている RADIUS/1.1 は実験的仕様であり、TLS/DTLS 上の ALPN 交渉を通じて、そのモードの共有シークレット、MD5 パケット認証、属性難読化メカニズムを削除します。すべての既存の UDP RADIUS がこれによってアップグレードされたとは主張できません。RADIUS/1.1

RADIUS サーバーは、ローカル設定、証明書、ディレクトリ、またはその他のアイデンティティソースを使用でき、アカウントデータを LDAP/AD に配置する必要はありません。課金記録はセッションイベントと統計を記述しますが、厳密な1回性の台帳を自然に構成するものではなく、アプリケーションは再送、欠落、およびセッション関連付けを処理する必要があります。

TACACS+ は、デバイス管理における認証、コマンドごとの認可、および課金に一般的に使用されます。その伝統的なプロトコルヘッダーは平文で、本文は共有シークレットに基づく難読化を使用するため、「全体が現代的に暗号化されている」と単純化することはできません。特定の RADIUS デプロイメントを置き換えるかどうかは、デバイスの機能と管理ニーズによって異なります。RFC 8907

これらを組み合わせてアイデンティティシステムを構築する

ある企業は、LDAP でディレクトリを保存し、Kerberos でドメインサービスにアクセスし、IdP が WebAuthn でユーザーを認証し、Web アプリケーションに SAML または OIDC 結果を発行します。オフィスネットワークは RADIUS/EAP によってアクセス制御されます。これらのコンポーネントは人員のライフサイクルを共有しますが、同じセッション状態を自動的に共有するわけではありません。

従業員が退職した後、ディレクトリの無効化、チケットの残存有効期間、IdP セッション、アプリケーションセッション、登録済み passkey、およびネットワークアクセスセッションはそれぞれ変化します。完全な設計では、各状態の保持者、有効期間、および失効伝播方法を明確にする必要があります。プロトコルの選択後、このアイデンティティライフサイクルを依然として結びつける必要があります。