Shiro vs. SpringSecurity [cerrado]


132

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.

Respuestas:


118

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


He leído todo esto antes de comenzar a usar shiro. Las anotaciones de Shiro parecen sufrir algunos problemas en la primavera. La información sobre cómo resolverlo es muy difícil y hay varias publicaciones en stackoverflow (1 o 2 publicadas por mí) que la mayoría de las veces no encontraron respuestas. Estaba pensando seriamente que debería ir a la seguridad de primavera a pesar de que dijo complicación, con eso estoy seguro de que puedo tener personas que me indiquen la dirección correcta.
sensei negro

@blacksensei ¿resolvió los problemas que mencionó? ¿Seguir con Shiro o cambiarse a Spring Security?
Alexander Suraphel

Hola @AlexanderSuraphel No me mudé a Spring para ese proyecto. Un colega lo está usando activamente. Y planeo probarlo en un proyecto de arranque de primavera. Funciona muy bien para mí. Moveré todos los demás proyectos. Tan simple como eso
sensei negro

Ok, ¡decido probar Shiro para el próximo proyecto!
Eric Wang

32

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).


¿Le gustaría decir algo sobre cuándo es bueno pasar de la seguridad basada en contenedores a alternativas como shiro u otras? Vea una pregunta más centrada aquí: stackoverflow.com/questions/7782720/…
Rajat Gupta

10
He probado tanto el shiro como la seguridad de primavera, y personalmente siento que el shiro es bastante fácil de entender donde la seguridad de primavera se siente compleja. Todavía tengo que descubrir cómo configurar los permisos, que puedo asignar a roles / grupos / usuarios en la seguridad de primavera (creo que ACL puede ser la solución). Con shiro fue bastante fácil. No soy experto en seguridad de primavera o shiro, es solo mi experiencia personal como usuario de ambos.
Sudhir N

@sudhir, ¿has encontrado cuellos de botella en la configurabilidad de Shiro?
Alexander Suraphel el

Funcionó para todos nuestros casos de usuario, creo que es posible adaptarlo para la mayoría de las situaciones. ¿Cuál es tu caso de uso?
Sudhir N

21

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.


Pierre, gracias por el aporte. También necesito sso. No creo que pueda mostrar algunos ejemplos de las clases que tuvo que exponer.
KingAndrew

@ KingAndrew: en pocas palabras, lo que hice fue implementar mi propio AuthorizingRealm, AuthenticationToken y AuthenticationFilter. Y todos los filtros y fontanería necesarios. Pero lo que hago no es "normal", sino que se basa en un token almacenado en la base de datos que es común entre las 2 aplicaciones. Entonces no estoy usando un servidor SSO separado.
Pierre Henry
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.