Inicio de sesión único para las solicitudes HTTP mediante la autenticación Web SPNEGO

Puede negociar de forma segura y autenticar solicitudes HTTP para los recursos protegidos de WebSphere Application Server utilizando SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) como servicio de autenticación web para WebSphere Application Server.

En las secciones siguientes se describe la autenticación web SPNEGO de forma más detallada:

¿Qué es SPNEGO?

SPNEGO es una especificación estándar definida en The Simple and Protected GSS-API Negotiation Mechanism (IETF RFC 2478).

Cuando la seguridad del servidor de Liberty está habilitada y la autenticación web SPNEGO está habilitada, SPNEGO se inicializa al procesar una primera solicitud HTTP de entrada. Si no se especifica el filtro de autenticación o se especifica y se cumplen los criterios, SPNEGO es responsable de autenticar el acceso al recurso protegido que se identifica en la solicitud HTTP.

Además de los servicios de tiempo de ejecución de seguridad de WebSphere Application Server, son necesarios algunos componentes externos para habilitar el funcionamiento de SPNEGO. Estos componentes externos incluyen:
  • Para plataformas WindowsServidores Microsoft Windows Servers con dominio de Active Directory y centro de distribución de claves (KDC) Kerberos asociado.
  • 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 y Mozilla Firefox son ejemplos de navegadores. Cualquier navegador utilizado debe estar configurado para utilizar el mecanismo de autenticación web SPNEGO.

El usuario (el lado del cliente) desencadena la autenticación de solicitudes HTTP, 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 usuario de la señal SPNEGO. A continuación, la identidad se utiliza para tomar decisiones de autorización.

La autenticación web SPNEGO es una solución del lado del servidor de WebSphere Application Server. Las aplicaciones del lado del cliente son responsables de generar la señal SPNEGO para que la utilice la autenticación Web SPNEGO. La identidad de usuario del registro de seguridad de WebSphere Application Server debe ser idéntica a la identidad que la autenticación web SPNEGO recupera. 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 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.

WebSphere Application Server valida la identidad en el registro de seguridad. Si la validación es satisfactoria, se recupera la credencial de delegación GSS del cliente y se coloca en el sujeto del cliente, y se crea una señal de seguridad LTPA (Lightweight Third Party Authentication). A continuación, devuelve la cookie LTPA al usuario en la respuesta HTTP. Las solicitudes HTTP posteriores de este mismo usuario para acceder a más recursos protegidos de WebSphere Application Server utilizan la señal de seguridad LTPA que se ha creado anteriormente para evitar inicios de sesión repetidos.

La autenticación web SPNEGO en un reino de Kerberos individual

La autenticación web SPNEGO está soportada en un único reino Kerberos (dominio). El proceso de reconocimiento de comunicación de solicitud-respuesta se muestra en la siguiente figura:

Figura 1. La autenticación web SPNEGO en un reino de Kerberos individual

Se soporta la autenticación web de SPNEGO en un solo reino de Kerberos. Se muestra el proceso de reconocimiento de respuesta a desafíos.

En la figura anterior, se producen los sucesos siguientes:

  1. Para empezar, el usuario inicia la sesión en el controlador de dominio de Microsoft MYDOMAIN.EXAMPLE.COM desde la estación de trabajo.
  2. A continuación, el usuario intenta acceder a la aplicación Web. El usuario solicita un recurso web protegido utilizando un navegador cliente, que envía una solicitud HTTP GET al servidor de Liberty.
  3. La autenticación SPNEGO del servidor de Liberty responde al navegador cliente con una cabecera challenge HTTP 401 que contiene el estado Authenticate: Negotiate.
  4. El navegador cliente reconoce la cabecera de negociación porque está configurado para dar soporte a la autenticación Windows integrada. El cliente analiza el nombre de host del URL solicitado. El cliente utiliza el nombre de host para formar el nombre principal de servicio (SPN) Kerberos de destino HTTP/myLibertyMachine.example.com para solicitar un tíquet de servicio de Kerberos del servicio de otorgamiento de certificados de Kerberos (TGS) en el KDC Kerberos de Microsoft (TGS_REQ). A continuación, el TGS envía un tíquet de servicio Kerberos (TGS_REP) al cliente. El tíquet de servicio de Kerberos (señal SPNEGO) demuestra tanto la identidad como los permisos del usuario al servicio (servidor de Liberty).
  5. A continuación, el navegador cliente responde a la cabecera challenge Authenticate: Negotiate del servidor de Liberty con la señal SPNEGO que se ha obtenido en el paso anterior en la cabecera HTTP de solicitud.
  6. La autenticación SPNEGO del servidor de Liberty ve la cabecera HTTP con la señal SPNEGO, valida la señal SPNEGO y obtiene la identidad (principal) del usuario.
  7. Tras obtener la identidad del usuario, el servidor de Liberty valida el usuario en su registro de usuarios y realiza las comprobaciones de autorización.
  8. Si se otorga el acceso, el servidor de Liberty envía la respuesta con un HTTP 200. El servidor de Liberty también incluye una cookie LTPA en la respuesta. Esta cookie LTPA se utiliza para los solicitudes posteriores.
Nota: No es necesario que otros clientes (por ejemplo, los servicios web, .NET y J2EE) que soportan SPNEGO sigan el mismo proceso de reconocimiento de respuesta-desafío mostrado anteriormente. Dichos clientes pueden obtener un tíquet de otorgamiento de servicio (TGT) y un tíquet de servicio de Kerberos para el servidor de destino, crear una señal SPNEGO, insertarla en la cabecera HTTP y, a continuación, seguir el proceso normal para crear una solicitud HTTP.

Autenticación web SPNEGO en reinos Kerberos de confianza

La autenticación web SPNEGO también está soportada en reinos Kerberos de confianza. El proceso de reconocimiento de comunicación de solicitud-respuesta se muestra en la siguiente figura:

Figura 2. Autenticación web SPNEGO en un reino Keberos de confianza

También se soporta la autenticación web de SPNEGO en un dominio Kerberos de confianza. Se muestra el proceso de reconocimiento de respuesta a desafíos.

En la figura anterior, se producen los sucesos siguientes:

  1. El usuario inicia la sesión en el controlador de dominio de Microsoft TRUSTEDREALM.ACME.COM.
  2. Desde un navegador cliente, el usuario realiza una solicitud de un recurso web protegido que se aloja en un servidor de Liberty en el controlador de dominio Microsoft original, MYDOMAIN.EXAMPLE.COM.
  3. El servidor de Liberty responde al navegador cliente con una cabecera challenge HTTP 401 que contiene el estado Authenticate: Negotiate.
  4. El navegador cliente está configurado para dar soporte a la autenticación Windows integrada. El navegador cliente analiza el URL utilizando el nombre de host de la estación de trabajo que aloja la aplicación del servidor de Liberty. El navegador cliente utiliza el nombre de host como atributo para solicitar un tíquet de reinos cruzados Kerberos (TGS_REQ) para MYDOMAIN.EXAMPLE.COM del reino TRUSTEDREALM.ACME.COM.
  5. El navegador cliente utiliza el tíquet de reinos cruzados de Kerberos del paso 4 para solicitar un tíquet de servicio Kerberos del reino MYDOMAIN.EXAMPLE.COM. El tíquet de servicio de Kerberos (señal SPNEGO) demuestra la identidad y los permisos del usuario al servicio (servidor de Liberty).
  6. A continuación, el navegador cliente responde a la cabecera challenge Authenticate: Negotiate del servidor de Liberty con la señal SPNEGO que se ha obtenido en el paso anterior en la cabecera HTTP de solicitud.
  7. El servidor de Liberty recibe la solicitud y comprueba la cabecera HTTP con la señal SPNEGO. A continuación, extrae el tíquet de servicio Kerberos, lo valida y obtiene la identidad (principal) del usuario.
  8. Tras obtener la identidad del usuario, el servidor de Liberty valida el usuario en su registro de usuarios y realiza las comprobaciones de autorización.
  9. Si se otorga el acceso, el servidor de Liberty envía la respuesta con un HTTP 200. El servidor de Liberty también incluye una cookie LTPA en la respuesta. Esta cookie LTPA se utiliza para los solicitudes posteriores.
Nota: no es necesario realizar ninguna modificación en el servidor de Liberty para dar soporte a más dominios de confianza. Una relación de confianza entre los reinos necesarios de Active Directory es el único requisito para que SPNEGO funcione con dominios de confianza.

En el entorno de reinos de confianza de Kerberos, tenga en cuenta que la configuración del reino de confianza de Kerberos debe realizarse 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.

Información de soporte de para la autenticación web SPNEGO con un cliente de navegador

Se admiten los escenarios siguientes:
  • Consorcios de bosques cruzados
  • Confianza de dominio dentro del mismo bosque
  • Consorcio de reinos de Kerberos
No se admiten los escenarios siguientes:
  • Consorcios externos de bosques
  • Consorcios externos de dominios

Si desea más información sobre cómo configurar SPNEGO en el servidor Liberty, consulte Configuración de la autenticación SPNEGO en Liberty.


Icono que indica el tipo de tema Tema de concepto



Icono de indicación de fecha y hora Última actualización: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_spnego
Nombre de archivo:cwlp_spnego.html