Apache Shiro（RBAC）入门

1. 一句话简介

Apache Shiro 是一个轻量级、易用的 Java 安全框架，负责认证（Authentication）、授权（Authorization）、会话管理和加密，核心围绕 Subject、SecurityManager、Realm 三个概念。在 demo-rbac-shiro 模块中，通过 shiro-spring-boot-starter（1.4.0）接入 Shiro，并使用 sql/shiro.sql 初始化了一张标准的 RBAC 权限模型表结构（shiro_user、shiro_role、shiro_user_role、shiro_permission、shiro_role_permission 五张表），把"用户 → 角色 → 权限"的多对多关系落到数据库。Shiro 解决问题的核心是：在不侵入业务代码的前提下，用统一的 API 完成"你是谁（登录认证）"与"你能做什么（权限控制）"两件事。

2. 什么时候使用

✅ 适用场景
- 需要用 RBAC（用户-角色-权限）模型做权限控制，且希望表结构清晰、可配置的中小型系统——demo-rbac-shiro 正是按这套五表模型落地的。
- 想快速上手、减少学习成本，团队对 Spring Security 的复杂度没有把握时，Shiro 的出入口少、概念简单，学习曲线明显更低。
- 需要身份认证 + 授权 + 会话 + 加密一套齐全但边界明确的方案，Shiro 默认支持这些能力，配合 salt 盐值、权限表达式（如 permission 字段）即可满足常规需求。
- 非 Spring 环境或对框架耦合敏感的应用，Shiro 可以脱离 Spring 独立运行，也适合一些纯 Java 的工具类项目。
- 基于 spring-boot-starter-web 且想用 Undertow 替代 Tomcat 作为容器的场景（本模块即如此），Shiro 与容器解耦，不影响这类改造。
❌ 不适用 / 需谨慎
- 大型企业级、对安全体系要求极高的分布式微服务场景，Spring Security 与 Spring 生态集成更深入，社区和文档资源更丰富，Shiro 的能力边界显得不够。
- 明确要求原生 OAuth2 / OIDC / 单点登录深度集成的场景，Shiro 本身对 OpenID Connect 等协议支持较弱，任务会转移到拼装方案上。
- 已有复杂的安全扩展诉求（如细粒度方法级注解、多个安全过滤器链、区分布局/配置粒度）时，Shiro 的架构会显得不够灵活。
- 依赖 Spring Security 成熟组件的企业级授权服务器项目，Shiro 缺乏同等的开箱即用组件。
- 若团队倾向于跟随主流技术栈生态（Spring 官方路线），Spring Security 是"更官方"的选择，Shiro 社区活跃度相对偏低。
- 注意 Shiro 的历史版本存在反序列化等安全漏洞，选型或升级时必须关注版本维护情况（本项目用的是较老的 1.4.0）。

3. 常见业务场景

后台管理系统登录认证：管理员登录后台，Shiro 通过自定义 Realm 从数据库校验用户名、密码与盐值，认证通过后建立 Subject 会话，未登录统一重定向或返回未授权响应。这是 Shiro 最常见也最贴合 demo-rbac-shiro 骨架的使用方式。
菜单级 / 接口级权限控制：shiro_permission 表同时支持"页面"（type=1，对应前端路由）和"按钮"（type=2，对应后端接口）两类权限，可用于控制前端菜单显隐、后端接口是否放行，实现前后端一致的权限闭环。
基于 URL 的过滤器链拦截：通过 ShiroFilterChainDefinition 为不同 URL 配置 anon（匿名）、authc（需登录）、perms["xxx"]（需特定权限）等过滤规则，实现请求到达业务逻辑前的统一拦截，业务代码无需感知安全逻辑。
用户-角色-权限多对多的动态授权：角色挂权限、用户挂角色的五表关联结构，可支撑"同一个用户拥有多个角色、多个角色聚合不同权限"的复杂权限分配，适合权限经常变更、需要后台可视化管理权限的组织结构。
会话管理（登录状态保持）：Shiro 自带会话管理能力（结合 HTTP 或独立 SessionManager），可统一处理登录、登出、会话超时，无需在业务代码里手动维护登录态，适合有状态的传统 Web 应用。

4. 同类技术对比

对比维度	Apache Shiro	Spring Security	Sa-Token	JWT（纯方案）
学习曲线	低，概念少（Subject 等）	高，配置复杂	低，API 贴近业务	中，需自行实现全套逻辑
与 Spring 集成	需额外配置	原生深度集成	对 Spring Boot 友好	需手写拦截器/过滤器
功能丰富度	中（认证/授权/会话/加密）	高（含 OAuth2/OIDC 等）	中（偏登录鉴权）	低（仅完成身份凭证）
分布式能力	弱，需借助外部会话	一般，需扩展	强，天然适合分布式/无状态	强，天然无状态
生态/社区	中，较老	强，官方持续维护	中，第三方较活跃	各中间件混合，碎片化
适用规模	中小型单体	企业级、复杂安全体系	中小型+前后端分离	单体或分布式 API

选型建议

中小型单体项目、后台管理系统、想快速落地 RBAC 权限：优先选 Apache Shiro，学习成本低、上手快，demo-rbac-shiro 的"用户-角色-权限"五表模型即可直接复用。
企业级、复杂安全体系、需要原生集成 Spring 生态与各种安全协议：选 Spring Security，功能与生态最完整，但学习成本高，需做好团队投入规划。
前后端分离、微服务、需要无状态且分布式友好的登录鉴权（配合 Redis 单点登录）场景：优先考虑 Sa-Token，其分布式能力和 API 设计更适合现代架构。
纯粹的接口鉴权、仅需一次签发一个 TOKEN、不需要细致权限表达式与多级 RBAC 管理：可选用 JWT 组合方案，但需自行补齐刷新、续期、吊销、会话管理等能力。
一句话：单体重、要快 → Shiro；企业级、要全 → Spring Security；分布式、要无状态 → Sa-Token / JWT 组合。