Shiro vs. SpringSecurity [closed]

Answer 1

I had been using Spring Security (version 3.1) for a few months and was quite happy with it. It is really powerful and has some very nice feature, especially after implementing everything by hand as I did before ! It was though, like I read somewhere, sort of something that you set up once near the beginning of the develoepment of the app, and then pray for it to keep working till the end, because if you have to go fix it you'll probably have forgotten most of the stuff you had to parameter.

But then a new project came along, with more complex security requirements. In short, we had to implement some sort of custom SSO between a couple of related webapps.

I knew exactly what I wanted to achieve in terms of HTTP logic, cookies, session id's and stuff, and what should happen in what order, but I spent the better part of a day struggling with the Spring Security APIs, and still could not figure out exactly what class or interface I shoud implement or override, and how to plug them in the context. The whole API felt really complex and a bit esoteric at times. And while the doc is quite good for the general use cases and even some customization, it did not go deep enough to cover my needs.

After reading the answers here and on some other places on the web, I got the impression that Shiro would be easier to understand and customize to my needs. So I gave it a try.

And I am glad I did, because after a day working on it I managed to learn enough about the APIs not only to set up a basic authentication and authorization system in my Spring webapp without trouble, but also to implement the custom SSO behaviour I was looking for. I only had to extend 2 or 3 classes, and the whole thing took only about 25 lines of XML config in my spring context.

So as a conclusion, on the ease of use and learning curve aspects, Shiro is really quite likeable, and I think I will probably go with it in the future, unless I encounter some features lacking or some other problem (which I haven't so far).

TL;DR: Both are powerful, but Shiro is much easier to learn.

Answer 2

I too agree that Spring Security feels too complicated (to me). Sure, they have done things to reduce complexity, like creating custom XML namespaces to reduce the quantity of XML configuration, but for me, these don't address my personal fundamental issue with Spring Security: its names and concepts are often confusing in general to me. It's hard to just 'get it'.

The second you start using Shiro though, you just 'get it'. What was hard to understand in the security world is just that much easier to understand. Things that are unbearably difficult to use in the JDK (e.g. Ciphers) are simplified to a level that is not just bearable, but often a joy to use.

For example, how do you hash+salt a password and base64 encode it in Java or Spring Security? Neither are as simple and intuitive as Shiro's solution:

ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();

No need for commons-codec or anything else. Just the Shiro jar.

Now with regards to Spring environments, most of the Shiro developers use Spring as their primary application environment. That means Shiro's Spring integration is superb and it all works exceptionally well. You can rest assured that if you're writing a Spring app, you'll have a well-rounded security experience.

For example, consider the Spring XML config example in another post in this thread. Here's how you'd do (essentially) the same thing in Shiro:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd>

<bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
    <property name="securityManager" ref="securityManager"/>
    <property name="loginUrl" value="/login.jsp"/>
    <property name="successUrl" value="/home.jsp"/>
    <property name="unauthorizedUrl" value="/unauthorized.jsp"/>
    <property name="filterChainDefinitions">
        <value>
        /secure/** = authc
        /** = anon
        </value>
    </property>
</bean>

<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
    <property name="realm" ref="myRealm"/>
</bean>

<bean id="myRealm" class="...">
    ...
</bean>

Although slightly more verbose than the other Spring example, it is easier to read IMO.

You'll also find using Shiro's filter chain definitions are probably the easiest way to define general filter chains and web-based security rules ever! Much nicer than defining them in web.xml.

Finally, Shiro offers extreme 'pluggability' as well. You'll see that you can configure and/or replace just about anything because of Shiro's POJO/injection-friendly architecture. Shiro defaults almost everything to sane defaults and you can override or configure only what you need.

At the end of the day, I think choosing either of these two is more about your mental model - which of the two make more sense and is more intuitive for you? For some it will be Shiro, for others it will be Spring Security. Shiro works great in Spring environments, so I would say choose based on which of the two you enjoy more and makes the most sense to you.

For more on Shiro's Spring integration: http://shiro.apache.org/spring.html

Answer 3

I don't have experience using Shiro, and I "partly" agree with what you said about Spring Security. Prior to Spring Security 3.x, Spring Security (or Acegi) was very painful to set up. A simple role-based configuration will take at least 140 lines of cryptic XML configuration... I know this because I actually counted the lines myself. It was something where you set up one time, and you pray that it will work forever without you touching the configuration again, because you can assure you have forgotten what all the configuration means. :)

With Spring Security 3.x, it has tremendously improved upon. It introduces security namespace that drastically shorten the configuration from 140 lines to ~30 lines. Here's an example of Spring Security 3.x of one of my projects:-

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:security="http://www.springframework.org/schema/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security.xsd">

    <security:http auto-config="true">
        <security:form-login login-page="/index.do" authentication-failure-url="/index.do?login_error=1" default-target-url="/index.do"
            always-use-default-target="true" />
        <security:logout logout-success-url="/index.do" />
        <security:intercept-url pattern="/secure/**" access="ROLE_ADMIN,ROLE_USER" />
        <security:intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
    </security:http>

    <bean id="customAuthenticationProvider" class="my.project.CustomAuthenticationProviderImpl">
        ...
    </bean>

    <security:authentication-manager>
        <security:authentication-provider ref="customAuthenticationProvider" />
    </security:authentication-manager>

</beans>

The beauty of Spring Security 3.x is it is extremely configurable, which contributes to one of the main cons: too complicated to understand. The documentation isn't easy to read either because I'm only partially familiar with the some of the terms Spring Security used. However, the options are there if you need to create your custom configuration or control how granular you want your security to be. Or else, you can stick with the above < 30 lines to perform a role-based security check.

What I really like about Spring Security is once it is set up the security is integrated into the project seamlessly. It is as if the actual project code doesn't know the existence of the security... and that is good, because it allows me to easily detach or upgrade the security component in the future (ex: change database auth to LDAP/CAS auth).