【免费下载链接】flexpriceUsage-based pricing and billing for developers Cloud or self-hosted ⚙️ No-code UI Realtime usage metering Credits top-ups Control feature access项目地址https://gitcode.com/gh_mirrors/fl/flexprice点击查看免费下载本文以 Flexprice 开源仓库中的《Dynamic RBAC/ABAC System - Product Requirements Document》为骨架系统讲解面向企业多租户场景的动态角色权限体系从动态角色引擎、权限模板、条件访问策略、角色继承等核心设计到数据库 Schema、REST API 规格与分阶段实施计划同时对照仓库当前已落地的静态 RBAC 实现JSON 角色定义 集合查找 Gin 中间件说明一条从静态角色到动态权限的清晰演进路径。读完本文你将掌握 Flexprice 权限系统的完整设计蓝图、当前源码级的实现细节以及未来扩展为动态 RBAC/ABAC 的具体改造方向。一、背景静态角色为何无法满足企业需求Flexprice 是一个面向开发者的用量计费与定价usage-based pricing and billing平台天然需要服务多租户场景。早期系统的访问控制依赖固定角色user、manager、admin、superadmin这种静态角色结构在企业客户面前暴露出五类核心问题静态角色结构僵化固定角色无法映射企业多样化的组织架构与岗位职责灵活性不足难以适配不同企业独特的工作流与授权模式客户锁定风险企业客户如文档中提到的 XYZ Company要求自定义访问模式否则难以迁入合规缺口静态角色可能与监管要求如职责分离、最小权限不一致运维负担每次定制需求都要走人工工单增加支持成本。PRD 中给出的一组关键业务目标因此确立客户留存让企业客户完全掌控自己的访问管理市场差异化提供接近 AWS IAM 级别的角色与权限管理灵活性可扩展性每个租户支持无限自定义角色与细粒度权限合规性满足企业安全与审计要求。二、解决方案总览六大核心组件与关键特性PRD 提出的动态 RBAC/ABAC 方案由以下六类核心组件构成组件职责动态角色管理引擎Dynamic Role Management Engine角色 CRUD、层级解析与生命周期管理权限模板系统Permission Template System预置常用角色模板支持定制与版本化策略构建器Policy Builder Interface面向管理员的策略配置界面审计与合规模块Audit and Compliance Module记录全部角色/权限变更支撑合规报告多租户角色隔离Multi-tenant Role Isolation角色与权限按租户隔离API 优先架构API-First Architecture全部能力以 REST API 形式开放关键特性覆盖自定义角色创建可定义无限数量的自定义角色带描述性名称细粒度权限为资源与动作精确分配权限角色继承支持角色层级与权限继承条件访问支持基于时间、地点、属性的条件控制批量操作规模化管理角色与权限集成 API与既有系统无缝集成。三、详细需求规格FR / NFR3.1 功能需求FR-001动态角色创建优先级 Critical管理员可创建带特定权限的自定义角色验收标准包括使用自定义名称与描述创建角色单个角色可挂多个权限可设置角色过期时间可定义角色继承模式租户内角色名称唯一性校验。FR-002权限模板系统优先级 High为常见场景提供预置权限模板验收标准包括提供 Project Manager、Developer、Auditor 等常见角色模板允许对模板进行定制支持模板版本化支持跨租户共享模板需审批。FR-003条件访问策略优先级 High支持复杂访问条件验收标准包括基于时间的访问工作时间、临时访问基于位置的访问IP 段、地理限制基于属性的条件部门、项目分配多因素认证要求。FR-004角色分配管理优先级 Critical动态分配与回收角色验收标准包括批量角色分配/回收定时角色变更敏感角色审批流程角色分配审计轨迹。FR-005权限继承优先级 Medium支持层级角色结构验收标准包括父子角色关系从父角色继承权限子角色具备覆盖能力环形依赖防护。3.2 非功能需求编号维度目标NFR-001性能复杂策略角色评估 50ms角色创建 2s批量 1000 角色分配 30sNFR-002可扩展性每租户 10,000 自定义角色每租户 100,000 用户每分钟处理 1M 授权请求NFR-003安全策略存储加密全部角色/权限变更审计日志最小权限原则防权限提升NFR-004可用性99.9% 可用性 SLA高负载优雅降级自动故障转移四、技术架构设计4.1 动态角色引擎组件结构PRD 给出如下系统组件划分┌─────────────────────────────────────────────────────────────────┐ │ Dynamic Role Engine │ ├─────────────────────────────────────────────────────────────────┤ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Role Manager │ │ Permission Mgr │ │ Policy Engine │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │Template System │ │ Condition Eval │ │ Inheritance Mgr │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ ├─────────────────────────────────────────────────────────────────┤ │ Data Storage Layer │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Role Store │ │ Permission Store│ │ Audit Store │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ └─────────────────────────────────────────────────────────────────┘4.2 API 架构REST APIs: - GET /api/v1/roles - POST /api/v1/roles - PUT /api/v1/roles/{id} - DELETE /api/v1/roles/{id} - POST /api/v1/roles/{id}/permissions - GET /api/v1/permissions/templates - POST /api/v1/users/{id}/roles - GET /api/v1/audit/roles4.3 数据库 Schema动态角色表以(tenant_id, name)唯一约束保证租户内角色名唯一parent_role_id自引用实现角色层级is_system_role区分系统内置角色与用户自定义角色expires_at支持角色过期。CREATE TABLE dynamic_roles ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, name VARCHAR(255) NOT NULL, description TEXT, parent_role_id UUID REFERENCES dynamic_roles(id), is_system_role BOOLEAN DEFAULT FALSE, expires_at TIMESTAMP, created_by UUID NOT NULL, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW(), UNIQUE(tenant_id, name) );权限表resource action组成权限主体condition_expression存放 ABAC 条件表达式DSL 字符串is_system_permission标记系统预置权限。CREATE TABLE dynamic_permissions ( id UUID PRIMARY KEY, resource VARCHAR(100) NOT NULL, action VARCHAR(100) NOT NULL, condition_expression TEXT, description TEXT, is_system_permission BOOLEAN DEFAULT FALSE, created_at TIMESTAMP DEFAULT NOW() );角色-权限关联表复合主键(role_id, permission_id)granted_by记录授权人用于审计expires_at支持权限级临时授权。CREATE TABLE role_permissions ( role_id UUID REFERENCES dynamic_roles(id), permission_id UUID REFERENCES dynamic_permissions(id), granted_by UUID NOT NULL, granted_at TIMESTAMP DEFAULT NOW(), expires_at TIMESTAMP, PRIMARY KEY (role_id, permission_id) );配套技术分解文档docs/prds/dynamic-rbac-technical-breakdown.md还补充了user_roles分配表、role_hierarchy继承表、permission_templates模板表与audit_logs审计表的设计并给出了对应的 Go 领域模型与仓储层接口草案。五、用户故事Epic 划分Epic 1角色管理Story 1.1 创建自定义角色租户管理员创建名为 Project Lead 的角色赋予项目管理相关权限且不包含完整管理员权限角色创建后出现在用户分配下拉框中操作被记录审计。Story 1.2 角色模板管理员可浏览预置模板、在创建前定制模板、查看模板描述与所含权限并可保存定制后的模板复用。Epic 2权限管理Story 2.1 细粒度权限创建invoice.read.own权限实现用户只能查看自己创建的发票。Story 2.2 条件权限创建基于时间的权限使临时承包商只在合同期内可访问。Epic 3用户分配Story 3.1 单点分配将 Project Lead 角色分配给指定用户。Story 3.2 批量分配将 Developer 角色批量分配给整个工程团队成员。六、API 规格示例6.1 创建自定义角色POST /api/v1/roles Content-Type: application/json { name: Project Lead, description: Manages specific projects with limited admin access, parent_role_id: null, permissions: [ { resource: project, action: read, condition: resource.assigned_users.contains(user.id) }, { resource: project, action: update, condition: resource.lead_user_id user.id } ], expires_at: null }其中condition字段即 ABAC 策略表达式resource.assigned_users.contains(user.id)表示仅当资源分配给该用户时才可读。6.2 分配角色给用户POST /api/v1/users/{user_id}/roles Content-Type: application/json { role_id: 550e8400-e29b-41d4-a716-446655440000, assigned_by: admin_user_id, expires_at: 2024-12-31T23:59:59Z, reason: Promoted to project lead for Q4 projects }6.3 权限检查授权决策POST /api/v1/auth/check Content-Type: application/json { user_id: user123, resource: project, action: update, resource_attributes: { project_id: proj456, lead_user_id: user123, assigned_users: [user123, user789] } }授权引擎将结合user_id的角色集合与resource_attributes中的资源属性对权限上的condition_expression求值后给出 allow/deny 决策。七、分阶段实施计划16 周路线图Phase 1基础建设第 1-4 周—— 交付数据库 Schema、角色 CRUD、权限管理系统与核心单元测试技术任务包括创建数据库迁移、实现角色管理服务、构建权限评估引擎、创建角色管理 API 端点。Phase 2高级特性第 5-8 周—— 交付角色继承系统、条件访问策略、角色模板与批量操作技术任务包括实现层级解析、构建条件求值引擎、创建模板管理系统、增加批量导入导出。Phase 3集成与 UI第 9-12 周—— 交付角色管理后台、API 文档、静态角色迁移工具与性能优化技术任务包括构建 React 管理界面、编写完整 API 文档、实现角色迁移工具、加入缓存与优化。Phase 4生产就绪第 13-16 周—— 交付安全审计、性能测试、文档与培训、监控告警技术任务包括安全评审、真实数据压测、用户指南与 API 文档、监控看板。配套的技术分解文档进一步将上述阶段拆解为 20 周、5 个 Epic 的可执行任务清单含估算工时、优先级、依赖关系并给出统一测试策略单元测试覆盖率目标 90%、集成/端到端/性能/安全测试矩阵与部署策略Beta → 分阶段灰度 → 全量生产配套 Feature Flag 回滚、可逆迁移、API 版本化。八、成功指标、风险评估与合规要求客户成功指标30 天内 80% 企业客户创建自定义角色角色管理功能满意度 95%角色相关支持工单下降 50%客户 2 小时内完成角色体系搭建。技术成功指标授权响应 50ms角色评估服务 99.9% 可用每租户 10,000 角色无性能退化零未授权访问事件。风险评估级别风险缓解措施高通过角色继承实现权限提升自动化安全测试 人工安全评审高复杂角色评估拖慢系统缓存策略 性能监控中静态到动态角色迁移复杂渐进式迁移工具 回滚能力中非技术管理员难以操作用户测试 简化界面低客户需要培训文档、Webinar、客户成功支持合规与安全角色与权限数据静态加密全部管理操作审计日志合规数据留存策略GDPR 合规数据处理管理功能强制多因素认证最小权限原则定期访问评审与认证自动异常检测审计轨迹支持合规报告与 SIEM 集成。依赖清单内部依赖认证服务、租户管理、通知服务、审计日志系统外部依赖 Casbin 策略引擎、PostgreSQL、Redis 缓存与监控工具。九、仓库源码现状已落地的静态 RBAC 实现PRD 描述的是动态系统的目标蓝图。对照当前开源仓库Flexprice 已落地了一套以 JSON 角色定义 集合查找为核心的静态 RBAC 实现两者的对应关系是理解演进路径的关键。9.1 角色定义文件internal/config/rbac/roles.json当前角色全部定义在 internal/config/rbac/roles.json 中每个角色包含name、description与permissions三部分{ super_admin: { name: Super Admin, description: Provides unrestricted access to all resources, operations, and administrative settings., permissions: { *: [*] } }, all_reader: { name: All Reader, description: Provides read-only access to all resources and operations., permissions: { *: [read] } }, all_writer: { name: All Writer, description: Provides read and write access to all resources and operations, excluding user, role, and administrative management., permissions: { *: [read, write] } }, event_ingestor: { name: Event Ingestor, description: Provides write-only access to event ingestion. Intended for services that only submit events., permissions: { event: [write] } }, event_reader: { name: Event Reader, description: Provides read-only access to events. Intended for services that only consume or inspect events., permissions: { event: [read] } } }注意其中的*通配符*: [*]表示对所有实体、所有动作授权这是 super_admin 的实现方式*: [read]则是全局只读。PRD 中关于每个租户支持无限自定义角色的设想在现阶段通过新增 JSON 条目即可实现——无需修改任何代码。9.2 核心服务internal/rbac/rbac.gointernal/rbac/rbac.go 实现了服务核心。其设计理念是热路径集合查找 冷路径元数据RBACService.permissionsmap[string]map[string]map[string]bool三层嵌套 map角色 → 实体 → 动作启动时从 JSON 一次性构建权限检查为 O(1) 查找RBACService.roles完整角色定义含 name/description仅供 API 响应使用权限检查路径从不触碰元数据保证零开销。关键方法// HasPermission checks if any of the users roles grant permission // Complexity: O(roles) with O(1) lookups ~3 operations for typical use func (s *RBACService) HasPermission(roles []string, entity string, action string) bool { for _, role : range roles { permissions : s.permissions[role] if permissions nil { continue } if permissions[*] ! nil (permissions[*][*] || permissions[*][action]) { return true } if permissions[entity] ! nil (permissions[entity][*] || permissions[entity][action]) { return true } } return false }HasPermission支持两层通配符语义实体通配符*授予全部实体访问权动作通配符*授予该实体上的全部动作。这与 PRD 中策略评估 50ms的性能目标相呼应——实际实现将复杂度压到了常数级。服务还提供三个安全关键方法ValidateRoles(userType, roles)校验角色存在、角色可被该用户类型分配并禁止 super_admin 与其他角色混用CanGrantRoles(callerRoles, requestedRoles)防止权限提升——调用者只能授予自身已持有的权限按权限逐一比对而非按角色名比对例如 writer 无法铸造写权限超出自身的角色只有 super_admin 能创建另一个 super_adminListRoles(filter)支持按用户类型过滤角色服务于角色选择器与权限 UI。9.3 类型系统internal/types/rbac.go 与 context.gointernal/types/rbac.go 定义了角色、用户类型、实体、动作的强类型枚举角色Rolesuper_admin、all_reader、all_writer、event_ingestor、event_reader用户类型UserType区分人user与服务账号service_accountAllowedRoles()定义了每种类型可分配的角色集合——人可持有 super_admin/all_reader/all_writer服务账号可持有 super_admin/all_reader/event_ingestor/event_reader实体Entity覆盖 event、meter、customer、plan、subscription、invoice、wallet、feature、entitlement、payment、webhook、oauth、workflow、analytics 等 30 业务资源动作Action当前抽象为read与write两个动作。internal/types/context.go 实现了上下文传递认证中间件将角色数组写入请求 contextCtxRoles键GetRoles(ctx)读取。无角色空数组即无任何授权所有权限检查失败关闭fail-closed——这与 PRD 中最小权限原则一致。9.4 强制层internal/rest/middleware/permission.gointernal/rest/middleware/permission.go 中的RequirePermission(entity, action, opts...)是路由级显式授权中间件执行顺序按问题优先级排列租户暂停检查写操作在租户处于 suspended 状态时直接 403最先检查让用户先听到账户问题SuperAdminOnly 选项通过SuperAdminOnly()选项标记的管理类路由如修改他人角色仅允许持有 super_admin 的用户账号执行服务账号即使密钥带 super_admin 也被拒绝——这是防权限提升的第二道闸门RBAC 检查rbacService.HasPermission(roles, entity, action)失败返回 403 insufficient permissions。该中间件与 PRD 中角色分配审计轨迹的诉求对齐每次拒绝都会输出结构化日志user_id、tenant_id、environment_id、roles、entity、action、path。9.5 对外 APIinternal/api/v1/rbac.gointernal/api/v1/rbac.go 提供了GET /rbac/roles支持user_type查询参数过滤与GET /rbac/roles/{id}两个端点供前端角色下拉框与角色详情页消费。注意当前仓库的路由前缀与 PRD 草案中/api/v1/roles的路径略有出入以源码中的实际路由/rbac/roles为准。十、从静态到动态演进路径与两种方案对比仓库中同时存在两份推进动态化的设计文档docs/prds/rbac-abac-implementation.md 与 docs/prds/dynamic-rbac-technical-breakdown.md。前者给出了基于Casbin 的两级授权架构方案Level 1Handler 级粗粒度—— 保护 HTTP 路由模型为[role, endpoint, method]例如仅 admin 可POST /usersHandler 级不做租户判断静态角色即可满足评估更快。Level 2Service 级细粒度—— 保护业务操作模型为[role, resource, action, condition]通过r.attrs携带资源属性进行 ABAC 求值。租户隔离通过强制条件r.attrs.entity_tenant_id r.attrs.user_tenant_id实现跨租户访问仅限 superadmin条件为true。其 Casbin 服务级模型配置abac_service.conf如下[request_definition] r sub, obj, act, attrs [policy_definition] p sub, obj, act, condition [role_definition] g _, _ [policy_effect] e some(where (p.eft allow)) [matchers] m g(r.sub, p.sub) r.obj p.obj r.act p.act eval(p.condition)ABAC 条件示例来自该文档// Time-based condition current_time 09:00 current_time 17:00 // Attribute-based condition user.department resource.department // Owner-based condition user.id resource.owner_id // Multi-condition user.department finance resource.type invoice resource.amount 10000两份设计文档均强调类型安全使用枚举常量RoleAdmin、ActionRead、ResourceInvoice替代字符串字面量将拼写错误从运行时提前到编译期。两种实现路线的本质差异总结如下维度当前实现集合查找PRD 动态方案 / Casbin 方案角色定义静态 JSON 文件数据库表 运行时管理条件表达式无纯 RBACcondition_expression/ Casbin matcher 求值ABAC角色继承无parent_role_id层级 环形依赖防护角色过期无expires_at字段支持临时授权审计拒绝日志全量角色/权限变更审计 SIEM 集成性能O(1) 集合查找缓存Redis 条件求值引擎优化目标 50ms从仓库现状出发向 PRD 蓝图演进的最小路径是先迁移roles.json至数据库对应dynamic_roles/dynamic_permissions/role_permissions三表再为Role/Entity/Action枚举补充条件表达式字段最后引入条件求值引擎与 Redis 缓存——每一步都可向后兼容与 PRD 的 Phase 1→4 节奏一致。十一、附录术语表动态角色Dynamic Role用户自定义、携带自定义权限的角色权限模板Permission Template面向常见用例预置的权限集合角色继承Role Inheritance子角色自动继承父角色的权限条件访问Conditional Access依赖运行时属性的权限判定策略表达式Policy Expression以领域特定语言DSL书写的条件逻辑。延伸阅读PRD 原文docs/prds/dynamic-rbac-abac-system.md技术分解任务级实施路线图docs/prds/dynamic-rbac-technical-breakdown.mdCasbin 两级授权方案docs/prds/rbac-abac-implementation.md已落地的 RBAC 系统设计文档docs/prds/rbac/flexprice_rbac_system.md核心实现internal/rbac/rbac.go、internal/rest/middleware/permission.go、internal/types/rbac.go角色定义文件internal/config/rbac/roles.json赞分享【免费下载链接】flexpriceUsage-based pricing and billing for developers Cloud or self-hosted ⚙️ No-code UI Realtime usage metering Credits top-ups Control feature access项目地址https://gitcode.com/gh_mirrors/fl/flexprice点击查看免费下载相关推荐FlexPrice 信用票据Credit Note系统设计与实现指南从 PRD 到源码级落地FlexPrice 信用票据Credit Note系统设计与实现指南从 PRD 到源码级落地 导读 本文以 FlexPrice 仓库中的产品需求文档 crFlexprice 工作流编排系统实战指南从 PRD 到 Temporal 落地实现Flexprice 工作流编排系统实战指南从 PRD 到 Temporal 落地实现 Flexprice 的工作流编排系统Workflow OrchestrFlexPrice 客户地址与元数据字段扩展从 PRD 设计到源码落地的完整实现指南FlexPrice 客户地址与元数据字段扩展从 PRD 设计到源码落地的完整实现指南 本文围绕 FlexPrice 的 PRD《Customer Addres上一篇JeecgBoot项目中乾坤集成子应用显示问题的分析与解决下一篇Unibest项目中的代码格式化方案演进与最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/9 1:26:01 · 阅读 1.2k Flexprice 动态 RBAC/ABAC 访问控制系统：从 PRD 设计到 Go 源码落地实践
【免费下载链接】flexpriceUsage-based pricing and billing for developers Cloud or self-hosted ⚙️ No-code UI Realtime usage metering Credits top-ups Control feature access项目地址https://gitcode.com/gh_mirrors/fl/flexprice点击查看免费下载本文以 Flexprice 开源仓库中的《Dynamic RBAC/ABAC System - Product Requirements Document》为骨架系统讲解面向企业多租户场景的动态角色权限体系从动态角色引擎、权限模板、条件访问策略、角色继承等核心设计到数据库 Schema、REST API 规格与分阶段实施计划同时对照仓库当前已落地的静态 RBAC 实现JSON 角色定义 集合查找 Gin 中间件说明一条从静态角色到动态权限的清晰演进路径。读完本文你将掌握 Flexprice 权限系统的完整设计蓝图、当前源码级的实现细节以及未来扩展为动态 RBAC/ABAC 的具体改造方向。一、背景静态角色为何无法满足企业需求Flexprice 是一个面向开发者的用量计费与定价usage-based pricing and billing平台天然需要服务多租户场景。早期系统的访问控制依赖固定角色user、manager、admin、superadmin这种静态角色结构在企业客户面前暴露出五类核心问题静态角色结构僵化固定角色无法映射企业多样化的组织架构与岗位职责灵活性不足难以适配不同企业独特的工作流与授权模式客户锁定风险企业客户如文档中提到的 XYZ Company要求自定义访问模式否则难以迁入合规缺口静态角色可能与监管要求如职责分离、最小权限不一致运维负担每次定制需求都要走人工工单增加支持成本。PRD 中给出的一组关键业务目标因此确立客户留存让企业客户完全掌控自己的访问管理市场差异化提供接近 AWS IAM 级别的角色与权限管理灵活性可扩展性每个租户支持无限自定义角色与细粒度权限合规性满足企业安全与审计要求。二、解决方案总览六大核心组件与关键特性PRD 提出的动态 RBAC/ABAC 方案由以下六类核心组件构成组件职责动态角色管理引擎Dynamic Role Management Engine角色 CRUD、层级解析与生命周期管理权限模板系统Permission Template System预置常用角色模板支持定制与版本化策略构建器Policy Builder Interface面向管理员的策略配置界面审计与合规模块Audit and Compliance Module记录全部角色/权限变更支撑合规报告多租户角色隔离Multi-tenant Role Isolation角色与权限按租户隔离API 优先架构API-First Architecture全部能力以 REST API 形式开放关键特性覆盖自定义角色创建可定义无限数量的自定义角色带描述性名称细粒度权限为资源与动作精确分配权限角色继承支持角色层级与权限继承条件访问支持基于时间、地点、属性的条件控制批量操作规模化管理角色与权限集成 API与既有系统无缝集成。三、详细需求规格FR / NFR3.1 功能需求FR-001动态角色创建优先级 Critical管理员可创建带特定权限的自定义角色验收标准包括使用自定义名称与描述创建角色单个角色可挂多个权限可设置角色过期时间可定义角色继承模式租户内角色名称唯一性校验。FR-002权限模板系统优先级 High为常见场景提供预置权限模板验收标准包括提供 Project Manager、Developer、Auditor 等常见角色模板允许对模板进行定制支持模板版本化支持跨租户共享模板需审批。FR-003条件访问策略优先级 High支持复杂访问条件验收标准包括基于时间的访问工作时间、临时访问基于位置的访问IP 段、地理限制基于属性的条件部门、项目分配多因素认证要求。FR-004角色分配管理优先级 Critical动态分配与回收角色验收标准包括批量角色分配/回收定时角色变更敏感角色审批流程角色分配审计轨迹。FR-005权限继承优先级 Medium支持层级角色结构验收标准包括父子角色关系从父角色继承权限子角色具备覆盖能力环形依赖防护。3.2 非功能需求编号维度目标NFR-001性能复杂策略角色评估 50ms角色创建 2s批量 1000 角色分配 30sNFR-002可扩展性每租户 10,000 自定义角色每租户 100,000 用户每分钟处理 1M 授权请求NFR-003安全策略存储加密全部角色/权限变更审计日志最小权限原则防权限提升NFR-004可用性99.9% 可用性 SLA高负载优雅降级自动故障转移四、技术架构设计4.1 动态角色引擎组件结构PRD 给出如下系统组件划分┌─────────────────────────────────────────────────────────────────┐ │ Dynamic Role Engine │ ├─────────────────────────────────────────────────────────────────┤ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Role Manager │ │ Permission Mgr │ │ Policy Engine │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │Template System │ │ Condition Eval │ │ Inheritance Mgr │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ ├─────────────────────────────────────────────────────────────────┤ │ Data Storage Layer │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Role Store │ │ Permission Store│ │ Audit Store │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ └─────────────────────────────────────────────────────────────────┘4.2 API 架构REST APIs: - GET /api/v1/roles - POST /api/v1/roles - PUT /api/v1/roles/{id} - DELETE /api/v1/roles/{id} - POST /api/v1/roles/{id}/permissions - GET /api/v1/permissions/templates - POST /api/v1/users/{id}/roles - GET /api/v1/audit/roles4.3 数据库 Schema动态角色表以(tenant_id, name)唯一约束保证租户内角色名唯一parent_role_id自引用实现角色层级is_system_role区分系统内置角色与用户自定义角色expires_at支持角色过期。CREATE TABLE dynamic_roles ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, name VARCHAR(255) NOT NULL, description TEXT, parent_role_id UUID REFERENCES dynamic_roles(id), is_system_role BOOLEAN DEFAULT FALSE, expires_at TIMESTAMP, created_by UUID NOT NULL, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW(), UNIQUE(tenant_id, name) );权限表resource action组成权限主体condition_expression存放 ABAC 条件表达式DSL 字符串is_system_permission标记系统预置权限。CREATE TABLE dynamic_permissions ( id UUID PRIMARY KEY, resource VARCHAR(100) NOT NULL, action VARCHAR(100) NOT NULL, condition_expression TEXT, description TEXT, is_system_permission BOOLEAN DEFAULT FALSE, created_at TIMESTAMP DEFAULT NOW() );角色-权限关联表复合主键(role_id, permission_id)granted_by记录授权人用于审计expires_at支持权限级临时授权。CREATE TABLE role_permissions ( role_id UUID REFERENCES dynamic_roles(id), permission_id UUID REFERENCES dynamic_permissions(id), granted_by UUID NOT NULL, granted_at TIMESTAMP DEFAULT NOW(), expires_at TIMESTAMP, PRIMARY KEY (role_id, permission_id) );配套技术分解文档docs/prds/dynamic-rbac-technical-breakdown.md还补充了user_roles分配表、role_hierarchy继承表、permission_templates模板表与audit_logs审计表的设计并给出了对应的 Go 领域模型与仓储层接口草案。五、用户故事Epic 划分Epic 1角色管理Story 1.1 创建自定义角色租户管理员创建名为 Project Lead 的角色赋予项目管理相关权限且不包含完整管理员权限角色创建后出现在用户分配下拉框中操作被记录审计。Story 1.2 角色模板管理员可浏览预置模板、在创建前定制模板、查看模板描述与所含权限并可保存定制后的模板复用。Epic 2权限管理Story 2.1 细粒度权限创建invoice.read.own权限实现用户只能查看自己创建的发票。Story 2.2 条件权限创建基于时间的权限使临时承包商只在合同期内可访问。Epic 3用户分配Story 3.1 单点分配将 Project Lead 角色分配给指定用户。Story 3.2 批量分配将 Developer 角色批量分配给整个工程团队成员。六、API 规格示例6.1 创建自定义角色POST /api/v1/roles Content-Type: application/json { name: Project Lead, description: Manages specific projects with limited admin access, parent_role_id: null, permissions: [ { resource: project, action: read, condition: resource.assigned_users.contains(user.id) }, { resource: project, action: update, condition: resource.lead_user_id user.id } ], expires_at: null }其中condition字段即 ABAC 策略表达式resource.assigned_users.contains(user.id)表示仅当资源分配给该用户时才可读。6.2 分配角色给用户POST /api/v1/users/{user_id}/roles Content-Type: application/json { role_id: 550e8400-e29b-41d4-a716-446655440000, assigned_by: admin_user_id, expires_at: 2024-12-31T23:59:59Z, reason: Promoted to project lead for Q4 projects }6.3 权限检查授权决策POST /api/v1/auth/check Content-Type: application/json { user_id: user123, resource: project, action: update, resource_attributes: { project_id: proj456, lead_user_id: user123, assigned_users: [user123, user789] } }授权引擎将结合user_id的角色集合与resource_attributes中的资源属性对权限上的condition_expression求值后给出 allow/deny 决策。七、分阶段实施计划16 周路线图Phase 1基础建设第 1-4 周—— 交付数据库 Schema、角色 CRUD、权限管理系统与核心单元测试技术任务包括创建数据库迁移、实现角色管理服务、构建权限评估引擎、创建角色管理 API 端点。Phase 2高级特性第 5-8 周—— 交付角色继承系统、条件访问策略、角色模板与批量操作技术任务包括实现层级解析、构建条件求值引擎、创建模板管理系统、增加批量导入导出。Phase 3集成与 UI第 9-12 周—— 交付角色管理后台、API 文档、静态角色迁移工具与性能优化技术任务包括构建 React 管理界面、编写完整 API 文档、实现角色迁移工具、加入缓存与优化。Phase 4生产就绪第 13-16 周—— 交付安全审计、性能测试、文档与培训、监控告警技术任务包括安全评审、真实数据压测、用户指南与 API 文档、监控看板。配套的技术分解文档进一步将上述阶段拆解为 20 周、5 个 Epic 的可执行任务清单含估算工时、优先级、依赖关系并给出统一测试策略单元测试覆盖率目标 90%、集成/端到端/性能/安全测试矩阵与部署策略Beta → 分阶段灰度 → 全量生产配套 Feature Flag 回滚、可逆迁移、API 版本化。八、成功指标、风险评估与合规要求客户成功指标30 天内 80% 企业客户创建自定义角色角色管理功能满意度 95%角色相关支持工单下降 50%客户 2 小时内完成角色体系搭建。技术成功指标授权响应 50ms角色评估服务 99.9% 可用每租户 10,000 角色无性能退化零未授权访问事件。风险评估级别风险缓解措施高通过角色继承实现权限提升自动化安全测试 人工安全评审高复杂角色评估拖慢系统缓存策略 性能监控中静态到动态角色迁移复杂渐进式迁移工具 回滚能力中非技术管理员难以操作用户测试 简化界面低客户需要培训文档、Webinar、客户成功支持合规与安全角色与权限数据静态加密全部管理操作审计日志合规数据留存策略GDPR 合规数据处理管理功能强制多因素认证最小权限原则定期访问评审与认证自动异常检测审计轨迹支持合规报告与 SIEM 集成。依赖清单内部依赖认证服务、租户管理、通知服务、审计日志系统外部依赖 Casbin 策略引擎、PostgreSQL、Redis 缓存与监控工具。九、仓库源码现状已落地的静态 RBAC 实现PRD 描述的是动态系统的目标蓝图。对照当前开源仓库Flexprice 已落地了一套以 JSON 角色定义 集合查找为核心的静态 RBAC 实现两者的对应关系是理解演进路径的关键。9.1 角色定义文件internal/config/rbac/roles.json当前角色全部定义在 internal/config/rbac/roles.json 中每个角色包含name、description与permissions三部分{ super_admin: { name: Super Admin, description: Provides unrestricted access to all resources, operations, and administrative settings., permissions: { *: [*] } }, all_reader: { name: All Reader, description: Provides read-only access to all resources and operations., permissions: { *: [read] } }, all_writer: { name: All Writer, description: Provides read and write access to all resources and operations, excluding user, role, and administrative management., permissions: { *: [read, write] } }, event_ingestor: { name: Event Ingestor, description: Provides write-only access to event ingestion. Intended for services that only submit events., permissions: { event: [write] } }, event_reader: { name: Event Reader, description: Provides read-only access to events. Intended for services that only consume or inspect events., permissions: { event: [read] } } }注意其中的*通配符*: [*]表示对所有实体、所有动作授权这是 super_admin 的实现方式*: [read]则是全局只读。PRD 中关于每个租户支持无限自定义角色的设想在现阶段通过新增 JSON 条目即可实现——无需修改任何代码。9.2 核心服务internal/rbac/rbac.gointernal/rbac/rbac.go 实现了服务核心。其设计理念是热路径集合查找 冷路径元数据RBACService.permissionsmap[string]map[string]map[string]bool三层嵌套 map角色 → 实体 → 动作启动时从 JSON 一次性构建权限检查为 O(1) 查找RBACService.roles完整角色定义含 name/description仅供 API 响应使用权限检查路径从不触碰元数据保证零开销。关键方法// HasPermission checks if any of the users roles grant permission // Complexity: O(roles) with O(1) lookups ~3 operations for typical use func (s *RBACService) HasPermission(roles []string, entity string, action string) bool { for _, role : range roles { permissions : s.permissions[role] if permissions nil { continue } if permissions[*] ! nil (permissions[*][*] || permissions[*][action]) { return true } if permissions[entity] ! nil (permissions[entity][*] || permissions[entity][action]) { return true } } return false }HasPermission支持两层通配符语义实体通配符*授予全部实体访问权动作通配符*授予该实体上的全部动作。这与 PRD 中策略评估 50ms的性能目标相呼应——实际实现将复杂度压到了常数级。服务还提供三个安全关键方法ValidateRoles(userType, roles)校验角色存在、角色可被该用户类型分配并禁止 super_admin 与其他角色混用CanGrantRoles(callerRoles, requestedRoles)防止权限提升——调用者只能授予自身已持有的权限按权限逐一比对而非按角色名比对例如 writer 无法铸造写权限超出自身的角色只有 super_admin 能创建另一个 super_adminListRoles(filter)支持按用户类型过滤角色服务于角色选择器与权限 UI。9.3 类型系统internal/types/rbac.go 与 context.gointernal/types/rbac.go 定义了角色、用户类型、实体、动作的强类型枚举角色Rolesuper_admin、all_reader、all_writer、event_ingestor、event_reader用户类型UserType区分人user与服务账号service_accountAllowedRoles()定义了每种类型可分配的角色集合——人可持有 super_admin/all_reader/all_writer服务账号可持有 super_admin/all_reader/event_ingestor/event_reader实体Entity覆盖 event、meter、customer、plan、subscription、invoice、wallet、feature、entitlement、payment、webhook、oauth、workflow、analytics 等 30 业务资源动作Action当前抽象为read与write两个动作。internal/types/context.go 实现了上下文传递认证中间件将角色数组写入请求 contextCtxRoles键GetRoles(ctx)读取。无角色空数组即无任何授权所有权限检查失败关闭fail-closed——这与 PRD 中最小权限原则一致。9.4 强制层internal/rest/middleware/permission.gointernal/rest/middleware/permission.go 中的RequirePermission(entity, action, opts...)是路由级显式授权中间件执行顺序按问题优先级排列租户暂停检查写操作在租户处于 suspended 状态时直接 403最先检查让用户先听到账户问题SuperAdminOnly 选项通过SuperAdminOnly()选项标记的管理类路由如修改他人角色仅允许持有 super_admin 的用户账号执行服务账号即使密钥带 super_admin 也被拒绝——这是防权限提升的第二道闸门RBAC 检查rbacService.HasPermission(roles, entity, action)失败返回 403 insufficient permissions。该中间件与 PRD 中角色分配审计轨迹的诉求对齐每次拒绝都会输出结构化日志user_id、tenant_id、environment_id、roles、entity、action、path。9.5 对外 APIinternal/api/v1/rbac.gointernal/api/v1/rbac.go 提供了GET /rbac/roles支持user_type查询参数过滤与GET /rbac/roles/{id}两个端点供前端角色下拉框与角色详情页消费。注意当前仓库的路由前缀与 PRD 草案中/api/v1/roles的路径略有出入以源码中的实际路由/rbac/roles为准。十、从静态到动态演进路径与两种方案对比仓库中同时存在两份推进动态化的设计文档docs/prds/rbac-abac-implementation.md 与 docs/prds/dynamic-rbac-technical-breakdown.md。前者给出了基于Casbin 的两级授权架构方案Level 1Handler 级粗粒度—— 保护 HTTP 路由模型为[role, endpoint, method]例如仅 admin 可POST /usersHandler 级不做租户判断静态角色即可满足评估更快。Level 2Service 级细粒度—— 保护业务操作模型为[role, resource, action, condition]通过r.attrs携带资源属性进行 ABAC 求值。租户隔离通过强制条件r.attrs.entity_tenant_id r.attrs.user_tenant_id实现跨租户访问仅限 superadmin条件为true。其 Casbin 服务级模型配置abac_service.conf如下[request_definition] r sub, obj, act, attrs [policy_definition] p sub, obj, act, condition [role_definition] g _, _ [policy_effect] e some(where (p.eft allow)) [matchers] m g(r.sub, p.sub) r.obj p.obj r.act p.act eval(p.condition)ABAC 条件示例来自该文档// Time-based condition current_time 09:00 current_time 17:00 // Attribute-based condition user.department resource.department // Owner-based condition user.id resource.owner_id // Multi-condition user.department finance resource.type invoice resource.amount 10000两份设计文档均强调类型安全使用枚举常量RoleAdmin、ActionRead、ResourceInvoice替代字符串字面量将拼写错误从运行时提前到编译期。两种实现路线的本质差异总结如下维度当前实现集合查找PRD 动态方案 / Casbin 方案角色定义静态 JSON 文件数据库表 运行时管理条件表达式无纯 RBACcondition_expression/ Casbin matcher 求值ABAC角色继承无parent_role_id层级 环形依赖防护角色过期无expires_at字段支持临时授权审计拒绝日志全量角色/权限变更审计 SIEM 集成性能O(1) 集合查找缓存Redis 条件求值引擎优化目标 50ms从仓库现状出发向 PRD 蓝图演进的最小路径是先迁移roles.json至数据库对应dynamic_roles/dynamic_permissions/role_permissions三表再为Role/Entity/Action枚举补充条件表达式字段最后引入条件求值引擎与 Redis 缓存——每一步都可向后兼容与 PRD 的 Phase 1→4 节奏一致。十一、附录术语表动态角色Dynamic Role用户自定义、携带自定义权限的角色权限模板Permission Template面向常见用例预置的权限集合角色继承Role Inheritance子角色自动继承父角色的权限条件访问Conditional Access依赖运行时属性的权限判定策略表达式Policy Expression以领域特定语言DSL书写的条件逻辑。延伸阅读PRD 原文docs/prds/dynamic-rbac-abac-system.md技术分解任务级实施路线图docs/prds/dynamic-rbac-technical-breakdown.mdCasbin 两级授权方案docs/prds/rbac-abac-implementation.md已落地的 RBAC 系统设计文档docs/prds/rbac/flexprice_rbac_system.md核心实现internal/rbac/rbac.go、internal/rest/middleware/permission.go、internal/types/rbac.go角色定义文件internal/config/rbac/roles.json赞分享【免费下载链接】flexpriceUsage-based pricing and billing for developers Cloud or self-hosted ⚙️ No-code UI Realtime usage metering Credits top-ups Control feature access项目地址https://gitcode.com/gh_mirrors/fl/flexprice点击查看免费下载相关推荐FlexPrice 信用票据Credit Note系统设计与实现指南从 PRD 到源码级落地FlexPrice 信用票据Credit Note系统设计与实现指南从 PRD 到源码级落地 导读 本文以 FlexPrice 仓库中的产品需求文档 crFlexprice 工作流编排系统实战指南从 PRD 到 Temporal 落地实现Flexprice 工作流编排系统实战指南从 PRD 到 Temporal 落地实现 Flexprice 的工作流编排系统Workflow OrchestrFlexPrice 客户地址与元数据字段扩展从 PRD 设计到源码落地的完整实现指南FlexPrice 客户地址与元数据字段扩展从 PRD 设计到源码落地的完整实现指南 本文围绕 FlexPrice 的 PRD《Customer Addres上一篇JeecgBoot项目中乾坤集成子应用显示问题的分析与解决下一篇Unibest项目中的代码格式化方案演进与最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考