一般而言，企业内部一套成熟的权限系统，都是基于角色（Role）的 访问控制方法（RBAC – Role Based Access Control），即权限 （Permission）与角色相关联，用户（User）通过成为适当角色的成员而得到这 些角色的权限，权限包含资源（或者与操作组合方式相结合），最终实现权限控制 的目的。
背景
权限系统是根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源。
一般而言，企业内部一套成熟的权限系统，都是基于角色（Role）的访问控制方法（RBAC – Role Based Access Control），即权限（Permission）与角色相关联，用户（User）通过成为适当角色的成员而得到这些角色的权限，权限包含资源（或者与操作组合方式相结合），最终实现权限控制的目的。
一言以蔽之，基于角色的访问控制方法的访问逻辑表达式为“Who对What(Which)进行How的操作”，它的由内到外的逻辑结构为权限->角色->用户，即一个角色对应绑定多个权限，一个用户对应绑定多个角色，这也是秦苍基础架构部对于公共权限服务实现的基本指导思想。
权限服务与基础架构部其他公共服务的关系图
一.API权限定义、入库和拦截
对于API权限，我们实行基于注解（Annotation）的扫描入库和拦截，不需要业务服务自行在界面上录入
1、权限定义
API权限以每个接口或者实现类中的方法作为权限资源，每个权限和微服务名（Service Name）挂钩。
我们通过在业务服务的API上添加注解的方式，进行权限定义。基础架构部会提供一个权限组件（Permission Component）Jar给业务服务部门，里面包含了自定义的注解，这样的实现方式，对业务服务的影响非常小，增加权限机制只是在代码层面加几个注解而已。具体使用方式如下
对于一个普通的接口类，我们可以这样定义：
|
1 2 3 4 5 6 7 8 |
@Group(name = "User Permission Group", label = "用户权限组", description = "用户权限组") public interface UserService { @Permission(name = "Add User", label = "添加用户") boolean addUser(@UserId String userId, User user);
@Permission(name = "Delete User", label = "删除用户", description = "删除用户") boolean deleteUser(@UserId String userId, User user); } |
对于通过Swagger方式暴露出去的API，我们可以这样定义：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
@Path("/user") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) @Api(value = "User resource operations") @Group(name = "User Permission Group", label = "用户权限组", description = "用户权限组") public interface UserService { @GET @Path("/addUser/{userId}") @Permission(name = "Add User", label = "添加用户") boolean addUser(@PathParam("userId") @UserId String userId, User user);
@POST @Path("/deleteUser/{userId}") @Permission(name = "Delete User", label = "删除用户", description = "删除用户") boolean deleteUser(@PathParam("userId") @UserId String userId, User user); } |
在上述简短的代码中，我们可以发现有三个自定义的注解，@Group、@Permission和@UserId。
- @Permission，即为每个API（接口方法）定义一个权限，要求有name(英文格式),label(中文格式)和description(权限描述)
- @Group，即定义的权限归属哪个权限组，考虑到一个接口中包含很多个API，接口数目又比较多，那么我们可以为每个接口下的所有方法归为一个组。业务服务可自行定义权限组，也可以选择不定义，那么会归属到默认预定义的权限组中
- l@UserId，即业务服务需要在他们的API上加入用户ID的参数，当AOP切面拦截做权限验证时候，用户ID是需要传入的必要参数
2、权限入库和拦截
当API权限定义好以后，我们在权限组件里面加入扫描权限入库和拦截的算法。采用Spring AutoProxy自动代理的框架来实现我们的扫描算法。
2.1 创建PermissionInterceptor.java继承org.aopalliance.intercept.MethodInterceptor，步骤如下
- 实现Object invoke(MethodInvocation invocation)方法，获取注解值
- 根据不同注解进行不同的切面拦截，实现对@Group，@Permission和@UserId三个注解的权限拦截逻辑
2.2 创建PermissionAutoProxy.java继承Spring的org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator类，步骤如下
- 在构造方法里设置好Interceptor通用代理器（即实现了MethodInterceptor接口的拦截类PermissionInterceptor.java）
- shouldProxyTargetClass用来决定是接口代理，还是类代理。在权限定义的时候，其实我们还支持把注解加在实现类上，而不仅仅在接口上，这样灵活运用注解放置的方式-
- getAdvicesAndAdvisorsForBean是最核心的方法，用来决定哪个类、哪个方法上的注解要被扫描入库，也决定哪个类、哪个方法要被代理。如果我们做的更加通用一点，那么可以抽象出三个方法，供getAdvicesAndAdvisorsForBean调用
|
1 2 3 4 5 6 7 8 |
// 返回拦截类，拦截类必须实现MethodInterceptor接口，即PermissionInterceptor protected abstract Class<? extends MethodInterceptor> getInterceptorClass();
// 返回接口或者类的方法名上的注解，如果接口或者类中方法名上存在该注解，即认为该接口或者类需要被代理 protected abstract Class<? extends Annotation> getMethodAnnotationClass();
// 扫描到接口或者类的方法名上的注解后，所要做的处理 protected abstract void methodAnnotationScanned(Class<?> targetClass); |
2.3 创建PermissionScanListener.java实现Spring的org.springframework.context.ApplicationListener.ApplicationListener接口，步骤如下
- 在onApplicationEvent(ContextRefreshedEvent event)方法里实现入库代码
- 在微服务的Spring容器启动的时候，将自动触发权限数据入库的事件
通过上述阐述，我们就实现了权限的扫描入库和拦截
二、API权限所对应的角色（Role）管理
角色是一组API权限的汇总，每个角色也将和微服务名挂钩。角色组的作用是为了汇总和管理众多的角色
角色管理需要人工在界面上进行操作，角色管理分为角色组增删改查，以及每个角色组下的角色增删改查
三、 API权限所属的角色和用户（User）的绑定
权限不能直接和用户绑定，必须通过角色作为中间桥梁进行关联。那么我们要实现
- 角色与权限的绑定，即一个角色和多个权限的关联
- 用户与角色的绑定，即一个用户和多个角色的关联
角色和权限的绑定页面
用户和角色的绑定页面 </center
四、权限系统验证方式
1、API接入的验证方式
通过远程RPC方式的调用
1.1 扫描接入Permission组件的API Resource
|
1 2 3 4 5 6 7 |
@Configuration @ComponentScan(basePackages = { "com.omniprimeinc.service.myservice " }) @Import({ com.omniprimeinc.commonservice.permission.api.config.Config.class, com.omniprimeinc.commonservice.permission.annotations.config.Config.class }) public class Config {
} |
1.2 通过API Resource去调用RPC接口获取验证结果
|
1 2 3 4 5 6 7 8 9 |
@Path("/authorization") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) @Api(value = "Authorization resource operations") public interface AuthorizationResource { @GET @Path("/authorize/{userId}/{permissionName}/{serviceName}") Boolean authorize(@PathParam("userId") String userId, @PathParam("permissionName") String permissionName, @PathParam("serviceName") String serviceName); } |
2、Rest调用的验证方式
http://host:port/authorization/authorize/{userId}/{permissionName}/{serviceName}
通过User ID、Permission Name（权限名，映射于对应的方法名）、Service Name（应用名）来判断是否被授权，返回结果是true或者false
五、权限服务和用户服务的整合
用户服务即整合了Ldap系统的用户和桥接业务用户系统
权限服务接入用户服务后，可以在权限授权页面上选取相应的用户进行权限授权
六、权限服务的安全控制
未来规划，服务之间的调用增加如下机制
- 黑/白IP名单机制。当A服务调用B服务的时候，B服务会实现维护一个黑/白IP列表，表示B服务只允许在某个IP网段的A服务才能有权限调用B服务
- 服务间约定的SecretKey。当A服务调用B服务的时候，两个服务之间实现实现约定API访问密钥，此密钥不能轻易泄密。这样就规避了B服务被模拟Rest请求调用（例如通过PostMan调用）
- 服务的API签名。当A服务调用B服务的时候，A服务需要获得正确的B服务API的签名，才有权限去调用
http://blog.springcloud.cn/sc/mfw-jq/