微服务化开发实战+到微服务与容器
156.9元
(需用券)
去购买 >
一、简述
权限系统的设计一般分为:权限设计 = 功能权限 + 数据权限
本文主要对pigx平台在认证与授权方面的功能权限进行解析,而对于数据权限,一般是根据业务场景具体做特殊的设计,且必须在项目前期就做好规划,不像功能权限那样可以在后期完成,pigx对数据权限做了一定支持,具体请参考pigx数据权限设计
那么对于pigx的功能权限:
我们把请求按来源分为:外部请求和内部请求,其中外部请求分为登录请求和非登录请求
按目标资源分为:无注解、@Inner注解(仅内部请求)、@PreAuthorize注解(带权限控制)
下面是来源与资源的对应关系:
(请求类型与资源控制之间的关系)
对于请求而言,主要是外部与内部的区别,而外部请求必须经过网关(Gateway),网关对于请求的处理主要有登录与非登录的区别,因此上面表格中将外部请求细分为登录与非登录,这样对比资源的控制就更清晰、更细化
对于目标资源而言,主要有无注解、@Inner注解、@PreAuthorize注解三种:
无注解:一般用于对外公开资源,如商品浏览、官网等互联网接口。
对应的服务需要添加白名单配置:security.oauth2.client.ignore-urls后接口才可访问(或不引入依赖pigx-common-security、或采用@Inner(false)注解)
@Inner注解:一般用于被内部应用请求的接口,如日志、定时任务、文件存储等支持型服务,被注解后该接口将无法被外部请求访问到(需要网关提供保护,后面会讲到网关是如何保护内部应用请求的)
@PreAuthorize注解:用于外部请求非登录请求,该类请求须带token,因此是登录后对用户访问资源接口的权限控制,微服务依赖pigx-common-security以后就有认证(spring security oauth2)控制了,认证控制负责的是对token的鉴定,而对接口本身是否有权限访问是由pigx中的用户权限系统所控制,该注解就是在token鉴定成功以后,pigx用户权限系统再基于token内容进行的权限控制
下面通过以下部分对pigx平台认证与授权系统进行分析:
与网关相关的权限功能设计
与外部请求相关的权限功能设计
与内部请求相关的权限功能设计
二、与网关相关的权限功能设计
网关服务(Gateway)是所有服务的入口,起到了重要的作用,目前在pigx系统架构中主要有以下特殊作用的过滤器(Filter),他们都对权限系统的工作起到了一定的作用:
过滤器
作用
HttpBasicGatewayFilter
自定义basic认证,针对特殊场景使用
JiyupRequestGlobalFilter
清洗请求头中from 参数,用于防止外部模拟内部请求
PasswordDecoderFilter
对登录请求的密码参数进行解密处理
PreviewGatewayFilter
提供测试环境的支持
ValidateCodeGatewayFilter
对登录请求进行验证码检验
PigxRequestGlobalFilter分析:
内部服务请求通常不需要再通过auth服务进行一次鉴权,如A请求B时,如果B需要对A请求鉴权的话,A就需要拿到token,且B接送token后还需要请求auth服务鉴定token有效性,如果B在处理过程中还需要请求C,则C同样需要如此过程,不但复杂且给auth服务增添不少压力,一般的做法是网关请求A时,A进行一次鉴权,A到B,B到C的内部请求过程不需要再鉴权
为了实现B接口不鉴权,一般会将B所在服务中配置security.oauth2.client.ignore-urls,接口地址将不会鉴权
但单纯添加白名单是不行的,因为网关外部请求就可以直接获取到该接口资源
为了实现接口内部请求允许请求,外部请求不允许请求的目的,pigx引入了注解@Inner
该注解的接口请被切面PigxSecurityInnerAspect控制,控制逻辑很简单,只有请求头部带"from"标志时才允许访问:
@SneakyThrows
@Around("@annotation(inner)")
public Object around(ProceedingJoinPoint point, Inner inner) {
String header = re