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.

Nota: En WebSphere Application Server, versión 6.1, se introdujo un interceptor de asociación de confianza (TAI) que utiliza el mecanismo SPNEGO (Simple and Protected GSS-API Negotiation) para negociar y autenticar con seguridad solicitudes HTTP para recursos seguros. Esta función estaba en desuso en WebSphere Application Server Versión 7.0. La sustituye la autenticación web SPNEGO para proporcionar las mejoras siguientes:
  • 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

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.

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:
  • [Windows]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.

[AIX Solaris HP-UX Linux Windows][IBM i]Para obtener más información sobre cómo utilizar este módulo de inicio de sesión personalizado, consulte [AIX Solaris HP-UX Linux Windows][IBM i]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:

Figura 1. Elementos de configuración de seguridad y de autenticación Web SPNEGOEl administrador Web tiene acceso a los siguientes componentes de seguridad y los datos de configuración asociados de SPNEGO: módulo de autenticación Web, Interceptor de asociación de confianza SPNEGO, proveedores de seguridad JGSS y SPNEGO, archivos de tabla de claves de Kerberos y de configuración de Kerberos, propiedades de configuración de TAI SPNEGO y propiedades de sistema JVM.

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:

  • [Windows]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:

Figura 2. La autenticación Web SPNEGO en un reino de Kerberos individualSe 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. El cliente envía una solicitud HTTP/Post/Get/Web-Service a WebSphere Application Server.
  2. WebSphere Application Server devuelve HTTP 401 Autenticar/Negociar.
  3. El cliente obtiene un TGT (Ticket Granting Ticket).
  4. El cliente solicita un ticket de servicio (TGS_REQ).
  5. El cliente obtiene un ticket de servicio (TGS_REP).
  6. El cliente envía HTTP/Post/Get/Web-Service y una señal SPNEGO a WebSphere Application Server.
  7. 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.
  8. WebSphere Application Server valida el ID de usuario con el registro de usuarios WebSphere y crea una señal LTPA.
  9. WebSphere Application Server devuelve HTTP 200, contenido y la señal LTPA al cliente.
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. Estos clientes pueden obtener un TGT (Ticket Granting Ticket) y un ticket 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 de creación de una solicitud HTTP.

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:

Figura 3. La autenticación web SPNEGO en un reino de Kerberos de confianzaTambién se soporta la autenticación web de SPNEGO en un reino de 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 cliente envía una solicitud HTTP/Post/Get/Web-Service a WebSphere Application Server.
  2. WebSphere Application Server devuelve HTTP 401 Autenticar/Negociar
  3. El cliente obtiene un TGT (Ticket Granting Ticket).
  4. El cliente solicita un ticket de reino cruzado (TGS_REQ) para REALM2 del KDC de REALM1.
  5. El cliente utilizar el ticket de reino cruzado de paso 4 para solicitar un ticket de servicio del KDC de REALM2.
  6. El cliente envía HTTP/Post/Get/Web-Service y una señal SPNEGO a WebSphere Application Server.
  7. 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.
  8. WebSphere Application Server valida el ID de usuario con el registro de usuarios WebSphere y crea una señal LTPA.
  9. 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.

    [AIX Solaris HP-UX Linux Windows][IBM i]Para obtener más información, consulte [AIX Solaris HP-UX Linux Windows][IBM i]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:

Se da soporte a los siguientes escenarios:
  • Confianza de dominio dentro del mismo bosque
  • Confianza de dominio externo directamente entre dominios dentro de bosques distintos
  • Confianza de reino Kerberos
No se admiten los escenarios siguientes:
  • Confianza entre bosques
  • Confianza externa de bosques

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

Se da soporte a los siguientes escenarios:
  • Confianzas de bosque cruzado
  • Confianza de dominio dentro del mismo bosque
  • Confianza de reino Kerberos
No se admiten los escenarios siguientes:
  • Confianza externa de bosque
  • Confianzas externas de dominio

Configuración de SPNEGO como mecanismo de autenticación web para WebSphere Application Server

Antes de configurar la autenticación web SPNEGO en la consola administrativa o mediante mandatos wsadmin, debe realizar los pasos que se listan en Creación de un inicio de sesión único para las solicitudes HTTP mediante la autenticación Web SPNEGO para configurar la autenticación web SPNEGO para WebSphere Application Server.
Nota: La autenticación web SPNEGO en el lado del servidor debe ser llevada a cabo por el administrador del sistema. El archivo de tabla de claves de Kerberos no debe estar protegido.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_SPNEGO_explain
File name: csec_SPNEGO_explain.html