规划 Microsoft Entra 验证 ID 验证解决方案
Microsoft的 Microsoft Entra 验证 ID （Microsoft Entra VC） 服务使你能够信任用户标识证明，而无需扩展信任边界。 使用 Microsoft Entra VC，可以创建帐户或与其他标识提供者联合。 当解决方案使用可验证凭据实现验证交换时，它使应用程序能够请求未绑定到特定域的凭据。 使用此方法可以更轻松地大规模请求和验证凭据。
如果尚未这样做，建议查看 Microsoft Entra 验证 ID 体系结构概述。 还可以查看规划 Microsoft Entra 验证 ID 颁发解决方案。
指导范围
此内容涵盖使用 Microsoft 产品和服务规划可验证凭据验证解决方案的技术方面。 解决方案与信任系统相结合，其中当前支持的是 DID Web。 DID Web 是集中式公钥基础结构。
不特定于验证解决方案的支持技术不在范围内。 例如，网站会用于可验证凭据验证解决方案，但规划网站部署的细节并未包含在内。
规划验证解决方案时，必须考虑正在添加或修改哪些业务功能。 还必须考虑可以重复使用哪些 IT 功能，以及必须添加哪些功能来创建解决方案。 另请考虑为参与业务流程的人员以及支持解决方案最终用户和员工的人员提供哪些培训。 此内容未涵盖这些文章。 建议回顾一下 Microsoft Azure 架构良好的框架，获取涵盖这些文章的信息。
解决方案的组件
作为您验证解决方案计划的一部分，您必须启用验证者、主体和颁发者之间的互动。 在本文中，术语“信赖方”和“验证方”可互换使用。 下图显示了验证体系结构的组件。
Microsoft Entra 验证 ID 服务
在验证解决方案的上下文中，Microsoft Entra 验证 ID 服务起到了将该解决方案的 Microsoft 组件与信任系统连接起来的接口作用。 该服务将密钥集配置到 Key Vault，并生成去中心化标识符（DID）。
Microsoft Entra 租户
服务需要 Microsoft Entra 租户，其为解决方案中的 Azure 资源提供标识和访问管理 (IAM) 控制平面。 每个 Microsoft Entra 租户都使用多租户 Microsoft Entra 验证 ID 服务，它颁发代表验证者的单个 DID 文档。 如果有多个信赖方使用验证服务，则它们都使用相同的验证程序 DID。 验证程序 DID 提供指向公钥的指针，允许使用者和颁发者验证来自信赖方的消息。
Azure Key Vault
Azure Key Vault 服务存储验证程序密钥，这些密钥是在启用 Microsoft Entra 验证 ID 颁发服务时生成的。 密钥用于提供消息安全性。 每个验证方都有用于签名、更新和恢复 VC 的单个密钥集。 每次服务验证请求时，已验证 ID 都会使用此密钥集。 Microsoft密钥集当前使用椭圆曲线加密（ECC）SECP256k1。 我们正在探索更广泛的 DID 社区采用的其他加密签名架构。
请求服务 API
应用程序编程接口（API）为开发人员提供了一种方法，用于抽象解决方案组件之间的交互以执行验证操作。
信任系统
Microsoft Entra 验证 ID 目前支持 DID Web 作为信任系统，其中 DID 文档托管在颁发者 Web 服务器上。
Microsoft Authenticator 应用程序
Microsoft Authenticator 是移动应用程序。 Authenticator 协调用户、Microsoft Entra VC 服务和用于颁发 VC 的协定之间的交互。 它相当于一个数字钱包，VC 的持有者将 VC 存储在其中，包括 VC 使用者的私钥。 Authenticator 也是用于展示 VC 的验证机制。
信赖方 （RP）
Web 前端
信赖方 Web 前端使用请求服务 API 来验证 VC，方法是生成主体的钱包所使用的深度链接或 QR 码。 根据方案，前端可以是可公开访问的或内部网站，以启用需要验证的最终用户体验。 但是，钱包访问的终结点必须可公开访问。 具体而言，它可以使用特定请求参数控制重定向到钱包。
业务逻辑
可以创建新的逻辑，或使用特定于信赖方的现有逻辑，并通过呈现 VC 来增强该逻辑。
特定于场景的设计
下面是满足特定用例的设计示例。 第一种是用于员工入职管理，目的是减少与新员工入职相关的时间、成本和风险。 第二种是用于帐户恢复，使最终用户能够使用自助服务机制恢复或解锁其帐户。 第三种是用于访问高价值应用程序和资源，特别是用于企业对企业用例，在这些用例中，访问权限被授予为其他公司工作的人员。
帐户加入
可验证凭据可用于通过替换一些人工交互来加快载入速度。 VC 可用于加入员工、学生、公民或其他人员以访问服务。 例如，他们可以使用 VC 来验证其身份以激活远程交付给员工的徽章，而不是需要转到中央办公室来激活员工徽章。 相较于公民收到必须兑换以获取政府服务的代码，他们可以使用可验证凭证（VC）来证明身份并获取政府服务的访问权限。
其他元素
载入门户：一个 Web 前端，用于协调 VC 演示和验证的请求服务 API 调用，以及载入帐户的逻辑。
自定义逻辑/工作流：更新用户帐户前后具有组织特定步骤的特定逻辑。 示例可能包括审批工作流、其他验证、日志记录、通知等。
目标身份识别系统：在加入使用者时，加入门户需要与之交互的特定于组织的身份识别存储库。 要集成的系统是根据要加入 VC 验证的身份类型来确定的。 入职的身份验证常见方案包括：
Microsoft Entra ID 加入的外部标识，使用 API 颁发企业到企业 (B2B) 邀请，或向包颁发权利管理分配。
员工标识，在集中式身份识别系统中已通过人力资源 (HR) 系统加入。 在这种情况下，标识验证可能会作为 HR 工作流现有阶段的一部分进行集成。
设计注意事项
颁发者：作为 VC 颁发者，帐户加入非常适合外部身份证明服务。 检查加入的示例包括：运行情况检查、政府颁发的文档验证、地址或电话号码确认等。
存储 VC 属性：在可能的情况下，不要将 VCS 的属性存储在特定于应用的应用商店中。 特别小心个人数据。 如果应用程序内的特定流需要此信息，请考虑请求 VC 以按需检索声明。
与后端系统相关的 VC 属性：在与颁发者定义 VC 的属性时，建立一种机制，在用户呈现 VC 后关联后端系统中的信息。 该机制通常会在 RP 的上下文中结合收到的声明使用时间限定的唯一标识符。 一些示例：
新员工：当 HR 工作流到达需要身份验证的阶段时，RP 可以生成一个包含限时唯一标识符的链接。 然后，RP 将其发送到人力资源系统上的候选电子邮件地址。 此唯一标识符应足以将 VC 验证请求中的 firstName、lastName 等信息关联到 HR 记录或基础数据。 VC 中的属性可用于完成 HR 系统中的用户属性，或验证有关员工的用户属性的准确性。
外部标识 - 邀请：当外部用户被邀请到目标系统时，RP 可以生成一个包含表示邀请事务的唯一标识符的链接。 此链接可以发送到外部用户的电子邮件地址。 此唯一标识符应足以将 VC 验证请求关联到邀请记录或基础数据，并继续预配工作流。 VC 中的属性可用于验证或完成外部用户属性。
外部标识 - 自助服务：当外部标识通过自助服务（例如 B2C 应用程序）注册目标系统时，VC 中的属性可用于填充用户帐户的初始属性。 VC 属性还可用于查明是否已存在配置文件。
与目标标识系统的交互：Web 前端与目标标识系统之间的服务间通信需要作为高度特权系统进行保护，因为它具有创建帐户的权限。 向 Web 前端授予可能的最低特权角色。 一些示例包括：
若要在 Microsoft Entra ID 中创建新用户，RP 网站可以使用获得 MS Graph 作用域
User.ReadWrite.All的服务主体来创建用户，并使用作用域UserAuthenticationMethod.ReadWrite.All来重置其身份验证方法。若要使用 B2B 协作将用户邀请到 Microsoft Entra ID，RP 网站可以使用授予 MS Graph 范围
User.Invite.All的服务主体来创建邀请。如果你的 RP 在 Azure 中运行，请使用托管身份调用 Microsoft Graph。 使用托管标识可消除在代码或配置文件中管理服务主体凭据的风险。 若要了解托管标识的详细信息，请参阅 Azure 资源的托管标识。
访问组织内部的高价值应用程序
可验证凭据可用作访问组织内敏感应用程序的其他证明。 例如，VCS 还可用于根据实现特定条件（例如认证）向员工提供对业务线应用程序的访问权限。
其他元素
信赖方 Web 前端是基于业务需求通过请求服务 API 调用 VC 演示和验证来增强的应用程序的 Web 前端。
用户访问授权逻辑 是应用程序授权用户访问的逻辑层。 它得到了增强，以使用 VC 中的用户属性做出授权决策。
其他后端服务和依赖项：表示应用程序的其余部分逻辑，通过 VC 包含身份证明通常不会使其发生改变。
设计注意事项
目标：场景的目标决定了需要哪种凭据和颁发者。 典型方案包括：
授权：在此场景中，用户提供 VC 以做出授权决策。 旨在证明完成训练或持有特定认证的 VC 非常适合此场景。 VC 属性应包含有利于授权决策和审核的精细信息。 例如，VC 用于认证个人经过训练，并可以访问敏感的财务应用。 应用逻辑可以检查部门声明的精细化授权，并使用员工 ID 进行审核。
确认身份验证：在此方案中，目标是确认最初加入的同一个人确实是尝试访问高价值应用程序的人。 来自身份验证提供者的凭证将是一个很好的选择。 应用程序逻辑应验证 VC 中的属性是否与登录应用程序的用户保持一致。
检查吊销：使用 VC 访问敏感资源时，通常会与原始颁发者一起检查 VC 的状态，并对已吊销的 VC 拒绝访问。 与颁发者合作时，请确保在场景设计过程中对吊销进行明确讨论。
用户体验：使用 VC 访问敏感资源时，可以考虑两种模式。
逐步身份验证：用户使用现有身份验证机制启动与应用程序的会话。 用户必须在应用程序中为特定的高价值操作（例如业务工作流的审批）提供 VC。 这正好适用于在应用程序流中能轻易识别和更新此类高价值操作的各种场景。
会话建立：用户在启动与应用程序的会话过程中必须提供 VC。 当整个应用程序具有高价值时，采用 VC 是一个很好的选择。
访问组织边界外部的应用程序
还可以由希望根据不同组织的成员身份或就业关系授予访问权限或权益的信赖方使用可验证凭据。 例如，电子商务门户可以为特定公司的员工、给定机构的学生等提供折扣等权益。
可验证凭据的分散性质使此方案无需建立联合关系。
其他元素
信赖方 Web 前端：这是应用程序的 Web 前端，可以根据业务要求，通过请求服务 API 调用来进行 VC 呈现和验证，从而增强它。
用户访问授权逻辑：应用程序中的逻辑层负责授权用户访问。通过增强功能，该逻辑层能够使用 VC 中的用户属性进行授权决策。
其他后端服务和依赖项：表示应用程序的其余逻辑，该逻辑通常因通过可验证凭证（VC）实现身份验证而保持不变。
设计注意事项
目标：场景的目标决定了需要哪种凭据和颁发者。 典型方案包括：
身份验证：在此方案中，用户必须拥有 VC 才能证明与特定组织的雇佣关系或其他关系。 在这种情况下，RP 应配置为接受目标组织颁发的 VC。
授权：根据应用程序要求，应用程序可能会使用 VC 属性进行精细的授权决策和审核。 例如，如果电子商务网站向特定位置的组织的员工提供折扣，则可以根据 VC 中的国家/地区声明（如果存在）来验证折扣资格。
检查吊销：使用 VC 访问敏感资源时，通常会与原始颁发者一起检查 VC 的状态，并对已吊销的 VC 拒绝访问。 与颁发者合作时，请确保在场景设计过程中对吊销进行明确讨论。
用户体验：用户可以将 VC 呈现为启动与应用程序的会话的一部分。 通常，应用程序还提供一种替代方法来启动会话，以适应用户没有 VC 的情况。
帐户恢复
可验证凭据可用作帐户恢复的方法。 例如，当用户需要恢复其帐户时，他们可能会访问网站，其要求他们提供 VC，并调用 MS Graph API 来启动 Microsoft Entra 凭据重置，如下图所示。
注意
虽然本部分中介绍的方案特定于恢复 Microsoft Entra 帐户，但此方法还可用于恢复其他系统中的帐户。
其他元素
帐户门户：用于协调 VC 演示和验证 API 调用的 Web 前端。 此编排可以包括 Microsoft Graph 调用，以恢复 Microsoft Entra 中的帐户。
自定义逻辑或工作流：更新用户帐户之前和之后具有组织特定步骤的逻辑。 自定义逻辑可能包括审批工作流、其他验证、日志记录、通知等。
Microsoft Graph：公开表示性状态传输（REST）API 和客户端库，以访问用于执行帐户恢复的Microsoft Entra 数据。
Microsoft Entra 企业目录：包含通过帐户门户创建或更新的帐户的 Microsoft Entra 租户。
设计注意事项
VC 属性与 Microsoft Entra ID 的关联：在与颁发者协作定义 VC 的属性时，请确保就标识用户的声明达成一致。 例如，如果身份验证提供商 (IDV) 在员工入职前验证身份，请确保颁发的 VC 包含可以与内部系统匹配的声明。 此类声明可能是电话号码、地址或出生日期。 RP 可以在此过程中请求 VC 中找不到的信息，例如其社会保障号码（SSN）的最后四位数字。
具有现有 Microsoft Entra 凭据重置功能的 VC 角色：Microsoft Entra ID 具有内置的自助式密码重置 (SSPR) 功能。 在用户无权访问或失去对 SSPR 方法的控制的情况下，可以使用可验证凭据来提供另一种方法进行恢复。 如果用户丢失了计算机和移动设备，用户可以从标识证明颁发者重新获取 VC，并显示它以远程恢复其帐户。
同样，可以使用 VC 生成临时访问通行证，允许用户在没有密码的情况下重置其多重身份验证方法。
授权：创建授权机制（例如，在继续凭据恢复之前 RP 检查的安全组）。 例如，只有特定组中的用户才有资格使用 VC 恢复帐户。
与 Microsoft Entra ID 进行交互：Web 前端与 Microsoft Entra ID 之间的服务到服务通信必须作为高特权系统进行保护，因为它可以重置员工的凭据。 向 Web 前端授予可能的最低特权角色。 一些示例包括：
向 RP 网站授权，使其能够使用授予了 MS Graph 范围
UserAuthenticationMethod.ReadWrite.All的服务主体来重置身份验证方法。 不要授予User.ReadWrite.All，这允许创建和删除用户。如果 RP 在 Azure 中运行，请使用托管标识调用 Microsoft Graph。 托管标识消除了在代码或配置文件中管理服务主体凭据相关的风险。 有关详细信息，请参阅 Azure 资源的托管标识。
身份管理规划
以下是将 VC 合并到信赖方时需要考虑的一些 IAM 注意事项。 信赖方通常是应用程序。
认证
VC 的使用者必须是人类。
一个人钱包里有 VC，且必须以交互方式出示该 VC。 不支持代理等非交互式流。
授权
成功呈现 VC 本身就可被视为粗粒度授权入口。 VC 属性还可用于做出细粒度的授权决策。
确定过期的 VC 在应用程序中是否有意义;如果是，请在授权检查过程中检查 VC
exp声明（到期时间）的值。 一个过期不相关的例子是：请求政府颁发的文件（如驾照）来验证主体的年龄是否超过 18 岁。 即使 VC 已过期，出生日期声明也有效。确定已吊销的 VC 对授权决策是否有用。
如果它不相关，请跳过调用检查状态的 API（默认启用）。
如果相关，请在应用程序中添加适当的异常处理。
用户资料
可以使用已提供的 VC 中的信息来生成用户配置文件。 如果要使用属性生成配置文件，请考虑以下事项。
颁发 VC 时，它包含颁发时的属性快照。 VC 的有效期可能很长，你必须确定自己将接受的属性具有足够长的有效期，可以用作配置文件的一部分。
如果每次使用者启动与 RP 的会话时都需要提供 VC，请考虑使用 VC 呈现的输出来生成具有各种属性的非持久性用户配置文件。 非持久性用户配置文件有助于降低与存储静态用户属性相关的隐私风险。 应用程序可能需要在本地保存主题的属性。 如果是这样，则仅保存应用程序所需的声明。 不要保存整个 VC。
如果应用程序需要持久性用户配置文件存储：
请考虑使用
sub声明作为用户的不可变标识符。 这是一个不透明的唯一属性，对于给定的主体/RP 对，它是常数。定义从应用程序撤销用户配置文件的机制。 由于Microsoft Entra 验证 ID 系统的分散性质，因此没有应用程序用户预配生命周期。
不要存储 VC 令牌中返回的与个人数据相关的声明。
仅存储信赖方逻辑所需的声明。
规划性能
与任何解决方案一样，必须规划性能。 重点领域包括延迟、吞吐量和可伸缩性。 在发布周期的初始阶段，性能不应成为问题。 但是，如果采用解决方案会导致验证许多可验证凭据，则性能规划可能会成为解决方案的关键部分。
以下项目提供了在规划性能时要考虑的领域：
Microsoft Entra 验证 ID 颁发服务部署在西欧、北欧、美国西部 2 和美国中西部 Azure 区域。 若要限制延迟，请在最近的区域中部署验证前端（网站）和密钥保管库。
基于吞吐量的模型：
VC 验证容量受 Azure Key Vault 服务限制的限制。
每次验证 VC 都需要一个 Key Vault 签名操作。
无法控制限流；但是，我们建议阅读 Azure Key Vault 限流指南，以便了解限流可能如何影响性能。
为可靠性进行规划
为了最好地规划高可用性和灾难恢复，建议以下各项：
Microsoft Entra 验证 ID 服务部署在西欧、北欧、美国西部 2、美国中西部、澳大利亚和日本 Azure 区域。 请考虑在其中一个地区部署支持的 Web 服务器和应用程序，特别是在您预期大部分验证流量将来源的地区。
在设计可用性和冗余目标时，请查看并整合 Azure Key Vault 可用性和冗余中的最佳做法。
规划安全性
在设计安全性时，请考虑以下事项：
单个租户中的所有信赖方 (RP) 都具有相同的信任边界，因为它们共享相同的 DID。
为访问 Key Vault 的网站定义专用服务主体。
只有Microsoft Entra 验证 ID 服务和网站服务主体才有权使用 Key Vault 使用私钥对消息进行签名。
不要向 Key Vault 分配任何人工标识管理权限。 有关 Key Vault 最佳做法的详细信息，请参阅 Key Vault的 Azure 安全基线。
查看使用 Microsoft Entra ID 保护 Azure 环境，了解管理解决方案受支持的服务的最佳做法。
通过以下方式缓解欺骗风险：
实施 DNS 验证以帮助客户识别颁发者品牌。
使用对最终用户有意义的域。
缓解分布式拒绝服务（DDOS）和 Key Vault 资源限制风险。 每个 VC 演示请求都会生成 Key Vault 签名操作，并会累积计入服务限制。 建议在生成颁发请求之前，通过使用替代身份验证或验证码 (captcha) 来保护流量。
运作计划
在规划操作时，建议在审核过程中计划捕获每次凭据验证尝试。 使用该信息进行审核和故障排除。 此外，请考虑生成客户和支持工程师可根据需要引用的唯一事务标识符（ID）。
作为运营规划的一部分，请考虑监视以下各项：
可伸缩性：
作为端到端安全指标的一部分，监视 VC 验证失败情况。
监视凭据验证的端到端延迟。
可靠性和依赖项：
监视验证解决方案使用的基础依赖项。
出于安全：
启用 Key Vault 日志记录以跟踪签名操作，并监视和警报配置更改。 有关详细信息，请参阅 如何启用 Key Vault 日志记录。
将日志存档在安全信息和事件管理（SIEM）系统中，例如 Microsoft Sentinel，以便于长期保存。
后续步骤
详细了解如何构建 VC 解决方案
实现可验证凭据