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 开源项目里，换了个场景，依然适用。

从单体到账号中台：统一认证中心的架构思考

Mon, 11 Mar 2024 10:30:00 +0800

四个系统，四套登录

2023 年底我刚到某科技公司时，内部几个业务系统各有各的登录：统一支付平台一套账号，数据治理服务一套，数据集管理服务和知识库问答服务又各搞一套。员工要记四五个密码，离职了账号还关不干净；外部客户在一个系统注册完，跳到另一个系统还得再注册一次。运维和安全团队都在催：能不能统一一下。

这就是统一认证中心的起点。但很快想明白一件事：光把用户表抽出来解决不了问题，身份怎么统一、认证方式怎么扩展、应用之间怎么建立信任，这三件事都绕不开。

核心域怎么划

我把统一认证中心划成五个域：

身份域：全局唯一的 UserID（Snowflake 生成），一个用户可以绑定多种凭证，密码、手机、邮箱、微信/企微/飞书 OAuth 都行。
应用域：每个接入方有自己的 AppID/AppSecret，配置回调地址、授权方式、可用的登录 Provider。
组织域：用 AppRole 做团队/租户隔离，用户在不同应用里可以有不同角色。RBAC 权限模型落在认证中心，资源权限还是业务系统自己持有。
会话域：认证中心统一颁发 JWT（RSA 私钥签），业务系统拿 JWKS 公钥在本地验签，不回源。
Provider 域：短信、邮件、验证码、社交登录全做成可插拔接口，默认实现腾讯云 SMS/SES/Captcha，以后要换阿里或自建，加个实现就行。

技术栈上用 go-zero 拆 RPC 服务，Wire 做依赖注入，Service/DAO 分层。

分层与关键代码

整体分层这样组织：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


passport/
├── api/ # HTTP 网关 (go-zero rest)
│ ├── handler/
│ └── middleware/
├── rpc/ # gRPC 服务
│ ├── user/
│ ├── app/
│ ├── auth/
│ └── org/
├── internal/
│ ├── service/ # 业务编排
│ ├── dao/ # 数据访问
│ ├── provider/ # 可插拔 Provider
│ └── token/ # JWT 签发/JWKS
└── wire/

Provider 接口是可插拔的关键：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


type SMSProvider interface {
 Send(ctx context.Context, phone, tmplID string, params map[string]string) error
}

type EmailProvider interface {
 Send(ctx context.Context, to, subject, body string) error
}

type CaptchaProvider interface {
 Verify(ctx context.Context, ticket, randstr string) error
}

Wire 注入时按配置选择实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


func NewSMSProvider(cfg config.SMS) provider.SMSProvider {
 switch cfg.Provider {
 case "tencent":
 return tencent.NewSMS(cfg.Tencent)
 case "aliyun":
 return aliyun.NewSMS(cfg.Aliyun)
 default:
 return noop.NewSMS()
 }
}

登录入口用 AuthService 统一编排。不管密码、短信还是社交登录，最后都收拢到同一套"凭证换 UserID → 发 Token"的流程里：

 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


type AuthService struct {
 userDao dao.UserDAO
 credDao dao.CredentialDAO
 tokenSvc *token.Service
 providers provider.Container
}

func (s *AuthService) Login(ctx context.Context, req *LoginRequest) (*TokenPair, error) {
 var userID int64
 var err error
 switch req.GrantType {
 case "password":
 userID, err = s.loginByPassword(ctx, req.AppID, req.Account, req.Password)
 case "sms":
 userID, err = s.loginBySMS(ctx, req.AppID, req.Phone, req.Code)
 case "social":
 userID, err = s.loginBySocial(ctx, req.AppID, req.Provider, req.Code)
 default:
 return nil, ErrUnsupportedGrantType
 }
 if err != nil {
 return nil, err
 }
 return s.tokenSvc.Issue(ctx, userID, req.AppID)
}

JWT 签发用 RSA 私钥，公钥通过 JWKS 端点暴露：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


func (s *Service) Issue(ctx context.Context, userID int64, appID string) (*TokenPair, error) {
 now := time.Now()
 claims := Claims{
 UserID: userID,
 AppID: appID,
 RegisteredClaims: jwt.RegisteredClaims{
 Issuer: "passport",
 Subject: strconv.FormatInt(userID, 10),
 Audience: jwt.ClaimStrings{appID},
 ExpiresAt: jwt.NewNumericDate(now.Add(2 * time.Hour)),
 IssuedAt: jwt.NewNumericDate(now),
 ID: snowflake.NextID(),
 },
 }
 accessToken, err := jwt.NewWithClaims(jwt.SigningMethodRS256, claims).
 SignedString(s.privKey)
 // refresh token 省略
 return &TokenPair{AccessToken: accessToken, ...}, nil
}

最难的是用户合并

五个域里真正难缠的是身份。一个用户先用微信登录、后来又用手机号注册，识别为同一个人之后要合并。我的做法是建一张 user_bindings 表，凭证和用户是多对一关系，合并时把旧凭证挂到新 UserID 下，再写一条审计日志。

麻烦在后头：业务系统的外键引用的还是旧 UserID，得发事件通知各系统做 ID 映射。这件事比当初拍板时想的工作量大得多。

吊销、组织树和供应商灰度

JWT 吊销是个老话题。我们用短 AccessToken（2 小时）加长 RefreshToken（7 天），RefreshToken 存 Redis，随时可吊销；AccessToken 不做黑名单，靠短过期自然失效。登出只吊销 RefreshToken。支付这类安全要求极高的场景，再加一个"令牌版本号"claim，改密码时版本号递增，旧 token 立刻作废。

组织这块一开始想把组织树建在认证中心，后来发现各业务系统的组织模型差异太大：统一支付平台里是商户，数据治理服务里是团队，知识库问答服务里是企业。强行统一就是削足适履。最后认证中心只存 (app_id, user_id, role_external_id)，组织名和层级由业务系统自己维护。

Provider 也有灰度需求。腾讯云短信偶尔抖动，我在 Provider 层加了个 FanoutProvider，按权重在多家供应商之间分流，失败自动降级，配置走配置中心热更新，不用重启。

后来

统一认证中心上线之后，新业务接入 SSO 只要半天，离职员工的账号在一处关掉就全端下线，安全审计也有了统一入口。回头看，做账号中台靠的是克制：只做身份、认证、应用信任这三件事，组织和资源权限坚决留给业务系统。“登录"这件每个系统都要重复做的事，总算变成了一个可复用的平台能力。

封面图：anthony arrigo / Flickr · CC BY 2.0

账号中台 on 姚玉亮的网络日志