Shiro多域名权限如何管？多域名Shiro权限怎么配

伊甸高防高难度主机的傲慢与偏执，在Shiro多域名权限管理面前显得尤为真实，直接回答你的问题：把多域名映射进同一个Shiro应用，通过自定义Filter识别请求域名并动态切换Realm，再配合Redis集中管理Session与权限缓存，这就是兼顾安全与效率的可行解法。

这套方案的核心逻辑并不复杂：Shiro本身不做多域名解析，你需要替它做一次路由，下面从架构拆解到落地方案逐步拆开讲，帮你完整解决Shiro多域名权限管理怎么做、以及如何避免踩坑的问题。

一个应用服务多个域名，为什么Shiro默认搞不定

许多团队把Shiro作为权限框架嵌入Spring Boot项目后，第一个遇到的多域名问题就是：登录状态在a.com生效，切到b.com就失效，原因在于浏览器对Cookie的隔离策略，Shiro维护会话状态时，如果SessionId是存放在Cookie里，那么这个Cookie默认只能绑定一个域名，你从a.com跳到b.com，浏览器根本不会携带a.com的SessionId,Shiro自然不认这个用户。

另一个问题是Realm身份认证的数据源，Shiro的默认设计是一套Realm对应一套用户体系，如果你的多域名平台分别面对代理商、普通用户、内部管理员，这些角色的用户表不同、密码加密方式不同、权限粒度不同，只靠一个Realm去认证要么写满if-else，要么找Shiro官方配置多个Realm但无法根据访问的域名动态选择，这不是Shiro的缺陷，而是你还没有认清多域名环境下的需求本质：权限管理不再以应用为中心，而是以域名（或项目）为中心。

先搭好统一入口：域名与请求的绑定来自Filter

既然要让Shiro认得出当前用户要访问的是哪个“子世界”，最干净的切入点是自定义一个DomainFilter,放到Shiro过滤器链的入口位置。

用过滤器识别域名归属

在你的shiroConfig里，把filterChainDefinitionMap中的指向自定义的DomainFilter。DomainFilter继承OncePerRequestFilter，在doFilterInternal方法里解析request.getServerName()，把这个值塞进ThreadLocal或者Request attribute里，这个步骤的意义在于：后续所有的Realm选择、权限判断、Session标识,都可以从这个上下文里取出当前的域名标识。

这里有一个实操细节需要留意：域名映射关系不要硬编码在代码里，把域名与项目的对应关系放到Nacos配置中心或者数据库，改配置就需要重启应用的时代,在2026年的多域名权限方案里应该彻底终结。

Realm路由策略：让认证知道访问的是谁

拿到当前域名后，Shiro的AuthenticatingRealm支持通过AuthenticationToken传递一个额外的信息，比如你把域名塞进UsernamePasswordToken自定义子类的一个字段，然后在自定义Realm的doGetAuthenticationInfo方法里判断这个字段,决定去查哪张用户表。

public class DynamicRealm extends AuthorizingRealm {
    @Override
    protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) {
        DomainToken domainToken = (DomainToken) token;
        String domain = domainToken.getDomain();
        String username = (String) domainToken.getPrincipal();
        // 根据domain路由到不同的用户服务或用户表
        if ("app.example.com".equals(domain)) {
            // 查app侧用户体系
        } else if ("admin.example.com".equals(domain)) {
            // 查admin侧用户体系
        }
    }
}

行业共识认为，在多域名权限设计方案里，将“域”作为数据范围的关键维度，是避免后续权限膨胀的唯一出路，不要指望用一个“用户ID”打天下，多域名环境下，主体（用户）+ 项目（域名）的二元组，才是权限判断的完整维度。

Session与缓存：多域名安全高效的核心战场

这一块,恰恰是你与高性能方案的差距所在。

共享Session方案：放弃内存Session

在单机部署模式下，原本的DefaultWebSessionManager内存Session能够正常工作，一旦你的应用为了高可用部署了多实例，或者多域名回源到不同的网关节点，Session就必须外置。推荐用Redis作为Session存储，覆盖默认的AbstractSessionDAO。

具体操作路径不复杂，引入Shiro-Redis依赖，配置RedisSessionDAO与RedisCacheManager，把sessionManager和securityManager的sessionMode设为redis，这之后，a.com上认证成功生成一个Session，b.com通过同一个Redis读取到这个Session的会话数据。

但你要明白，只是共享Session还不够。SessionId的传递机制，是多域名登录不掉的最后一环，按照浏览器策略，Cookie是不能跨域共享的，解决办法通常有两种：一是通过URL重写传递SessionId，即a.com认证成功后重定向到b.com并携带JSESSIONID=xxx参数，b.com接收后由后端写入它自己的Cookie域，实现Session的交接；二是如果域名分布在同一个主域下，如user.example.com与shop.example.com，可以把Cookie域设置为.example.com，那么浏览器会自动携带这两个域名下的Cookie，实际项目中选择哪种，看你的子域名的隔离要求强烈建议用方案一，只在线索切换时传递一次，后续靠Redis共享保证会话一致,避免整个主域Cookie暴露在每一个子站点。

权限缓存的粒度控制：按“域名+用户”分区

多域名环境下，不要用全局权限缓存，用户可能在a.com是管理员，在b.com只是普通成员，如果缓存粒度是用户级别的，就会出现b.com的权限数据把a.com的访问权限覆盖掉,这是行业里常见的坑。

改动很小，把你的AuthorizationInfo缓存Key从单纯的用户名改为域名 + ":" + 用户名，这能保证给每个项目下的用户维护一套独立的权限快照，避免跨域权限穿透,安全边界清晰。

多域名细粒度权限模型：从角色到数据范围

权限模型层面,动态的权限点管理才是最考验架构能力的地方。

静态权限与动态权限的区别

很多开发者把权限管理等同于页面按钮的显示隐藏，这对多域名场景远远不够，比如你在多域名运营场景下，需要实现对“不同域名下的订单数据”进行隔离，这属于数据级权限，Shiro的原生Permissions只支持到字符串匹配，如order:view，它并不懂order:view:12345和order:view:67890之间的数据差异。

主流做法是把Shiro的Permission接口实现为DomainDataPermission，包含项目编码和数据范围两个维度，举个实例：app_project:order:view:company_10001，表示app项目下访问公司编号为10001的订单，配合自定义PermissionResolver，在doGetAuthorizationInfo中按当前域名的数据维度拼接权限字符串。

权限规则的动态刷新：不再重启应用

2026年了，不要一改权限就重新打包，在“多域名如何灵活分配权限”的现实诉求下，使用数据库存储权限规则，用Redis做热加载，同时利用Shiro自带的ModularRealmAuthorizer对权限判断解耦,具体做法：

• 维护一张权限规则表，字段包括项目域名、角色、权限点、数据范围
• 缓存Key格式为auth:domain:username，变更后调一次clearCache清掉当前用户的权限缓存即可

多域名环境下几个不得不注意的安全细节

安全与效率并重，意味着不能只图快,该处理的边界也要处理干净。

登录会话固定攻击

多域名跳转过程中，SessionId可能在URL中传递，这是会话固定攻击的高发场景，防范方式很简单：在用户完成登录认证后，立刻调用subject.getSession().stop()，然后重新new Subject().getSession()，让旧Session失效,新Session的标识重新生成。

跨域请求的CORS配置

如果你的多域名架构里涉及前后端分离，部分接口要走跨域请求，相比允许的粗暴配置，合理的做法是使用CorsFilter，只允许已配置的域名白名单，Filter加载顺序务必注意，在Shiro的Filter链中要放在登录校验Filter之前，否则结果是：跨域预检请求到达后台还没有经过CORS放行,Shiro已经先返回了401。

密码策略的多地差异

管理端用户密码复杂度要求较高，客户端用户相对弱一些，不同Realm实现各自的CredentialsMatcher，不必强行共用一套规则，这既能避免过度设计，也照顾了用户侧的实际体验，多域名权限管理咨询的场景，在不少中小企业里都是先跑起来再说，如果把密码策略也绑死,反而推高实施成本。

多域名下的性能优化：避免Shiro权限判断拖慢响应

安全高效中的“高效”，很大程度体现在性能上，多域名平台如果权限数据庞大,每个请求都查库显然不现实。

关键路径上的两级缓存

对权限信息做两级缓存：一级是Redis中的权限缓存，二级是本地内存缓存（Caffeine），在本地缓存中设置较短的过期时间，如3分钟，权限变更后在Redis的标记位更新版本号,本地缓存发现版本号不一致后重新加载。

认证接口限流

多域名平台的登录入口是最容易被拖垮的，在Shiro的FormAuthenticationFilter前后增加限流逻辑，对单个IP和单用户分别记录失败的次数，一定窗口内超过阈值直接拒绝认证，采用Redis的INCR和EXPIRE命令即可，成本极低,效果显著。

Q&A：Shiro多域名权限管理常见疑问

问：Shiro多域名单点登录，Cookie域必须设置成顶级域名吗？

不一定，只要多个域名属于同一个注册域（如a.example.com与b.example.com），就可以把Cookie域设为.example.com来自动携带SessionId，但如果平台域名为example.com与another.com这样完全不同的根域,就必须依靠URL重写这种主动传递Session的方式。

问：实现多域名权限管理用Shiro还是Spring Security更好？

从灵活性角度，Spring Security的OAuth2Client生态天然支持多域名的授权码模式，适合SSO体系，而Shiro的优势在于轻量、上手快，如果项目本身已经使用Shiro，并且多域名数量可控，通过自定义Filter与Realm路由方案完全可以满足需求，框架上没有绝对的优劣,主要看你的团队熟悉哪套技术栈与改造时间成本。

问：能否使用JWT替代Shiro的Session？

JWT适合无状态场景，多域名间可以直接通过Authorization头传递Token，规避了Cookie跨域问题，但JWT无法被动过期，当权限被调整后，已签发的Token依然有效，这在不安全场景下是个隐患，实际操作中，用Shiro管理会话与权限，把JWT作为前端传递的载体，由Shiro在BearerToken中解析出登录身份，两者结合可以做到安全与效率的平衡,但需要在认证阶段处理JWT的刷新策略。

看清本质：多域名权限管理不再只是登录拦截

从根本上说，Shiro多域名权限管理的复杂度来源于多个业务边界在一个应用里的融合，域名即是项目的边界，Shiro本可以做到这件事，只要你把“识别请求属于哪个域”这个逻辑前置，把Realm、Session、权限缓存三个块拆开，分别因域施策,那么整套系统就能安全地高效运转。

把动态的路径交给路由，把共享的状态交给Redis，把细致的权限判断交给定制的Permission实现，剩下的，就是用代码去落实这些边界，这不是框架的灵药，而是工程架构上一点点拆解出来的结果，简洁,且可维护。