做开源项目有时候最难的不是增加一个功能。而是你做到某个阶段以后突然意识到原来的架构已经装不下你真正想做的东西了。AuthX 就经历了这样一个阶段。最开始我们希望它能够解决最常见的用户、角色、菜单、按钮、API 权限问题。但随着功能不断增加我们开始越来越频繁地面对一些问题一个用户拥有多个角色时最终到底拥有哪些权限为什么这个用户能访问这个接口为什么他能看到这条数据而另一个人不能某个字段能不能只允许部分角色查看能不能让用户临时申请一个角色两个冲突角色能不能禁止同时授予权限修改以后怎么知道它到底影响了谁外部系统是否可以复用同一套授权能力Hadoop、HDFS 这类数据基础设施能不能也接入同一个授权体系这些问题已经远远超过了一个简单的后台管理系统。所以我们决定做一件更彻底的事情重新开始。AuthX 正式更名为 GrantForge项目现在正式从AuthX更名为GrantForge这个名字由两个词组成Grant ForgeGrant 是授权。Forge 是锻造。我们希望它表达的是Forge Your Access.权限不应该只是数据库里几张user_role、role_permission表。真正成熟的权限系统需要把身份、资源、角色、策略、数据、审计、授权决策以及外部系统连接起来。这也是 GrantForge 接下来希望解决的问题。因此这次不仅仅是一次 Rename。我们几乎把整个项目重新做了一遍。一、后端重新开始Spring Boot 4.1旧版本后端已经被替换。新的 GrantForge 后端重新基于Spring Boot 4.1构建。这次重构没有简单地把原来的代码搬过去而是重新建立整个项目的工程基础。包括Spring Boot 4.1HibernateLiquibaseOpenAPIRFC 9457 Problem DetailsRequest IDTSID 主键乐观锁多租户数据隔离国际化Prometheus MetricsHealth Probe数据库 Schema 也重新进行了可移植性设计。目前针对PostgreSQLMySQLMariaDBOracleSQL Server进行了兼容处理。数据库升级则统一通过 Liquibase 管理。换句话说我们不再把 GrantForge 当成一个“能跑起来的后台项目”。而是开始按照一个长期维护的基础设施项目去建设它。二、前端也重新做了一遍后端重写以后旧 Console 同样没有继续保留。新的管理端重新使用Vue 3 Tailwind CSS构建。同时移除了浏览器原生控件重新建立了一套统一的主题组件。新的 Console 支持中英文界面并根据当前登录用户真正拥有的权限动态展示页面和操作。这里有一个我们非常在意的原则看不到不代表没有权限后端拒绝才是真的没有权限。所以 GrantForge 的权限控制并不只存在于前端。页面、按钮和 API 都拥有自己的权限定义。服务器启动时会自动注册 API Endpoint 与对应权限Console 也维护自己的 Permission Manifest。CI 会进一步检查API、Console 与权限清单是否一致。这样可以减少非常常见的一类问题前端隐藏了按钮但接口其实谁都能调。三、重新构建 RBACGrantForge 的基础仍然是 RBAC。但是我们希望把 RBAC 做得更加完整。现在系统已经围绕User → Role → Permission建立了完整的授权体系。角色可以授予用户用户组部门职位一个用户最终的 Effective Permission则由所有角色共同计算得到。权限覆盖页面按钮API同时支持角色继承角色之间可以建立继承关系。比如普通员工 ↓ 部门管理员 ↓ 平台管理员上层角色可以继承下层角色已经拥有的能力。这可以明显减少大型组织中的重复授权。四、权限不再停留在「菜单和按钮」这是这次 GrantForge 重构中我个人非常重视的一部分。很多所谓的 RBAC 系统做到最后解决的其实只有这个按钮能不能点。但真实业务里最复杂的问题通常不是按钮。而是点击按钮以后他到底能看到什么数据所以 GrantForge 开始加入真正的数据权限体系。数据行级权限现在角色可以配置数据策略。应用中的实体可以声明自己受到 Data Permission 管理。GrantForge 根据当前用户的权限条件对数据进行过滤。例如销售人员只能查看自己负责的客户部门负责人可以查看自己部门的数据区域管理员region EAST平台管理员ALL最终同一个 APIGET /customers不同用户调用后看到的数据可以完全不同。这也是我们希望实现的Row-Level Security。五、字段级权限有些情况下控制“哪一行能看”仍然不够。例如员工信息{name:张三,phone:138****,salary:30000}普通员工也许可以看到姓名。HR 可以看到手机号。但是工资字段只有特定角色才能查看。GrantForge 因此进一步加入了Field-Level Permission字段策略可以决定VisibleHiddenMaskedRead Only例如salary → Hidden phone → Masked email → Visible而且不仅影响查询结果。对于只读保护字段服务器也会拒绝非法修改。六、告诉你「为什么有这个权限」权限系统发展到一定规模以后会出现一个非常现实的问题这个用户为什么有这个权限比如某个员工突然拥有customer.delete到底来自直接角色用户组部门职位角色继承如果只能看到最终结果排查权限问题会非常痛苦。所以 GrantForge 增加了Effective Permission Explain除了告诉你ALLOW还希望能够解释WHY ALLOW管理员可以查看一个用户最终拥有哪些权限以及这些权限是如何得到的。这对于复杂组织中的权限排查非常重要。七、修改权限之前先看看会发生什么权限属于高风险配置。所以有些修改不能简单地点保存 → 生效 → 出问题再回滚。GrantForge 增加了权限模拟能力。你可以在真正修改之前查看What If?例如如果给 Alice 增加 FinanceAdmin 角色会怎样系统可以模拟 Alice新增哪些权限。失去哪些权限。哪些资源将受到影响。然后管理员再决定是否真正执行。八、临时权限申请现实中的权限并不总是永久的。例如某个开发人员需要临时查看生产环境日志。财务人员月底临时需要高级权限。运维工程师需要临时进入某个系统排查问题。传统系统通常只有一个办法管理员手动加角色 ↓ 使用完成 ↓ 希望管理员还记得删于是 GrantForge 开始支持Role Request用户可以申请角色。审批人审核后可以只授予一段时间。例如ProductionViewer 有效时间 2026-10-05 10:00 ↓ 2026-10-05 18:00时间结束以后权限自动失效。九、职责分离有些角色不能同时拥有企业权限系统中还有一个很重要的问题Separation of Duties职责分离。例如付款申请人和付款审批人理论上不应该是同一个人。GrantForge 因此加入了角色冲突约束。可以定义Role A ✕ Role B禁止同一个账号同时持有两个互斥角色。相比单纯 RBAC这开始更接近真实企业权限治理场景。十、加入 Access Review权限系统运行时间越长权限只会越来越多。员工换部门。岗位变化。项目结束。临时权限忘记回收。最终很容易出现Permission Creep权限膨胀。所以 GrantForge 增加了周期性Access Review管理员可以重新检查谁还拥有这些角色以及这些授权现在是否仍然合理这也是权限治理中非常重要的一部分。十一、登录能力开始完整起来GrantForge 同样重新建设了身份认证体系。除了本地账号现在已经加入OpenID Connect可以通过 OIDC Provider 登录。LDAP可以连接企业 LDAP Directory。Two-Factor Authentication支持基于 Authenticator App 的二步验证。同时 Console Session 改成数据库 Session 管理。管理员可以查看并结束登录 Session。登录历史也会记录到审计系统。十二、Audit Log任何权限平台最终都绕不开审计。GrantForge 会记录权限变化并保持 Audit Log 的追加式存储。管理员可以搜索和导出审计日志。这样以后遇到谁改了这个权限什么时候改的之前是什么这类问题时不需要再去服务器翻日志。十三、GrantForge 不只是给自己用这是整个项目非常重要的一次方向变化。以前 AuthX 更像一套带权限能力的后台管理系统。现在 GrantForge 希望逐渐变成可以为其他应用提供授权能力的基础设施。所以我们开始增加应用集成能力。Spring Boot StarterJava / Spring Boot 应用可以通过 Starter 接入 GrantForge。应用可以询问这个用户能不能执行这个操作例如grantForge.can(user,order,delete);JavaScript Client同时提供 JavaScript Client。Vue 应用可以通过 Directive 控制界面能力。例如buttonv-permissionuser.delete删除用户/buttonOAuth / OpenID Connect应用可以注册 OAuth Client。用户可以通过 GrantForge 登录应用。这样 GrantForge 开始同时承担Authentication Authorization两部分能力。十四、授权决策开始独立出来除了传统 RBACGrantForge 还开始构建更加独立的授权决策能力。应用可以直接询问Alice 能不能读取 Resource X系统返回ALLOW或者DENY同时可以进一步解释为什么。这意味着以后业务系统不一定需要自己实现复杂权限逻辑。授权决策可以逐渐交给 GrantForge。十五、开始进入数据基础设施权限这次更新里还有一个非常重要、但可能不是所有人第一眼都会注意到的方向Service Plugin AgentGrantForge 定义了 Service Type Plugin API。不同的数据基础设施可以通过插件接入。每个 Plugin 运行在自己的 ClassLoader 中。系统负责注册服务保存服务凭据管理 Policy下发 Policy SnapshotAgent 执行授权收集授权决策第一个 Service PluginHDFSGrantForge 已经加入 HDFS Service Type Plugin。同时增加了 Hadoop NameNode Agent。Agent 可以获得签名后的 Policy Snapshot。然后对访问请求执行授权判断。默认策略采用Default Deny也就是说没有明确允许就拒绝。这套设计和普通 Web 后台中的 RBAC 已经有明显区别。它开始尝试解决数据基础设施中的统一权限治理问题。十六、插件化意味着什么我们不希望把所有系统的逻辑全部写死在 GrantForge Core 中。未来不同的数据系统都可以有自己的 Service Plugin。例如理论上可以继续扩展HDFS Hive Kafka Iceberg Object Storage Database ……GrantForge Core 负责Identity Policy Authorization Audit具体服务 Plugin 负责理解Resource Action ServiceAgent 则负责Enforcement这会让整个架构更容易扩展。十七、百万账户规模测试权限系统在数据量很小的时候几乎什么实现都能跑。真正的问题是10 个用户和1,000,000 个用户完全不是同一个问题。因此我们也开始针对百万账户规模对 Authorization 和 List API 进行 Benchmark。同时围绕权限计算做了一些优化Permission CachePrepared CatalogRead-only TransactionIndexed PaginationPostgreSQL Trigram Search权限缓存会一直保留直到它依赖的数据发生变化。目标是尽量避免每一个请求都重新计算整棵权限关系。十八、完整的工程质量体系这次重构还有大量工作其实用户根本看不到。但我认为它们对于一个长期维护的开源项目同样重要。GrantForge 现在在 CI 中加入了大量自动化检查。包括Checkstyle PMD SpotBugs ArchUnit JaCoCo ShellCheck CodeQL Dependency Review Secret Scan CycloneDX SBOM License Check Commit Message Check同时要求每个 Source File 都存在对应 Unit Test File。并对每个模块设置Line Coverage Branch Coverage质量门禁。十九、多数据库测试支持多个数据库写在 README 里很容易。真正困难的是每个版本都保证它真的还能运行。因此 GrantForge 建立了共享的 Multi-Database Test Harness。持久层会针对不同数据库执行测试。包括PostgreSQLMySQLMariaDBOracleSQL ServerLiquibase Changelog 也增加了 CI 检查。避免加入只在某一种数据库中有效的 Column Type。二十、完整的 E2E 测试除了单元测试以外GrantForge 也开始构建完整的 Full Stack Acceptance Test。测试直接针对打包后的 Server 运行。Web 端进一步覆盖ViewRouter GuardAuth StoreBootstrapShared ComponentsToastFormatter这意味着测试对象不再只是某几个核心 Service。而是在逐渐覆盖真正交付给用户的整个系统。二十一、部署方式也完整起来了GrantForge 现在开始提供多种部署方式。包括Docker Docker Compose HelmRelease 也可以通过版本 Tag 自动发布。Maven Artifact 同样加入 Release Pipeline。对于 Java 开发者来说后续可以更加方便地直接集成 GrantForge 的 SDK / Starter而不需要从源码构建。二十二、文档站也重新做了项目文档站重新使用Next.js Tailwind CSS构建。README 也重新整理为英文版和中文版。项目名称、仓库链接、Logo、Brand 等内容都已经开始统一迁移到 GrantForge。对我来说这也是一个比较重要的信号GrantForge 不再只是 AuthX 换了一个名字。我们正在重新定义这个项目到底是什么。为什么要做这么多有人可能会问现在已经有很多IAM RBAC SSO OAuth Policy Engine开源项目。为什么还要继续做 GrantForge这个问题其实我自己也想过很多次。后来我的答案变得越来越简单因为我自己需要这样一套东西。在开发不同产品的时候我反复遇到用户管理再写一次 角色管理再写一次 菜单权限再写一次 按钮权限再写一次 API 权限再写一次 数据权限再写一次 OAuth 再接一次 审计再做一次每一个项目都在重复。而当系统越来越复杂以后又开始需要LDAP OIDC 2FA Field Permission Row Permission Access Review Temporary Grant Policy Explain Audit再往数据平台走还会遇到HDFS Hive Kafka Database Object Storage的授权问题。所以我希望最终能有一个东西应用负责业务GrantForge 负责权限。这就是现在 GrantForge 想走的方向。GrantForge 还远没有完成这次重构做了很多事情。但是我仍然不认为 GrantForge 已经“完成”。恰恰相反。现在可能只是刚刚建立好了真正的地基。接下来还有大量问题值得继续研究。例如更复杂的 Policy Model 更完整的 ABAC Service Plugin Agent Policy Distribution Authorization Performance Multi-Region High Availability 更多数据基础设施集成以及如何让这些复杂能力保持足够简单。这是我认为最难的一件事情。最后从 AuthX 到 GrantForge对我来说并不是一次普通的版本升级。它更像是一次重新开始。我们把旧后端替换掉了。把前端重新做了。把权限模型重新梳理了。把数据权限、字段权限、审计、权限解释、临时授权、职责分离、OIDC、LDAP、2FA、Plugin、Agent、HDFS 等能力一点一点重新搭起来。然后重新思考一个真正可以长期使用的开源权限平台到底应该是什么样子现在我还没有最终答案。但至少 GrantForge 已经开始朝这个方向走了。如果你也正在做SaaS企业后台数据平台微服务权限中心IAM统一认证数据权限或者你也曾经被复杂的 RBAC、数据权限和授权逻辑折磨过。欢迎关注 GrantForge。也欢迎参与项目一起把它继续做下去。GrantForgeForge Your Access.让应用专注业务。把授权交给 GrantForge。