Soporte del mecanismo de autenticación Kerberos (KRB5) para la seguridad
El mecanismo de autenticación Kerberos permite la interoperatividad con otras aplicaciones (como, por ejemplo, .NET, y DB2, entre otras) que dan soporte a la autenticación de Kerberos. Proporciona soluciones interoperativas de extremo a extremo de inicio de sesión único (SSO) y conserva la identidad original del solicitante.
- Descripción de Kerberos
- Beneficios de utilizar Kerberos como mecanismo de autenticación
- Autenticación Kerberos en un entorno de reino de Kerberos individual
- Autenticación Kerberos en un entorno de reino de Kerberos cruzado o de confianza
- Puntos a tener en cuenta antes de configurar Kerberos como mecanismos de autenticación para WebSphere Application Server
- Información de soporte de para la autenticación de Kerberos
- Configuración de Kerberos como mecanismo de autenticación para WebSphere Application Server
- Configuración de Kerberos como mecanismo de autenticación para un cliente Java puro
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 del MIT (Massachusetts Institute of Technology) donde se creó originalmente.
Kerberos está compuesto de tres partes: un cliente, un servidor y un tercero de confianza conocido como centro de distribución de claves de Kerberos (KDC). 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
Los beneficios de utilizar 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, por ejemplo, .NET y DB2, entre otras) que dan soporte a la autenticación de 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 ticket 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 inicio de sesión único de Kerberos mediante la memoria caché de credenciales Kerberos para autenticar en WebSphere Application Server.
- J2EE, servicio web, .NET y los clientes de navegador web que utilizan el protocolo HTTP pueden utilizar la señal SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) para autenticar en WebSphere Application Server y participar en el inicio de sesión único mediante la autenticación web de SPNEGO. El soporte para SPNEGO como servicio de autenticación web es nuevo en este release de WebSphere Application Server.
Para obtener más información, consulte Inicio de sesión único para las solicitudes HTTP mediante la autenticación Web SPNEGO.
- WebSphere Application Server puede dar soporte a los mecanismos de autenticación de 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 soporta la autenticación Kerberos en un entorno de reino de Kerberos individual tal como se muestra en la figura siguiente:

Cuando WebSphere Application Server recibe una señal Kerberos o SPNEGO para autenticar, utiliza el principal del servicio de Kerberos (SPN) 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 Kerberos de WebSphere extrae una credencial de delegación GSS de cliente, crea una base de señal de autenticación de Kerberos en la credencial de Kerberos y las 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 realizar un inicio de sesión personalizado JAAS para correlacionar el nombre del principal de Kerberos con el nombre de usuario WebSphere.
Autenticación Kerberos en un entorno de reino de Kerberos cruzado o de confianza
WebSphere Application Server también soporta la autenticación Kerberos en un entorno de reino de Kerberos cruzado o de confianza tal como se muestra en la figura siguiente:

Cuando WebSphere Application Server recibe una señal Kerberos o SPNEGO para autenticar, utiliza el principal del servicio de Kerberos (SPN) 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 Kerberos de WebSphere siempre extrae una credencial de delegación GSS de cliente y un vale de 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 realizar un inicio de sesión personalizado JAAS para correlacionar el nombre del principal de Kerberos con el nombre de usuario 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. El mismo reino de Kerberos debe utilizar todos los servidores WebSphere Application Server. Sin embargo, los clientes o recursos de programa de fondo (como DB2 y el servidor .NET, entre otros) que soportan la autenticación Kerberos cuentan con su propio reino de 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.
- Para añadir reinos de confianza de Kerberos en la consola administrativa, pulse .
En la figura siguiente, se muestra un cliente Java y administrativo que utiliza una memoria caché de credenciales de Kerberos para autenticar en WebSphere Application Server con una señal Kerberos en un reino de Kerberos de confianza:

- El cliente utiliza la memoria caché de credenciales Kerberos si existe.
- El cliente solicita un vale de reino cruzado (TGS_REQ) para Realm A del KDC de Realm B mediante la memoria caché de credenciales de Kerberos.
- El cliente utiliza un vale de reino cruzado para solicitar un vale de servicio de Kerberos para server1 (TGS_REQ) del KDC de Realm A.
- 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.
- 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.
- Opcionalmente, puede requerirse un módulo de inicio de sesión JAAS personalizado si el KDC y WebSphere Application Server no utilizan el mismo registro de usuarios.
- El usuario se valida con el registro de usuarios de WebSphere Application Server.
- Los resultados (correcto o anomalía) se devuelven al cliente.
En la figura siguiente, se muestra un cliente de Java y administrativo que utiliza un nombre y una contraseña de principal de Kerberos para autenticar en WebSphere Application Server con una señal de Kerberos:

- El cliente obtiene el TGT (Ticket Granting Ticket) del KDC.
- El cliente obtiene un vale de servicio de Kerberos para server1 (TGS_REQ) mediante el TGT.
- 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.
- 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.
- Opcionalmente, puede requerirse un módulo de inicio de sesión JAAS personalizado si el KDC y WebSphere Application Server no utilizan el mismo registro de usuarios.
- El usuario se valida con el registro de usuarios de WebSphere Application Server.
- Los resultados se devuelven al cliente.
En la figura siguiente, se muestran las comunicaciones entre servidores:

Cuando se inicia un WebSphere Application Server, éste 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 WebSphere Application Server utiliza el ID de servidor interno en lugar del ID de servidor y la contraseña, la comunicación entre servidores se establecerá mediante una señal LTPA. En la figura anterior, se producen los sucesos siguientes:
- 1WebSphere Application Serverinvoca un método, foo(), en un EJB (Enterprise JavaBeans) que se ejecuta en WebSphere Application Server2.
- Server1 obtiene un vale de servicio de Kerberos para Server2 (TGS_REQ) mediante el TGT de Server1.
- Lleve a cabo el mismo procedimiento para el paso 2.
- 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.
- 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.
- El ID de servidor se valida con el registro de usuarios de WebSphere.

Puntos a tener en cuenta antes de configurar Kerberos como mecanismos de autenticación para WebSphere Application Server
WebSphere Application Server ahora soporta señales SPNEGO en la cabecera HTTP, señales Kerberos, señales LTPA y BasicAuth (GSSUP) para la autenticación.
- La opción Delegación de credenciales Kerberos habilitada debe estar habilitada. Para obtener más información sobre esta opción, consulte Configuración de Kerberos como mecanismo de autenticación mediante la consola administrativa.
- 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 duplicación 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 tiquet Kerberos es válido para un periodo de tiempo que dure mientras se ejecuta la aplicación. Por ejemplo, si la aplicación procesa una transacción que dura 5 minutos, el tiquet Kerberos debe ser válido durante 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.
La siguiente propiedad personalizada de seguridad se deberá establecer en true: com.ibm.websphere.security.krb.longLivedTicket.
- Si tiene previsto utilizar la credencial de Kerberos de delegación de cliente para la autenticación en sentido descendente, asegúrese de que el cliente puede solicitar un tíquet de servicio que sea mayor que 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.
- Está disponible el soporte de Kerberos completo de extremo a extremo con
Tivoli Access Manager utilizando los
siguientes KDC:
- z/OS
- Microsoft (uno o varios reinos)
- AIX
- Linux
- Ahora puede configurar y habilitar reinos cruzados de Kerberos para WebSphere Application Server y el cliente ligero.
- La función administrativa de WebSphere Application Server con Kerberos está limitada a 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 la autenticación de Kerberos se soporta para clientes administrativos (wsadmin o clientes Java) deberá 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.
- No se soporta la configuración mixta de LTPA y Kerberos de células cuando algunos de los nodos son nodos de WebSphere Application Server Release 6.x o anteriores.
Información de soporte de para la autenticación de Kerberos
- Confianzas de dominios externos que no están en el mismo bosque
- Confianza de dominio dentro del mismo bosque
- Confianza de reino Kerberos
- Confianza entre bosques
- Confianza externa de bosque
Configuración de Kerberos como mecanismo de autenticación para WebSphere Application Server
Configuración de Kerberos como mecanismo de autenticación para un cliente Java puro
Los usuarios finales pueden configurar un mecanismo de autenticación Kerberos para el cliente Java puro. Para obtener más información, consulte Configuración de un cliente Java para la autenticación Kerberos.