Compartir a través de

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

  • Artículo

基于角色的访问控制 (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 声明中的值做出授权决策。

Groups

开发人员还可使用 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 返回的令牌中。 如果角色信息保留在自定义数据存储中，则应用程序必须检索角色。 检索角色通常是使用中间件中定义的扩展点完成的，这些扩展点可在被用于开发应用程序的平台中使用。 开发人员负责妥善保护自定义数据存储。

通过使用 Azure AD B2C 自定义策略，可以与自定义数据存储进行交互，并在令牌中包括自定义声明。

选择方法

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

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

尽管应用角色或组可用于授权，但两者之间的主要差异可能会影响哪个解决方案是给定场景下最佳的解决方案。

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

后续步骤