mcpField
E
entra-verified-id

entra-verified-id

github.com/vinayaklatthe安全17844 次安装19 周前更新
代码仓库

关于 entra-verified-id

用于设计 Microsoft Entra Verified ID 身份流程的技能；该平台基于开放标准提供可验证凭证。它帮助组织向用户签发凭证并验证其他发行方的凭证，无需通过后台交换身份数据。

主要功能

  1. 01签发和验证数字凭证
  2. 02设计凭证架构与证明流程
  3. 03规划凭证撤销
  4. 04使用 SDK 构建验证应用
  5. 05通过 Conditional Access 要求出示凭证

适用场景

  1. 01验证远程员工入职身份
  2. 02无需服务台工单即可恢复账户
  3. 03授予访问权限前核验承包商凭证
  4. 04对特权操作启用 Face Check

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-verified-id

安装后在 Claude Code 中输入/entra-verified-id确认已加载。

详细介绍

Microsoft Entra Verified ID

Entra Verified ID 是 Microsoft 基于开放标准（W3C 可验证凭据数据模型、去中心化标识符、OpenID4VC）构建的可验证凭据平台。它让组织能够向任何人（员工、承包商、客户）签发已签名的数字凭据，并验证由他人（Microsoft、政府、合作伙伴、你自己的租户）签发的凭据，而无需通过旁路通道共享用户身份数据。

适用场景

  • 高可信度入职（远程新员工身份验证）。
  • 无需联系帮助台即可恢复账户。
  • 跨组织访问（持有雇主签发的 VC 的承包商）。
  • 授予特权访问权限前验证供应商／合作伙伴身份。
  • 需要可携带、由用户控制的凭据的客户场景。

请勿将此技能用于 B2C 消费者身份验证（entra-external-id）、标准员工身份（entra-id）或 X.509 PKI（pki-design）。

一段话说明架构

你的租户会获得一个去中心化标识符（DID）。Key Vault 中的签名密钥会按照架构（声明）生成可验证凭据，并配合规则文件（签发时如何收集这些声明）和显示文件（凭据在钱包中的视觉呈现）。用户将凭据保存在Microsoft Authenticator（默认钱包）中。验证方（任何应用／租户）通过二维码或深层链接请求凭据，钱包出示凭据，验证方依据签发者的 DID 验证签名。可选的 Face Check 会要求钱包将实时自拍照与 VC 中的照片声明进行匹配。

实施方法

  1. 设置签发者租户。

    • 验证域名所有权（将关联域名证明附加到你的 DID）。
    • 配置 Key Vault 和签名密钥；授予 Verified ID 服务所需的权限。
    • 选择 DID 方法：did:web（关联到你的域名，推荐用于企业）或 did:ion。

  2. 设计凭据架构。 从一到两种凭据开始，而不是十种：

    • 已验证员工（姓名、员工 ID、业务部门、签发日期）。
    • 已验证贸易技能／认证（技能、有效期）。 避免声明过多属性——隐私风险和撤销工作量会随属性增加而上升。

  3. 选择签发证明流程：

    • ID Token（Entra）——用户登录后从 Entra ID 提取声明（适用于员工场景，速度快）。
    • ID Token Hint——由你的应用提供声明（自定义数据存储）。
    • 用户自我声明——由用户输入声明（保证级别最低；很少使用）。
    • 可验证凭据——声明来自其他 VC（重新签发／逐步提升保证级别）。
    • 身份验证合作伙伴（例如通过 Microsoft Marketplace 提供的 LexisNexis、Onfido、IDEMIA）——用于远程入职时进行真正的身份验证。

  4. 签发前制定撤销策略。使用 status list 2021 方法进行批量撤销。规划生命周期事件：员工离职时触发 API 调用以撤销凭据。

  5. 搭建验证方应用。 Web／移动应用生成二维码 → 用户使用 Authenticator 扫描 → 应用接收出示的凭据。提供 .NET、Node.js、Java、Python 的 SDK。

  6. 高价值用例（从这里开始）：

    • 远程入职：候选人通过合作伙伴验证身份 → 获得已验证员工 VC → 使用该凭据完成首次无需 TAP 的 Entra ID 设置，包括配置通行密钥。
    • 无需帮助台的账户恢复：账户被锁定的用户出示已验证员工 VC → 无需提交工单即可重置 MFA。
    • 特权访问时使用 Face Check：执行高影响管理员操作时，在授权前触发 Face Check 凭据出示请求。

  7. 通过身份验证上下文与身份验证强度的组合，与 Conditional Access 集成——CA 可以要求用户出示 VC，才能访问敏感资源。

防护措施

  • 将颁发者签名密钥视同 CA 密钥。 密钥一旦泄露，攻击者就能冒用你的名义颁发伪造的 VC。使用由 Key Vault HSM 提供支持的密钥，设置独立的访问策略，并在 Verified ID 服务主体以外的实体使用密钥时发出警报。
  • 不要在凭证中放入无法证明有必要的个人身份信息。 VC 会长期存储在钱包中；必须遵循 GDPR 的数据最小化原则。
  • 在颁发前规划撤销机制。 状态列表端点必须始终可访问；应像对待 CRL 一样维护它们。
  • DID 文档是公开的。 不要在其中包含敏感端点或元数据。
  • 目前钱包仅支持 Microsoft Authenticator（第三方 OpenID4VC 钱包正在兴起，但尚未实现普遍互操作）。请据此规划。
  • 不要在每次声明变更时都重新颁发。 使用有效期较短的 VC，或通过 API 刷新证明；避免频繁撤销。
  • Face Check 要求 VC 中包含照片声明。 确保照片来源可信（HR 系统、经合作伙伴验证）——否则人脸匹配结果也不可靠。
  • 验证方的同意屏幕很重要。 用户会看到你请求了哪些声明；应尽量减少请求的声明。

常见反模式

  • “颁发包含 20 个属性的单一超大型凭证”——会泄露隐私，并导致任何信息变更都必须重新颁发。应组合使用多个较小的 VC。
  • “在入职流程中使用自我声明的‘已验证员工’”——没有任何保证；攻击者可以随意填写信息。应使用 Entra ID 或合作伙伴证明。
  • “将签名密钥放在 App Service 配置中”——绕过 HSM，且没有审计记录。务必使用 Key Vault。
  • “不设置撤销机制”——员工离职后仍能永久持有有效 VC。从第一天起就应设置状态列表并自动处理离职。
  • “验证方不使用信任列表，接受任何 DID”——会接受冒充的颁发者。应明确固定可信颁发者 DID。
  • “使用 Verified ID 进行日常登录，而不使用通行密钥/FIDO2”——VC 用于身份核验，而非会话身份验证。登录应使用 FIDO2/通行密钥（passkeys-fido2）。
  • “为了节省远程入职成本，跳过身份验证合作伙伴”——最薄弱的一环是初始信任；合作伙伴证明正是其价值所在。

示例提示词

  • 为 5,000 名员工颁发 Verified Employee 凭证，并将撤销机制集成到由 HR 驱动的离职工作流中。
  • 设计一个远程入职流程：由验证合作伙伴颁发 VC，随后配置通行密钥，并实现无需 TAP 的首次登录。
  • 通过出示 Verified Employee VC，实现无需帮助台介入的 MFA 重置。
  • 在激活 Global Administrator 权限时，为特权访问添加 Face Check。
  • 设计承包商凭证的架构，包含技能、项目和到期声明。
  • 使用 Verified ID Request Service，以 .NET 搭建验证方 Web 应用。
  • 为企业级颁发者部署选择 did:web 还是 did:ion。

Microsoft Learn

评论

支持 Markdown