#networking #安全协议
本页目录

认证框架

Kerberos(对称密钥+票据)、SAML(联合身份+XML 断言)、WebAuthn(公钥+本地生物识别)——三种认证框架分别解决域内、跨域、防钓鱼三个不同场景。LDAP 和 RADIUS 则在基础设施层提供目录和网络准入。

概述

"认证"要回答的问题永远是同一个——⁠怎么证明你是你⁠，但不同协议把"证明"放在了不同的位置上，由此分出几个世代：

协议年代凭据形态信任放在哪主战场
Kerberos1988对称票据中心 KDC企业内网 / AD
LDAP bind1993用户名+密码目录服务器内部目录 / 后端存储
SAML 2.02005签名 XML 断言IdP企业 Web SSO
RADIUS1991共享密钥 + EAPAAA 服务器网络接入 (WiFi/VPN)
WebAuthn2019非对称密钥对用户设备抗钓鱼的无密码登录

理解一条主线就够了：⁠密码是负债⁠。它会被复用、钓鱼、撞库、在传输和存储中泄露。后面每一代协议都在想办法让密码少出现一次——Kerberos 让密码只在本地参与一次派生、再不上网；SAML/OIDC 让密码只交给 IdP 一个地方；WebAuthn 干脆用设备里不可导出的私钥彻底取代密码。选型的本质是：⁠在你已有的基础设施和威胁模型下，密码能被消除到什么程度⁠。

Kerberos — 票据制单点登录

AD 域登录的底座。核心思想：用户只在登录时用密码派生一次密钥，之后全程靠有时限的对称加密票据访问各服务，密码再不经过网络。

Kerberos 三阶段:登录一次,之后全靠票据 角色:KDC = AS(认证服务器)+ TGS(票据授予服务器);客户端;服务 ① AS-REQ/REP · 登录一次 Client → AS: “我是 alice” AS → Client: TGT(TGS密钥 加密)+ 会话密钥(密码派生 密钥加密) → 密码本身从不上网 ② TGS-REQ/REP · 每访问一次 Client → TGS: 出示 TGT, “我要访问 fileserver” TGS → Client: 服务票据 (fileserver密钥加密) + 新会话密钥 ③ AP-REQ/REP · 访问服务 Client → fileserver: 服务票据 + authenticator(时间戳, 防重放) fileserver 解票据 → 信任 KDC 背书 →(可选)AP-REP 双向认证 服务端无需联系 KDC、无需存用户密码就能验证客户端——只要能解开"用自己密钥 加密的票据",就证明票据是 KDC 签发的。密码只在登录一次时参与派生,之后再不上网。

为什么这样设计：服务端无需联系 KDC、无需存用户密码就能验证客户端——它只要能解开"用自己密钥加密的票据"，就证明票据是 KDC 签发的。代价与威胁：

  • 时钟同步⁠：authenticator 靠时间戳防重放，全域时钟偏差通常须 < 5 分钟（所以 AD 强依赖 NTP）。
  • KDC 是高价值单点⁠：拿到 krbtgt 账户的哈希即可伪造任意 TGT（Golden Ticket）；拿到某服务密钥可伪造该服务票据（Silver Ticket）。
  • Kerberoasting：服务票据用服务账户密码派生的密钥加密，攻击者可请求后离线爆破弱口令的服务账户——所以服务账户要用强随机密码 / gMSA。

LDAP — 目录与 bind 认证

LDAP（RFC 4511）首先是一个层级目录⁠（cn=alice,ou=users,dc=example,dc=com），存人、组、设备及其属性。它的"认证"就是 bind 操作：拿 DN + 密码去服务器换一个"通过/拒绝"。

LDAP 应用接入:search-then-bind 两步 ① 服务账户 bind 应用用服务账户 bind → search 出 alice 的完整 DN ② 用户 DN + 密码 bind 再用 alice 的 DN + 她输入的密码 做一次 bind → 成功即密码正确

bind 方式对比

simple bind DN + 明文密码 必须跑在 LDAPS/StartTLS 之上, 否则口令裸奔 SASL bind GSSAPI(Kerberos)/ EXTERNAL(mTLS) 不传密码,更强 LDAP 本身不是 SSO 协议——是"凭据校验 + 身份数据源",常被藏在 SAML/OIDC/RADIUS 背后当存储。

定位要点：LDAP 本身不是 SSO 协议⁠，它是"凭据校验 + 身份数据源"，常被藏在 SAML/OIDC/RADIUS 背后当存储。Active Directory ≈ LDAP（目录）+ Kerberos（认证）+ DNS（定位）三件套的组合。

SAML 2.0 — 企业 Web SSO

XML 时代的浏览器 SSO 标准（Okta、Azure AD、企业内网）。SP（服务方）把认证"外包"给 IdP（身份方），IdP 返回一份带数字签名的断言（Assertion）。

SAML 2.0 SP-initiated 流程(HTTP 重定向 + 表单 POST 绑定) 1 User → SP:访问受保护资源 2 SP → Browser:重定向到 IdP,携带 AuthnRequest(HTTP-Redirect binding) 3 IdP 验证用户(可能复用已有会话)→ 生成 Assertion 4 IdP → Browser → SP:自动 POST 表单回传 Response(HTTP-POST binding) 5 SP 验证 XML 签名 + 条件 → 建立本地会话 Assertion 关键字段 <Issuer> 谁签发(须在 SP 信任列表) <Subject><NameID> 用户标识 <Conditions NotBefore=".." NotOnOrAfter=".."> 有效期 → 防重放 <AttributeStatement> email / groups / role 等 <ds:Signature> XML-DSig 签名(覆盖断言或整个 Response)

安全要点（SAML 的坑几乎都在验签）：

  • XML Signature Wrapping (XSW)：攻击者把合法签名的元素挪位、再注入伪造断言。SP 必须严格校验"签名覆盖的正是被采信的那个元素"，并固定 schema 解析——这是 SAML 实现最常见的 CVE 来源。
  • 必须校验 Audience（这份断言是给我的）、NotOnOrAfter（未过期）、Recipient 与 InResponseTo（防重放/防注入），并对 NameID 做一次性消费。
  • 它为什么还活着：纯浏览器重定向、无需 JS、与老牌企业 IdP 兼容性最好。新项目则首选 OIDC。

WebAuthn / Passkeys — 抗钓鱼的无密码

FIDO2/WebAuthn（W3C）用一对非对称密钥取代密码：私钥生成后锁在设备安全单元里、不可导出，服务器只存公钥。

WebAuthn:非对称密钥对取代密码,私钥不出设备

注册 · navigator.credentials.create Server → challenge(随机) 认证器 为(RP ID=example.com)生成密钥对, 私钥留本地 → 返回 credential_id + public_key +(可选)attestation Server 存 credential_id ↔ public_key

认证 · navigator.credentials.get Server → challenge + 允许的 credential_id 认证器 用户验证(指纹/PIN)→ 用私钥对 (challenge + origin + RP ID)签名 Server 用公钥验签 + 核对 challenge + origin

签名绑定 origin/RP ID——认证器只认得对的域名,这是密码、OTP 都给不了的抗钓鱼保证。

它唯一真正重要的性质是抗钓鱼⁠：签名里绑定了 origin/RP ID，浏览器只会把 example.com 的凭据用于 example.com。哪怕用户被骗到 examp1e.com，认证器也找不到匹配凭据、签不出可用结果——这是密码、OTP、推送通知都给不了的保证。其余概念：

  • attestation：证明"这是某型号正品认证器"，消费场景一般不校验（隐私 + 兼容）。
  • discoverable credential（resident key）：把用户句柄也存进认证器，实现"无需先输用户名"的登录——这正是 Passkey 的基础。
  • Passkey = 可同步的 discoverable 凭据⁠：经 iCloud Keychain / Google Password Manager 跨设备同步，可用性大增，但信任随之转移到那个云账户；纯硬件密钥（device-bound）不同步、更强但易丢失。

RADIUS — 网络接入的 AAA

RADIUS（RFC 2865）管的不是"登录网站"，而是"⁠能不能上这张网⁠"——WiFi（WPA2/3-Enterprise）、VPN、交换机端口（802.1X）。它做 AAA：Authentication、Authorization、Accounting。

RADIUS:网络接入层的 AAA 前台 NAS AP / 交换机 / VPN 网关 RADIUS 服务器 Authentication/Authorization/Accounting

UDP 1812/1813 shared secret(NAS↔服务器)

EAP 隧道承载真正的认证方法 EAP-TLS = 证书双向认证(最强) PEAP/TTLS = TLS 隧道里再跑 MSCHAPv2 等 常回查 LDAP / AD / Kerberos

802.1X 三方 终端(supplicant) 交换机(authenticator) RADIUS(server)

RADIUS 只是 AAA 前台,把接入层和身份层解耦——真正的账号数据留在 LDAP/AD/Kerberos。

要点：RADIUS 自己只是个 AAA 前台，身份数据通常还在 LDAP/AD 里；它把"接入层"和"身份层"解耦。需要按命令做细粒度授权与审计（网络设备运维）时，用 TACACS+（逐命令授权、全程加密）替代。

选型

需求首选关键理由
AD 域内服务互认Kerberos票据 SSO, 密码不上网
内部目录 / 作为后端身份源LDAP(S)是数据源而非 SSO, 藏在别的协议背后
企业 Web SSO（老牌 IdP）SAML 2.0纯浏览器、兼容性最好
现代 App / 移动端 / 联邦登录OIDCJSON/JWT, 比 SAML 轻
抗钓鱼的用户登录WebAuthn/Passkeyorigin 绑定, 消除密码
WiFi / VPN / 端口准入RADIUS + EAP网络接入层 AAA
网络设备逐命令授权审计TACACS+细粒度 + 全加密

实践里它们是分层叠用而非二选一：典型组合是 WebAuthn/OIDC 做用户登录前台 + LDAP/AD 做身份源 + Kerberos/RADIUS 管内网与接入⁠。

参考

  • Kerberos: RFC 4120 · MIT Kerberos 文档 · "Kerberos: The Definitive Guide"
  • WebAuthn: w3c.github.io/webauthn · webauthn.guide · passkeys.dev
  • SAML: OASIS SAML 2.0 Core · "On Breaking SAML"（XSW 攻击论文）
  • 统一平台⁠: Keycloak（同时讲 OIDC/SAML/LDAP/Kerberos brokering，值得搭起来读）

Keywords: Kerberos, KDC, TGT, Golden Ticket, Kerberoasting, LDAP, bind, SAML, Assertion, XML Signature Wrapping, WebAuthn, Passkey, FIDO2, phishing-resistant, RADIUS, EAP, 802.1X, TACACS+

相关页面

© 2026 liz's doc