Question

第一个同时使用单点登录和Azure的项目，所以也许我只是做的不正确。在使用SSO之前，我将自己生成令牌。这使我可以将所需的任何内容放入令牌中，以用于确定权限。结合使用react-adal和Azure AD SSO，令牌是在客户端生成的，而我得到的只是用户身份。按照过去的操作，我编写了一个自定义属性，以确保用户具有相应的API调用权限。但是，我不仅要从每次请求传递的令牌中获取信息，还必须在每次请求时查询权限，这实际上使数据库命中率翻了一番。

我是否可以使用单点登录和应用程序驱动的权限来处理角色/权限（管理员，管理员，用户，只读等），而无需每次需要检查权限时都查询数据库？

上一个过程： User visits site > enters credentials > server authenticates, gets permissions, generates token with permissions, returns it to client > client passes token on every request > server validates and parses token > attribute checks parsed token to ensure user has necessary permission > completes request

当前进程：User visits site > client authenticates with Azure AD and gets token > client passes token on every request > server gets authentication information from token > server queries database to get users permissions > attribute checks query results to ensure user has necessary permission > completes request

如何改善当前流程？我发现的每个google结果都仅包含身份验证，还没有深入到实际应用程序中，因此我无法找到“最佳实践”甚至任何实践。我只是做错了吗？

Answer 1

请查看Azure AD中与应用程序角色相关的功能，以实现您的自定义RBAC。它应该为您提到的内容提供一个很好的起点，因为角色集合将作为Azure AD传入令牌的一部分提供给您。

应用程序角色

Microsoft文档-Application Roles

目的-这些角色在组织清单中为组织正在开发并已在Azure Active Directory中注册的应用程序定义。这些角色非常适合您的应用程序，可以在应用程序的代码中使用，以为经过身份验证的用户实现授权逻辑。

示例应用程序（使用此概念并执行您想要的操作）-

Authorization in a web app using Azure AD application roles & role claims

快速说明

1）向Azure AD注册应用程序后，可以通过在Azure AD中编辑应用程序清单（JSON）来定义自定义角色（特定于您的应用程序）。以下是应用程序角色定义的示例JSON示例：

"appRoles": 
[
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Creators can create Surveys",
    "displayName": "SurveyCreator",
    "id": "1b4f816e-5eaf-48b9-8613-7923830595ad",
    "isEnabled": true,
    "value": "SurveyCreator"
  },
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Administrators can manage the Surveys in their tenant",
    "displayName": "SurveyAdmin",
    "id": "c20e145e-5459-4a6c-a074-b942bbd4cfe1",
    "isEnabled": true,
    "value": "SurveyAdmin"
  }
]

2）您将能够通过Azure门户或以编程方式将这些角色分配给用户/组/应用程序。（您可以控制角色的允许成员类型）

3）现在，当最终用户登录到您的应用程序时，传入的Azure AD令牌将为您提供角色声明的集合（基于分配给用户的任何角色），您可以在应用程序中做出授权决定。

if (context.User.HasClaim(ClaimTypes.Role, "Admin")) { ... }

这是Microsoft Docs上的另一个相关文档-Role-based and resource-based authorization

我看到您在问题中也标记了asp.net-core。因此，如果您使用的是ASP.NET核心应用程序，则可以使用上面链接的Role-based authorization部分中所示的策略。

public class SurveyCreatorRequirement : AuthorizationHandler<SurveyCreatorRequirement>, IAuthorizationRequirement
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, SurveyCreatorRequirement requirement)
    {
        if (context.User.HasClaim(ClaimTypes.Role, Roles.SurveyAdmin) ||
            context.User.HasClaim(ClaimTypes.Role, Roles.SurveyCreator))
        {
            context.Succeed(requirement);
        }
        return Task.FromResult(0);
    }
}

在旁注中，我看到了人们选择根据用户所属的组执行某些授权逻辑的情况。这仅仅是信息，而不是您需要做的事情。我将在此答案中同时分享角色和组的一些详细信息，但绝对要先查看应用程序角色。您甚至可以将角色和组结合使用来制定授权策略。

组

组可以有多个用户或其他组作为成员。再次可以通过Azure门户或以编程方式管理组。

注意：组完全独立于您的应用程序，即，即使没有应用程序，Azure AD组也可以并且确实存在以将成员分组。另一方面，应用程序角色是特定于您的应用程序的，除了您的应用程序之外，它们对任何人都没有多大意义。

基于组做出决策的示例应用

Authorization in a web app using Azure AD groups & group claims

基于个人或特定资源的授权

还知道，当涉及到基于资源的单个授权（而不是基于角色的更为通用的授权）时，无论如何，您还是需要去数据库或其他持久性存储，因为那是唯一了解详细信息的地方权限与系统中各个对象之间的映射。

我已经在此处的相关SO帖子-Resource based Authorization with Azure AD

中对此进行了讨论

我应如何使用Azure AD SSO处理应用程序内权限？

1 个答案:

应用程序角色

组

基于个人或特定资源的授权