RBAC 权限模型：用户-团队-角色的设计与落地

Wed, 29 May 2024 10:30:00 +0800

权限模型五花八门

统一认证中心之前，有的系统把权限硬编码在代码里，有的用配置文件，还有的直接在数据库里存用户和菜单的关联。人员入职、换岗，得在每个系统分别改一遍权限；真到审计的时候，谁到底有什么权限，根本说不清。

所以要做的就是把用户、团队、角色、权限点收敛到统一认证中心一处管理，同时还得支撑前面说过的 AppRole 应用自治。

比经典 RBAC 多一层团队

经典 RBAC 是用户-角色-权限三层，我们在中间加了团队，变成用户-团队-角色-权限。核心实体四个：User、Team、Role、Permission。用户和团队多对多，进了团队之后，通过 TeamMember 关联一个或多个角色。角色分全局角色和 AppRole 两种；权限点用「资源:操作」的格式，比如 dataset:read、order:refund，角色绑定权限点，用户经由角色间接拿到权限。

还支持角色继承：team-admin 继承 team-viewer 的全部权限，管理员比普通成员多出一堆权限这种常见配置，就不用重复维护了。

查权限就是展开继承链

角色定义和角色-权限绑定是两张表：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


type Role struct {
 ID int64 `gorm:"primaryKey"`
 AppID string `gorm:"index"` // 空表示全局角色
 Code string `gorm:"size:64;uniqueIndex:idx_app_code"`
 Name string `gorm:"size:128"`
 ParentID int64 // 角色继承
 IsBuiltin bool
}

type RolePermission struct {
 RoleID int64 `gorm:"uniqueIndex:idx_role_perm"`
 Permission string `gorm:"uniqueIndex:idx_role_perm;size:64"`
}

func (s *Service) ListUserPermissions(ctx context.Context,
 userID, teamID int64, appID string) ([]string, error) {

 roles, err := s.memberDAO.ListRoles(ctx, teamID, userID, appID)
 if err != nil {
 return nil, err
 }
 // 展开继承链上的所有角色
 allRoles, err := s.roleDAO.ExpandWithParents(ctx, roles)
 if err != nil {
 return nil, err
 }
 return s.permDAO.ListByRoleIDs(ctx, allRoles)
}

ListUserPermissions 做的事不复杂：先查出用户在这个团队、这个应用上的角色，把继承链上的父角色全部展开，最后汇总权限点。

鉴权分两级。网关层做粗粒度：这个 Token 能不能访问这个路由，用 JWT 里带的角色信息判断就够。业务服务层做细粒度：能不能操作这条数据，通过 gRPC 调统一认证中心的 CheckPermission，或者读本地权限缓存。缓存用 Redis，key 是 perm:{teamID}:{userID}:{appID}，成员关系或角色变更时主动失效。

缓存这坑最深

权限缓存的一致性，是最初低估了的部分。成员变更时只删当前用户的缓存，这没问题；但角色权限变更时，得把这个角色下所有用户的缓存都删掉，用户一多就是缓存击穿。

后来改成版本号方案：每个团队的权限版本号存在 Redis，缓存 key 带上版本号，变更时递增版本，旧缓存自然过期。代价是新旧权限会有短暂的并存窗口，评估下来可以接受。

粒度是另一件要拿捏的事。权限点切得太细，配置维护成本高；太粗又起不到管控效果。我们的经验是按业务操作定义，一个接口一个权限点，特殊操作再细分。

后来

这套模型落地之后，人员的入转调离只需要在一处改权限，审计也能统一导出。配上 AppRole 的应用自治和带版本号的权限缓存，安全管控是统一的，业务线的灵活性也保住了。这套用户-团队-角色-权限的模型后来还复用到了 alchemy-furnace 开源项目里，换了个场景，依然适用。

AppRole 与应用团队隔离：多业务线权限自治的实现

Mon, 13 May 2024 10:30:00 +0800

角色表快撑不住了

统一认证中心接入的应用越来越多，权限模型先扛不住了。支付平台有运营、财务、商户管理员这些角色；数据治理服务有数据管理员、分析师；数据集管理服务又有自己的文档管理员。要是所有角色都放到认证中心全局定义，角色表迟早撑爆，而且业务线想调整自己的角色，还得来找认证中心团队，自治无从谈起。

我们需要一层「应用角色（AppRole）」：每个应用自己定义、自己管理角色，认证中心只负责团队隔离。

认证中心管边界，应用管角色

做法是把权限拆成两层。认证中心全局层只管团队（Team）和成员关系，应用层管 AppRole。一个用户在同一个团队里，对不同应用可以有不同角色：张三在数据中台团队里，对数据治理服务是 admin，对知识库问答就只是 viewer。

团队是隔离边界，数据、配置、成员都按 team_id 隔离，跨团队访问必须显式授权。AppRole 的角色编码（admin/editor/viewer 这类）和对应权限点由应用自己定义，认证中心只存绑定关系，不关心权限点具体是什么意思。

查权限就是查一次绑定

绑定关系就一张表，team_id、user_id、app_id 联合唯一，AppRole 字段存的是应用自己定义的角色编码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


type TeamMember struct {
 ID int64 `gorm:"primaryKey"`
 TeamID int64 `gorm:"uniqueIndex:idx_team_user_app"`
 UserID int64 `gorm:"uniqueIndex:idx_team_user_app"`
 AppID string `gorm:"uniqueIndex:idx_team_user_app"`
 AppRole string `gorm:"size:32"` // 应用自定义角色编码
}

func (s *Service) CheckPermission(ctx context.Context,
 userID, teamID int64, appID, perm string) bool {

 member, err := s.memberDAO.Get(ctx, teamID, userID, appID)
 if err != nil {
 return false
 }
 // 应用通过接口返回角色 -> 权限点映射
 perms, err := s.appProvider.GetPermissions(ctx, appID, member.AppRole)
 if err != nil {
 return false
 }
 for _, p := range perms {
 if p == perm || p == "*" {
 return true
 }
 }
 return false
}

CheckPermission 的逻辑很直白：查出用户在这个团队、这个应用上的角色，再向应用要这个角色对应的权限点列表，匹配上就放行。角色到权限点的映射由应用自己实现，认证中心不做解释。

JWT 里带了当前 team_id 和各应用的 role 映射，业务系统在本地就能做粗粒度鉴权，细粒度权限点再查认证中心或读缓存。团队隔离则下沉到 DAO 层强制：所有查询都带 team_id 条件，我们用 Gorm 的 Scopes 封了个 WithTeam，免得哪次手写漏了。

两个坑

第一个是切换团队。用户可能同时属于多个团队，但 Token 里只能放一个当前 team_id。最初想把所有团队都塞进 Token，团队一多就超过 HTTP 头大小限制了。后来改成 Token 只放当前团队，加了个 switch-team 接口重新签发，前端切团队时调一下。

第二个是自治带出来的小代价：AppRole 让应用自己定义之后，认证中心管理后台没法统一展示权限点了。解决办法是让应用注册一个权限元数据接口，认证中心拉取后展示。多了一次对接，换来自治，这笔账算得过来。

后来

AppRole 加 Team 的两层模型，说白了就是在全局管控和应用自治之间找平衡：认证中心管身份和团队边界，应用管自己的角色和权限点。后来支付平台、数据治理、知识库问答几条业务线先后接入，新应用进来定义好自己的角色就能用，认证中心的表结构不用动。

封面图：bfi Office Furniture / Flickr · CC BY-SA 2.0

RBAC on 姚玉亮的网络日志