Anthropic-Cybersecurity-Skills 实战指南：SAML 2.0 与 Microsoft Entra ID（Azure AD）身份联合的标准体系与落地实践

导读

本文围绕 skills/building-identity-federation-with-saml-azure-ad/references/standards.md 展开，系统梳理基于 SAML 2.0 建立本地 Active Directory 与 Microsoft Entra ID（原 Azure AD）之间身份联合（Identity Federation）所需掌握的标准协议、Entra ID 联合域要求和合规映射基线。你将掌握 SAML 2.0 / WS-Federation / OpenID Connect 三类协议在混合身份场景中的选型差异，理解 NIST SP 800-63C、FedRAMP 与 ISO 27001:2022 对联合身份的具体控制要求，并结合仓库内该技能配套的 SKILL、API 参考、工作流与 Python 校验脚本，将标准落地为可审计、可验证的联合 SSO 配置。

一、Federation Protocols：三大联合协议全景

身份联合（Identity Federation）的核心思想是：由一个身份提供方（IdP）完成用户认证，另一个资源方（SP）信任并接受该认证结果，用户无需在两端维护两套独立凭据。standards.md 首先对三类主流联合协议给出了精确定义，这也是后续选型的基础。

1.1 SAML 2.0（OASIS）

Security Assertion Markup Language 2.0 是 OASIS 标准组织定义的、基于 XML 的认证与授权数据交换框架。它的关键特征如下：

• 消息格式：断言（Assertion）以 XML 承载，包含认证语句、属性语句与授权决策语句；
• Profile（应用场景）：Web Browser SSO（浏览器 SSO，最常用）、Enhanced Client or Proxy（ECP，富客户端或代理场景）、Single Logout（单点登出）；
• Binding（传输绑定）：HTTP Redirect（通过 URL 参数重定向传递）、HTTP POST（通过表单 POST 传递）、HTTP Artifact（先传引用再交换真实断言）、SOAP。

仓库中 api-reference.md 给出了这些 Binding 的标准 URI，可用于元数据解析与校验：

Binding	URI
HTTP-POST	urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
HTTP-Redirect	urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
SOAP	urn:oasis:names:tc:SAML:2.0:bindings:SOAP

同时，解析 IdP 元数据时需要使用标准 XML 命名空间，仓库的 agent.py 与 process.py 中均有体现：

ns = {
    "md": "urn:oasis:names:tc:SAML:2.0:metadata",
    "ds": "http://www.w3.org/2000/09/xmldsig#",
    "saml": "urn:oasis:names:tc:SAML:2.0:assertion",
}

1.2 WS-Federation（OASIS）

Web Services Federation Language 是面向 Web 服务与被动联合（passive federation，即浏览器驱动）的规范，被 AD FS 用于浏览器场景的身份联合：

• Token 类型：支持 SAML 1.1 与 SAML 2.0 两种令牌格式；
• 典型用途：本地 AD FS 与云端（如 Microsoft 365 / Entra ID）之间的被动联合，浏览器把认证请求重定向到 IdP，认证后以 POST 形式回传令牌。

1.3 OpenID Connect

OpenID Connect 构建于 OAuth 2.0 之上，是与 SAML 的 XML 体系相对的 JSON/REST 方案：

• 令牌格式：JWT（JSON Web Token）而非 SAML 断言；
• 在 Entra ID 中的定位：现代 Web 与移动应用的首选协议；
• 本质区别：SAML 偏重企业 SSO 与第三方应用的成熟互操作，OIDC 更契合云原生 API 生态。

standards.md 将三者关系归纳为互补而非替代：企业存量应用与合规审计场景多选 SAML 2.0，遗留应用靠 WS-Federation 衔接，新应用默认 OIDC。

二、Microsoft Entra ID 联合要求

2.1 支持的联合协议与选型表

standards.md 用一张表明确了 Entra ID 对不同协议的支持情况与适用场景：

Protocol	Use Case	Token Format
SAML 2.0	Enterprise SSO, third-party apps	SAML assertion (XML)
WS-Federation	Legacy applications, AD FS	SAML token
OpenID Connect	Modern web/mobile apps	JWT

配套的 SKILL.md 进一步给出了四种联合/身份模型，帮助你按认证权威（Authentication Authority）归属做架构决策：

Model	Authentication Authority	Use Case
Federated (AD FS)	On-premises AD FS	Regulatory requirement to keep auth on-prem
Managed (PHS)	Azure AD with password hash sync	Simplest cloud auth, AD FS not needed
Managed (PTA)	On-premises via pass-through agent	Cloud auth validated against on-prem AD
Third-Party Federation	External IdP (Okta, Ping)	Multi-IdP environment

其中"Federated"模式正是本文主角：认证权威留在本地 AD FS，Entra ID 仅作为代理（broker）把断言兑换为自己的令牌。

2.2 域联合（Domain Federation）前置要求

standards.md 强调，将一个域配置为联合域必须满足以下条件：

• 域必须在 Azure AD 中完成验证（Domain must be verified），未验证的域无法设置联合配置；
• 每个域仅允许一份联合配置（Only one federation configuration per domain），域与 IdP 是强绑定关系；
• 推荐启用密码哈希同步（Password hash sync）作为备份——这正是 workflows.md 中故障切换流程的前提；
• 混合身份同步需借助 Azure AD Connect，确保本地对象与云端对象的 ImmutableID 锚定关系一致。

从源码结构看，process.py 中的 get_domains() 正是通过 Microsoft Graph 的 /domains 端点枚举每个域的 authenticationType（取值为 Managed 或 Federated）与 isVerified 状态，可作为"域是否满足联合前置条件"的自动化检查手段。

2.3 联合域的 SAML 认证架构

SKILL.md 给出了联合域下的完整认证流，这也是 standards.md 所述协议的动态实例：

User → Cloud App (SP)
   │
   └── Redirect to Azure AD
          │
          ├── Azure AD checks federated domain
          │
          └── Redirect to on-premises AD FS
                 │
                 ├── AD FS authenticates against Active Directory
                 │
                 ├── AD FS issues SAML token
                 │
                 └── Token posted back to Azure AD
                        │
                        ├── Azure AD validates federation trust
                        │
                        ├── Azure AD issues its own token
                        │
                        └── User receives access token for cloud app

workflows.md 还细化了 AD FS 侧认证手段与断言内容：内网走 Kerberos、外网走 Forms 认证、可叠加 MFA 挑战；断言携带 UPN、ImmutableID（objectGUID 的 Base64 编码）、Email、显示名与组成员，并由令牌签名证书签名。Entra ID 验证签名后，将 ImmutableID 与已同步用户匹配，执行条件访问策略，最终为应用签发自身令牌。

2.4 联合信任（Federation Trust）组件

Component	Description
Token-Signing Certificate	X.509 certificate used by IdP to sign SAML assertions
Federation Metadata	XML document describing IdP endpoints and capabilities
Relying Party Trust	Configuration in AD FS for each SP (Azure AD)
Claims Rules	Transform AD attributes into SAML claims
Issuer URI	Unique identifier for the IdP (entity ID)

三、Compliance Mapping：三套合规基线的联合身份要求

standards.md 的核心价值在于把"技术标准"与"合规标准"对齐，这是企业在设计联合身份架构时最容易忽略的部分。

3.1 NIST SP 800-63C：联合与断言（Federation and Assertions）

NIST SP 800-63C 定义了三个联合保障等级（Federation Assurance Level, FAL），用于度量"IdP 向 RP 传递认证结果时断言的安全性"：

• FAL1：Bearer assertion（持有型断言），直接呈现给 RP。断言本身即访问凭证，被截获即被冒用；
• FAL2：Bearer assertion 叠加额外安全措施（如 RP 侧强制绑定、额外认证或加密通道），降低断言被重放的窗口；
• FAL3：Holder-of-key assertion（密钥持有型断言），断言与用户持有的密钥绑定，RP 可通过持有者证明验证用户真实持有密钥，安全性最高。

在 Entra ID + AD FS 联合场景中，SAML 断言通过 HTTPS POST 绑定传递且由令牌签名证书签名，可视为向 FAL2 级别对齐的工程实践；若业务对断言防重放有更高要求，则应评估向 FAL3（持有者密钥）演进的可能性。

3.2 FedRAMP：身份与认证控制

standards.md 明确了 FedRAMP 对联合身份直接相关的三类控制项：

• IA-2：Identification and Authentication——所有用户（包括非本组织用户）必须唯一标识并认证；
• IA-5：Authenticator Management——认证器（证书、令牌、口令）的全生命周期管理；
• IA-8：Identification and Authentication (Non-Organizational Users)——针对外部用户（合作伙伴、外包人员）的身份与认证要求。

其结论是：跨组织访问（cross-organization access）要求实施联合。因为 IA-8 所辖的非组织用户无法由本组织统一维护凭据，只能通过受信 IdP 的联合认证来满足"已认证身份"的证明链。在云上（如 FedRAMP 授权的 SaaS 应用）接入企业用户时，以 AD FS 为 IdP 的 SAML 联合正是满足 IA-2 / IA-8 的常见实现。

3.3 ISO 27001:2022：附录 A 控制项

standards.md 将联合身份映射到 ISO 27001:2022 附录 A 的三个控制项：

• A.5.16：Identity management——身份全生命周期（创建、变更、注销）管理；
• A.5.17：Authentication information——认证信息的分配与保护，避免明文存储与共享；
• A.8.5：Secure authentication——采用安全认证技术，SAML 联合断言配合 MFA 即是典型落点。

这些控制项与 template.md 中"Claims Rules / Validation Results / Disaster Recovery"表格一一呼应：身份映射（A.5.16）、令牌与证书管理（A.5.17）、认证与 MFA 验证（A.8.5）都被转化成了可执行、可记录的实施条目，这正是把合规要求工程化的做法。

3.4 本技能的框架映射

该技能在 frontmatter 中还声明了与 NIST CSF 2.0（PR.AA-01/02/05/06）、MITRE ATT&CK（如 T1606.002、T1556.007、T1484.002、T1078.004、T1110.003）及 MITRE F3 的映射关系。这意味着联合身份配置不仅是功能实现，同时是检测对抗行为（如联合域劫持、口令喷洒）与欺诈初始访问（F1006 账户接管）的防御基线——详见仓库的 ATTACK_COVERAGE.md 与 docs/mitre-f3-mapping.md。

四、标准落地的实战路径

standards.md 偏重标准与要求，本技能的 SKILL.md 与 workflows.md 则提供了五步实施与四阶段工作流，二者结合即为从标准到生产的完整闭环。

4.1 五步实施框架

1. 准备 AD FS 基础设施：安装 AD FS 角色并构建场（farm），使用 gMSA 服务账户与公开 TLS 证书，服务名如 fs.corp.example.com；
2. 配置 Azure AD 联合域：通过 Microsoft Graph PowerShell（Connect-MgGraph -Scopes "Domain.ReadWrite.All"）以 AD FS 联合元数据（issuerUri、passiveSignInUri、signingCertificate、preferredAuthenticationProtocol = "saml"）将托管域转为联合域；
3. 配置 AD FS 声明规则：添加指向 Azure AD 的 Relying Party Trust，通过 LdapClaims 模板抽取 AD 属性（UPN、email、givenName、surname），并以 PassThroughClaims 把 UPN 作为持久化 NameID 传递；
4. 配置第三方 SaaS 联合：在 Entra Admin Center 的 Enterprise Applications 中配置 SAML SSO，填写 Identifier、Reply URL (ACS)、Sign-on URL，映射 NameID 与附加声明，下载联合元数据交给 SaaS 应用侧；
5. 证书生命周期管理：Get-AdfsCertificate 检查令牌签名证书有效期，优先启用自动轮换（默认开启），手动轮换则按"添加为次要 → 更新 Azure AD → 提升为主 → 移除旧证书"四步执行。

4.2 四阶段工作流

workflows.md 将上述过程组织为 Prerequisites → Federation Configuration → Application SSO → Security Hardening 四个阶段，并在每个阶段内置验证动作：阶段二用 Test-MgDomainFederationConfiguration 验证联合配置并执行端到端登录测试；阶段四要求启用条件访问、MFA、智能锁定（smart lockout）、外网锁定（extranet lockout）、证书自动轮换，并将 AD FS 审计日志转发至 SIEM。

4.3 故障切换：AD FS 中断的兜底

由于 standards.md 明确要求"Password hash sync recommended as backup"，workflows.md 给出了两条降级路径：

• 方案一：分阶段迁移到托管认证（Staged Rollout）——启用密码哈希同步，通过 Azure AD staged rollout 将部分组迁至托管认证，用户直接以口令哈希向 Azure AD 认证；
• 方案二：紧急转托管域（Convert-MgDomainToManaged）——全量切换，但前提同样是密码哈希同步处于激活状态。

AD FS 恢复后需重新建立联合信任、把域转回联合域并验证认证流。可见，"备份认证通道"不是可选项，而是联合架构的强制冗余设计。

五、用仓库脚本把标准变成可审计证据

本技能的 agent.py 与 process.py 是 standards.md 中"协议与元数据"要求的直接自动化实现。

5.1 agent.py：SAML 联合配置验证代理

agent.py 提供四步闭环，其校验逻辑严格对应标准要求：

• fetch_federation_metadata(tenant_id)：拉取 Entra ID 租户联合元数据（https://login.microsoftonline.com/{tenant-id}/federationmetadata/2007-06/federationmetadata.xml）；
• parse_metadata()：按 SAML 2.0 metadata 命名空间解析 entityID、SingleSignOnService（含 Binding 与 Location）及 X509Certificate；
• generate_sp_metadata()：生成 SP 侧元数据，默认 ACS 绑定为 HTTP-POST、NameID 格式为 emailAddress，支持可选的 SLO（HTTP-Redirect）；
• validate_configuration()：输出分级校验结论——Critical（IdP 无 SSO 服务、无签名证书）、High（ACS URL 未使用 HTTPS）、Medium（缺少 HTTP-POST 绑定），与 api-reference.md 的 Validation Checks 表完全一致。

python scripts/agent.py --tenant-id <tenant-id> --sp-entity-id <sp-entity-id> \
    --acs-url https://app.example.com/acs --slo-url https://app.example.com/slo

5.2 process.py：联合配置健康审计器

process.py 的 FederationAuditor 类面向日常运维审计：

• 通过 MSAL 客户端凭据流程获取令牌，调用 Microsoft Graph（需 Domain.Read.All、AuditLog.Read.All、Directory.Read.All 权限）；
• validate_adfs_metadata()：抓取并解析 AD FS 联合元数据，检查 entityID 与 KeyDescriptor 下的证书数量；
• check_certificate_expiry()：基于 cryptography 库解析证书，输出 days_until_expiry、is_expired、needs_renewal（<30 天告警），直接支撑 standards.md 中"证书生命周期"与 ISO 27001 A.5.17 的落地；
• get_signin_logs()：按域过滤 auditLogs/signIns，跟踪 authenticationProtocol 与失败原因；
• generate_federation_audit_report()：汇总全部联合域的 issuerUri、passiveSignInUri 与证书健康，自动产出 Critical/High 级发现项，例如证书已过期则给出"立即轮换并更新 Azure AD"的处置动作。

pip install msal requests cryptography lxml
# 用法：
#   auditor = FederationAuditor(tenant_id, client_id, client_secret)
#   report = auditor.generate_federation_audit_report()
#   print(json.dumps(report, indent=2))

5.3 模板化收口：template.md

template.md 提供实施记录模板，包含 Federation Details（租户、联合域、AD FS 服务 URL、备份认证方式）、Claims Rules 映射表（UPN→NameID、objectGUID→ImmutableID、mail→emailaddress）、Validation Results（元数据可达性、证书有效性、SP/IdP 双端 SSO 流、MFA 与智能锁定、登录日志）以及 Disaster Recovery 检查清单（含 break-glass 云管理员账户）。这套模板让前述每一条标准要求都能落到可审计的证据条目。

六、Validation Checklist：上线前的最终把关

SKILL.md 给出的验收清单可作为本文（尤其 standards.md）的收尾检查项，覆盖协议配置、证书、认证与冗余：

• [ ] AD FS 场运行正常，TLS 与令牌签名证书均有效；
• [ ] Azure AD 域已配置为联合域且联合元数据正确；
• [ ] 声明规则正确将 AD 属性转换为 SAML 断言；
• [ ] 测试用户可完整走通联合认证流；
• [ ] 在 AD FS 或 Azure AD 条件访问层面强制 MFA；
• [ ] 证书自动轮换已启用，或已排定手动轮换计划；
• [ ] 联合元数据端点可公开访问（/adfs/services/trust/mex 及被动登录端点）；
• [ ] 已配置智能锁定防止暴力破解（对应 ATT&CK T1110.003 口令喷洒防御）；
• [ ] AD FS 外网锁定策略已配置；
• [ ] 已为 AD FS 健康与证书过期配置监控（可交由 process.py 定期审计）；
• [ ] 灾难恢复方案中已文档化托管认证降级路径。

七、小结：从标准到可验证的联合身份

回顾 standards.md 的三块内容可以形成一条清晰的决策链：

1. 协议层（SAML 2.0 / WS-Federation / OIDC）决定断言格式、Binding 与适用场景——企业第三方应用与合规审计首选 SAML 2.0；
2. 平台层（Entra ID 域联合要求）决定域验证、单一联合配置、密码哈希同步备份与 Azure AD Connect 同步，是架构可落地的前提；
3. 合规层（NIST SP 800-63C 的 FAL1~FAL3、FedRAMP IA-2/IA-5/IA-8、ISO 27001:2022 A.5.16/A.5.17/A.8.5）决定安全等级与审计证据的颗粒度。

在本仓库中，这三层不是静态文档，而是与 SKILL.md、api-reference.md、workflows.md、agent.py、process.py 及 template.md 形成闭环的可执行体系——标准给出"为什么"与"是什么"，脚本给出"怎么验证"，模板给出"怎么留证"。读者可参照本文，先以 agent.py 验证协议配置，再以 process.py 建立证书与登录日志的持续审计，最终用 template.md 固化证据，交付一套既符合标准又经得起审计的联合身份架构。