java - ¿Cuándo pasar de la seguridad administrada por el contenedor a alternativas como Apache Shiro, Spring Security?

jsf jaas

Question

Estoy tratando de asegurar mi aplicación que está construida utilizando JSF2.0.

Estoy confundido acerca de cuándo las personas optan por alternativas de seguridad como Shiro, Spring Security o esapi de owasp, dejando atrás la seguridad administrada por contenedores. Habiendo visto algunas de las preguntas relacionadas en Stack Overflow, donde 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 han recomendado encarecidamente usar Apache Shiro. Soy un principiante en cuanto a los problemas de seguridad y no tengo idea de cuáles pueden ser los problemas relevantes y cómo tratarlos. 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 su cuenta.

En cuanto a los requisitos de mi 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 según sus roles.

En ese caso, ¿qué crees que podría ser una buena opción para mí?

Personalmente, me han convencido de optar por Shiro, ya que es fácil de usar y se encarga de la mayoría de las cosas para el principiante.

Answer 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 un poco para el sistema de permisos / grupo / usuario / entidad. Planeo hacer la autorización en el nivel ''EntityManager / Entity'', el nivel de servicio y los niveles de Web / API. "Cierra la puerta, pero guarda tus joyas en una caja fuerte de 3 toneladas en la habitación de atrás". Mucho de la última mitad que Shiro maneja MUCHO mejor. Pero no me siento tan cómodo tratando de integrar openid4j / openauth4j en Shiro.

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

PD: Spring también trae muchas otras cosas a la placa, como la integración con JSF, por lo que tiene mucho atractivo.

Answer 2

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

• Es común que un servidor de aplicaciones ofrezca algunos servicios además de JAAS, como el inicio de sesión único, los módulos de inicio de sesión integrados, etc., por lo que a veces, cuando la granularidad de permisos no es un requisito, debe optar por JAAS.

• La última vez que lo comprobé, Shiro tampoco era compatible con la autenticación ssl mutua (usando certificados digitales), pero probablemente no estarías usando eso ...

• Si utiliza Shiro, su aplicación probablemente será más portátil entre los 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.

En general, según los requisitos que especificó:

• Usando un Servidor de Aplicaciones (GlassFish, JBoss): JAAS (ootb authc / authz, módulos de inicio de sesión integrados)
  
• Usando un contenedor Servlet (Jetty / Tomcat): Shiro (más fácil de configurar y usar)

Espero eso ayude :)

Answer 3

No sé exactamente nada acerca de Apache Shiro, excepto lo siguiente, pero lo que ha citado proviene prácticamente literalmente de su página web , que contiene varias declaraciones erróneas como "JAAS] requiere definiciones estáticas que solo los programadores podrían cambiar", y "JAAS es demasiado vinculado a las preocupaciones de nivel de máquina virtual '', y la implicación de que JAAS no tiene que ver con usuarios y roles, lo cual es simplemente falso. Me gustaría mucho convencimiento para alejarse de la seguridad administrada por contenedor. Es parte de la Especificación de Servlet, por lo que tiene que ser soportado por cualquier contenedor; está bien entendido Es soportado por clases JDK sin terceros; ... Y funciona para mi ;-)