基于作用域/角色/组的访问控制

Question

我正在使用Azure Active Directory，并试图理解此处描述的三种类型的访问控制。每种方法的优点和缺点是什么？你什么时候会使用它们：

• 使用清单的oauth2Permissions部分进行基于范围的访问控制，我可以在其中添加读写权限，如下所示：

  {"adminConsentDescription"："允许应用程序代表登录用户读取MyApi。"，"adminConsentDisplayName"："读取MyApi的访问权限"，"id"："56d944c0-f3aa-4f80-9472-9c1414383abf"，"isEnabled"：true，"类型"："用户"，"userConsentDescription"："允许应用程序代表您读取MyApi。"，"userConsentDisplayName"："读取MyApi的访问权限"，"value"："read_my_api"}，{"adminConsentDescription"："允许应用程序代表登录用户对MyApi进行写访问。"，"adminConsentDisplayName"："写入对MyApi的访问权限"，"id"："6d66a2bd-c8c7-4ee0-aef4-9424b51b4967"，"isEnabled"：true，"类型"："用户"，"userConsentDescription"："允许应用程序代表您对MyApi进行写访问。"，"userConsentDisplayName"："写入对MyApi的访问权限"，"value"："write_my_api"}

• 基于角色的访问控制（RBAC）-使用清单的appRoles部分。

• 使用清单的groupMembershipClaims部分进行基于组的访问控制

Answer 1

我认为作用域和角色/组之间最显著的区别是谁决定客户端可以做什么。

• 资源范围由资源所有者（用户）通过同意屏幕授予应用程序。例如，客户端应用程序可以发布到我的时间线或查看我的朋友列表
• 用户角色和组由Azure AD目录的管理员分配。例如，用户可以提交费用报告，也可以审批费用报告

当外部应用程序希望通过公开的API访问用户的数据时，通常会使用作用域。它们决定客户端应用程序可以做什么

基于角色或组的访问通常在应用程序中使用，以确定用户可以做什么。

Answer 2

两个最流行的：

• 基于角色的访问控制-您正在为应用程序配置中的用户或组分配角色（在Azure门户内）。然后在代码中，您可以使用这些角色将用户授权到应用程序的某些部分。你可以做一些行：if (User.IsInRole("SuperAdmin")) {...}
• 使用groupMembershipClaims的基于组的访问控制-它类似，但您正在检查用户是否属于特定组