Generación de señales SPNEGO para solicitudes JAX-WS de salida
La clase com.ibm.wsspi.security.auth.krb5.SpnegoTokenHelper se puede utilizar para crear una señal SPNEGO mediante programación.
- Una señal solicitada utilizando credenciales nativas de Windows. Cuando el proceso de WebSphere Java™ se ejecuta en un sistema Windows con un ID de usuario, que tiene credenciales Kerberos, el sistema operativo Windows mantiene un tíquet de otorgamiento de tíquet (TGT) de Kerberos para dicho usuario. La clase SpnegoTokenHelper utiliza este TGT para solicitar una señal SPNEGO que se puede solicitar para un ServicePrincipalName (SPN) para el sistema de servicio de destino.
- Una señal solicitada utilizando credenciales Kerberos almacenadas en memoria caché. En un sistema en el que un usuario ha iniciado una sesión, normalmente utilizando herramientas como la herramienta de Java kinit, las credenciales Kerberos del usuario se almacenan en un archivo de memoria caché llamado krb5cc_<id_usuario>. De forma alternativa, se puede crear un archivo de tabla de claves que contiene la clave de un usuario utilizando una serie de herramientas como, por ejemplo, la herramienta ktpass de Microsoft o la herramienta ktab de Java. Estos archivos contienen una copia de la clave Kerberos del usuario que se puede utilizar para obtener un tíquet de otorgamiento de tíquet (TGT) para dicho ID de usuario. La clase SpnegoTokenHelper utiliza este TGT para solicitar una señal SPNEGO que se puede solicitar para un ServicePrincipalName (SPN) para el sistema de servicio de destino.El proceso de WebSphere se debe configurar para utilizar krb5cc_<id_usuario> o el archivo de tabla de claves. También debe proporcionarse el UserPrincipalName (UPN) para la credencial almacenada en memoria caché en el archivo.
- Una señal solicitada utilizando una credencial Kerberos que utiliza un ID de usuario y una contraseña. En este escenario, el proceso de WebSphere utiliza la clase SpnegoTokenHelper para conectarse al servidor de distribución de claves Kerberos con el ID de usuario y la contraseña proporcionados para obtener un tíquet de otorgamiento de tíquet (TGT). A continuación, la clase solicita la señal SPNEGO con este TGT. La clase SpnegoTokenHelper necesita el ServicePrincipalName (SPN) para el sistema de servicio de destino y el ID de usuario y la contraseña.
- Una señal solicitada utilizando una credencial Kerberos que existe en un sujeto
de Java. El sujeto puede obtener una credencial
Kerberos de uno de los modos siguientes:
- El usuario ha iniciado sesión en una aplicación web utilizando autenticación web SPNEGO de entrada. Sólo es necesario configurar y habilitar la autenticación web SPNEGO en WebSphere Application Server para esta opción. El ID de usuario asociado con el servicio SPNEGO de entrada debe habilitarse para la delegación de Kerberos completa.
- Se ha recibido una solicitud web JAX-WS que contiene una señal Kerberos WS-Security. El ID de usuario asociado con la solicitud de servicio web de entrada debe habilitarse para la delegación de Kerberos completa.
- El usuario ha iniciado sesión con el ID de usuario y la contraseña y WebSphere Application Server se ha configurado para autenticación LTPA y Kerberos.
- Se ha recibido una solicitud de servicio web JAX-WS que contiene una señal de nombre de usuario con una contraseña y WebSphere Application Server se ha configurado para autenticación LTPA y Kerberos. La clase SpnegoTokenHelper utilizará las credenciales del sujeto para solicitar un tíquet de servicio para el ServicePrincipalName (SPN) para el sistema de servicio de destino. Los métodos asociados con este enfoque necesitan un parámetro Subject (Sujeto) de Java, además del valor SPN.
- Una señal solicitada utilizando una credencial Kerberos en el Sujeto de Java de la identidad del emisor actual. Este enfoque es similar al enfoque anterior y se utiliza un método de conveniencia en la clase SpnegoTokenHelper para obtener la identidad del emisor actual. Se siguen aplicando las restricciones en el sujeto previamente mencionado. Los métodos asociados con este enfoque sólo necesitan el ServicePrincipalName (SPN).
Los 5 enfoques tienen dos variaciones; en la primera variación, se puede especificar el tiempo de vida de la señal y un distintivo booleano que indica que debe solicitarse una señal delegable. En la segunda variación, el tiempo de vida de la señal es infinito y la señal no se solicita como delegable.
Los 5 enfoques devuelven una serie (por ejemplo, “Negotiate YIIFKwYG….”). Es responsabilidad del programador utilizar la serie para inyectar la cabecera Authorization de salida.
- Notas para credenciales nativas
- La memoria caché de credenciales de inicio de sesión de
Microsoft Kerberos (MSLSA) se basa en la capacidad de
extraer el tíquet de Kerberos completo, incluida la clave de sesión de la memoria caché de
credenciales de inicio de sesión de Kerberos (LSA). En un intento de aumentar la seguridad, Microsoft ha implementado una característica mediante la que
ya no se exportan las claves de sesión para Ticket Getting Tickets, lo que puede hacer que sean
inservibles para IBM® JGSS cuando se intenta solicitar más tíquets de servicio. Esta nueva característica se ha encontrado en Windows 2003
Server y sistemas posteriores. Microsoft ha proporcionado la siguiente clave de registro para inhabilitar esta nueva característica:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters AllowTGTSessionKey = 0x01 (DWORD)
- Requisitos del archivo de configuración de Kerberos
- El archivo de configuración de Kerberos debe estar correctamente configurado independientemente
del enfoque.
- El modo en que el proceso de WebSphere accede al centro de distribución de claves (KDC) debe configurarse correctamente mediante las stanzas [realms] y [domain_realm].
- Los tipos de cifrado que deben utilizarse en la stanza [libdefaults] deben especificar los valores default_tkt_enctypes y default_tgs_enctypes.
- La stanza [libdefaults] debe incluir lo siguiente:
- forwardable = true
- renewable = true
- noaddresses = true
- La stanza [libdefaults] debe definir un valor clockskew razonable.
Referencia a una tabla de claves
JAASClientUsingKeytab {
com.ibm.security.auth.module.Krb5LoginModule required useKeytab="file:///C:\\WAS\\ND855\\profiles\\AppSrv01\\config\\cells\\testserver-vmCell01-855\\cachKerbUser.keytab" credsType=both
tryFirstPass=true forwardable=true noAddress=true;
};
Ejemplos de utilización de la clase SPNEGOTokenHelper
En el primer ejemplo, se obtiene una señal SPNEGO para un usuario basándose en las credenciales nativas de Windows bajo las cuales se ejecuta el proceso de WebSphere.
String nativeToken = SpnegoTokenHelper.buildSpnegoAuthorizationStringFromNativeCreds(spn, GSSCredential.INDEFINITE_LIFETIME, false);
- spn - ServicePrincipalName del sistema para el cual se destina la señal SPNEGO. Por ejemplo, sería una serie como “HTTP/service.host.ibm.com@IBM.COM”
- Tiempo de vida del contexto. En el ejemplo GSSCredential.INDEFINITE_LIFETIME
- Delegate (Delegar) - Si la señal incluye credenciales delegables. En el ejemplo, la señal no incluirá credenciales delegables.
El segundo ejemplo muestra la utilización de una tabla de claves o un archivo de credenciales almacenado en memoria caché. En este ejemplo, se utiliza el método más sencillo (no se especifica ningún tiempo de vida y la señal no es delegable).
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromUpn(spn,upn, jaas);
- upn - UserPrincipalName de la identidad del archivo. Por ejemplo, alice@IBM.COM.
- Jaas - El nombre de la configuración JAAS que se ha de utilizar (que hace referencia al keytab del archivo de credenciales en caché, por ejemplo, “JAASClientUsingKeytab”.
El tercer ejemplo muestra la utilización de un ID de usuario y una contraseña para generar una señal Kerberos.
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromUseridPassword(spn,userid,pwd,1000,true);
Los nuevos parámetros introducidos son userid (ID de usuario) y password (contraseña). El ejemplo también muestra cómo solicitar una señal no infinita, la señal se genera para 1000 segundos y se puede delegar (el servicio que está asociado con este spn debe estar habilitado para la delegación).
El cuarto ejemplo muestra un mecanismo que se utiliza con poca frecuencia en el que se empieza con un sujeto que contiene una credencial Kerberos. Este ejemplo se muestra para completar la información pero, a menos que controle mediante programación la creación del sujeto, lo más probable es que no utilice este método.
String token = buildSpnegoAuthorizationFromSubject(spn, subject);
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromCallerSubject(spn);
Para obtener información más detallada, consulte Generación de señales SPNEGO para solicitudes JAX-WS de salida utilizando enlaces del conjunto de políticas de cliente.