如何对资源(前端页面+后端接口)进行权限控制
在微服务架构中,请求的拦截在gateway中完成,而权限的查询是在uaa中完成,在gateway和uaa集成部署的情况下实现较为简单,如果两者分离实现起来就会比较麻烦,一种方案是在gateway的资源filter中内部调用uaa的权限查询模块,该方案是可行的,但是存在两个弊端:
响应延时:每个资源的请求都会附带一次uaa内部调用,加重uaa服务的负担并延长了响应时间。
过度依赖:gateway作为api网关,过度依赖了api提供方(uaa)的内部方法,导致系统耦合度提升。
因此应寻找一种低响应延时、松散依赖的解决方案:“token扩展”。
"token扩展"的思路为在token形成时追加用户资源权限(ar)属性,在资源的拦截中获取ar并与当前请求的资源比对,相当于将用户的资源权限缓存到了token中,uaa通过客户端浏览器将权限信息传递至gateway,gateway直接解析request获取AR,避免了内部调用导致的过度依赖问题和相应延时问题。此方案应注意在用户登录期间的AR变动需在下次登录后方能生效!!!
具体步骤如下:
uaa中扩展token属性(具体步骤参考最后部分),如在token中扩展ar属性,内部包含当前用户有权限访问的前端页面列表
{...,"ar":["a.html","b.html"]}
gateway中拦截鉴权
//解析ar Cookie accessTokenCookie = OAuth2CookieHelper.getAccessTokenCookie(request); Maptoken 属性扩展additionalInformation = tokenStore.readAccessToken(accessTokenCookie.getValue()) .getAdditionalInformation(); List ar = (List ) additionalInformation.get("ar"); //鉴权 for (String resourceUrl : ar) { if (resourceUrl == null) { continue; } if (resourceUrl.startsWith(requestUri)) { return false; } }
org.springframework.security.oauth2.provider.token.TokenEnhancer#enhance提供了扩展token属性的可能性,以下demo在token中增加ar属性,并使用@Component注入容器以生效。
@Component public class ArTokenEnhancer implements TokenEnhancer { @Override public OAuth2AccessToken enhance(OAuth2AccessToken accessToken, OAuth2Authentication authentication) { addClaims((DefaultOAuth2AccessToken) accessToken,authentication); return accessToken; } private void addClaims(DefaultOAuth2AccessToken token, OAuth2Authentication authentication) { MapadditionalInformation = token.getAdditionalInformation(); additionalInformation.put("ar", "something you like"); token.setAdditionalInformation(additionalInformation); } }
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/72705.html
摘要:口服务的负载均衡。服务的注册与发现接口管理服务注册是指向服务注册中心注册一个服务实例,服务提供者将自己的服务信息如服务名地址等告知服务注册中心。服务注册中心会提供服务的健康检查方案,检查被注册的服务是否可用。服务降级的功能。 微服务具有以下的特点。 口 按照业务来划分服务,单个服务代码量小,业务单一,易于维护。 口 每个微服务都有自己独立的基础组件,例如数据库、 缓存等,且运行在独立...
摘要:参与者流量来自于内部系统和外部流量,其中大部分来自于外部流量。水平扩容服务的水平扩容重要性不言而喻。 背景 目前微店中台团队为了满足公司大部分产品、运营以及部分后端开发人员的尝鲜和试错的需求,提供了一套基于图形化搭建的服务端接口交付方案,利用该方案及提供的系统可生成一副包含运行时环境定义可立即运行的工程代码,最后,通过 某种serverless平台 实现生成后代码的部署、CI、运行、反...
摘要:协议转换微服务架构允许使用不同的协议以便于获得使用不同技术的优势。过于庞大的在实现时,应当避免将非通用逻辑如领域特定数据转换放入其中。服务应始终对其数据域拥有完全的所有权。构建一个过于庞大的,从服务团队争夺控制权,这违反了微服务的理念。 我们团队的后端服务中,一开始只有一个大服务,所有的东西都往里面写,可以想象下,当这个服务变得不断的庞大,将会变得多么难以维护。后来逐渐把一些数据服务抽...
摘要:本文主要是从前端的角度,使用搭建一个简易的测试项目,在自己搭建的代理服务的下实现简单的微信分享。在微信测试工具中调试接口,点击发送即可会出现比较漂亮的分享链接。 一、背景简介: 目前流行的前后端分离项目,一般都处于不同的域名下,前后端开发过程中,是分别部署在不同服 务器上,在做接口联调时,会出现跨域的情况,部署上线时,基本不存在这种需要,因此搭建一个 前端代理服务,方便开发。 作为一个...
阅读 2906·2021-11-15 18:02
阅读 3800·2021-10-14 09:43
阅读 3732·2021-09-08 10:41
阅读 2522·2019-08-30 15:53
阅读 1803·2019-08-30 14:14
阅读 1943·2019-08-29 16:12
阅读 3138·2019-08-29 14:03
阅读 1280·2019-08-29 13:46