La hebra de ejecución contiene una señal de propagación predeterminada
para que lo utilicen las aplicaciones y la infraestructura de seguridad. El producto
propaga esta señal de propagación predeterminada en sentido descendente
y la señal permanece en la hebra a la que llega la invocación en cada salto.
Acerca de esta tarea
Los
datos deben estar disponibles desde el contenedor de cualquier recurso al que llegue la señal de propagación. Recuerde que debe habilitar la característica de
propagación en cada servidor donde se envíe una solicitud para que funcione la
propagación. Asegúrese de que ha habilitado la propagación de atributos de
seguridad para todas las células del entorno donde desee realizar la
propagación.
Existe una
clase WSSecurityHelper que tiene interfaces de programas de aplicación (API) para
acceder a los atributos de PropagationToken.
En este tema se describen los
escenarios de uso y se incluyen algunos ejemplos. Existe una relación muy estrecha entre la señal de propagación y la característica de área de trabajo. La principal diferencia entre estas
características es que después de añadir atributos a la señal de propagación, no puede modificar los atributos. No puede cambiar estos atributos, por lo que el tiempo de ejecución de
seguridad puede añadir información de auditoría y dejarla ahí el resto de tiempo que
dure la invocación. Cada vez que añade un atributo a una clave específica, se
almacena un objeto ArrayList para que contenga este atributo.
Los nuevos atributos que
se añadan con la misma clave se añadirán al objeto ArrayList. Cuando se llama a
getAttributes, el objeto ArrayList se convierte en una matriz de serie y se conserva el orden. El primer elemento de la matriz de serie es el primer atributo que se ha añadido
para esa clave específica.
En la señal de propagación predeterminada, se mantiene un distintivo de cambios donde se anotan cronológicamente las modificaciones de datos realizadas en la señal. Se realiza un seguimiento de estos cambios para que WebSphere Application Server sepa cuándo debe volver a
enviar la información de autenticación en sentido descendente para que el servidor en sentido descendente
tenga estos cambios. Normalmente, CSIv2 (Common
Secure Interoperability Versión 2) mantiene una sesión entre los servidores de un
cliente autenticado. Si se modifica la señal de propagación, se genera una sesión nueva y, a continuación, se lleva a cabo una autenticación nueva.
Si se realizan muchos
cambios en la señal de propagación durante un método, se realizan muchas
llamadas en sentido descendente. Si cambia la señal antes de realizar
muchas llamadas en sentido descendente o cambia la señal entre cada
llamada en sentido descendente, el rendimiento de seguridad disminuirá.
- Obtenga de la lista de servidores de la señal de propagación
por omisión.
Cada vez que se propaga la señal de propagación y se utiliza para crear el sujeto
autenticado, ya sea horizontalmente o en sentido descendente, el nombre del servidor
de aplicaciones receptor se anota en la señal de propagación. El formato del host es "Célula:Nodo:Servidor", que proporciona acceso al nombre de célula, al
nombre de nodo y al nombre de servidor de cada servidor de aplicaciones que recibe
la invocación.
El siguiente código incluye esta
lista de nombres y se puede invocar desde una aplicación J2EE
(Java™
2 Platform, Enterprise Edition).
El formato de cada servidor de la lista es: célula:nombre_nodo:nombre_servidor.
Por ejemplo, la salida es: miGestor:nodo1:servidor1
String[] server_list = null;
// Si la seguridad está inhabilitada en este servidor de aplicaciones, no realice
la comprobación
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Obtiene la matriz de series server_list
server_list = com.ibm.websphere.security.WSSecurityHelper.getServerList();
}
catch (Exception e)
{
// Realiza el manejo normal de excepciones de la aplicación
}
if (server_list != null)
{
// imprime cada servidor de la lista, siendo el primero
server_list[0]
for (int i=0; i<server_list.length; i++)
{
System.out.println("Server[" + i + "] = " + server_list[i]);
}
}
}
- Obtenga la lista de interlocutores utilizando la API getCallerList.
Se genera una señal de propagación predeterminada cada vez que se establece un usuario
autenticado en la hebra de ejecución o cada vez que alguien intenta añadir atributos
a la señal de propagación. Siempre que se establece un usuario autenticado en la
hebra, el usuario se conecta a la señal de propagación predeterminada. A veces, se puede conectar el mismo usuario varias veces,
si el usuario RunAs es distinto del emisor. La siguiente lista incluye las normas
que se utilizan para determinar si un usuario añadido a la hebra puede iniciar la sesión en la señal de propagación:
- El sujeto actual debe estar autenticado. Por ejemplo, un sujeto no autenticado no
se conecta.
- El sujeto autenticado actual se conecta si no se ha conectado anteriormente un
sujeto.
- El sujeto autenticado actual se conecta si el último sujeto autenticado
conectado no contiene el mismo usuario.
- El sujeto autenticado actual se conecta en cada servidor de aplicaciones
exclusivo implicado en el proceso de propagación.
El siguiente ejemplo de código muestra cómo utilizar la API
getCallerList.
El formato de cada emisor de la lista es: célula:nombre_nodo:nombre_servidor:ámbito:número_puerto/securityName.
Por ejemplo, la salida es:
MiGestor:nodo1:servidor1:ldap.austin.ibm.com:389/jsmith.
String[] caller_list = null;
// Si la seguridad está inhabilitada en este servidor de aplicaciones, no
compruebe la lista de emisores
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Obtiene la matriz de series caller_list
caller_list = com.ibm.websphere.security.WSSecurityHelper.getCallerList();
}
catch (Exception e)
{
// Realiza el manejo normal de excepciones de la aplicación
}
if (caller_list != null)
{
// Imprime cada uno de los emisores de la lista; caller_list[0] es el primer
emisor
for (int i=0; i<caller_list.length;i++)
{
System.out.println("Caller[" + i + "] = " + caller_list[i]);
}
}
}
- Obtenga el nombre de seguridad del primer usuario autenticado,
utilizando la API getFirstCaller:
Siempre que desee saber qué emisor autenticado ha iniciado la solicitud, puede
llamar al método getFirstCaller y la lista de emisores se analiza. No obstante,
este método devuelve sólo el nombre de seguridad del emisor. Si necesita saber algo más
que el nombre de seguridad, llame al método getCallerList y recupere la primera entrada
de la matriz de serie. Esta entrada proporciona información completa del emisor.
El
siguiente ejemplo de código recupera el nombre de seguridad del primer emisor autenticado
utilizando la API getFirstCaller.
Por ejemplo, la salida es:
jsmith.
String first_caller = null;
// Si la seguridad está inhabilitada en este servidor de aplicaciones, no realice
la comprobación
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Obtiene el primer emisor
first_caller = com.ibm.websphere.security.WSSecurityHelper.getFirstCaller();
// Imprime el nombre del emisor
System.out.println("First caller: " + first_caller);
}
catch (Exception e)
{
// Realiza el manejo normal de excepciones de la aplicación
}
}
- Obtenga el nombre del primer servidor de aplicaciones para una solicitud,
utilizando el método getFirstServer.
Siempre que desee saber cuál es el primer servidor de aplicaciones para esta
solicitud, puede llamar directamente al método getFirstServer.
El siguiente ejemplo
de código recupera el nombre del primer servidor de aplicaciones utilizando la API
getFirstServer.
Por ejemplo, la salida es: miGestor:nodo1:servidor1.
String first_server = null;
// Si la seguridad está inhabilitada en este servidor de aplicaciones, no realice
la comprobación
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Obtiene el primer servidor
first_server = com.ibm.websphere.security.WSSecurityHelper.getFirstServer();
// Imprime el nombre del servidor
System.out.println("First server: " + first_server);
}
catch (Exception e)
{
// Realiza el manejo normal de excepciones de la aplicación
}
}
- Añada los atributos personalizados a la señal de propagación predeterminada
utilizando la API addPropagationAttribute.
Puede añadir atributos personalizados a la señal propagación predeterminada para que los utilicen las aplicaciones.
Esta señal sigue a la solicitud en sentido descendente de modo que los atributos están disponibles
cuando son necesarios. Cuando utilice la señal de propagación predeterminada para añadir
atributos, debe comprender las siguientes cuestiones:
- Al añadir información a la señal de propagación, el almacenamiento en memoria caché de sesiones CSIv2 resulta afectado. Añada información con moderación entre las
solicitudes remotas.
- Cuando se añade información con una determinada clave, la información no se
puede eliminar.
- Puede añadir tantos valores a una clave específica como sea necesario. No
obstante, todos los valores deben estar disponibles desde una matriz de serie devuelta en
el orden en el que se han añadido.
- La señal de propagación sólo está disponible en los servidores en los que se han
habilitado la propagación y la seguridad.
- Es necesario el atributo de seguridad de
Java
2, javax.security.auth.AuthPermission
wssecurity.addPropagationAttribute, para añadir atributos a la señal de
propagación por omisión.
- Una aplicación no puede utilizar claves que empiecen por com.ibm.websphere.security
o com.ibm.wsspi.security. Estos prefijos se reservan para el uso del sistema.
El siguiente ejemplo de código muestra cómo utilizar la API
addPropagationAttribute.
// Si la seguridad está inhabilitada en este servidor de aplicaciones,
// no compruebe el estado de la seguridad del servidor
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Especifica la clave y los valores
String key = "mykey";
String value1 = "value1";
String value2 = "value2";
// Establece key y value1
com.ibm.websphere.security.WSSecurityHelper.
addPropagationAttribute (key, value1);
// Establece key y value2
String[] previous_values = com.ibm.websphere.security.WSSecurityHelper.
addPropagationAttribute (key, value2);
// Nota: previous_values debe contener value1
}
catch (Exception e)
{
// Realiza el manejo normal de excepciones de la aplicación
}
}
- Obtenga los atributos personalizados con la API getPropagationAttributes.
Los atributos personalizados se añaden a la señal de propagación predeterminada
utilizando la API addPropagationAttribute. Recupere estos atributos utilizando la API
getPropagationAttributes. Est señal sigue a la solicitud en sentido descendente de modo que los atributos están disponibles
cuando son necesarios. Cuando utilice la señal de propagación por omisión para recuperar
atributos, debe comprender las siguientes cuestiones:
- La señal de propagación sólo está disponible en los servidores en los que se han
habilitado la propagación y la seguridad.
- Es necesario el permiso de seguridad de
Java
2, javax.security.auth.AuthPermission
"wssecurity.getPropagationAttributes", para recuperar atributos de la señal de propagación por omisión.
Consulte el apartado
Adición de atributos
personalizados al PropagationToken por omisión para añadir atributos
utilizando la API addPropagationAttributes.
El siguiente ejemplo de código muestra cómo utilizar la API
getPropagationAttributes.
// Si la seguridad está inhabilitada en este servidor de aplicaciones, no realice
la comprobación
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
String key = "mykey";
String[] values = null;
// Establece key y value1
values = com.ibm.websphere.security.WSSecurityHelper.
getPropagationAttributes (key);
// Imprime los valores
for (int i=0; i<values.length; i++)
{
System.out.println("Value[" + i + "] = " + values[i]);
}
}
catch (Exception e)
{
// Realiza el manejo normal de excepciones de la aplicación
}
}
Por ejemplo, la salida es:
Value[0] = value1
Value[1] = value2
- Modifique la configuración de fábrica de señales de propagación para utilizar una fábrica de señales distinta de la fábrica de señales predeterminada.
Cuando WebSphere Application Server genera un símbolo de propagación por omisión, el servidor de
aplicaciones utiliza la clase TokenFactory especificada mediante la propiedad
com.ibm.wsspi.security.token.propagationTokenFactory.
La fábrica de señales predeterminada que se especifica para esta propiedad se denomina
com.ibm.ws.security.ltpa.AuthzPropTokenFactory.
Esta fábrica de señales codifica los datos de la señal de propagación y no cifra los datos. Dado que la señal de propagación generalmente
fluye a través de CSIv2 utilizando SSL (Secure Sockets Layer), no es necesario cifrar la señal. No obstante, si necesita seguridad adicional para la señal de propagación, puede
asociar una implementación diferente de la fábrica de señales a esta propiedad para obtener el cifrado. Por ejemplo, si decide asociar la fábrica de señales com.ibm.ws.security.ltpa.LTPAToken2Factory a esta propiedad, la señal se cifra con AES. No obstante, tiene que equilibrar la influencia en el rendimiento con sus
necesidades de seguridad. Añadir información confidencial a la señal de propagación es un buen motivo para
cambiar la implementación de la fábrica de señales por una que cifre y no que simplemente codifique.
- Abra la consola de administración.
- Pulse Seguridad > Seguridad global.
- Pulse Propiedades personalizadas.
- Realice su propio inicio de sesión y cifrado de la señal
de propagación por omisión.
Si desea realizar su propio inicio de sesión y cifrado de la señal de propagación por omisión, debe implementar las clases siguientes:
- com.ibm.wsspi.security.ltpa.Token
- com.ibm.wsspi.security.ltpa.TokenFactory
La implementación de la fábrica de señales crea una instancia y valida la implementación de la señal. Puede utilizar las claves LTPA (Lightweight Third Party Authentication)
y pasarlas al método de inicialización de la fábrica de señales o puede utilizar sus propias
claves. Si usa sus propias claves, deben ser las mismas en todas partes para validar
las señales que se generaron utilizando dichas claves. Consulte la documentación de la API, disponible mediante un enlace de la primera página
del centro de información, para obtener más información sobre cómo implementar
su propia fábrica de señales.
- Asocie la fábrica de señales con la señal de propagación predeterminada.
- Abra la consola de administración.
- Pulse Seguridad > Seguridad global.
- Pulse Propiedades personalizadas.
- Localice la propiedad com.ibm.wsspi.security.token.propagationTokenFactory y compruebe que el valor de esta propiedad coincida con la implementación de la fábrica de señalespersonalizada.
- Compruebe que las clases de implementación se hayan colocado en el directorio
raíz_servidor_aplicaciones/classes,
de modo que el cargador de clases de WebSphere Application Server pueda cargar las
clases.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Compruebe que las clases de implementaciones estén en el directorio
${USER_INSTALL_ROOT}/classes de modo que el cargador de clases de WebSphere Application Server
pueda cargar las clases.
Compruebe que el perfil de usuario QEJBSVR tenga autorización de lectura, grabación y ejecución
(*RWX) sobre el directorio de clases. Puede utilizar el mandato WRKAUT, (Trabajar con autorización), para ver los permisos de autorización para el directorio.