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

Question

我正在使用Azure Active Directory,并尝试了解此处描述的三种类型的访问控制.每种方法的优点和缺点是什么？何时使用它们:

• 基于范围的访问控制使用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 进行基于组的访问控制 - 类似，但您正在检查用户是否属于特定组