您好,登录后才能下订单哦!
小编给大家分享一下Ids4中分模块保护资源API怎么用,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!
书接上文,上回书咱们说到了IdentityServer4(下文统称Ids4)官方已经从v3更新升级到了v4版本,我的Blog.Idp项目也做了同步更新,主要是针对快速启动UI做的对应修改,毕竟Ids4类库nuget包更新就是一键的事儿
更新的内容涉及的比较多,主要是对一些属性的优化,亦或者是对ASP.NetCore更兼容等等,其中我个人认为最核心也最重要的一个更新,就是新增了ApiResourceScopes表,进一步细化了对资源服务器的限制颗粒度,总结来说:
之前我们是一个客户端只能针对一个资源服务器来操作,那该资源服务器下的所有api都会被保护,当然也都会被控制。所以是面向整个ApiResources的。
但是现在做了细化以后,一个资源服务器可以分隔出多个作用域Scope,那这样的话,我们就可以定义多个客户端,分模块的去访问同一个统一的资源服务器。
比如BlogVue项目,访问Blog相关的api;TibugNuxt项目,访问Tibug相关的api。
这里先不要着急的抬杠这么扩展的好处和优劣点,等到自己有需要,或者自己有这样的需求的时候就明白了,本文不做解释,只是一把梭的讲解如何配置三端,从而满足分模块保护资源API的目的。
本文我就用http://vueblog.neters.club项目举例,将Blog.Core资源服务器中定义一个Blog模块,来实现基于Scope的策略授权方案配置,主要是针对三端进行配置。
首先我们需要定义一个单独的资源服务器作用域,然后将这些作用域配置到资源上:
// v4更新
public static IEnumerable<ApiScope> GetApiScopes()
{
return new ApiScope[] {
new ApiScope("blog.core.api"),
new ApiScope("blog.core.api.BlogModule"),
};
}
public static IEnumerable<ApiResource> GetApiResources()
{
// blog.core 项目
return new List<ApiResource> {
new ApiResource("blog.core.api", "Blog.Core API") {
// include the following using claims in access token (in addition to subject id)
//requires using using IdentityModel;
UserClaims = { JwtClaimTypes.Name, JwtClaimTypes.Role,"rolename" },
// v4更新
Scopes={ "blog.core.api","blog.core.api.BlogModule"},
ApiSecrets = new List<Secret>()
{
new Secret("api_secret".Sha256())
},
}
};
}
这些基础代码肯定都能看的懂吧,只要你学会Ids4,肯定都明白,那对应到数据库里,就是这样的:
然后需要配置客户端Client,将我们需要的Scope赋给指定的客户端:
对应的数据库也是很简单:
这里给大家再啰嗦一句,要学好Ids4,数据库表结构一定要做到了然于胸,什么数据对应什么表,什么错误对应什么配置,要做到心中有数。
到这里认证中心就配置完了,接下来就是客户端了。
这个地方很简单,和之前几乎一模一样,只是在scope作用域上,改一下资源的域就行:
constructor () { super({ authority: 'https://ids.neters.club', client_id: 'blogvuejs', redirect_uri: 'http://localhost:6688/callback', response_type: 'id_token token', scope: 'openid profile roles blog.core.api.BlogModule', post_logout_redirect_uri: 'http://localhost:6688' }) }
就是代码中的 blog.core.api.BlogModule 这个Scope。
那就剩下最后一步了,配置资源服务器,既然使用到了作用域Scope,那就需要针对具体的作用域,配置具体的策略方案。
这里先说下,为了达到封装的效果呢,我把认证和授权分开写了,结构是这样的:
既然我们现在是增加了作用域Scope,那就是需要一个基于Scope的策略授权方案,在授权扩展类AuthorizationSetup.cs中,添加代码:
// 4、基于 Scope 策略授权
services.AddAuthorization(options =>
{
// 博客模块的策略
options.AddPolicy("Scope_BlogModule_Policy", builder =>
{
//客户端Scope中包含blog.core.api.BlogModule才能访问
builder.RequireScope("blog.core.api.BlogModule");
});
// 其他模块的策略
// ...
});
我们可以根据需要添加多个模块,每个模块会对应一个Scope,那每个Scope又对应一个客户端Client,这样就实现了项目基本的授权方案,认证相关的配置不用动。
然后只需要在指定的控制器或者Action上配置权限特性就行:
到这里基本就搞定了,调试后,可以发现新生成的Token令牌也发生了变化:
可能你会说,那我已经使用了复杂的基于数据库的策略授权,为啥还要搞这个呢?
我是这么想的,毕竟这个面向scope开发是可以在ids4可控的,细分到客户端的,这么配置好后,就不用配置复杂的数据库了,当然这一般都是针对前台的展示项目,后端Admin项目肯定需要很复杂的数据库配置更好。
以上是“Ids4中分模块保护资源API怎么用”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。