Shiro vs. SpringSecurity [closed]
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
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).