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

Question

我正在使用 Azure Active Directory，并试图了解描述的三种类型的访问控制 here 。每种方法的优点和缺点是什么以及何时使用它们:

• 使用 list 的 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) - 使用 list 的 appRoles 部分。

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

Answer 1

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

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

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

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