Soporte del mecanismo de autenticación Kerberos (KRB5) para la seguridad

El mecanismo de autenticación Kerberos permite la interoperatividad con otras aplicaciones (como .NET, DB2® y otras) que dan soporte a la autenticación Kerberos . Proporciona soluciones interoperativas de extremo a extremo de inicio de sesión único (SSO) y conserva la identidad original del solicitante.

Nota: Soporte de seguridad para Kerberos ya que se ha añadido el mecanismo de autenticación para WebSphere® Application Server Versión 7.0. Kerberos es un protocolo de autenticación de red desarrollado, flexible, abierto y muy seguro. Kerberos incluye autenticación, autenticación mutua, integridad y confidencialidad de mensajes, así como funciones de delegación. Puede habilitar Kerberos en el lado del servidor. Se proporciona soporte para permitir que el cliente Java™ enriquecido utilice la señal Kerberos para la autenticación en WebSphere Application Server.
En las secciones siguientes, se describe la autenticación Kerberos de forma más detallada:

Descripción de Kerberos

Kerberos ha resistido el paso del tiempo y ahora ya se encuentra en la versión 5.0. Kerberos disfruta de un amplio soporte de plataforma (por ejemplo, para Windows, Linux®, Solaris, AIX®y z/OS®) en parte porque el código fuente de Kerberos se puede descargar libremente desde el Massachusetts Institute of Technology (MIT) donde se creó originalmente.

Kerberos está compuesto de tres partes: un cliente, un servidor y un tercero de confianza conocido como KDC (Key Distribution Center) de Kerberos). El KDC proporciona servicios de autenticación y otorgamiento de vales.

El KDC mantiene una base de datos o repositorio de cuentas de usuario para todos los principales de seguridad de su reino. Muchas distribuciones Kerberos utilizan repositorios basados en archivos para el principal de Kerberos y una base de datos de políticas, mientras que otros utilizan el protocolo LDAP (Lightweight Directory Access Protocol) como repositorio.

Kerberos no da soporte a ninguna noción de grupos (es decir, grupos iKeys o grupos de usuarios o principales). El KDC mantiene una clave a largo plazo para cada principal de su base de datos de cuentas. Esta clave a largo plazo se obtiene de la contraseña del principal. El KDC y el usuario que representa el principal son los únicos que deberían conocer la clave o contraseña a largo plazo.

Beneficios de utilizar Kerberos como mecanismo de autenticación

Las ventajas de tener Kerberos como mecanismo de autenticación para WebSphere Application Server incluyen lo siguiente:

  • El protocolo Kerberos es un estándar. Esto permite la interoperatividad con otras aplicaciones (como .NET, DB2 y otras) que dan soporte a la autenticación Kerberos . Proporciona soluciones interoperativas de extremo a extremo de inicio de sesión único (SSO) y conserva la identidad original del solicitante.
  • Al utilizar la autenticación Kerberos, la contraseña de texto no cifrado del usuario no sale de la máquina del usuario. El usuario se autentica y obtiene un TGT (Ticket Granting Ticket) de Kerberos a partir de un KDC, utilizando un valor de hash unidireccional de la contraseña del usuario. El usuario obtiene también un ticket de servicio de Kerberos del KDC utilizando el TGT. El tíquet de servicio de Kerberos que representa la identidad del cliente se envía a WebSphere Application Server para su autenticación.
  • Un cliente Java puede participar en el SSO de Kerberos utilizando la memoria caché de credenciales de Kerberos para autenticarse en WebSphere Application Server.
  • Los clientes J2EE, de servicio web, .NET y de navegador web que utilizan el protocolo HTTP pueden utilizar la señal SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) para autenticarse en WebSphere Application Server y participar en SSO utilizando la autenticación web SPNEGO. El soporte para SPNEGO como servicio de autenticación web es nuevo en este release de WebSphere Application Server.

    Consulte Inicio de sesión único SPNEGO para obtener más información.

  • WebSphere Application Server puede dar soporte a los mecanismos de autenticación Kerberos y LTPA (Lightweight Third-Party Authentication) al mismo tiempo.
  • Se permite la comunicación entre servidores mediante la autenticación Kerberos.

Autenticación Kerberos en un entorno de reino de Kerberos individual

WebSphere Application Server da soporte a la autenticación Kerberos en un único entorno de reino Kerberos tal como se muestra en la figura siguiente:

Figura 1. Autenticación Kerberos en un entorno de reino de Kerberos individual
WebSphere Application Server da soporte a la autenticación Kerberos en un único entorno de dominio Kerberos

Cuando WebSphere Application Server recibe una señal Kerberos o SPNEGO para la autenticación, utiliza el principal de servicio (SPN) Kerberos para establecer un contexto de seguridad con un solicitante. Si se establece un contexto de seguridad, el módulo de inicio de sesión de WebSphere Kerberos extrae una credencial de delegación GSS de cliente, crea una señal de autenticación Kerberos basada en la credencial Kerberos y los coloca en el asunto del cliente con otras señales.

Si el servidor debe utilizar un servidor en sentido descendente o recursos de fondo, utiliza la credencial de delegación GSS de cliente. Si un servidor en sentido descendente no soporte la autenticación Kerberos, el servidor utilizará la señal LTPA en lugar de la señal Kerberos. Si un cliente no incluye una credencial de delegación GSS en la solicitud, el servidor utilizará la señal LTPA del servidor en sentido descendente. La señal y el principal de autenticación de Kerberos se propagan al servidor en sentido descendente como parte de la función de propagación de los atributos de seguridad.

Si WebSphere Application Server y el KDC no utilizan el mismo registro de usuarios, es posible que sea necesario un módulo de inicio de sesión personalizado JAAS para correlacionar el nombre principal de Kerberos con el nombre de usuario de WebSphere .

Autenticación Kerberos en un entorno de reino de Kerberos cruzado o de confianza

WebSphere Application Server también da soporte a la autenticación Kerberos en un entorno de reino Kerberos cruzado o de confianza, tal como se muestra en la figura siguiente:

Figura 2. Autenticación Kerberos en un entorno de reino de Kerberos cruzado o de confianza
WebSphere Application Server también da soporte a la autenticación Kerberos en un entorno de reino Kerberos cruzado o de confianza

Cuando WebSphere Application Server recibe una señal Kerberos o SPNEGO para la autenticación, utiliza el principal de servicio (SPN) Kerberos para establecer un contexto de seguridad con un solicitante. Si se establece un contexto de seguridad, el módulo de inicio de sesión WebSphere Kerberos siempre extrae una credencial de delegación GSS de cliente y un tíquet Kerberos y los coloca en el asunto del cliente con otras señales.

Si el servidor debe utilizar un servidor en sentido descendente o recursos de programa de fondo, utilizará la credencial de delegación GSS de cliente. Si un servidor en sentido descendente no soporte la autenticación Kerberos, el servidor utilizará la señal LTPA en lugar de la señal Kerberos. Si un cliente no incluye una credencial de delegación GSS en la solicitud, el servidor utilizará la señal LTPA del servidor en sentido descendente. La señal y el principal de autenticación de Kerberos se propagan al servidor en sentido descendente como parte de la función de propagación de los atributos de seguridad.

Si WebSphere Application Server y el KDC no utilizan el mismo registro de usuarios, es posible que sea necesario un módulo de inicio de sesión personalizado JAAS para correlacionar el nombre principal de Kerberos con el nombre de usuario de WebSphere .

En este release de WebSphere Application Server, los nuevos dominios múltiples de seguridad sólo dan soporte a Kerberos a nivel de célula. Todos los WebSphere Application Serverdeben ser utilizados por el mismo dominio Kerberos . Sin embargo, los clientes y/o recursos de fondo (como DB2, el servidor .NET y otros) que dan soporte a la autenticación Kerberos pueden tener su propio dominio Kerberos . Sólo se da soporte a la autenticación entre reinos de confianza de igual a igual y de confianza transitiva. Para los reinos Kerberos de confianza, deben llevarse a cabo los pasos siguientes:

  • 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 un reino de confianza de Kerberos.
  • Es posible que en el archivo de configuración Kerberos deba constar el reino de confianza.
  • Añada reinos de confianza de Kerberos en la consola administrativa pulsando Seguridad global > CSIv2 comunicaciones de salida > Reinos de autenticación de confianza-salida.

La figura siguiente muestra un cliente Java y administrativo que utiliza una memoria caché de credenciales de Kerberos para autenticarse en WebSphere Application Server con una señal Kerberos en un dominio Kerberos de confianza:

Figura 3. Utilización de una memoria caché de credenciales de Kerberos para autenticarse en WebSphere Application Server con una señal Kerberos en un dominio Kerberos de confianza
Utilización de una memoria caché de credenciales de Kerberos para autenticarse en WebSphere Application Server con una señal Kerberos en un reino Kerberos de confianza
En la figura anterior, se producen los sucesos siguientes:
  1. El cliente utiliza la memoria caché de credenciales Kerberos si existe.
  2. El cliente solicita un tíquet de dominio cruzado (TGS_REQ) para Realm A desde el KDC de Realm B utilizando la memoria caché de credenciales de Kerberos .
  3. El cliente utiliza un tíquet de dominio cruzado para solicitar el tíquet de servicio de Kerberos para server1 (TGS_REQ) desde el KDC de Realm A .
  4. La señal de Kerberos que devuelve KDC (TGS_REP ) se añade a la señal de autenticación de mensaje de CSIv2 y se envía a server1 para su autenticación.
  5. El servidor llama a Krb5LoginModuleWrapper para establecer un contexto de seguridad con el cliente mediante el nombre principal del servicio de Kerberos (SPN) y las claves del archivo krb5.keytab. Si el servidor establece un contexto de seguridad con el cliente correctamente, siempre extraerá la credencial de delegación GSS de cliente y los vales y los colocará en el asunto del cliente.
  6. Opcionalmente, es posible que sea necesario un módulo de inicio de sesión JAAS personalizado si el KDC y WebSphere Application Server no utilizan el mismo registro de usuarios.
  7. El usuario se valida con el registro de usuarios para WebSphere Application Server.
  8. Los resultados (correcto o anomalía) se devuelven al cliente.

La figura siguiente muestra un cliente Java y administrativo que utiliza un nombre principal y una contraseña de Kerberos para autenticarse en WebSphere Application Server con una señal Kerberos :

Figura 4. Utilización de un nombre principal y una contraseña de Kerberos para autenticarse en WebSphere Application Server con una señal Kerberos
Utilizando un nombre principal y una contraseña de Kerberos para autenticarse en WebSphere Application Server con una señal Kerberos .
En la figura anterior, se producen los sucesos siguientes:
  1. El cliente obtiene el TGT (Ticket Granting Ticket) del KDC.
  2. El cliente obtiene un vale de servicio de Kerberos para server1 (TGS_REQ) mediante el TGT.
  3. La señal de Kerberos que devuelve KDC (TGS_REP ) se añade a la señal de autenticación de mensaje de CSIv2 y se envía a server1 para su autenticación.
  4. El servidor llama a Krb5LoginModuleWrapper para establecer un contexto de seguridad con el cliente mediante el nombre principal del servicio de Kerberos (SPN) y las claves del archivo krb5.keytab. Si el servidor establece un contexto de seguridad con el cliente correctamente, siempre extraerá la credencial de delegación GSS de cliente y los vales y los colocará en el asunto del cliente.
  5. Opcionalmente, es posible que sea necesario un módulo de inicio de sesión JAAS personalizado si el KDC y WebSphere Application Server no utilizan el mismo registro de usuarios.
  6. El usuario se valida con el registro de usuarios para WebSphere Application Server.
  7. Los resultados se devuelven al cliente.

En la figura siguiente, se muestran las comunicaciones entre servidores:

Figura 5. Comunicaciones entre servidores
Cuando se inicia un servidor de aplicaciones WebSphere , utiliza el ID de servidor y la contraseña para iniciar sesión en el KDC y, a continuación, obtiene el TGT. Posteriormente, utiliza el TGT para solicitar un vale de servicio para comunicarse con otro servidor. Si un servidor de aplicaciones WebSphere utiliza el ID de servidor interno en lugar del ID de servidor y la contraseña, la comunicación de servidor a servidor se realiza utilizando una señal LTPA.

Cuando se inicia un WebSphere Application Server , utiliza el ID de servidor y la contraseña para iniciar la sesión en el KDC y, a continuación, obtiene el TGT. Posteriormente, utiliza el TGT para solicitar un vale de servicio para comunicarse con otro servidor. Si un WebSphere Application Server utiliza el ID de servidor interno en lugar del ID de servidor y la contraseña, la comunicación de servidor a servidor se realiza utilizando una señal LTPA. En la figura anterior, se producen los sucesos siguientes:

  1. WebSphere Application Server 1 invoca un método, foo (), en un Enterprise JavaBeans (EJB) que se ejecuta en WebSphere Application Server 2.
  2. Server1 obtiene un vale de servicio de Kerberos para Server2 (TGS_REQ) mediante el TGT de Server1.
  3. Lleve a cabo el mismo procedimiento para el paso 2.
  4. La señal de Kerberos que devuelve un KDC (TGS_REP ) se añade a la señal de autenticación de mensaje de CSIv2 y se envía a Server2 para su autenticación.
  5. Server2 llama al método acceptSecContext() para establecer un contexto de seguridad con server1 mediante el nombre principal de servicio de Kerberos (SPN) server2 y las claves del archivo krb5.keytab. Si server2 establece un contexto de seguridad con server1 correctamente, siempre extraerá los vales y la credencial de delegación GSS de server1 y los colocará en el asunto.
  6. El ID de servidor se valida con el registro de usuarios de WebSphere .
Evitar problemas: Si una aplicación cliente Java y el servidor de aplicaciones existen en la misma máquina y utilizan distintos nombres de reino de Kerberos , el tiempo de ejecución utiliza el nombre de reino predeterminado del archivo de configuración Kerberos . De forma alternativa, puede especificar el nombre de reino durante el proceso de inicio de sesión.
Evitar problemas: Kerberos y la autenticación LTPA se pueden configurar en varios entornos KDC. La autenticación básica puede constar de una contraseña y un nombre abreviado sin el nombre de reino Kerberos. Para esta autenticación básica, una combinación del elemento domain_realm y el elemento default_realm determina qué KDC utiliza el cliente Kerberos para autenticar la solicitud. Los usuarios que no pertenecen al KDC determinado deben iniciar sesión con un nombre principal de Kerberos totalmente cualificado, por ejemplo, Bob@myKerberosRealm.

Cosas a tener en cuenta antes de configurar Kerberos como mecanismo de autenticación para WebSphere Application Server

WebSphere Application Server ahora da soporte a señales SPNEGO en la cabecera HTTP, señales Kerberos , señales LTPA y BasicAuth (GSSUP) para la autenticación.

Para proporcionar soluciones Kerberos de extremo a extremo y soluciones SPNEGO de extremo a extremo para Kerberos, tenga en cuenta lo siguiente:
  • La opción Delegación de credenciales Kerberos habilitada debe estar habilitada. Consulte Configuración de Kerberos como mecanismo de autenticación utilizando la consola administrativa para obtener más información sobre esta opción.
  • Un cliente debe obtener un TGT (tíquet de otorgamiento de tíquet) con distintivos reenviables, sin dirección y renovables para que un servidor de destino pueda extraer una credencial de Kerberos de delegación de cliente y utilizarla para ir al servidor en sentido descendente.
  • Un TGT de cliente tiene una dirección que no se puede utilizar para entornos de servidor en sentido descendente, de clúster y de memoria caché de DRS (Data replication service - Servicio de réplica de datos).
  • Consulte las plataformas KDC de Kerberos para asegurarse de que permite Kerberos de delegación de cliente.
  • Para una aplicación de larga duración, un cliente debe solicitar un TGT con un distintivo renovable para que un servidor de destino pueda renovar el Kerberos de delegación.
  • Para una aplicación de larga ejecución, asegúrese de que el tíquet Kerberos sea válido para un período de tiempo que sea, al menos, igual al período durante el que se ejecute la aplicación. Por ejemplo, si la aplicación procesa una transacción que dura 5 minutos, el tíquet de Kerberos debe ser válido para, al menos, 5 minutos.
  • Se soportan la autenticación de Kerberos y la autenticación web SPNEGO para consorcios de dominios cruzados Active Directory en el mismo bosque.
  • Para que un agente administrativo utilice el mecanismo de autenticación de Kerberos, debe intercambiar una clave LTPA con un perfil de subsistema administrativo.

    [z/OS]La siguiente propiedad personalizada de seguridad debe establecerse en true: com.ibm.websphere.security.krb.longLivedTicket.

  • Si piensa utilizar la credencial de Kerberos de delegación de cliente para la autenticación en sentido descendente, asegúrese de que el cliente pueda solicitar un tiquet de servicio que sea mayor de 10 minutos. Si la duración de la credencial de Kerberos de delegación de cliente es inferior a 10 minutos, el servidor intenta renovarla.
Nota: El cliente, las máquinas WebSphere Application Server y KDC deben mantener el reloj sincronizado. Se recomienda utilizar un servidor de horas para mantener sincronizados todos los sistemas.
Para este release de WebSphere Application Server, tenga en cuenta lo siguiente:
  • El soporte completo de Kerberos de extremo a extremo con Tivoli ® Access Manager está disponible utilizando los siguientes KDC:
    • z/OS
    • Microsoft (único o multidominio)
    • AIX
    • Linux
  • Ahora puede configurar y habilitar los reinos cruzados de Kerberos para WebSphere Application Server y el cliente ligero.
  • La función administrativa de WebSphere Application Server con Kerberos está limitada por lo siguiente:
    • El mecanismo de autenticación preferido para actividades de gestión flexibles es el mecanismo de autenticación RSA (Rivest Shamir Adleman) (de manera predeterminada).
    • El gestor de trabajos configurado con Kerberos como la autenticación administrativa no soporta reinos Kerberos cruzados. Deben estar en el mismo reino Kerberos que los nodos registrados o tener la autenticación administrativa establecida en RSA
    • Mientras que la autenticación Kerberos está soportada para clientes administrativos (wsadmin o clientes Java), debe utilizar el mismo reino KDC que el WebSphere Application Server que administra. De lo contrario, se recomiendan un ID de usuario y una contraseña.
    • La configuración mixta de célula Kerberos y LTPA no está soportada cuando algunos de los nodos son nodos de WebSphere Application Server Release 6.x o anteriores.

Información de soporte para la autenticación Kerberos

Se da soporte a los siguientes escenarios:
  • Confianzas de dominios externos que no están en el mismo bosque
  • Confianza de dominio dentro del mismo bosque
  • Consorcio de reinos de Kerberos
No se admiten los escenarios siguientes:
  • Confianza entre bosques
  • Consorcios externos de bosques

Configuración de Kerberos como mecanismo de autenticación para WebSphere Application Server

Debe realizar los pasos en el orden indicado en Configuración de Kerberos como mecanismo de autenticación para WebSphere Application Server para configurar Kerberos como mecanismo de autenticación para WebSphere Application Server.
Nota: El mecanismo de autenticación Kerberos en el lado del servidor lo deben realizar el administrador del sistema y en el lado del cliente Java los usuarios. El archivo keytab de Kerberos no debe estar protegido.

Configuración de Kerberos como mecanismo de autenticación para el cliente Java puro

Los usuarios finales pueden configurar opcionalmente el mecanismo de autenticación Kerberos para el cliente Java puro. Consulte Configuración de un cliente Java para la autenticación Kerberos para obtener más información.

[8.5.5.19 o posterior]

Configuración de Kerberos como mecanismo de autenticación de enlace para LDAP

Puede configurar Kerberos como el mecanismo de autenticación de enlace para enlazar al servidor LDAP y realizar búsquedas de usuarios y grupos. Este mecanismo de autenticación de enlace es una alternativa al mecanismo de autenticación de enlace simple, que utiliza un nombre distinguido de enlace y una contraseña de enlace.

Para configurar Kerberos como el mecanismo de autenticación de enlace para servidores LDAP en repositorios federados, realice los pasos del tema sobre cómo configurar LDAP en una configuración de repositorio federado.

Para configurar Kerberos como el mecanismo de autenticación de enlace para un servidor LDAP autónomo, realice los pasos del tema sobre cómo configurar registros de usuario LDAP.