Inicio de sesión único para las solicitudes HTTP mediante la autenticación Web SPNEGO
Puede negociar y autenticar solicitudes HTTP de forma segura para recursos protegidos en WebSphere Application Server mediante SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) como servicio de autenticación web de WebSphere Application Server.
- Puede configurar y habilitar la autenticación web SPNEGO y los filtros en WebSphere Application Server mediante la consola administrativa.
- La recarga dinámica de SPNEGO se proporciona sin necesidad de detener y reiniciar WebSphere Application Server.
- El repliegue de un método de inicio de sesión de la aplicación se proporciona si falla la autenticación web SPNEGO.
- SPNEGO puede personalizarse en el nivel de dominio de seguridad de WebSphere. Consulte Varios dominios de seguridad para obtener más información.
Puede habilitar la autenticación Web SPNEGO o SPNEGO TAI, pero no ambas.
En las secciones siguientes, se describe la autenticación Web SPNEGO de forma más detallada:
- Descripción de SPNEGO
- Ventajas de la autenticación Web SPNEGO
- La autenticación Web SPNEGO en un reino de Kerberos individual
- La autenticación web SPNEGO en un reino de Kerberos de confianza
- Información de soporte para la autenticación web SPNEGO con un cliente Java utilizando el protocolo HTTP:
- Información de soporte para la autenticación Web de SPNEGO con un cliente de navegador
- Configuración de SPNEGO como mecanismo de autenticación web para WebSphere Application Server
Descripción de SPNEGO
SPNEGO es una especificación estándar definida en The Simple and Protected GSS-API Negotiation Mechanism (IETF RFC 2478).
Cuando se habilita la seguridad de aplicación y la seguridad global de WebSphere Application Server y también se habilita la autenticación Web SPNEGO, el mecanismo SPNEGO se inicializa al procesar la primera solicitud HTTP de entrada. A continuación, el componente del autenticador Web interactúa con SPNEGO, que se define y habilita en el repositorio de configuración de seguridad. Cuando se cumplen los criterios de filtro, SPNEGO se encarga de autenticar el acceso al recurso protegido que se define en la solicitud HTTP.
Servidores Microsoft Windows con el dominio de Active Directory y el centro de distribución de claves (KDC) de Kerberos asociado. Para obtener información sobre los servidores Microsoft Windows Servers soportados, consulte los Requisitos del sistema para WebSphere Application Server Versión 9.0 en Windows.
- Una aplicación de cliente, por ejemplo, Microsoft .NET, o un servicio Web y un cliente J2EE que da soporte al mecanismo de autenticación Web de SPNEGO, tal como se ha definido en IETF RFC 2478. Microsoft Internet Explorer Versión 5.5 o posterior y Mozilla Firefox Versión 1.0 son ejemplos de navegador. Todos los navegadores deben configurarse para que puedan utilizar el mecanismo de autenticación Web SPNEGO. Para obtener más información sobre como realizar esta configuración, consulte Configuración del navegador del cliente para utilizar SPNEGO.
La autenticación de solicitudes HTTP se desencadena mediante el solicitante (el extremo del cliente), que genera una señal SPNEGO. WebSphere Application Server recibe esta señal. Concretamente, la autenticación Web SPNEGO decodifica y recupera la identidad del solicitante de la señal de SPNEGO. La identidad se utiliza para establecer un contexto seguro entre el solicitante y el servidor de aplicaciones.
La autenticación web SPNEGO es una solución del extremo del servidor de WebSphere Application Server. Las aplicaciones del extremo del cliente son responsables de generar la señal SPNEGO para que lo utilice la autenticación Web SPNEGO. La identidad del solicitante del registro de seguridad de WebSphere Application Server debe ser idéntica a la que la autenticación Web SPNEGO recupera. No se da una correspondencia idéntica cuando el servidor de Microsoft Windows Active Directory es el servidor LDAP (Lightweight Directory Access Protocol) que se utiliza en WebSphere Application Server. Un módulo de inicio de sesión personalizado está disponible como un plug-in para dar soporte a la correlación personalizada de la identidad procedente de Active Directory con el registro de seguridad de WebSphere Application Server.
Para obtener más información sobre cómo utilizar este módulo de inicio de sesión personalizado, consulte
Correlación de un nombre principal de cliente Kerberos con el ID del registro de usuarios de WebSphere.
WebSphere Application Server valida la identidad en el registro de seguridad. Si la validación es satisfactoria, el ticket de Kerberos de cliente y la credencial de delegación GSS se recuperan y colocan en el asunto del cliente; de este modo, se obtiene una señal de seguridad LTPA (Lightweight Third Party Authentication). A continuación, coloca y devuelve un cookie al solicitante en la respuesta HTTP. Las solicitudes HTTP subsiguientes de este mismo solicitante para acceder a los recursos protegidos adicionales de WebSphere Application Server utilizan la señal de seguridad LTPA creando anteriormente para evitar las solicitudes de inicio de sesión repetidas.
El administrador Web tiene acceso a los componentes de seguridad de SPNEGO y datos de configuración asociados siguientes, tal como se muestra en la figura siguiente:

Ventajas de la autenticación Web SPNEGO
Entre las ventajas de que WebSphere Application Server utilice SPNEGO como servicio de autenticación web para WebSphere Application Server se encuentran las siguientes:
Se establece un entorno de inicio de sesión único integrado con servidores Microsoft Windows utilizando el dominio de Active Directory.
- El coste de administración de un número elevado de ID y contraseñas se reduce.
- Se establece una transmisión segura y autenticada mutuamente de las credenciales de seguridad desde los clientes de Microsoft .NET o de navegador Web.
- Se logra la interoperatividad con los servicios web y las aplicaciones Microsoft .NET que utilizan la autenticación de SPNEGO a nivel de transporte.
- Con el soporte de la autenticación Kerberos, la autenticación Web SPNEGO puede proporcionar un mecanismo SPNEGO de extremo a extremo para la solución Kerberos y conservar la credencial Kerberos del cliente.
La autenticación Web SPNEGO en un reino de Kerberos individual
La autenticación Web SPNEGO se soporta en un reino de Kerberos individual. El proceso de reconocimiento de comunicación de solicitud-respuesta se muestra en la siguiente figura:

En la figura anterior, se producen los sucesos siguientes:
- El cliente envía una solicitud HTTP/Post/Get/Web-Service a WebSphere Application Server.
- WebSphere Application Server devuelve HTTP 401 Autenticar/Negociar.
- El cliente obtiene un TGT (Ticket Granting Ticket).
- El cliente solicita un ticket de servicio (TGS_REQ).
- El cliente obtiene un ticket de servicio (TGS_REP).
- El cliente envía HTTP/Post/Get/Web-Service y una señal SPNEGO a WebSphere Application Server.
- WebSphere Application Server valida la señal SPNEGO. Si la validación es satisfactoria, recupera el ID de usuario y la credencial de delegación GSS de la señal SPNEGO. Cree una KRBAuthnToken con una credencial Kerberos de cliente.
- WebSphere Application Server valida el ID de usuario con el registro de usuarios WebSphere y crea una señal LTPA.
- WebSphere Application Server devuelve HTTP 200, contenido y la señal LTPA al cliente.
La autenticación web SPNEGO en un reino de Kerberos de confianza
La autenticación Web SPNEGO también se soporta en un reino de Kerberos de confianza. El proceso de reconocimiento de comunicación de solicitud-respuesta se muestra en la siguiente figura:

En la figura anterior, se producen los sucesos siguientes:
- El cliente envía una solicitud HTTP/Post/Get/Web-Service a WebSphere Application Server.
- WebSphere Application Server devuelve HTTP 401 Autenticar/Negociar
- El cliente obtiene un TGT (Ticket Granting Ticket).
- El cliente solicita un ticket de reino cruzado (TGS_REQ) para REALM2 del KDC de REALM1.
- El cliente utilizar el ticket de reino cruzado de paso 4 para solicitar un ticket de servicio del KDC de REALM2.
- El cliente envía HTTP/Post/Get/Web-Service y una señal SPNEGO a WebSphere Application Server.
- WebSphere Application Server valida la señal SPNEGO. Si la validación es satisfactoria, recupera el ID de usuario y la credencial de delegación GSS de la señal SPNEGO. Cree una KRBAuthnToken con una credencial Kerberos de cliente.
- WebSphere Application Server valida el ID de usuario con el registro de usuarios WebSphere y crea una señal LTPA.
- WebSphere Application Server devuelve HTTP 200, contenido y la señal LTPA al cliente.
En el entorno de reinos de Kerberos de confianza, tenga en cuenta lo siguiente:
- La configuración del reino de confianza de Kerberos debe ser llevada a cabo en cada uno de los KDC de Kerberos. Consulte la guía del administrador y del usuario de Kerberos para obtener más información sobre cómo configurar reinos de confianza de Kerberos.
- Es posible que el nombre principal de cliente de Kerberos de la señal SPNEGO no exista en el registro de usuarios de WebSphere; es posible que dicho nombre sea necesario para la correlación del principal de Kerberos con el registro de usuarios WebSphere.
Para obtener más información, consulte
Correlación de un nombre principal de cliente Kerberos con el ID del registro de usuarios de WebSphere.
Información de soporte para la autenticación web SPNEGO con un cliente Java™ utilizando el protocolo HTTP:
- Confianza de dominio dentro del mismo bosque
- Confianza de dominio externo directamente entre dominios dentro de bosques distintos
- Confianza de reino Kerberos
- Confianza entre bosques
- Confianza externa de bosques
Información de soporte para la autenticación Web de SPNEGO con un cliente de navegador
- Confianzas de bosque cruzado
- Confianza de dominio dentro del mismo bosque
- Confianza de reino Kerberos
- Confianza externa de bosque
- Confianzas externas de dominio