2023年4月18日发(作者：幼儿园人事管理制度)微服务-API⽹关-权限控制
权限控制介绍
权限控制是⼀个古⽼的话题，你可能会想有没有什么权限设计⽅案可以满⾜所有的应⽤场景呢？
答案是没有，就像⼏乎所有问题⼀样，没有⼀种系统可以解决所有情况的，我们需要根据不同的场景和需求来设计不同的系统。
权限控制主要设计、、、、、等对象。下⾯我先对这些对象做些解释，让⼤家先有个概念。然后我们再说说业
⽤户⾓⾊组对象操作权限
界有哪些⽐较优秀的权限控制设计⽅案。
名词解释
⽤户
发起操作的估计英语
主体。
⾓⾊
对于⽤户的抽象概念，类似于⽤户的属性，⽐如就是⼀个⾓⾊。
管理员
组
可以是⽤户组，也可以是⾓⾊组，也可以是对象组。
对象
指操作所针对的客体对象，⽐如订单数据或图⽚⽂件。
操作
指作⽤于对象的动作，⽐如读取、写⼊。
权限
⼀般把对象和操作的对应关系和在⼀起究竟的近义词是什么
叫权限，⽐如读取⽂件的权限，读取就是操作，⽂件就是对象。中国航空母舰
权限控制设计⽅案
DAC
即，英⽂全称是。
⾃主访问控制Discretionary Access Control
系统会识别⽤户，然后根据被操作对象（Subject）的权限控制列表（ACL: Access Control List）或者权限控制矩阵（ACL: Access
Control Matrix）的信息来决定⽤户的是否能对其进⾏哪些操作，例如读取或修改。
⽽拥有对象权限的⽤户，⼜可以将该对象的权限分配给其他⽤户，所以称之为“⾃主（Discretionary）”控太极基本功
制。
这种设计最常见的应⽤就是⽂件系统的权限设计，如微软的NTFS。
DAC最⼤缺陷就是对权限控制⽐较分散，不便于管理，⽐如⽆法简单地将⼀组⽂件设置统⼀的权限开放给指定的⼀群⽤户。
MAC
即强制访问控制，英⽂全称是。
Mandatory Access Control
MAC是为了弥补DAC权限控制过于分散的问题⽽诞⽣的。在MAC的设计中，每⼀个对象都都有⼀些权限标识，每个⽤户同样也会有⼀些权
限标识，⽽⽤户能否对该对象进⾏操作取决于双⽅的权限标识的关系，这个限制判断通常是由系统硬性限制的。⽐如在影视作品中我们经常
能看到特⼯在查询机密⽂件时，屏幕提⽰需要“⽆法访问，需要⼀级安全许可”，这个例⼦中，⽂件上就有“⼀级安全许可”的权限标识，
⽽⽤户并不具有。
MAC⾮常适合机密机构或者其他等级观念强烈的⾏业，但对于类似商业服务系统，则因为不够灵活⽽不能适⽤。
ABAC
即基于属性的访问控制，英⽂全称是。
Attribute-Bad Access Control
ABAC被⼀些⼈称为是权限系统设计的未来。
不同于常见的将⽤户通过某种⽅式关联到权限的⽅式，ABAC则是通过动态计算⼀个或⼀组属性来是否满⾜某种条件来进⾏授权判断（可以
编写简单的逻辑）。属性通常来说分为四类：⽤户属性（如⽤户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如⼀
篇⽂章，⼜称资源属性），所以理论上能够实现⾮常灵活的权限控制，⼏乎能满⾜所有类型的需求。
例如规则：“允许所有班主任在上课时间⾃由进出校门”这条规则，其中，“班主任”是⽤户的⾓⾊属性，“上课时间”是环境属性，“进
出”是操作属性，⽽“校门”就是对象属性了。为了实现便捷的规则设置和规则判断执⾏，ABAC通常有配置⽂件（XML、YAML等）或
DSL配合规则解析引擎使⽤。
总结⼀下，ABAC有如下特点：
集中化管理
可以按需实现不同颗粒度的权限控制
不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中
定义权限时，不能直观看出⽤户和对象间的关系
规则如果稍微复杂⼀点，或者设计混乱，会给管理者维护和追查带来⿇烦
权限判断需要实时执⾏，规则过多会导致性能问题
既然ABAC这么好，那最流⾏的为什么还是RBAC呢？
我认为主要还是因为⼤部分系统对权限控制并没有过多的需求，⽽且ABAC的管理相对来说太复杂了。便因为ABAC太难⽤，
Kubernetes
在版本⾥引⼊了RBAC的⽅案。
1.8
RBAC
即基于⾓⾊的访问控制，英⽂全称是。
Role-Bad Access Control
因为DAC和MAC的诸多限制，于是诞⽣了RBAC，并且成为了迄今为⽌最为普及的权限设计模型。
RBAC在⽤户和权限之间引⼊了的概念。
⾓⾊
每个⽤户关联⼀个或多个⾓⾊，每个⾓⾊关联⼀个或多个权限，从⽽可以实现了⾮常灵活的权限管理。⾓⾊可以根据实际业务需求灵活创
建，这样就省去了每新增⼀个⽤户就要关联⼀遍所有权限的⿇烦。
由RBAC还可以做些扩展，⽐如下⾯两种⽅式。
⾓⾊继承
即Hierarchical Role，顾名思义，⾓⾊继承就是指⾓⾊可以继承于其他⾓⾊，在拥有其他⾓⾊权限的同时，⾃⼰还可以关联额外的权限。
这种设计可以给⾓⾊分组和分层，⼀定程度简化了权限管理⼯作。
职责分离
即Separation of Duty，为了避免⽤户拥有过多权限⽽产⽣利益冲突，例如⼀个篮球运动员同时拥有裁判的权限（看⼀眼就给你判犯规狠
不狠？），另⼀种职责分离扩展版的RBAC被提出。
RBAC模型
关系图
如图所⽰，每个⽤户关联⼀个或多个⾓⾊，每个⾓⾊关联⼀个或多个权限。权限是由⼀对对象和操作组成。
由此我们可以设计出主要的表结构关系。
表结构
⽤户⾓⾊表
uridroleid
1000120001
⾓⾊权限表
roleidpermissionid
2000150001
权限表
permissionidobjecteidoperationid
500013000140001
有了上⾯三张表，我们就有了完整的映射关系，还有些表是定义各个对象的，⽐如，
⽤户表
urnameemailtelephonestatus
zhangsanzhangsan@enabled
⾓⾊表
roleidrolenamerolecname
20001developer业务开发
操作表
operationidnamedescribe
40001Query查询
对象表
objectidnametypedesc
30001域名test
API⽹关权限控制模型设计
API⽹关的权限控制，我们采⽤RBAC模型。
API⽹关⾥⾯的对象其实只有两种，⼀种是前端元素，⽐如菜单、按钮；另⼀种是API接⼝，⽐如某个微服务的查询域名接⼝。
对于前端元素，操作对象只有在页⾯上显⽰或者不显⽰；⽽对于API接⼝，操作对象只有能调⽤或者不能调⽤。
根据上⾯的分析，操作对象其实就可以省略了，那么我们的RBAC模型就更简单了。可以简化为下图，
⽤户⾓⾊对象
如果你觉得上⾯的结构不够⽤，那么你可以根据需要扩展，⽐如在⽤户和⾓⾊之间添加⼀层，⽤于隔离⽤户和⾓⾊这两个对象。还可
⽤户组
以给⾓⾊分层，不同的⾓⾊间可以设置归属关系。如下所⽰，
⽤户⽤户组⾓⾊对象
⾓⾊A
⽤户对象
⾓⾊B
我们需要考虑⼀个问题，前端元素和API接⼝很多⼀⼀对应的，⽐如触发某个按钮会调⽤某个接⼝去执⾏动作，所以为了在控制台配置权限
的时候能简单些，我们需要⼀个前端元素对象和API接⼝对象的映射表，有了这个表，如果在控制台为某个⾓⾊配置了前端元素权限，那么
这个⾓⾊默认就有了对应的API接⼝权限了。
联动表
objectidobjectid
3000130002
关键点设计
对象范围
我们前⾯说到的对象有前端元素和API接⼝，这两种对象对于所有微服务都适⽤，那么有没有其他类型的对象权限也可以在API⽹关中管理
呢？
我先不回答这个问题，我们先拿⼀些对象分析分析看看。
我们先说这种对象，域名分⼀级域名和⼆三级域名，⼆三级域名是归属于⼀级域名的，所以在权限分配时，如果给⾓⾊分配了⼀级域名
域名
的权限，那么它下⾯的⼆三级域名也需要获取相应的权限，这⾥⾯涉及到对象归属和权限继承的问题。
我们再看看这种对象，它就没有归属关系，但证书的操作类型有增、删、改、查、启⽤、停⽤、续期等，操作类型⽐较多，⽽且有些是
证书
特别的，⽐如续期。
根据上⾯的分析，我们可以看出不同的对象，要么在对象本⾝上花样多，要么对应的操作类型花样繁杂，所以其他对象不适合在API⽹关⾥
⾯做权限管理。
MVC框架权限控制
我们在学习微服务框架权限控制的时候也回头看看MVC框架的权限控制是怎么样的，对⽐下看看微服务框架有什么优势，这也叫
学⽽时习
之，温故⽽知新
。
我们以Python开发框架Django为例来说明，在Django框架中⾃带表级别的权限控制模块，就是你可以控制数据库表的增、删、改、查操
作，如果引⼊guardian这个插件的话还可以做到字段级别的权限控制。因为HTML/JS模块数据是由后端来填充的，所以Django可以控制
前端元素，那它可以控制API接⼝的权限吗？
答案是不能，因为权限的控制只能在接⼝函数⾥⾯来做。由此，我们知道微服务框架的⼀个优势了哈。
缓存
在⽤户登录某微服务前端系统后，前端服务会从API⽹关获取需要的⽤户信息和前端元素，这种动作是⽤户登录才会触发，不会很频繁，权
限控制服务可以hould住，⽤户每在前端操作⼀次通常就会触发⼀次接⼝调⽤，在调⽤前会问权限服务有没有权限调⽤，可以看到这个时间
周期有点长，我们可以通过在⽹关内放⼀层缓存，⾥⾯缓存各个接⼝的权限信息，在权限服务有更新的时候会⾃动触发更新⽹关⾥⾯的缓
存。缓存的数据结构可以设计成如下图所⽰，
开源⽅案
Shiro
推荐指数 ***
开发语⾔
Java
源码地址
介绍
Shiro是⼀个强⼤的简单易⽤的Java安全框架，主要⽤来更便捷的认证，授权，加密，会话管理。Shiro⾸要的和最重要的⽬标就是容易使
⽤并且容易理解。最主要的就是⾝份验证和权限控制这两个功能。
架构
组件
1. Authentication：⾝份认证/登录，验证⽤户是不是拥有相应的⾝份。
2. Authorization：授权，即权限验证，验证某个已认证的⽤户是否拥有某个权限；即判断⽤户是否能做事情，常见的如：验证某个⽤户
是否拥有某个⾓⾊。或者细粒度的验证某个⽤户对某个资源是否具有某个权限。
3. Session Manager：会话管理，即⽤户登录后就是⼀次会话，在没有退出之前，它的所有信息都在会话中；会话可以是普通 JavaSE
环境的，也可以是如 Web 环境的。
4. Cryptography：加密，保护数据的安全性，如密码加密存储到数据库，⽽不是明⽂存储。
5. Web Support：Web⽀持，可以⾮常容易的集成到 web 环境。
6. Caching：缓存，⽐如⽤户登录后，其⽤户信息、拥有的⾓⾊/权限不必每次去查，这样可以提⾼效率。
7. Concurrency：shiro ⽀持多线程应⽤的并发验证，即如在⼀个线程中开启另⼀个线程，能把权限⾃动传播过去。
8. Testing：提供测试⽀持。
9. Run As：允许⼀个⽤户假装为另⼀个⽤户（如果他们允许）的⾝份进⾏访问。
10. Remember Me：记住我，这个是⾮常常见的功能，即⼀次登录后，下次再来的话不⽤登录了。
优点
⽤SecurityManager来管理其他组件，它是JavaBeans⽅式，是可兼容的，因此可以采⽤可配置的⽅式定制其他组件。
⽤户、⾓⾊、对象和权限信息是配置在INI⽂件中的，应该也可以采⽤数据库来存储，INI配置格式如下：
# =============================================================================
# Tutorial INI configuration
# =============================================================================
[urs]
root = cret, admin
guest = guest, guest
presidentskroob = 12345, president
darkhelmet = ludicrousspeed, darklord, schwartz
lonestarr = vespa, goodguy, schwartz
# ----------------------------------------------------------------------------2022世界杯在哪个国家
-
# Roles with assigned permissions
# roleName = perm1, pe书法名言
rm2, ..., permN
# -----------------------------------------------------------------------------
[roles]
admin = *
schwartz = lightsaber:*
goodguy = winnebago:drive:eagle5
权限模型可以是Role-Bad Access Control，也可以是Permission-Bad Access Control，即可以定义对象的层级关系，例如：
printer:query:JP0139829
Printer代表打印机，query代表查询操作，JP0139829代表具体的打印机，结合起来就是可以查询JP0139829这台打印机的信息。
