java - example - wildfly 13
Spring Security Kerberos encadenado con básicos (2)
Dado que esta pregunta es un poco difícil, supongo que ya está familiarizado con los ejemplos de Kerberos de Spring Security que muestran cómo configurar la autenticación de Kerberos con una autenticación de formulario como alternativa. No tengo pruebas de que funcione, pero creo que debería poder encadenar su autenticación de Kerberos con autenticación básica sin ningún problema. Comparto mis pensamientos sobre esto ...
Pensamiento 1: FilterChains
El truco para soportar varios métodos de autenticación es establecer correctamente el orden de los filtros de autenticación. Si el pedido es incorrecto, el cliente podría suspender la autenticación básica y es posible que nunca llegue al filtro de autenticación kerberos, porque el diálogo de autenticación básica del navegador aparecería. Esto podría depender un poco de cómo se implementan el proveedor de autenticación básica y los filtros en Spring. De todos modos, si el orden es correcto, el filtro siguiente en la cadena después del filtro Kerberos (el filtro de autenticación básico) comenzará su trabajo.
Pensamiento 2: la autenticación de Kerberos no debería romper la autenticación básica
El navegador debe tratar la comunicación con el proveedor de servicios kerberos de forma diferente a la comunicación con el proveedor de autenticación básica, ya que los protocolos son diferentes. La comunicación SAML se ejecuta en su propio espacio de nombres , por lo tanto, en mi opinión, no debería afectar la comunicación básica de autenticación, que se basa en el elemento de autorización en el encabezado HTTP.
EDITAR: incluso si la suposición sobre el espacio de nombres no juega ningún papel en el comportamiento de los navegadores, el paso 6 en el diagrama de secuencia será un punto crucial. Cuando el encadenamiento del filtro es correcto, Spring debe devolver una respuesta 401 como 401 - Access denied - WWW-authenticate - Basic realm = "your domain" que forzará a su navegador a la autenticación básica.
Pensamiento 3: Negociar Spnego en Spring Security Kerberos
La configuración de Spnego en la documentación de Spring Security Kerberos se basa en esos pensamientos. Esto se puede ver en las muestras, también, en la línea 49 y 50 de este WebSecurityConfig.java
Me sorprendería si experimentas problemas.
Un último pensamiento
Si no hay requisitos que lo obliguen a realizar una autenticación básica, le recomendaría no usarlo. Mejor quedarse con una autenticación basada en tokens. Incluso si no estoy totalmente de acuerdo con todos los detalles de este blog, explica por qué la autenticación básica no debería usarse , si puede evitarla.
Tengo una pregunta con suerte rápida sobre Spring Security.
Estoy buscando una solución para integrar seguridad en nuestra aplicación que proporciona SSO pero también HTTP básico.
Una de las piezas automatizadas de nuestro sistema solo admite la autenticación básica y estamos bastante encerrados en ella. Actualmente estamos apuntando a usar Kerberos para nuestra solución de SSO y luego también a soporte básico (para uso muy restringido). Todo esto protegerá los servicios web RESTful que se ejecutan a través de resteasy.
¿Alguien ve alguna imposibilidad inherente en esta solución de Kerberos y BASIC encadenados juntos en la seguridad de primavera? Tuvimos problemas con WildFly y undertow no fue capaz de admitir múltiples métodos de autenticación diferentes, que usan códigos de respuesta HTTP en sus apretones de manos.
Gracias por el aporte
Le recomiendo que lea la respuesta de Mika. Está muy bien hecho y me dio la confianza para seguir adelante.
En última instancia, esto funcionó; pero explicaré un par de puntos que tuve.
Uso Request Matcher''s para dividir mis llamadas en diferentes bloques de configuración HTTP
En orden 1 configuré un bloque para filtrar las solicitudes de una herramienta específica, por agente de usuario. En ese bloque, configuré la autenticación básica en básicamente la forma estándar OOTB. Aunque escribí y proporcioné mi propio proveedor de autenticación, este proveedor llamó a un sistema subyacente que usamos para administrar a nuestros usuarios por nombre de usuario / contraseña.
Luego, en el orden 2, configuré un bloque para procesar Kerberos. Después de luchar con la configuración del proveedor de Kerberos y crear un esquema para autenticar en nuestro sistema subyacente, todo esto bien procesado. Después de obtener el nombre de usuario de Kerberos para el usuario del dominio conectado a mi aplicación web, verifiqué si ese nombre de usuario estaba en mi sistema. Si lo son, los registramos. Si no, los dirigimos a la página de inicio de sesión. (No todos los usuarios de dominio están autorizados para nuestra aplicación web, incluso si están autenticados)
Finalmente, el último bloque se configuró para la autenticación de formularios.
Pero hubo algunos puntos difíciles.
- Tuve que configurar globalmente el administrador de autenticación tanto para mi formulario básico personalizado como para el proveedor de Kerberos.
- Y también como nota al margen, tuve que configurar mi bean de autenticación de administrador como sugiere este enlace . Probablemente debido al empedrado conjunto de configuración xml / java que he creado.
- IE también fue extraño. En mi cadena kerberos, también configuré un formulario de inicio de sesión. Esto permitió a los usuarios que calificaron para la cadena navegar directamente al formulario de inicio de sesión para autenticarse; o si alguien no pudo verificar mi nombre de usuario de Kerberos, podría reenviarlo a la página de inicio de sesión. Esto funcionó bien con FireFox, pero IE continúa enviando el encabezado Negotiate incluso después de que mi servidor envió una redirección. Básicamente, el usuario falla kerberos, obtiene un redireccionamiento a la página de inicio de sesión, pero IE envía el token de Kerberos a lo largo. Esto hace que SpnegoAuthenticationProcessingFilter de Spring Security vuelva a activarse y valide el token de Kerberos. Por supuesto, esto falla nuevamente y envía al usuario la página de inicio de sesión que continúa el ciclo.
En resumen, Spring Security permitió 3 bloques agradables y bastante limpios que realizan diversas autentificaciones / autorizaciones diferentes, y luego todo funciona en conjunto para proporcionar el mismo objeto de contexto de usuario a nuestra aplicación web.