Propagación de atributos de seguridad
Con la propagación de atributos de seguridad, WebSphere Application Server puede transportar atributos de seguridad (contenido de sujeto autenticado e información de contexto de seguridad) de un servidor a otro en la configuración. WebSphere Application Server puede obtener estos atributos de seguridad de un registro de usuario de empresa, que consulta atributos estáticos, o de un módulo de inicio de sesión personalizado, que puede consultar atributos estáticos o dinámicos. Los atributos de seguridad dinámicos, que tienen una naturaleza más personalizada, pueden incluir el nivel de autenticación que se utiliza en la conexión, así como la identidad, la ubicación y la dirección IP del interlocutor original, entre otros.
La propagación de atributos de seguridad ofrece servicios de propagación que utilizan la serialización Java™ para los objetos contenidos en el sujeto. No obstante, el código Java debe poder serializar y deserializar estos objetos. El lenguaje de programación Java especifica las reglas sobre cómo se puede serializar un objeto en el código Java. Como pueden surgir problemas cuando se trabaja con distintas plataformas y versiones de software, WebSphere Application Server también ofrece una infraestructura de símbolos que habilita la funcionalidad de serialización personalizada. La infraestructura de señales posee otras ventajas, entre las que se encuentra la posibilidad de identificar la exclusividad de la señal. Esta exclusividad determina cómo se coloca en memoria caché el sujeto y el objetivo de la señal. La infraestructura de símbolos define cuatro interfaces de símbolo de marcador que permiten al tiempo de ejecución de WebSphere Application Server determinar cómo se propaga el símbolo.
Con WebSphere Application Server Versión 6.0 y posteriores, se puede configurar un proveedor de JACC (Java Authorization Contract for Container) personalizado para forzar el control de acceso de las aplicaciones Java EE (Java Platform, Enterprise Edition). Un proveedor de JACC personalizado puede explorar los atributos de seguridad personalizados en el sujeto JAAS interlocutor al tomar las decisiones de control de acceso.
Cuando se autentica una solicitud, los módulos de inicio de sesión determinan si esta solicitud es un inicio de sesión inicial o un inicio de sesión de propagación. Un inicio de sesión inicial es el proceso de autenticación de la información del usuario, normalmente un ID de usuario y una contraseña, y la posterior llamada a las interfaces de programación de aplicaciones (API) del registro de usuario remoto para buscar los atributos seguros que representan los derechos de acceso del usuario. Un inicio de sesión de propagación es el proceso de validación de la información del usuario, normalmente un símbolo LTPA (Lightweight Third Party Authentication), y la posterior deserialización de una serie de símbolos que constituyen objetos personalizados y objetos de la infraestructura de símbolos conocidos en WebSphere Application Server.
- Señal de autorización
- La señal de autorización contiene la mayoría de atributos de seguridad relacionados con la autorización que se propagan. El motor de autorizaciones de WebSphere Application Server utiliza la señal de autorización predeterminada para tomar decisiones de autorización Java EE (Java Platform, Enterprise Edition). Los proveedores de servicios pueden utilizar las implementaciones de la señal de autorización personalizada para aislar los datos en una señal diferente, realizar la serialización y la deserialización personalizada, y tomar decisiones de autorización personalizadas utilizando la información de la señal en el momento adecuado. Si desea obtener más información sobre cómo utilizar e implementar este tipo de señal, consulte Utilización de la señal de propagación predeterminada para propagar atributos de seguridad y Implementación de una señal de propagación personalizada para la propagación de atributos de seguridad.
- Señal de inicio de sesión único (SSO)
- Una señal SingleSignonToken personalizada añadida al sujeto se añade automáticamente a la respuesta como una cookie HTTP y contiene los atributos devueltos a los navegadores web. El método getName de la interfaz de señales
con el método getVersion definen el nombre de la cookie. WebSphere Application Server define una señal SingleSignonToken predeterminada con el nombre del LtpaToken y la Versión 2. El nombre de cookie que se añade es LtpaToken2. No añada información confidencial o
datos descifrados a la cookie de respuesta.
También se recomienda utilizar el protocolo SSL (Secure Sockets Layer) para proteger la solicitud siempre que se utilicen cookies. Con la señal de SSO, los usuarios web pueden autenticarse una vez cuando acceden a los recursos web que están situados en varios servidores WebSphere Application Server. Una señal de SSO personalizada amplía esta funcionalidad al añadir procesos personalizados al escenario de inicio de sesión único. Si desea obtener más información sobre las señales de SSO, consulte Implementación del inicio de sesión único para minimizar las autenticaciones de usuario web. Si desea obtener más información sobre cómo utilizar e implementar este tipo de señal, consulte Utilización de la señal de inicio de sesión único predeterminada con la fábrica de señales predeterminada o personalizada para propagar atributos de seguridad y Implementación de una señal de inicio de sesión único personalizada para la propagación de atributos de seguridad.
- Señal de propagación
- La señal de propagación no se asocia con el usuario autenticado, por lo que no
se almacena en el sujeto. En su lugar, la señal de propagación se almacena en la
hebra y sigue la invocación allí donde vaya. Cuando se envía una solicitud a otro
servidor externo, las señales de propagación de esa hebra se envían con la solicitud
y el servidor de destino ejecuta las señales. Los atributos que se almacenan en la hebra se propagan independientemente de las conmutaciones de usuario RunAS de Java EE (Java Platform, Enterprise Edition).
La señal de propagación predeterminada supervisa y anota todas las conmutaciones de usuario y de host. Puede añadir información adicional a la señal de propagación predeterminada utilizando las interfaces de programación de aplicaciones (API) de WSSecurityHelper. Para recuperar y establecer implementaciones personalizadas de una señal de propagación, puede utilizar la clase WSSecurityPropagationHelper. Si desea obtener más información sobre cómo utilizar e implementar este tipo de señal, consulte Utilización de la señal de propagación predeterminada para propagar atributos de seguridad y Implementación de una señal de propagación personalizada para la propagación de atributos de seguridad.
- Señal de autenticación
- La señal de autenticación fluye a los servidores en sentido descendente y
contiene la identidad del usuario. Este tipo de señal realiza la misma función que
la señal LTPA (Lightweight Third Party Authentication) de las versiones
anteriores. Aunque este tipo de símbolo se reserva normalmente para las operaciones
internas de WebSphere Application Server, puede añadirlo al sujeto y el símbolo se
propaga utilizando el método getBytes de la interfaz de símbolos.
Se utiliza una señal de autenticación personalizada únicamente para el proveedor de servicios que lo añade al sujeto. WebSphere Application Server no lo utiliza para operaciones de autenticación, ya que existe una señal de autenticación predeterminada que se utiliza para la autenticación de WebSphere Application Server. Este tipo de señal está disponible para que el proveedor de servicios identifique cómo utilizan la señal los datos personalizados para tomar decisiones de autenticación personalizadas. Si desea obtener más información sobre cómo utilizar e implementar este tipo de señal, consulte Señal de autenticación por omisión y Implementación de una señal de autenticación personalizada para la propagación de atributos de seguridad.
- Señal de autenticación Kerberos
- El símbolo de autenticación de Kerberos contiene credenciales Kerberos como, por ejemplo, el nombre de principal Kerberos, GSSCredential y la credencial de delegación de Kerberos. Esta señal se propaga al servidor en sentido descendente. Aunque normalmente este tipo de señal se reserva para operaciones internas de WebSphere Application Server, si contiene la credencial GSS, se puede utilizar el método getGSSCredential para extraer dicha credencial. A continuación, se puede poner en el sujeto y se puede utilizar para la aplicación. Esta señal se crea al autenticarse en WebSphere Application Server con la autenticación Kerberos o Web SPNEGO.
Propagación horizontal y propagación en sentido descendente
En WebSphere Application Server, están disponibles la propagación horizontal, que utiliza el inicio de sesión único para las peticiones web, y la propagación en sentido descendente, que utiliza RMI/IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol) para acceder a los enterprise beans.
Propagación horizontal
En la propagación horizontal, los atributos de seguridad se propagan entre los servidores frontales. Los atributos de seguridad serializados, que son el contenido de Subject y las señales de propagación, pueden contener atributos estáticos y dinámicos. La señal de inicio de sesión único (SSO) almacena información adicional específica del sistema que se necesita en la propagación horizontal. La información contenido en la señal SSO indica al servidor receptor dónde se encuentra el servidor de origen y cómo se puede comunicar con él. Asimismo, la señal SSO también contiene la clave para buscar los atributos serializados. Para habilitar la propagación horizontal, debe configurar las características de señal de inicio de sesión único y de propagación de atributos de seguridad de entrada web. Puede configurar estas dos características mediante la consola administrativa.
Cuando hay servidores frontales configurados y están en el mismo dominio de duplicación DRS (Data Replication Service), el servidor de aplicaciones propaga automáticamente la información serializada a todos los servidores que hay dentro del mismo dominio. En la figura 1, la aplicación 1 se despliega en el servidor 1 y el servidor 2, y los dos servidores son miembros del mismo dominio de duplicación DRS. Si se origina una solicitud en la aplicación 1 en el servidor 1 y se redirecciona a la aplicación 1 en el servidor 2, los atributos de inicio de sesión originales se encuentran en el servidor 2 sin solicitudes remotas adicionales.
- Se obtiene la función de recuperar información de inicio de sesión del servidor original.
- No es necesario realizar llamadas remotas de registro de usuario, ya que el servidor de aplicaciones puede regenerar el sujeto a partir de la información serializada. Sin esta función, el servidor de aplicaciones debe realizar entre cinco y seis llamadas remotas.

Implicaciones de rendimiento de la propagación horizontal
Las implicaciones de rendimiento de la llamada remota JMX o DRS dependen del entorno. La llamada remota JMX o DRS se utiliza para obtener los atributos de inicio de sesión originales. La propagación horizontal reduce muchas de las llamadas remotas de registro de usuario en aquellos casos en los que estas llamadas provocan la mayoría de problemas de una aplicación. No obstante, la deserialización de estos objetos también puede provocar la disminución del rendimiento, aunque esta disminución puede ser inferior a la provocada por las llamadas remotas de registro de usuario. Se recomienda probar el entorno con la propagación horizontal habilitada e inhabilitada. En aquellos casos en los que deba utilizar la propagación horizontal para conservar los atributos de inicio de sesión originales, pruebe si el rendimiento es mayor en el entorno con DRS o JMX. Normalmente, se recomienda configurar DRS por motivos de rendimiento y sustitución por anomalía. No obstante, como DRS propaga la información a todos los servidores que hay en el mismo dominio de duplicación (tanto si se accede a los servidores como si no), puede haber una disminución del rendimiento si hay demasiados servidores en ese dominio de duplicación. En este caso, reduzca el número de servidores que hay en el dominio de duplicación o no configure los servidores en un dominio de duplicación DRS. La última sugerencia hace que una llamada remota JMX recupere los atributos, cuando sea necesario, lo cual puede ser la opción más rápida.
Memoria caché de seguridad (WSSecureMap)
En la Figura 1, la memoria caché de seguridad (WSSecureMap) es la memoria caché dinámica que se utiliza para la propagación de atributos de seguridad. La memoria caché WSSecureMap almacena los atributos de seguridad utilizados para volver a crear las credenciales de usuarios; se escala con el número de usuarios que inician sesión. El tiempo de vida predeterminado de WSSecureMap es el mismo que el tiempo de espera de la señal LTPA. Esto es, las entradas de la memoria caché WSSecureMap se liberan cuando el usuario finaliza la sesión. El patrón de uso para WSSecureMap es regular.
El tamaño de la memoria caché WSSecureMap se establece en la consola administrativa. (
). Defina com.ibm.ws.security.WSSecureMapInitAtStartup y com.ibm.ws.security.WSSecureMapSize para controlar cómo se utiliza la memoria caché.Propagación en sentido descendente
En la propagación en sentido descendente, se genera un sujeto en el servidor web frontal, ya sea mediante un inicio de sesión de propagación o un inicio de sesión de registro de usuarios. WebSphere Application Server propaga la información de seguridad en sentido descendente para las invocaciones de enterprise bean cuando estén habilitadas la propagación de entrada y de salida RMI (Remote Method Invocation).
Ventajas de propagación de los atributos de seguridad
La característica de propagación de atributos de seguridad de WebSphere Application Server tiene las siguientes ventajas:
Permite a WebSphere Application Server utilizar la información de atributos de seguridad para operaciones de autenticación y autorización. La propagación de los atributos de seguridad puede eliminar la necesidad de llamadas de registro de usuario en cada salto remoto de una invocación. Las versiones anteriores de WebSphere Application Server sólo propagaban el nombre del usuario autenticado, pero ignoraban otro tipo de información de atributos de seguridad que se tenía que volver a generar en sentido descendente utilizando llamadas remotas de registro de usuario. Para resaltar las ventajas de esta nueva funcionalidad, observe el siguiente ejemplo:
En los releases anteriores, se podía utilizar un servidor proxy inverso (RPSS), como WebSEAL, para autenticar el usuario, recopilar información de grupo y recopilar otros atributos de seguridad. Como se ha indicado anteriormente, WebSphere Application Server aceptaba la identidad del usuario autenticado, pero descartaba el resto de información de atributos de seguridad. Para crear un sujeto JAAS (Java Authentication and Authorization Service) que incluyera los objetos WSCredential y WSPrincipal necesarios, WebSphere Application Server realizaba de 5 a 6 llamadas al registro de usuario. El objeto WSCredential contiene información de seguridad variada que se necesita para autorizar un recurso Java EE. El objeto WSPrincipal contiene el nombre del reino y el usuario que representa el principal del sujeto.
En el release actual del servidor de aplicaciones, la información que se obtiene del servidor proxy inverso se puede utilizar en WebSphere Application Server y propagar en sentido descendente a otros recursos de servidor sin necesidad de realizar llamadas adicionales al registro de usuario. El mantenimiento de la información de atributos de seguridad permite proteger los recursos de servidor tomando las decisiones correspondientes de autorización basadas en la confianza. Las conmutaciones de usuarios que se realicen debido a las configuraciones RunAs de Java EE no hacen que el servidor de aplicaciones pierda la información del interlocutor original. Esta información se almacena en el PropagationToken que se encuentra en la hebra de ejecución.
- Permite a los proveedores de terceros conectarse a señales personalizadas. La interfaz de señales contiene un método getBytes que permite la implementación de la señal para definir la serialización personalizada, los métodos de cifrado o ambos.
- Ofrece la posibilidad de tener varias señales del mismo tipo dentro de un sujeto creado por distintos proveedores. WebSphere Application Server puede manejar varias señales con el mismo objetivo. Por ejemplo, puede tener varias señales de autorización en el sujeto y cada uno tener distintos atributos de autorización generados por distintos proveedores.
- Ofrece la posibilidad de tener un ID exclusivo para cada tipo de señal que se utiliza para formular un identificador de sujeto más exclusivo que el nombre de usuario, en aquellos casos en los que los atributos dinámicos pueden cambiar el contexto de un inicio de sesión de usuario. El tipo de señal tiene un método getUniqueId() que se utiliza para devolver una serie exclusiva para operaciones de memoria caché. Por ejemplo, puede que necesite propagar un ID de ubicación que indique la ubicación desde la que el usuario se conecta al sistema. Este ID de ubicación se puede generar durante el inicio de sesión original utilizando un servidor proxy inverso o la configuración de inicio de sesión WEB_INBOUND, y se puede añadir al sujeto antes de la serialización. También se pueden añadir al sujeto otros atributos y utilizar un ID exclusivo. Se deben tener en cuenta todos los ID exclusivos para la exclusividad del sujeto completo. WebSphere Application Server puede especificar qué es exclusivo en la información del Sujeto, lo cual puede afectar posteriormente al tipo de acceso del usuario al sujeto.