Shiro vs. SpringSecurity [cerrado]

Actualmente estoy evaluando los marcos de seguridad basados ​​en Java, soy un usuario de Spring 3.0, por lo que parecía que SpringSecurity sería la opción correcta, pero Spring Security parece sufrir una complejidad excesiva, ciertamente no parece que esté haciendo que la seguridad sea más fácil de implementar, Shiro parece ser mucho más coherente y más fácil de entender. Estoy buscando listas de pros y contras entre estos dos marcos.

También estoy de acuerdo en que Spring Security se siente demasiado complicado (para mí). Claro, han hecho cosas para reducir la complejidad, como crear espacios de nombres XML personalizados para reducir la cantidad de configuración XML, pero para mí, estos no abordan mi problema fundamental personal con Spring Security: sus nombres y conceptos a menudo son confusos en general para yo. Es difícil simplemente "entenderlo".

Sin embargo, en el momento en que comienzas a usar Shiro, simplemente lo 'entiendes'. Lo que era difícil de entender en el mundo de la seguridad es mucho más fácil de entender. Las cosas que son insoportablemente difíciles de usar en el JDK (por ejemplo, Ciphers) se simplifican a un nivel que no solo es soportable, sino que a menudo es un placer usarlo.

Por ejemplo, ¿cómo hash + salt una contraseña y codificar en base64 en Java o Spring Security? Tampoco son tan simples e intuitivos como la solución de Shiro:

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

No hay necesidad de códecs comunes ni nada más. Solo el frasco de Shiro.

Ahora con respecto a los entornos de Spring, la mayoría de los desarrolladores de Shiro usan Spring como su entorno de aplicación principal. Eso significa que la integración de Shiro's Spring es excelente y todo funciona excepcionalmente bien. Puede estar seguro de que si está escribiendo una aplicación Spring, tendrá una experiencia de seguridad completa.

Por ejemplo, considere el ejemplo de configuración Spring XML en otra publicación de este hilo. Así es como harías (esencialmente) lo mismo en 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>

Aunque un poco más detallado que el otro ejemplo de Spring, es más fácil leer IMO.

¡También encontrará que usar las definiciones de cadena de filtro de Shiro es probablemente la forma más fácil de definir cadenas de filtro generales y reglas de seguridad basadas en la web! Mucho mejor que definirlos en web.xml.

Finalmente, Shiro también ofrece una 'capacidad de conexión' extrema. Verá que puede configurar y / o reemplazar casi cualquier cosa debido a la arquitectura POJO / inyección amigable de Shiro. Shiro predetermina casi todo a valores predeterminados razonables y puede anular o configurar solo lo que necesita.

Al final del día, creo que elegir cualquiera de estos dos es más sobre su modelo mental: ¿cuál de los dos tiene más sentido y es más intuitivo para usted? Para algunos será Shiro, para otros será Spring Security. Shiro funciona muy bien en entornos de primavera, por lo que diría que elegir en función de cuál de los dos disfrutas más y tiene más sentido para ti.

Para más información sobre la integración de Shiro's Spring: http://shiro.apache.org/spring.html

No tengo experiencia en el uso de Shiro, y estoy "parcialmente" de acuerdo con lo que dijo sobre Spring Security. Antes de Spring Security 3.x, Spring Security (o Acegi) era muy doloroso de configurar. Una configuración simple basada en roles tomará al menos 140 líneas de configuración XML críptica ... Lo sé porque realmente conté las líneas yo mismo. Fue algo que configuraste una vez y rezas para que funcione para siempre sin que vuelvas a tocar la configuración, porque puedes asegurarte de que has olvidado lo que significa toda la configuración. :)

Con Spring Security 3.x, ha mejorado enormemente. Introduce un securityespacio de nombres que acorta drásticamente la configuración de 140 líneas a ~ 30 líneas. Aquí hay un ejemplo de Spring Security 3.x de uno de mis proyectos: -

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

La belleza de Spring Security 3.x es que es extremadamente configurable, lo que contribuye a uno de los principales inconvenientes: demasiado complicado de entender. La documentación tampoco es fácil de leer porque solo estoy parcialmente familiarizado con algunos de los términos utilizados por Spring Security. Sin embargo, las opciones están ahí si necesita crear su configuración personalizada o controlar qué tan granular desea que sea su seguridad. O bien, puede seguir con las <30 líneas anteriores para realizar una verificación de seguridad basada en roles.

Lo que realmente me gusta de Spring Security es que una vez que se configura, la seguridad se integra perfectamente en el proyecto. Es como si el código real del proyecto no conociera la existencia de la seguridad ... y eso es bueno, porque me permite desconectar o actualizar fácilmente el componente de seguridad en el futuro (por ejemplo: cambiar la autenticación de la base de datos a LDAP / CAS auth).

Había estado usando Spring Security (versión 3.1) durante algunos meses y estaba bastante contento con él. Es realmente potente y tiene algunas características muy buenas, especialmente después de implementar todo a mano como lo hice antes. Sin embargo, como leí en alguna parte, fue algo que configuraste una vez cerca del comienzo del desarrollo de la aplicación, y luego rezas para que siga funcionando hasta el final, porque si tienes que arreglarlo, probablemente haya olvidado la mayoría de las cosas que tenía que parametrizar.

Pero luego apareció un nuevo proyecto, con requisitos de seguridad más complejos. En resumen, tuvimos que implementar algún tipo de SSO personalizado entre un par de aplicaciones web relacionadas.

Sabía exactamente lo que quería lograr en términos de lógica HTTP, cookies, identificadores de sesión y demás, y qué debería suceder en qué orden, pero pasé la mayor parte del día luchando con las API de Spring Security, y todavía no podía entender averiguar exactamente qué clase o interfaz debo implementar o anular, y cómo conectarlos en el contexto. Toda la API se sintió realmente compleja y un poco esotérica a veces. Y aunque el documento es bastante bueno para los casos de uso general e incluso para algunas personalizaciones, no fue lo suficientemente profundo como para cubrir mis necesidades.

Después de leer las respuestas aquí y en otros lugares de la web, tuve la impresión de que Shiro sería más fácil de entender y personalizar según mis necesidades. Así que lo intenté.

Y me alegro de haberlo hecho, porque después de un día de trabajo logré aprender lo suficiente sobre las API, no solo para configurar un sistema básico de autenticación y autorización en mi aplicación web Spring sin problemas, sino también para implementar el comportamiento personalizado de SSO. buscando. Solo tuve que extender 2 o 3 clases, y todo tomó solo unas 25 líneas de configuración XML en mi contexto de primavera.

Como conclusión, sobre la facilidad de uso y los aspectos de la curva de aprendizaje, Shiro es realmente agradable, y creo que probablemente lo seguiré en el futuro, a menos que encuentre algunas características que faltan o algún otro problema (que no tengo hasta aquí).

TL; DR: Ambos son poderosos, pero Shiro es mucho más fácil de aprender.