范围/角色/基于组的访问控制

Question

我正在使用Azure Active Directory，并尝试了解所描述的三种类型的访问控制here。每种方法有哪些优点和缺点，何时使用它们：

• 使用我的清单中的oauth2Permissions部分进行基于范围的访问控制，我可以像这样添加读写权限：

  {
    "adminConsentDescription": "Allow the application read access to MyApi on behalf of the signed-in user.",
    "adminConsentDisplayName": "Read access to MyApi",
    "id": "56d944c0-f3aa-4f80-9472-9c1414383abf",
    "isEnabled": true,
    "type": "User",
    "userConsentDescription": "Allow the application read access to MyApi on your behalf.",
    "userConsentDisplayName": "Read access to MyApi",
    "value": "read_my_api"
  },
  {
    "adminConsentDescription": "Allow the application write access to MyApi on behalf of the signed-in user.",
    "adminConsentDisplayName": "Write access to MyApi",
    "id": "6d66a2bd-c8c7-4ee0-aef4-9424b51b4967",
    "isEnabled": true,
    "type": "User",
    "userConsentDescription": "Allow the application write access to MyApi on your behalf.",
    "userConsentDisplayName": "Write access to MyApi",
    "value": "write_my_api"
  }
  

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

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

Answer 1

我认为范围和角色/组之间最显着的区别是谁决定允许客户端做什么。

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

当外部应用程序想要通过公开的API访问用户的数据时，通常会使用范围。他们确定客户端应用程序可以做什么。

基于角色或组的访问通常在应用程序中用于确定用户可以执行的操作。

Answer 2

两个最受欢迎的一个：

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