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 varias fuentes. Estoy tratando de comprender los diversos componentes que se combinan para proporcionar autenticación.

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

---

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 subsistema < xmlns = "urn: jboss: domain: security: 1.0" > element.

El reino se puede configurar para autenticar usuarios en 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 real y las contraseñas se pasan 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 correcta (y puede que no sea):

• ¿Esta caída de todo el proceso de autenticación bajo una especificación como JAAS, o es JAAS sólo una parte pequeña o facultativo de ¿este procedimiento?
• ¿Todos los tipos de < auth-methods > (es decir, BASIC, DIGEST y FORM) funcionan con todo tipo de módulos de inicio de sesión? This page parece sugerir que no, pero no he visto ninguna documentación clara que coincida con < login-module > opciones < login-config > opciones.
• El nombre de usuario y el flujo de contraseñas desde un inicio de sesión a un módulo de inicio de sesión parece sencillo, pero ¿qué sucede con los sistemas como OpenID o OAuth donde hay pasos intermedios (como redirección a páginas de inicio de sesión externas)?
• ¿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 centraré en la implementación de JBoss para responder.

implementación de seguridad de JBoss

JBoss se basa en la autenticación JAAS para implementar la seguridad JavaEE. De esta forma, toma beneficios de una API estable y puede usar existing LoginModule implementations. Los módulos de inicio de sesión se utilizan 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 es compatible con la autenticación basada en contraseñas sino también con la autenticación basada en tokens.

autenticaciones basadas Token

Un buen ejemplo de lo que puede hacerse en JBoss gracias a JAAS es el HTTP Negotiation support for Kerberos SPNEGO: un adicional auth-method llamado SPNEGO se implementa gracias a un autenticador Tomcat y token de validación utiliza JavaSE standard Kerberos LoginModule.

Por cierto, la API LoginModule no es un requisito, que incluso puede ser demasiado complejo para algunos protocolos. Por ejemplo, la implementación para admitir OpenID with PicketLink solo usa la API del servlet.

bibliotecas de seguridad de terceros

estas bibliotecas a menudo proporcionan capas de seguridad a una aplicación que se ejecuta un JavaEE o contexto de Java puro, incluso si no toma los beneficios de las especificaciones JavaEE para la 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 trata de 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 la primavera de Seguridad pero es más joven y probablemente más fácil de configurar.

la seguridad de la costura no se basa en la seguridad JavaEE o JBoss, pero sólo en Servlet API y JSF. Obviamente, es la opción más fácil para la aplicación web basada en JSF/Seam. Detrás de la escena, usa implementaciones PicketLink.

Como conclusión, la cuestión de utilizar bibliotecas de terceros, además o en sustitución a la seguridad JavaEE depende de opciones de arquitectura: complejidad de la aplicación, la independencia del proveedor y la portabilidad, el control de las implementaciones de correcciones de errores o mejoras. En su contexto específico, tener múltiples fuentes de autenticación requiere una solución flexible como la Seguridad de muelle que soporta authentication provider chaining (o Shiro).