问题
我目前正在评估基于Java的安全框架，我是一个Spring 3.0用户，所以SpringSecurity似乎是正确的选择，但是Spring安全性似乎过于复杂，看起来似乎并没有让安全性更容易实现， Shiro似乎更连贯，更容易理解。我正在寻找这两个框架之间的利弊列表。
#1 热门回答(113 赞)
我也同意Spring Security感觉太复杂了(对我而言)。当然，他们已经做了降低复杂性的工作，比如创建自定义XML命名空间以减少XML配置的数量，但对我来说，这些并不能解决Spring Security的基本问题：它的名称和概念通常会让我感到困惑。 "得到它"很难。
第二个你开始使用Shiro，你只是'得到它'。在安全领域难以理解的是更容易理解。在JDK中使用难以忍受的事情(例如密码)被简化到不仅可以忍受的水平，而且通常是使用的乐趣。
例如，如何在Java或Spring Security中对salt进行哈希密码并对其进行base64编码？与Shiro的解决方案一样简单直观：
ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();
不需要commons-codec或其他任何东西。只是Shiro罐子。
现在关于Spring环境，大多数Shiro开发人员使用Spring作为他们的主要应用程序环境。这意味着Shiro的Spring集成非常棒，而且一切都运行得非常好。你可以放心，如果你正在编写Spring应用程序，你将获得全面的安全体验。
例如，请考虑此线程中另一篇文章中的Spring XML配置示例。以下是你在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>
虽然比其他Spring示例略显冗长，但更容易阅读IMO。
你还会发现使用Shiro的过滤器链定义可能是定义常规过滤器链和基于Web的安全规则的最简单方法！比在web.xml中定义它们要好得多。
最后，Shiro也提供了极端的"可插拔性"。你会发现，由于Shiro的POJO /注入友好架构，你可以配置和/或替换任何东西。 Shiro几乎可以将所有内容默认为默认值，你可以仅覆盖或配置所需内容。
在一天结束时，我认为选择这两者中的任何一个更多是关于你的心理模型 - 两者中哪一个更有意义，对你更直观？对于一些人来说，这将是Shiro，对于其他人来说，它将是Spring Security。 Shiro在Spring环境中运行得很好，所以我想根据你喜欢的两个中的哪一个选择并且对你最有意义。
有关Shiro的Spring集成的更多信息：http://shiro.apache.org/spring.html
#2 热门回答(31 赞)
我没有使用Shiro的经验，我"部分"同意你所说的关于Spring Security的内容。在Spring Security 3.x之前，Spring Security(或Acegi)设置非常痛苦。一个简单的基于角色的配置将需要至少140行神秘的XML配置...我知道这是因为我实际上自己计算了这些行。这是你设置一次的东西，你祈祷它会永远工作而不再触摸配置，因为你可以保证你已经忘记了所有配置的含义。 :)
使用Spring Security 3.x，它有了极大的改进。它引入了securitynamespace，大大缩短了140行到~30行的配置。这是我的一个项目的Spring Security 3.x的一个例子： -
<?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>
Spring Security 3.x的优点在于它具有极强的可配置性，这是其中一个主要缺点：太难理解。文档也不容易阅读，因为我只是部分熟悉Spring Security使用的一些术语。但是，如果你需要创建自定义配置或控制你希望安全性的粒度，则可以使用这些选项。否则，你可以坚持使用上述<30行来执行基于角色的安全检查。
我真正喜欢Spring Security的是，一旦设置安全性就可以无缝地集成到项目中。就好像实际的项目代码不知道安全性的存在......这很好，因为它允许我将来轻松分离或升级安全组件(例如：将数据库auth更改为LDAP / CAS AUTH)。
#3 热门回答(19 赞)
我使用Spring Security(3.1版)已经有几个月了，对它非常满意。它非常强大，并且具有一些非常好的功能，特别是在我像以前一样手工实现所有功能之后！但是，就像我在某个地方读到的那样，你在应用程序开发之初就设置了一些东西，然后祈祷它继续工作直到最后，因为如果你必须去修复它你会可能已经忘记了你必须参数的大部分内容。
但随后出现了一个新项目，其中包含更复杂的安全要求。简而言之，我们必须在几个相关的Web应用程序之间实现某种自定义SSO。
我确切地知道我想要在HTTP逻辑，cookie，会话ID和内容方面实现什么，以及应该以什么顺序发生什么，但是我花了大部分时间来努力使用Spring Security API，但仍然无法想象究竟是什么类或接口我应该实现或覆盖，以及如何在上下文中插入它们。整个API感觉非常复杂，有时甚至有点深奥。虽然doc对于一般用例甚至一些自定义都非常有用，但它并不足以满足我的需求。
在阅读了这里以及网络上其他一些地方的答案后，我得到的印象是，Shiro更容易理解并根据我的需求进行定制。所以我试一试。
我很高兴我做到了，因为经过一天的努力，我设法学习了很多API，不仅在我的Spring webapp中建立了基本的身份验证和授权系统，而且还实现了我自定义的SSO行为。寻找。我只需要扩展2或3个类，在我的spring上下文中，整个过程只需要大约25行XML配置。
因此，作为一个结论，关于易用性和学习曲线方面，Shiro真的非常可爱，我想我将来可能会用它，除非我遇到一些功能缺乏或其他一些问题(我没有至今)。
TL; DR：两者都很强大，但是Shiro更容易学习。