通过

应用程序开发人员的基于角色的访问控制

基于角色的访问控制（RBAC）允许某些用户或组具有访问和管理资源的特定权限。 应用程序 RBAC 不同于 Azure 基于角色的访问控制 和 Microsoft Entra 基于角色的访问控制。 Azure 自定义角色和内置角色都是 Azure RBAC 的一部分，用于帮助管理 Azure 资源。 Microsoft Entra RBAC 用于管理 Microsoft Entra 资源。 本文介绍了特定于应用程序的 RBAC。 有关实现特定于应用程序的 RBAC 的信息，请参阅 如何向应用程序添加应用角色并在令牌中接收它们。

角色定义

RBAC 是一种在应用程序中强制实施授权的常用机制。 当组织使用 RBAC 时，应用程序开发人员定义角色，而不是授权单个用户或组。 然后，管理员可以将角色分配给不同的用户和组，以控制谁有权访问内容和功能。

RBAC 可帮助应用程序开发人员管理资源及其使用情况。 RBAC 还允许应用程序开发人员控制用户可以访问的应用程序区域。 管理员可以使用 用户分配所需的 属性来控制哪些用户有权访问应用程序。 开发人员需要考虑应用程序中的特定用户以及用户可以在应用程序中执行的操作。

应用程序开发人员首先在Microsoft Entra 管理中心的应用程序注册部分内创建角色定义。 角色定义包含一个值，该值是为被分配到该角色的用户返回的。 然后，开发人员可以使用此值来实现应用程序逻辑，从而确定这些用户在应用程序中能做什么或不能做什么。

RBAC 选项

考虑在应用程序中包括基于角色的访问控制授权时，应应用以下指南：

  • 定义应用程序授权需求所需的角色。
  • 为经过身份验证的用户应用、存储和检索相关角色。
  • 根据分配给当前用户的角色确定应用程序行为。

定义角色后，Microsoft标识平台支持多个不同的解决方案，这些解决方案可用于为经过身份验证的用户应用、存储和检索角色信息。 这些解决方案包括应用角色、Microsoft Entra 组，以及使用自定义数据存储来处理用户角色信息。

开发人员可以灵活地提供自己的实现，规定如何将角色分配解释为应用程序权限。 这种权限解释可能涉及到使用中间件，或者应用程序平台或相关库提供的其他选项。 应用程序通常接收用户角色信息作为声明，然后根据这些声明决定用户权限。

应用角色

Microsoft Entra ID 允许 为应用程序定义应用角色 ，并将这些角色分配给用户和其他应用程序。 您为用户或应用程序分配的角色定义了他们对应用程序中资源和操作的访问权限级别。

Microsoft Entra ID 为经过身份验证的用户或应用程序颁发访问令牌时，它会在访问令牌的 roles 声明中包括已分配实体（用户或应用程序）的角色的名称。 例如 Web API 之类的应用程序在接收请求中的访问令牌后，可以根据 roles 声明中的值做出授权决策。

群组

开发人员还可以使用 Microsoft Entra 组 在其应用程序中实现 RBAC，其中特定组中用户的成员身份被解释为其角色成员身份。 当组织使用组时，令牌包含组声明。 组声明指定租户内用户的所有分配组的标识符。

重要

使用组时，开发人员需要了解超额声明的概念。 默认情况下，如果用户所属的组数超过超额限制（SAML 令牌的为 150 个，JWT 令牌的为 200 个，使用隐式流颁发的令牌的仅为 6 个），Microsoft Entra ID 将不会在令牌中发出组声明。 它会在令牌中添加“超额声明”，指示令牌使用者需要查询 Microsoft Graph API 以检索用户的组成员身份。 有关使用超额声明的详细信息，请参阅访问令牌中的声明。 可以仅发出分配给应用程序的组，但基于组的分配需要 Microsoft Entra ID P1 或 P2 版本。

自定义数据存储

应用角色和组都将有关用户分配的信息存储在 Microsoft Entra 目录中。 管理可供开发人员使用的用户角色信息的另一个选项是在自定义数据存储中维护目录外部的信息。 例如，在 SQL 数据库、Azure 表存储或 Azure Cosmos DB for Table 中。

使用自定义存储，开发人员可以额外自定义和控制如何向用户分配角色以及如何呈现这些角色。 但是，额外的灵活性也带来了更多的责任。 例如，目前没有机制可用于将此信息包含在从 Microsoft Entra ID 返回的令牌中。 如果角色信息保留在自定义数据存储中，应用程序必须检索角色。 检索角色通常是使用中间件中定义的扩展点完成的，这些扩展点可在被用于开发应用程序的平台中使用。 开发人员负责正确保护自定义数据存储。

选择方法

通常，应用角色是建议的解决方案。 应用角色提供最简单的编程模型，用于 RBAC 实现。 但是，特定的应用程序要求可能表明不同的方法是更好的解决方案。

开发人员可以使用应用角色来控制用户是否可以登录到应用程序，或者应用程序可以获取 Web API 的访问令牌。 当开发人员想要描述和控制应用程序中的授权参数时，应用角色优先于Microsoft Entra 组。 例如，使用组进行授权的应用程序将在下一个租户中中断，因为组标识符和名称可能不同。 使用应用角色的应用程序仍然安全。

尽管应用角色或组都可用于授权，但它们之间的主要差异可能会影响给定方案的最佳解决方案。

应用角色 Microsoft Entra 组 自定义数据存储
编程模型 最简单的。 它们特定于应用程序，在应用程序注册中定义。 它们随应用程序一起移动。 更复杂的。 租户之间的组标识符各不相同，可能需要考虑超额声明。 组不特定于应用程序，而是特定于 Microsoft Entra 租户。 最复杂。 开发人员必须实现存储并检索角色信息的方式。
在 Microsoft Entra 租户之间，角色值是静态的 是的 否 这取决于具体的实现方式。
可在多个应用程序中使用角色值 否（除非在每个应用程序注册中重复配置角色）。 是的 是的
存储在目录中的信息 是的 是的 否
信息通过令牌传递 是（角色声明） 是（对于超额情况，可能需要在运行时检索组声明） 否（通过自定义代码在运行时检索）。
生存期 存在于目录中的应用程序注册中。 删除应用程序注册时将被删除。 在目录中。 即使删除了应用程序注册，也保持不变。 存在于自定义数据存储中。 与应用程序注册不相关。

后续步骤