我们当前正在将内部桌面应用程序移至具有统一Identity Server的一系列Web应用程序。因此,我们利用Identity Server管理所有用户帐户,并允许其联合访问我们的客户端和API。总的来说,这一切都很好。
但是,我发现在没有利用AspNetCore身份的情况下有人设法实现基于角色或基于策略的授权的例子并没有太多运气。使用IdentityServer管理用户时,我希望不必在身份服务器和各个Web应用程序之间复制用户,而我希望每个Web应用程序都管理自己的内部权限。
在不利用整个AspNetCore身份的情况下,如何实现基于策略的授权的示例?
答案 0 :(得分:1)
您的问题的答案是设置单独的身份验证服务器和单独的授权服务器。正如IdentityServer的一位创建者对here所做的评论:
IdentityServer既是OAuth 2.0又是OpenID Connect实现。 是的-我们建议使用IdentityServer进行最终用户身份验证, 联盟和API访问控制。
PolicyServer是我们建议的用户授权。
该文章本身值得阅读,这是指向PolicyServer网站的链接。
这个想法很简单,尽管可能有不同的方法。实施可能会花费一些时间,因为免费的开源版本使用本地资源,而您可能希望使用集中式版本。在这种情况下,您可以考虑先看看商业版本。
简而言之,它是如何工作的。首先,对用户进行身份验证。然后,授权中间件将声明添加到用户。然后,用户被授权。在code中,类似:
app.UseAuthentication();
// add this middleware to make roles and permissions available as claims
// this is mainly useful for using the classic [Authorize(Roles="foo")] and IsInRole functionality
// this is not needed if you use the client library directly or the new policy-based authorization framework in ASP.NET Core
app.UsePolicyServerClaims();
app.UseAuthorization();
这将保留身份验证流程和用户的“选择加入”授权。要提高性能,可以使用缓存。
sub
声明是关键。作为oidc流的一部分,这是唯一且保持不变的声明。
OSS示例适用于Mvc客户端,但是当您使用资源(api)对其进行扩展时,它将无法立即使用。因为访问令牌可能不包含所有声明。
这就是本质,这是最清楚哪些声明相关的资源。因此,应该是请求信息的资源。
实际上,这就是本地PolicyServer实现的功能,它为客户端和api提供了不同的策略json。您可以将其移动到数据库中,并使用客户端/作用域作为区分符,定义每个用户(子)的角色/权限。
api可以使用访问令牌从授权服务器请求信息。解决客户想要知道允许哪些功能的问题,例如对于构建菜单,您可以将授权服务器扩展到可以请求角色/权限列表的端点。