前言
在1个多用户系统中，系统安全是必须要考虑的问题。
不同用户在系统中的职责不同，能够访问的资源和可以执行的操作也不一样，例如普通用户可能只能查看数据，而管理员则可以修改或删除数据。
如果系统不对这些操作进行限制，就可能出现未授权访问、误操作甚至数据泄露等问题，因此出于系统安全考虑，大多数多用户系统都会引入权限控制机制。
权限控制的核心是在用户访问当前系统的资源时，根据用户身份和系统中的权限规则，判断该用户是否有权执行某个操作，从而保证系统资源只被授权用户访问。
权限控制机制包含两类数据：用户身份信息和权限策略信息，数据来源通常如下：
| 数据 | 数据来源 |
|---|---|
| 用户身份信息 | JWT / SSO / 用户系统 |
| 权限策略 | 权限数据库 / Casbin policy |
权限控制是将用户身份信息与权限策略数据结合，通过权限判断流程决定是否允许访问资源。（基于数据做决策）
| 概念 | 英文 | 中文 |
|---|---|---|
| AuthN | Authentication | 身份认证 |
| AuthZ | Authorization | 授权 |
| 鉴权 | Authorization check | 权限校验 |
权限控制系统，有了用户身份信息和权限策略信息之后，就可以基于数据对当前用户访问当前系统资源的操作行为进行决策，标准流程如下：
请求进入系统
↓
AuthN（认证）
验证JWT token
↓
获取用户 identity
user = zhangsan
↓
AuthZ（鉴权/权限判断）
是否允许访问资源
↓
Casbin判断
↓
allow / deny
一、RBAC权限控制模型
RBAC即Role-Based Access Control基于角色的访问控制。
RBAC权限控制的关键是角色，权限不会直接分配到用户，而是通过角色间接分配到用户。
系统不认用户身份，根据用户的角色授予用户不同的权限；
1.RBAC的4大模型
RBAC根据这套模型功能的复杂程度不同，由简单到复杂又可以分为RBAC-0、RBAC-1、RBAC-2、RBAC-3四个层级。
1.1.RBAC-0
RBAC-0是最基础的，就是在用户与角色、角色与权限间建立关系，每种关系均为多对多。
1.2.RBAC-1
RBAC-1是在RBAC-0的基础上，增加了继承关系。就是一个角色只能有另一角色的部分权限，这个角色的权限大小受另一角色权限影响。
简单说，角色2由角色1派生，那么角色2所有得权限必然小于角色1，角色1拥有权限1，2，而角色2只有拥有权限。
角色分级
1.3.RBAC-2
RBAC-2模型，其实就是通过限制滥用角色，防止角色冲突。
一个简单例子，你不能即是老板也是老板秘书，这样关系就乱了
这里就是用户3不能同时拥有角色2，3。
1.4.RBAC-3
RBAC-3是RBAC-1与RBAC-2的结合，就是既有继承关系，又有限制条件，基础都一样。
二、ABAC权限控制模型
当前90%的企业都在使用RBAC，但实际使用之后会有如下问题：
- 1.角色爆炸（RoleExplosion）
- 岗位一多，角色就指数级增长，管理员、部门管理员、项目管理员、只读管理员、临时管理员…最后角色比用户还多，根本管不住。
- 2.权限控制僵硬不灵活，不支持动态判断
- RBAC只看当前用户是什么角色，是啥角色就有啥权限，不支持：时间（上班才能访问）地点（内网才能访问）设备（必须是公司设备）数据属性（只能看自己部门的数据）→ 现代零信任、微服务完全不够用。
- 3.权限颗粒度太粗
- 想控制到：某个人只能看某条数据/某个接口只能调用几次,RBAC 做不到，只能硬加角色，越搞越乱。
- 4.最小权限原则无法落地不安全
- 职责划分模糊，易出现权限过大，为了省事，直接给管理员角色。最小权限原则很难落地。
- 5.不支持基于资源属性隔离
- 云原生场景租户、项目、环境一多，RBAC 组合爆炸，无法基于资源属性做隔离。
- 6.权限维护成本极高
- 人员变动、组织结构调整时：要删角色、建角色、重新绑定…运维成本巨大。
Attribute-Based Access Control基于属性的访问控制，即基于当前用户用于的权限属性进行随机应变。
1.Casbin权限检查引擎
ABAC的核心优势是多维度属性动态授权，但如果把这些属性判断逻辑硬编码到业务代码里，会导致代码耦合高、规则难维护、变更成本大。
而Casbin正是为解决这个痛点而生的工具，Casbin把ABAC的权限规则从业务代码中抽离出来，变成可配置、可管理的策略规则。
Casbin本质是一个通用的访问控制框架，而非单纯的ABAC实现，它的核心价值是：
- 权限规则与代码解耦：把 谁（主体属性）在什么条件（环境属性）下对什么（资源属性）做什么（动作属性 的判断逻辑，从业务代码中抽离成策略规则（支持文件 / 数据库存储）。
- 提供标准化的ABAC模型定义：通过Model文件定义ABAC的核心要素（主体、资源、动作、环境属性），策略规则基于Model动态配置，无需修改代码。
- 灵活的规则引擎：内置表达式解析能力，支持复杂的属性判断（如时间、IP、数据归属、用户职级等），无需硬编码 if-else。
Casbin可以动态读取权限策略规则，是判断当前用户是否有权限做某事的引擎，不授予权限，只负责裁决，也不需要自己写代码进行权限规则判断。
Casbin支持一下主流编程语言
2.LNMP架构权限管理
早期LNMP/Tomcat集群架构中，Nginx后面的多个后端程序（PHP/Java），通过共用1个Redis实例共享Session。
在LNMP架构下，所有PHP节点都连同1个Redis，每1次请求进来，都要去Redis查1次session，然后拿到用户信息、权限，再判断能不能访问。、
3.微服务架构权限管理
用户请求统一经过微服务API网关，网关负责校验JWT Token合法性，完成用户身份认证。
用户请求
↓
API 网关（统一认证 & 路由）
↓
┌─────────┬─────────┬─────────┐
微服务A 微服务B 微服务C
│ │ │ |
本地权限 本地权限 本地权限
└─────────┴─────────┴─────────┘
↑
权限中心（统一配置）
网关解析出user_id、tenant_id等用户身份信息，通过请求头向下游透传。
权限策略在权限中心集中管理权限，并通过缓存/消息推送至各微服务本地。
微服务A→B→C 调用链路上，每个服务仅从请求头获取用户身份，基于本地缓存或Casbin等引擎完成本地权限判断，不再远程调用权限中心或Redis。
Casbin官网
浙公网安备 33010602011771号