授权基础知识

  • 项目

授权（有时简写为 AuthZ）用于设置权限，这些权限用于评估对资源或功能的访问权限。 相比而言，身份验证（有时简写为 AuthN）侧重于证明某实体（如用户或服务）确实是其所称的身份。

授权可以包括指定实体能够访问的功能、资源或数据。 授权还指定可以对数据执行的操作。 此授权操作通常称为“访问控制”。

身份验证和授权这两个概念不局限于用户。 通常，构建服务或守护程序应用程序的目的是让其以自身身份而不是代表特定用户发出资源请求。 在本文中，术语“实体”用于指代用户或应用程序。

授权方法

可通过多种常见方法来处理授权。 基于角色的访问控制目前是使用 Microsoft 标识平台的最常见方法。

身份验证即授权

最简单的授权形式可能是根据是否已对发出请求的实体进行身份验证来授予或拒绝访问权限。 如果请求者可证明自己是所自称的身份，则可访问受保护的资源或功能。

访问控制列表

通过访问控制列表 (ACL) 进行的授权涉及到维护明确的特定实体列表，这些实体有权或无权访问资源或功能。 ACL 提供对身份验证即授权的精细控制，但管理工作会随着实体数量的增加而变得困难。

基于角色的访问控制

基于角色的访问控制 (RBAC) 可能是在应用程序中强制授权的最常见方法。 使用 RBAC 时，会对角色进行定义，以说明实体可执行的活动类型。 应用程序开发人员向角色而非单个实体授予访问权限。 然后，管理员可再将角色分配给不同的实体，从而控制哪些实体有权访问哪些资源和功能。

在高级 RBAC 实现中，可将角色映射到权限集合，其中权限描述了可执行的细化操作或活动。 然后，会将角色配置为权限组合。 通过将授予给为实体分配的各种角色的权限进行组合，计算实体的总体权限集。 此方法的一个很好的示例是用于管理对 Azure 订阅中资源的访问权限的 RBAC 实现。

注意

应用程序 RBAC 不同于 Azure RBAC 和 Microsoft Entra RBAC。 Azure 自定义角色和内置角色都是 Azure RBAC 的一部分，可帮助你管理 Azure 资源。 Microsoft Entra RBAC 允许管理 Microsoft Entra 资源。

基于属性的访问控制

基于属性的访问控制 (ABAC) 是一种更精细的访问控制机制。 在此方法中，规则应用于实体、所访问的资源和当前环境。 这些规则用于确定对资源和功能的访问级别。 例如，可能只允许拥有管理员身份的用户在工作日上午 9 点至下午 5 点期间访问使用元数据标记“仅限工作时间的管理员”标识的文件。 在这种情况下，通过检查用户的属性（状态为管理员）、资源属性（文件上的元数据标记）以及环境属性（当前时间）来确定访问权限。

ABAC 的一项优势是，可通过规则和条件评估实现更精细的动态访问控制，而无需创建大量特定的角色和 RBAC 分配。

通过 Microsoft Entra ID 实现 ABAC 的一种方法是使用动态组。 动态组可让管理员基于具有所需值的特定用户属性将用户动态分配到组。 例如，可以创建一个作者组，其中包含职务“作者”的所有用户都被动态分配到作者组。 可将动态组与 RBAC 结合用于授予，在此情况下，将角色映射到组，并将用户动态分配到组。

Azure ABAC 是目前可用的 ABAC 解决方案的一个示例。 Azure ABAC 构建在 Azure RBAC 之上，它在特定操作上下文中根据属性添加角色分配条件。

实现授权

授权逻辑通常是在需要访问控制的应用程序或解决方案中实现的。 在许多情况下，应用程序开发平台提供中间件或其他 API 解决方案，以简化授权的实现。 例如，在 ASP.NET 中使用AuthorizeAttribute 或在 Angular 中使用路由守卫。

如果授权方法依赖于经过身份验证的实体的相关信息，应用程序会评估在身份验证过程中交换的信息。 例如，使用安全令牌中提供的信息。 如果计划使用令牌中的信息进行授权，建议按照这份关于如何通过声明验证正确保护应用的指南进行操作。 对于安全令牌中未包含的信息，应用程序可能会对外部资源进行额外调用。

开发人员不必将授权逻辑完全嵌入其应用程序中。 而是，专用授权服务可用于集中实现和管理授权。

后续步骤