Repository navigation
[Enhancement] Improve Shiro's Spring Support #1576
Description
Activity
I think this is a great idea!
Reacted by Lenny Primak- addedjavaPull requests that update Java codePull requests that update Java codespringSpring and SpringBootSpring and SpringBoot
on Jul 8, 2024 Supersedes #1236It does not supersede it, the issues are separate
Does this mean that Shiro/Spring can finally be configured via shiro.ini as well?
I hadn't thought about that 🤔 Possibly...
Being compatible with Spring Security and implementing it by creating an AuthenticationProvider is indeed a good idea, but it doesn't seem to address the warning from BeanPostProcessorChecker caused by ShiroFilterFactoryBean in issue #1236.
- addedvalidDisable automation for valid issuesDisable automation for valid issues
on Apr 22, 2025 I have done this in my project , but all I have done is delegated the authentication to shiro using AuthenticationProvider and called the realm methods.
All security context is managed by spring its just a pure authentication delegation.Reacted by Lenny Primak@vgaur Would you like to contribute your changes to 3.x branch?
Reacted by VISHAL GAURAVHi @bdemers @lprimak, I'd like to pick this up. Before diving into an implementation, I'd like to align on scope and a few design decisions, since some of these are hard to change once an API is public:
-
Scope — authentication only, or authorization too?
Should this first iteration focus purely on authentication (a ShiroRealmdelegating through a Spring SecurityAuthenticationProvider), or should it also cover authorization (e.g. an equivalent to@RequiresPermissions/@RequiresRolesvia Spring Security's method security /@PreAuthorize)? -
Session management
Is session integration (Shiro session vs. Spring Security'sSecurityContext/session handling) in scope here, or should that be tracked as a separate issue? -
Backward compatibility
Should this live in a brand-new module (e.g.shiro-spring-security) alongside the existingshiro-spring, or be added to the existing module? -
GrantedAuthority↔ ShiroPermission/Rolemapping
Shiro's permission model (WildcardPermission, e.g."user:read:123") doesn't map 1:1 onto Spring Security's flatGrantedAuthoritystrings. For a first pass, I'm thinking of mapping only roles toGrantedAuthority(ROLE_xxx), and leaving permission checks to Shiro's ownSubject.isPermitted()for now, rather than trying to fully replicate Shiro's permission model as authorities. Does that sound reasonable, or did you have a different mapping strategy in mind from your earlier attempts? -
New Maven module?
Related to 3. — would a new module likeshiro-spring-boot-security-starter(auto-configuring theAuthenticationProviderbean when both Shiro and Spring Security are on the classpath) be the right shape, or would you prefer this differently structured?
Let me know your thoughts!
-
Thank you @celikfatih We can use the help on this one.
Now to answer your questions:
Scope.
One of main points of this ticket is to dramatically simplify integration.
To be honest, I don't think "just authentication" is going to be enough. So it has to be both.Session.
Shiro wraps sessions, so I am not sure. Probably a separate issue, let's deal with it when we get thereBackward compatibility.
I would go with a new module. I am thinking that the new module is going to replace the integration in place now.
Again, I could be wrong, but let's go with that assumption for now.shiro-spring-securitysounds like a good name.PermissionMapping.
Your instinct is right Let's do roles for now, and leave permissions for later.Couple of points:
- I would love for this all to be configurable via shiro.ini
- Annotation processing is a big question, as who gets to handle that. Is there a Spring way of easily register annotations? Keep current method? This would relates to permissions. Maybe
@RequiresPermissionsshould be enough, if all the above works out - Simplicity should be front-of-mind. Spring security is complex, and this would not be complete if it's even more complicated to use. My ultimate goal would be making it simpler than Spring security alone (much simpler really)
Search before asking
Enhancement Request
I think, it would be better for Shiro's Spring support to integrate with Spring Security (e.g. Spring Sec, delegate to Shiro), instead of as a replacement This would reduce a lot of code, footprint, and complexity of the integration.
Describe the solution you'd like
Create a Spring Security
AuthenticationProviderthat delegates to Shiro.I've hacked on this a couple of times but I ran into a few minor issues each time, and then ran out of time to continue.
I'd love to hear other thoughts on this
Are you willing to submit PR?