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

El Kerberos El mecanismo de autenticación permite la interoperabilidad con otras aplicaciones (como .NET, DB2® y otros) que apoyan Kerberos autenticación. 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 agregó 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 el Kerberos token para autenticación en el 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 Kerberos El código fuente se puede descargar gratuitamente desde el Instituto de Tecnología de Massachusetts (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

Los beneficios de tener Kerberos como mecanismo de autenticación para WebSphere Application Server Incluya lo siguiente:

  • El protocolo Kerberos es un estándar. Esto permite la interoperabilidad con otras aplicaciones (como .NET, DB2 y otros) que apoyan Kerberos autenticación. 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 Kerberos El ticket de servicio que representa la identidad del cliente se envía a WebSphere Application Server para autenticación.
  • Un cliente Java puede participar en Kerberos SSO utilizando el Kerberos caché de credenciales para autenticarse WebSphere Application Server.
  • J2EE Los clientes de navegador web, servicio web, .NET y que utilizan el protocolo HTTP pueden utilizar el token del mecanismo de negociación GSS-API simple y protegido (SPNEGO) para autenticarse en el WebSphere Application Server y participar en SSO mediante la autenticación web SPNEGO. La compatibilidad con SPNEGO como servicio de autenticación web es nueva en esta versión de WebSphere Application Server.

    Leer acerca de Inicio de sesión único SPNEGO para más información.

  • WebSphere Application Server puede soportar ambos Kerberos y mecanismos de autenticación de autenticación ligera de terceros (LTPA) 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 apoya Kerberos autenticación en un solo Kerberos entorno de reino como se muestra en la siguiente figura:

Figura 1. Autenticación Kerberos en un entorno de reino de Kerberos individual
WebSphere Application Server apoya Kerberos autenticación en un solo Kerberos entorno del reino

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

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 el WebSphere Application Server y el KDC no utilizan el mismo registro de usuarios, entonces un JAAS Es posible que se requiera un módulo de inicio de sesión personalizado para asignar el Kerberos nombre principal al WebSphere nombre de usuario.

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

WebSphere Application Server también apoya Kerberos autenticación en forma cruzada o confiable Kerberos entorno de reino como se muestra en la siguiente figura:

Figura 2. Autenticación Kerberos en un entorno de reino de Kerberos cruzado o de confianza
WebSphere Application Server también apoya Kerberos autenticación en forma cruzada o confiable Kerberos entorno del reino

Cuando el WebSphere Application Server recibe un Kerberos o token SPNEGO para la autenticación, utiliza el Kerberos entidad de servicio (SPN) para establecer un contexto de seguridad con un solicitante. Si se establece un contexto de seguridad, el WebSphere Kerberos El módulo de inicio de sesión siempre extrae una credencial de delegación GSS del cliente y Kerberos ticket y los coloca en el asunto del cliente con otros tokens.

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 el WebSphere Application Server y el KDC no utilizan el mismo registro de usuarios, entonces un JAAS Es posible que se requiera un módulo de inicio de sesión personalizado para asignar el Kerberos nombre principal al WebSphere nombre de usuario.

En esta versión de WebSphere Application Server, la nueva seguridad para múltiples dominios solo admite Kerberos a nivel celular. Todo WebSphere Application Server s debe ser utilizado por el mismo Kerberos reino. Sin embargo, los clientes y/o los recursos backend (como DB2, servidor .NET y otros) que admiten Kerberos la autenticación puede tener su propia Kerberos reino. Sólo se soporta 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.
  • AgregarKerberos reinos de confianza en la consola administrativa haciendo clic en seguridad global >CSIv2 comunicaciones salientes > Reinos de autenticación confiables: salientes .

La siguiente figura muestra un cliente administrativo y de Java que utiliza un Kerberos caché de credenciales para autenticarse WebSphere Application Server con un Kerberos token en un lugar de confianza Kerberos reino:

Figura 3. Usando un Kerberos caché de credenciales para autenticarse WebSphere Application Server con un Kerberos token en un lugar de confianza Kerberos reino
Usando un Kerberos caché de credenciales para autenticarse WebSphere Application Server con un Kerberos token en un lugar de confianza Kerberos reino
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 ticket entre dominios (TGS_REQ) paraRealm A desde elRealm B KDC utilizando el Kerberos caché de credenciales.
  3. El cliente utiliza un ticket entre reinos para solicitar Kerberos billete de servicio paraserver1 (TGS_REQ) delRealm A KDC.
  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, una costumbre JAAS Es posible que se necesite el módulo de inicio de sesión si el KDC y WebSphere Application Server no utilice el mismo registro de usuarios.
  7. El usuario es validado con el registro de usuarios para WebSphere Application Server.
  8. Los resultados (correcto o anomalía) se devuelven al cliente.

La siguiente figura muestra un cliente administrativo y de Java que utiliza un Kerberos nombre principal y contraseña para autenticarse WebSphere Application Server con un Kerberos simbólico:

Figura 4. Usando un Kerberos nombre principal y contraseña para autenticarse WebSphere Application Server con un Kerberos simbólico
Usando un Kerberos nombre principal y contraseña para autenticarse WebSphere Application Server con un Kerberos simbólico.
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, una costumbre JAAS Es posible que se necesite el módulo de inicio de sesión si el KDC y WebSphere Application Server no utilice el mismo registro de usuarios.
  6. El usuario es validado 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 un WebSphere El servidor de aplicaciones se inicia, utiliza el ID y la contraseña del servidor para iniciar sesión en el KDC y luego obtiene el TGT. Posteriormente, utiliza el TGT para solicitar un vale de servicio para comunicarse con otro servidor. si un WebSphere El servidor de aplicaciones utiliza el ID del servidor interno en lugar del ID y la contraseña del servidor, la comunicación de servidor a servidor se realiza mediante un token LTPA.

Cuando un WebSphere Application Server se inicia, utiliza el ID y la contraseña del servidor para iniciar sesión en el KDC y luego 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 del servidor interno en lugar del ID y la contraseña del servidor, la comunicación de servidor a servidor se realiza mediante un token LTPA. En la figura anterior, se producen los sucesos siguientes:

  1. WebSphere Application Server 1 invoca un método, foo(), en una empresa JavaBeans (EJB) ejecutándose 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. La identificación del servidor se valida con el WebSphere registro de usuarios.
Evite problemas: Si una aplicación cliente Java y el servidor de aplicaciones existen en la misma máquina y utilizan diferentes Kerberos nombres de dominio, el tiempo de ejecución utiliza el nombre de dominio predeterminado del Kerberos archivo de configuración. De forma alternativa, puede especificar el nombre de reino durante el proceso de inicio de sesión.
Evite problemas: Kerberos y la autenticación LTPA se puede configurar en múltiples 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 considerar antes de configurar Kerberos como mecanismo de autenticación para WebSphere Application Server

WebSphere Application Server ahora admite tokens SPNEGO en el encabezado HTTP, Kerberos tokens, tokens LTPA y BasicAuth (GSSUP) para 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. Leer acerca de Configurando Kerberos como mecanismo de autenticación utilizando la consola administrativa para 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 verdadero: 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, WebSphere Application Server y las máquinas KDC deben mantener el reloj sincronizado. El procedimiento recomendado es utilizar un servidor de horas para conservar todos los sistemas sincronizados.
Para este lanzamiento de WebSphere Application Server, tenga en cuenta lo siguiente:
  • Completa de extremo a extremo Kerberos El soporte con Tivoli® Access Manager está disponible mediante los siguientes KDC:
    • z/OS
    • Microsoft (único o multi-reino)
    • AIX
    • Linux
  • Ahora puedes configurar y habilitar Kerberos cruzar reinos para WebSphere Application Server y el cliente ligero.
  • WebSphere Application Server función administrativa con Kerberos está limitado 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 Kerberos La autenticación es compatible con clientes administrativos (clientes wsadmin o Java). Debe utilizar el mismo dominio KDC que el WebSphere Application Server administra. De lo contrario, se recomiendan un ID de usuario y una contraseña.
    • Celda mixta Kerberos y la configuración LTPA no es compatible cuando algunos de los nodos están WebSphere Application Server Liberar 6.x nodos o antes.

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 orden como se enumeran en Configurando Kerberos como mecanismo de autenticación para WebSphere Application Server para configurar Kerberos como mecanismo de autenticación para WebSphere Application Server.
Nota: Kerberos El mecanismo de autenticación en el lado del servidor debe ser realizado por el administrador del sistema y en el lado del cliente Java por parte de los usuarios. El archivo keytab de Kerberos no debe estar protegido.

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

Los usuarios finales pueden configurar opcionalmente Kerberos Mecanismo de autenticación para el cliente Java puro. Leer acerca de Configurar un cliente Java para Kerberos autenticación para 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.