2011-10-16 12 views
18

Estoy tratando de proteger mi aplicación que está construida usando JSF2.0.¿Cuándo pasar de la seguridad administrada de Container a alternativas como Apache Shiro, Spring Security?

Estoy confundido acerca de cuándo optan las personas por alternativas de seguridad como Shiro, Spring Security o owasp's esapi, dejando atrás la seguridad administrada por contenedores. Después de haber visto algo de related questions en Stack Overflow, me di cuenta de que la seguridad basada en contenedores era más preferida por los desarrolladores de JSF en el pasado. Pero también me recomendaron usar Apache Shiro. Soy novato en cuanto a los problemas de seguridad y no tengo idea de cuáles pueden ser los problemas relevantes & cómo tratar con ellos. Por lo tanto, estoy buscando algo que maneje la mayoría de los problemas de seguridad a través de su configuración predeterminada/por sí misma.

En términos de mis requisitos de aplicación, tengo una aplicación social donde los usuarios con diferentes roles tienen acceso a diferentes conjuntos de páginas y pueden usar diferentes niveles de funcionalidad en esas páginas en función de sus roles.

En ese caso, ¿cuál crees que podría ser una buena opción para mí?

Personalmente he sido convencido de optar por Shiro ya que es fácil de usar y se encarga de la mayoría de las cosas para los novatos.

+4

¿Quién lo recomendó encarecidamente y qué razones dieron? – EJP

+1

razones fueron: "con shiro es bastante fácil configurar la seguridad, shiro se encarga de la mayoría de los problemas a través de su configuración predeterminada, los mecanismos de seguridad existentes de Java como JAAS son demasiado confusos, etc., y es más adecuado para principiantes como yo que no sé mucho sobre cuestiones de seguridad " –

+2

Bueno, suponiendo que todo eso sea cierto, ¿cuál es exactamente tu pregunta? – EJP

Respuesta

4

No sé exactamente nada acerca de Apache Shiro, excepto de la siguiente manera, pero lo que ha citado viene prácticamente textualmente de su Web page, que contiene varios errores como '[JAAS] requiere definiciones estáticas que solo los programadores pueden cambiar', y 'JAAS está muy ligado a preocupaciones de nivel de máquina virtual', y la implicación de que JAAS no se trata de usuarios y roles, lo cual es simplemente falso. Me gustaría convencer mucho para alejarme de la seguridad administrada por contenedores. Es parte de la especificación del servlet, por lo que debe ser compatible con cualquier contenedor; es bien entendido; es compatible con las clases de JDK sin terceros; ... y funciona para mí ;-)

+2

pero * por lo que he oído, * la seguridad administrada por contenedor no cubre todo lo que puede satisfacer la demanda de seguridad de una aplicación web y no es muy fácil para los principiantes (en el dominio de seguridad web) configurarlo? ¡¿Supongo que estas son las limitaciones/desventajas de lo mismo ?! –

+1

@Marcos, eso es, estás adivinando. Comenzaría por definir sus requisitos reales y luego ver qué sistemas pueden soportarlos. Por el momento solo estás reiterando la publicidad. – EJP

+0

puede ser ... pero solo tenía la intención de escuchar la opinión de los expertos sobre esto antes de haber comenzado con algo en particular. –

17

Lo que me gusta de Shiro es que es realmente fácil configurar la seguridad basada en permisos. JAAS se basa principalmente en roles, lo que es una granularidad que, irónicamente, es más útil para las aplicaciones web de los consumidores que para las aplicaciones empresariales (como podemos observar en sus requisitos).

  • Es común para un servidor de aplicaciones para proporcionar algunos servicios en la parte superior de JAAS, como inicio de sesión único, construido en LoginModules, etc, por lo que a veces, cuando el permiso granularidad no es un requisito, hay que ir por JAAS.

  • Que yo sepa Shiro también no admite la autenticación mutua SSL (utilizando certificados digitales), pero probablemente no estaría usando que ...

  • Si utiliza Shiro su aplicación será probablemente más portátil entre servidores de aplicaciones/contenedores de servlets (¡oh, la ironía!), ya que la configuración de seguridad de JavaEE tiende a ser específica del proveedor para la mayoría de las configuraciones no triviales.

Con todo, en base a los requisitos especificados:

  • Usando un AppServer (GlassFish, JBoss): JAAS (OOTB authc/authz, una función de LoginModules)
  • Uso un contenedor de servlets (el embarcadero/Tomcat): Shiro (más fácil de configurar y usar)

espero que ayude :)

1

He decidido que SpringSecurity (SS) será nuestro marco de Autenticación y Autorización. Principalmente porque SS hace OpenID y OAuth. Aunque tendré que personalizarlo para el sistema de permisos/grupo/usuario/entidad bastante. Planeo hacer una autorización en el nivel 'EntityManager/Entity', nivel de servicio y niveles web/API. "Asegure la puerta, pero tenga sus joyas en una caja fuerte de 3 toneladas en la trastienda". Mucho de la última mitad Shiro maneja MUCHO mejor. Pero no me siento tan cómodo tratando de integrar openid4j/openauth4j en Shiro.

Sería REALMENTE agradable seleccionar y elegir las características de ambos, sin ninguna interferencia o inflamación del código. Esa es la mejor opción.

PS, Spring trae muchas otras cosas al plato, también, como la integración con JSF, por lo que tiene un gran atractivo.