我为少数几个应用程序提供了IdentityServer作为身份验证部分。每个应用程序都有一个api和一个webgui。到目前为止，一切都很好。现在，我想通过Authorize [Role =“ Admin，…”]属性保护api。
在IdentityServer的声明中添加角色没有多大意义，因为每个应用程序都有不同的角色，并且可以根据应用程序将每个用户分配给不同的角色。我尝试实施效果良好的策略规则，但是使用此解决方案，我无法为授权创建“或”规则（用户应具有“管理员”或“管理”角色才能被授权执行此操作）。所以这也不是一个选择。我认为解决方案应该是创建一个将角色添加到当前用户的服务，但是我不知道该怎么做。
经过几个小时的搜索，我仍然找不到适合这种情况的东西，可以申请。
答案 0 :(得分：0)
签出https://leastprivilege.com/2016/12/16/identity-vs-permissions/
最佳实践是将角色分配给用户，然后将这些角色分配给IdentityServer中的“应用程序角色”。在您的应用程序中，您将检查“应用程序角色”的存在。
这使您可以将用户的属性与应用程序的业务逻辑分离。
答案 1 :(得分：0)
IdentityServer只需验证身份并返回带有声明的主体。就是这样。其他所有事情都由您的后备店处理。换句话说，如果您已与Identity集成，则可以使用与Identity相同的标准方式向用户添加角色。
但是，下一个问题是，索赔（哪些角色）与主体一起发送，重要的是，不更新。获取更新的声明的唯一方法是获取新的委托人，这通常涉及重新认证。在典型的Web应用程序场景中，您会使安全令牌无效，这将提示用户再次登录。从API角度来看，这还应具有以下效果：在请求受保护的端点时引起401响应，然后应导致客户端从auth端点检索新的访问令牌。
就授权用户是管理员角色还是管理角色而言，基于策略的授权完全可以处理该问题。我不确定您为什么认为不能。您可以从字面上创建类似AdminOrManagementRequirement的东西以及关联的处理程序。然后，您只需应用Authorize属性，如：
[Authorize(Policy = "AdminOrManagement")]
当然，可以使用您在Startup中注册策略的任何名称。