Skip to content

[Enhancement] Improve Shiro's Spring Support #1576

Description

@bdemers

Search before asking

  • I had searched in the issues and found no similar issues.

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 AuthenticationProvider that 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?

  • Yes I am willing to submit a PR!

Activity

  1. lprimak commented on Jul 8, 2024

    @lprimak
    Contributor

    I think this is a great idea!

  2. added this to the 3.0.0 milestone on Jul 8, 2024
  3. added
    javaPull requests that update Java code
    springSpring and SpringBoot
    on Jul 8, 2024
  4. lprimak commented on Jul 8, 2024

    @lprimak
    Contributor

    Supersedes #1236

    It does not supersede it, the issues are separate

  5. lprimak commented on Jul 9, 2024

    @lprimak
    Contributor

    Does this mean that Shiro/Spring can finally be configured via shiro.ini as well?

  6. bdemers commented on Jul 9, 2024

    @bdemers
    MemberAuthor

    I hadn't thought about that 🤔 Possibly...

  7. SilenceLurker commented on Nov 1, 2024

    @SilenceLurker

    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.

  8. reopened this on Feb 7, 2025
  9. added
    validDisable automation for valid issues
    on Apr 22, 2025
  10. vgaur commented on Nov 23, 2025

    @vgaur

    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.

  11. lprimak commented on Feb 8, 2026

    @lprimak
    Contributor

    @vgaur Would you like to contribute your changes to 3.x branch?

  12. modified the milestones: 3.0.0, Backlog on Apr 12, 2026
  13. celikfatih commented on Sep 14, 2026

    @celikfatih
    Contributor

    Hi @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:

    1. Scope — authentication only, or authorization too?
      Should this first iteration focus purely on authentication (a Shiro Realm delegating through a Spring SecurityAuthenticationProvider), or should it also cover authorization (e.g. an equivalent to @RequiresPermissions/@RequiresRoles via Spring Security's method security / @PreAuthorize)?

    2. 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?

    3. Backward compatibility
      Should this live in a brand-new module (e.g. shiro-spring-security) alongside the existing shiro-spring, or be added to the existing module?

    4. GrantedAuthority ↔ Shiro Permission/Role mapping
      Shiro's permission model (WildcardPermission, e.g. "user:read:123") doesn't map 1:1 onto Spring Security's flatGrantedAuthority strings. For a first pass, I'm thinking of mapping only roles toGrantedAuthority (ROLE_xxx), and leaving permission checks to Shiro's own Subject.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?

    5. New Maven module?
      Related to 3. — would a new module like shiro-spring-boot-security-starter (auto-configuring theAuthenticationProvider bean 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!

  14. lprimak commented on Sep 14, 2026

    @lprimak
    Contributor

    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 there

    Backward 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-security sounds 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 @RequiresPermissions should 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

javaPull requests that update Java codespringSpring and SpringBootvalidDisable automation for valid issues

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions