规划 Microsoft Entra 验证 ID 验证解决方案
使用 Microsoft 的 Microsoft Entra 验证 ID (Microsoft Entra VC) 服务，无需扩展信任边界即可信任用户身份证明。 借助 Microsoft Entra VC，可以创建帐户或与另一个标识提供者联合。 解决方案使用可验证凭据进行验证交换时，应用程序能够请求未绑定到特定域的凭据。 此方法可以更轻松地大规模请求和验证凭据。
如果还没有 Microsoft Entra 验证 ID，建议查看 Microsoft Entra 验证 ID 体系结构概述。 还可以查看规划 Microsoft Entra 已验证 ID 颁发解决方案。
指南范围
此内容包含规划使用 Microsoft 产品和服务的可验证凭据验证解决方案的多个技术方面的内容。 该解决方案与信任系统相接，其中 DID Web 目前受支持。 DID Web 是集中式公钥基础结构。
本内容不包含非特定于验证解决方案的支持技术。 例如，在可验证凭据验证解决方案中使用了网站，但没有详细介绍网站部署规划。
在规划验证解决方案时，必须考虑要添加或修改的业务功能。 还必须考虑可重用的 IT 功能，以及必须添加哪些功能来创建解决方案。 另外，考虑业务流程中涉及的人员以及支持解决方案最终用户和员工的人员所需的培训。 本内容未涉及这些文章。 建议回顾一下 Microsoft Azure 架构良好的框架，获取涵盖这些文章的信息。
解决方案组件
作为验证解决方案计划的一部分，必须启用验证方、使用者和颁发者之间的交互。 在本文中，术语“信赖方”和“验证方”可互换使用。 下图显示了验证体系结构的组件。
Microsoft Entra 验证 ID 服务
在验证者解决方案上下文中，Microsoft Entra 验证 ID 服务充当解决方案的 Microsoft 组件与信任系统之间的接口。 该服务对密钥保管库密钥集进行预配，并对分散式标识符 (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 的单个密钥集。 每次处理验证请求时，都将使用此密钥集。 Microsoft 密钥集目前使用椭圆曲线加密 (ECC) SECP256k1。 我们将探索更广泛的 DID 社区所采用的其他加密签名架构。
请求服务 API
应用程序编程接口 (API) 为开发人员提供一种方法来抽象解决方案组件之间的交互，以执行验证操作。
信任系统
Microsoft Entra 已验证 ID 目前支持 DID Web 作为信任系统，其中 DID 文档托管在颁发者 Web 服务器上。
Microsoft Authenticator 应用程序
Microsoft Authenticator 是移动应用程序。 Authenticator 可协调用户、Microsoft Entra 已验证 ID 服务和用于颁发 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 属性：尽可能不要将 VC 中的属性存储在特定于应用的存储区中。 请特别注意个人数据。 如果应用程序内的特定流需要此信息，请考虑请求 VC 以按需检索声明。
与后端系统关联的 VC 属性：与颁发者一起定义 VC 的属性时，建立一种机制，以便在用户提供 VC 后，将后端系统中的信息关联起来。 该机制通常会在 RP 的上下文中结合收到的声明使用时间限定的唯一标识符。 下面是一些示例：
新员工：当 HR 工作流需要身份证明时，RP 可以生成具有时间限制的唯一标识符的链接。 然后，RP 将此链接发送到 HR 系统上应聘者的电子邮件地址。 此唯一标识符应足以将来自 VC 验证请求的信息（例如，名字、姓氏）与 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 资源的托管标识。
访问组织中的高价值应用程序
可验证凭据可以用作访问组织内部敏感应用程序的其他证明。 例如，VC 还可用于根据实现特定标准（如认证）为员工提供对业务线应用程序的访问权限。
其他元素
信赖方 Web 前端：这是应用程序的 Web 前端，可以根据业务要求，通过请求服务 API 调用来进行 VC 呈现和验证，从而增强它。
用户访问授权逻辑：应用程序中的逻辑层，它可用于授权用户进行访问，并经过增强以使用 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 帐户，但此方法还可用于恢复其他系统中的帐户。
其他元素
帐户门户：用于编排 API 调用以进行 VC 出示和验证的 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 生成临时访问密码，让用户能够在没有密码的情况下重置其 MFA 身份验证方法。
授权：创建授权机制（例如，在继续凭据恢复之前 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 颁发服务的 Azure 区域有欧洲西部、欧洲北部、美国西部 2 和美国中西部。 要限制延迟，请在最近的区域中部署验证前端（网站）和密钥保管库。
基于吞吐量的模型：
VC 验证容量受 Azure Key Vault 服务限制的限制。
每次验证 VC 都需要一个 Key Vault 签名操作。
你无法控制限制；但是，建议阅读 Azure Key Vault 限制指南，以便你了解限制对性能的影响。
规划可靠性
为针对高可用性和灾难恢复进行最佳规划，建议考虑以下事项：
部署了 Microsoft Entra 已验证 ID 服务的 Azure 区域有欧洲西部、欧洲北部、美国西部 2、美国中西部、澳大利亚、日本。 请考虑将受支持的 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 签名操作，这些操作会逐渐增加服务限制。 建议在生成颁发请求之前，先通过合并备用身份验证或验证码来保护流量。
规划操作
在规划操作时，建议在审核过程中计划捕获每次凭据验证尝试。 使用该信息进行审核和故障排除。 此外，请考虑生成客户和支持工程师可根据需要引用的唯一事务标识符 (ID)。
作为操作规划的一部分，请考虑对以下内容进行监视：
可伸缩性：
监视失败的 VC 验证，作为应用程序的端到端安全指标的一部分。
监视凭据验证的端到端延迟。
可靠性和依赖项：
监视验证解决方案使用的基础依赖项。
安全性：
启用密钥保管库日志记录来跟踪签名操作，以及监视配置更改并发出警报。 有关详细信息，请参阅如何启用 Key Vault 日志记录。
在安全信息与事件管理 (SIEM) 系统中存档日志，例如在 Microsoft Sentinel 中长期保留日志。
后续步骤
详细了解如何构建 VC 解决方案
实现可验证凭据