spring-security - integrar - spring security tutorial español pdf

Entender la autenticación en un servidor de aplicaciones Java

Question

Actualmente estoy trabajando en un proyecto que se ejecuta en JBoss AS 7 y que requiere autenticación de una variedad de fuentes. Estoy tratando de comprender los diversos componentes que se combinan para proporcionar autenticación.

Tengo algunas suposiciones / suposiciones sobre cómo todo esto encaja, pero necesito asegurarme de que mi comprensión sea correcta. A continuación, lo que entiendo es el proceso de autenticación de JBoss AS7.

Usted tiene un dominio de seguridad que define cómo se autentican los usuarios. Este dominio queda expuesto a su aplicación para asegurar una parte o la totalidad. En AS7, esto se configura en el elemento <subsystem xmlns = "urn: jboss: domain: security: 1.0">.

El reino se puede configurar para autenticar a los usuarios contra una variedad de orígenes mediante el uso de módulos de inicio de sesión, como una base de datos, LDAP, un archivo local u otra cosa. Se pueden definir múltiples módulos de inicio de sesión, y puede especificar que una combinación de módulos de inicio de sesión debe "tener éxito" para que se produzca la autenticación.

El nombre de usuario y las contraseñas reales se transfieren a través de un mecanismo definido en el archivo web.xml (para servlets), definido en el elemento <login-config>.

Suponiendo que el proceso anterior es correcto (y puede que no):

• ¿Todo este proceso de autenticación cae bajo una especificación como JAAS, o JAAS es solo una pequeña parte o parte de este procedimiento?
• ¿Funcionan todos los tipos de <auth-methods> (es decir, BASIC, DIGEST y FORM) con todo tipo de módulos de inicio de sesión? Esta página parecería sugerir que no, pero no he visto ninguna documentación clara que coincida con las opciones <login-module> options <login-config>.
• El nombre de usuario y el flujo de contraseñas desde un login-config a un login-module parece bastante sencillo, pero ¿qué sucede con los sistemas como OpenID o OAuth donde hay pasos intermedios (como la redirección a páginas externas de inicio de sesión)?
• ¿Cómo encajan proyectos como Seam 3 Security , Apache Shiro y Spring Security en esta imagen?

Answer 1

La especificación de seguridad JavaEE deja mucho espacio a los implementadores de contenedores, así que me concentraré en la implementación de JBoss para responder.

Implementación de seguridad de JBoss

JBoss confía en la autenticación JAAS para implementar la seguridad de JavaEE. De esta forma, toma beneficios de una API estable y puede usar las implementaciones existentes de LoginModule . Los módulos de inicio de sesión se usan para autenticar un tema pero también para agregar roles al Subject . JAAS proporciona mecanismos para autorización, verificación de permisos y JBoss lo usa internamente.

JAAS LoginModule no solo admite la autenticación basada en contraseña sino también la autenticación basada en token.

Autenticaciones basadas en tokens

Un buen ejemplo de lo que se puede hacer en JBoss gracias a JAAS es el soporte de Negociación HTTP para Kerberos SPNEGO : se implementa un auth-method adicional llamado SPNEGO gracias a un autenticador de Tomcat y la validación de token utiliza el Kerberos LoginModule estándar de JavaSE .

Por cierto, la API de LoginModule no es un requisito, incluso puede ser demasiado compleja para algunos protocolos. Por ejemplo, la implementación para admitir OpenID con PicketLink solo usa Servlet API.

Bibliotecas de seguridad de terceros

Estas bibliotecas a menudo proporcionan capas de seguridad a una aplicación que ejecuta un JavaEE o contexto Java puro, incluso si no se beneficia de las especificaciones de JavaEE para autenticación o autorización basada en roles.

Spring Security proporciona otras abstracciones que la seguridad JavaEE para que los desarrolladores de aplicaciones implementen autenticación y autorización, principalmente gracias a ServletFilter cuando se ServletFilter una aplicación web. Un gran panel de opciones está disponible para asegurar su aplicación: es posible mezclar múltiples opciones como: uso de JAAS, uso de seguridad de contenedores de JavaEE o implementaciones específicas de Spring Security (el caso de OpenID y OAuth). No hay dependencia de JavaEE, por lo que puede usarse casi en cualquier situación cuando se ejecuta en JavaSE. La mayoría de los arquitectos eligen crear seguridad de aplicaciones en Spring Security para tener la libertad de cambiar implementaciones específicas en el futuro.

Apache Shiro es muy similar a Spring Security pero es más joven y probablemente más fácil de configurar.

La seguridad de Seam no depende de la seguridad de JavaEE ni de JBoss, sino solo de las API de Servlet y JSF. Obviamente, es la opción más fácil para la aplicación web basada en JSF / Seam. Detrás de escena, utiliza implementaciones de PicketLink .

Como conclusión , la cuestión de utilizar bibliotecas de terceros además o en reemplazo de la seguridad de JavaEE depende de las opciones arquitectónicas: complejidad de la aplicación, independencia del proveedor y portabilidad, control en implementaciones para corregir errores o mejoras. En su contexto específico, tener varias fuentes de autenticación requiere una solución flexible como Spring Security que admita el encadenamiento de proveedores de autenticación (o Shiro).