网站的flash,陕西煤化建设集团铜川分公司网站,wordpress 访客 用户,百度网盘网页img写在前面因为最近在忙别的#xff0c;好久没水文了 今天来水一篇#xff1b;在学习或者做权限系统技术选型的过程中#xff0c;经常有朋友有这样的疑问 #xff1a;“IdentityServer4的能不能做到与传统基于角色的权限系统集成呢#xff1f;”“我的公司有几百个接口好久没水文了 今天来水一篇在学习或者做权限系统技术选型的过程中经常有朋友有这样的疑问 “IdentityServer4的能不能做到与传统基于角色的权限系统集成呢”“我的公司有几百个接口IdentityServer4能不能做到关联用户给这些用户授予不同的接口的权限呢”我的回答是是的可以同时我还想补充下IdentityServer4是给我们的授权流程/需求提供一个新的 标准化的选择而不是限制你的需求它是一个基础的框架你可以根据你的需求自定义成任意你要的样子。OK下面开始说说我的实现思路不一定最优只为抛砖引玉。开始之前先准备好两个WebApi 项目分别有两个接口Hei.UserApi6001GetUsername: https://localhost:6001/api/profile/getusernameGetScorehttps://localhost:6001/api/Credit/GetScore //用户信用分要求高期望管理员才可以调用Hei.OrderApi6002GetOrderNohttps://localhost:6002/api/Order/GetOrderNoGetAddresshttps://localhost:6002/api/Delivery/GetAddress //用户地址敏感期望管理员才可以调用实现请看源码准备好两个角色R01 管理员R02 普通用户准备好两个用户Bob: subid1001,普通用户Alice: subid1002,管理员实际用户有多个角色的本文为了简化问题一个用户只允许一种角色角色对应的权限管理员可以调用 Hei.UserApi和Hei.OrderApi的所有接口普通用户只可以调用 Hei.UserApi-GetUsername和Hei.OrderApi-GetOrderNo实现思路先来看晓晨大佬画的 access_token 验证交互过程图imgimage-20220223112832900可以看到Token在首次被服务端验证后后续的验证都在客户端验证的本文的重点就在这里需要判断token有没有权限重写这部分即可开始实现服务端1、生成自定义token1、 IdentityServer4 服务端重写IResourceOwnerPasswordValidator 和 IProfileService 两个接口生成携带有自定义信息的access_tokenpublic class CustomResourceOwnerPasswordValidator : IResourceOwnerPasswordValidator
{public CustomResourceOwnerPasswordValidator(){}public Task ValidateAsync(ResourceOwnerPasswordValidationContext context){if (!string.IsNullOrEmpty(context.UserName) !string.IsNullOrEmpty(context.Password)){var loginUser UserService.Users.First(c c.Username context.UserName c.Password context.Password);if (loginUser ! null){context.Result new GrantValidationResult(loginUser.SubjectId, OidcConstants.AuthenticationMethods.Password, new Claim[]{new Claim(my_phone,10086)}); //这里增加自定义信息return Task.CompletedTask;}}return Task.CompletedTask;}
}StartUp.cs 启用builder.AddResourceOwnerValidatorCustomResourceOwnerPasswordValidator();
builder.AddProfileServiceCustomProfileService();2、请求一个token来看看image-20220223115450490image-20220223115310375可以看到我这里token携带有了自定义信息 my_phone同样的你可以把角色id直接放这里或者直接跟用户的subid关联本demo就是客户端1、自定义授权标签CustomRBACAuthorizepublic class CustomRBACAuthorizeAttribute : AuthorizeAttribute{public CustomRBACAuthorizeAttribute(string policyName){this.PolicyName policyName;}public string PolicyName{get{return PolicyName;}set{Policy ${Const.PolicyCombineIdentityServer4ExternalRBAC}{value.ToString()};}}}后面接口打这个标签就表示使用基于自定义的与权限校验2、自定义授权 IAuthorizationRequirementpublic class CustomRBACRequirement: IAuthorizationRequirement{public string PolicyName { get; }public CustomRBACRequirement(string policyName){this.PolicyName policyName;}}3、自定义IAuthorizationPolicyProviderpublic class CustomRBACPolicyProvider : IAuthorizationPolicyProvider{private readonly IConfiguration _configuration;public DefaultAuthorizationPolicyProvider FallbackPolicyProvider { get; }public CustomRBACPolicyProvider(IConfiguration configuration, IOptionsAuthorizationOptions options){_configuration configuration;FallbackPolicyProvider new DefaultAuthorizationPolicyProvider(options);}public TaskAuthorizationPolicy GetDefaultPolicyAsync(){return FallbackPolicyProvider.GetDefaultPolicyAsync();}public TaskAuthorizationPolicy GetFallbackPolicyAsync(){return Task.FromResultAuthorizationPolicy(null);}public TaskAuthorizationPolicy GetPolicyAsync(string policyName){if (policyName.StartsWith(Const.PolicyCombineIdentityServer4ExternalRBAC, StringComparison.OrdinalIgnoreCase)){var policys new AuthorizationPolicyBuilder();//这里使用自定义Requirementpolicys.AddRequirements(new CustomRBACRequirement(policyName.Replace(Const.PolicyCombineIdentityServer4ExternalRBAC,)));return Task.FromResult(policys.Build());}return Task.FromResultAuthorizationPolicy(null);}}4、自定义Requirement的的 AuthorizationHandler/// summary
/// 处理CustomRBACRequirement的逻辑
/// /summary
/// param namecontext/param
/// param namerequirement/param
/// returns/returns
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, CustomRBACRequirement requirement)
{var subid context.User?.FindFirst(ClaimTypes.NameIdentifier)?.Value;var routeData _httpContextAccessor.HttpContext?.GetRouteData();var curentAction routeData?.Values[action]?.ToString();var curentController routeData?.Values[controller]?.ToString();//入口程序集用来标识某个apivar apiName Assembly.GetEntryAssembly().GetName().Name;if (string.IsNullOrWhiteSpace(subid) false string.IsNullOrWhiteSpace(curentAction) false string.IsNullOrWhiteSpace(curentController) false){//核心就在这里了查出用户subid对应的角色权限然后做处理判断有没有当前接口的权限//我这里是demo就简单的模拟下真实的权限数据应该都是写数据库或接口的var userPermission PermissionService.GetUserPermissionBySubid(apiName, subid);if (userPermission ! null userPermission.Authorised.ContainsKey(curentController)){ var authActions userPermission.Authorised[curentController];//这里判断当前用户的角色有当前action/controllers的权限//(真实的权限划分由你自己定义比如你划分了只读接口只写接口、特殊权限接口、内部接口等在管理后台上分组打标签/标记然后授予角色就行)if (authActions?.Any(action action curentAction) true){context.Succeed(requirement);}}}return Task.CompletedTask;
}jwt 的token本来是去中心化的现在这样一来每次请求进来都去调接口验证可以说是违背了去中心化的思想所以保证性能问题得自己解决权限数据public class PermissionService
{/// summary/// 权限信息实际上这些应该存在数据库/// /summarypublic static ListPermissionEntity Permissions new ListPermissionEntity{//RoleId R01 是管理员,有两个Api的多个接口的权限new PermissionEntity{ PermissionId0001,RoleIdR01, ApiNameHei.UserApi,Authorisednew Dictionarystring, Liststring{{ Profile,new Liststring{ GetUsername}},{ Credit,new Liststring{ GetScore}},}},new PermissionEntity{ PermissionId0002,RoleIdR01, ApiNameHei.OrderApi,Authorisednew Dictionarystring, Liststring{{ Delivery,new Liststring{ GetAddress}},{ Order,new Liststring{ GetOrderNo}},}},//RoleId R02 是普通员工,有两个Api的多个 部分 接口的权限new PermissionEntity{ PermissionId0001,RoleIdR02, ApiNameHei.UserApi,Authorisednew Dictionarystring, Liststring{{ Profile,new Liststring{ GetUsername}},//{ Credit,new Liststring{ GetScore}}, //用户信用分接口权限就不给普通员工了}},new PermissionEntity{ PermissionId0002,RoleIdR02, ApiNameHei.OrderApi,Authorisednew Dictionarystring, Liststring{//{ Delivery,new Liststring{ GetAddress}}, //用户地址信息也是{ Order,new Liststring{ GetOrderNo}},}}};当然这些数据一般都是根据你的权限需求存数据库的与你的权限管理后台相配合5、注册自定义授权处理程序/// summary/// 提交自定义角色的授权策略/// /summary/// param nameservices/param/// returns/returnspublic static IServiceCollection AddCustomRBACAuthorizationPolicy(this IServiceCollection services){services.AddSingletonIHttpContextAccessor, HttpContextAccessor();services.AddSingletonIAuthorizationPolicyProvider, CustomRBACPolicyProvider();services.AddSingletonIAuthorizationHandler, CustomRBACRequirementHandler();return services;}6、在接口上使用自定义授权标签CustomRBACAuthorize[Route(api/[controller]/[action])][ApiController]public class CreditController : ControllerBase{/// summary/// 获取信用分/// /summary/// param nameid/param/// returns/returns[HttpGet][CustomRBACAuthorize] //这里就表名public int GetScore(string id){return 666;}}7、测试结果管理员1001 角色id R01 Aliceimage-20220223151041196请求image-20220223152252049可以看到都是 200普通用户1002 角色id R02 Bobimage-20220223151144846请求image-20220223152233656可以看到获取用户信用积分、订单投递地址的接口403了与我们全面的设定相符总结就是一个简单的思路1、给access_token 带上自定义信息2、在客户端重写本地验证/权限校验逻辑即可其实token黑白名单token撤销原理类似 希望能帮上一点小忙IdentityServer4就是一个工具希望大家不要给它设定太多的限制“不能做这个不能做那个等等”源码https://github.com/gebiWangshushu/cnblogs-demos/tree/dev/IdentityServerWithRBAC.Example如果能有个小星星那就再好不过了(✧◡✧)参考https://docs.microsoft.com/zh-cn/aspnet/core/security/authorization/iauthorizationpolicyprovider?viewaspnetcore-3.1#multiple-authorization-policy-providershttps://www.cnblogs.com/stulzq/p/9226059.html文章博客园地址请点击“阅读原文”不给我点个赞再走吗~
