Puede invocar el gestor de seguridad de flujos de mensajes en cualquier punto del flujo de mensajes, entre un nodo de entrada y un nodo de salida o solicitud, utilizando un nodo SecurityPEP.
En el diagrama siguiente se muestra un flujo de mensajes de ejemplo y ofrece una visión general de la secuencia de sucesos que se producen cuando un nodo de entrada recibe un mensaje de entrada que no tiene habilitada la seguridad (o que no tiene ningún perfil de seguridad asociado) y posteriormente lo procesa un nodo
SecurityPEP en el flujo de mensajes:

En los pasos siguientes se explica la secuencia de sucesos que se producen cuando llega un mensaje a un nodo de entrada que no tiene habilitada la seguridad (o que no tiene asociado ningún perfil de seguridad). Los números corresponden a los del diagrama anterior:
- Puede utilizar un nodo SecurityPEP en cualquier punto de un flujo de mensajes entre un nodo de entrada y un nodo de salida o de solicitud. El nodo SecurityPEP habilita la seguridad que se debe aplicar a un flujo de mensajes en las situaciones siguientes:
- Cuando el nodo de entrada del flujo de mensajes no tiene habilitada la seguridad (por ejemplo, los nodos FileInput, TCPIPClientInput, SAPInput y JMSInput).
- Cuando el nodo de entrada de flujos de mensajes tiene habilitada la seguridad y se puede configurar para llevar a cabo operaciones de autenticación, pero el flujo de mensajes es necesario para realizar algunos direccionamientos o filtrados antes de saber a qué función empresarial se debe invocar; como resultado, deberá realizar una autorización posteriormente en la lógica del flujo de mensajes.
- Cuando el flujo de mensajes incluye varios nodos de salida o solicitud, que requieren que se lleve a cabo una correlación de identidad específica antes de cada nodo para obtener las señales de seguridad correspondientes para la propagación.
El árbol de mensajes que se propaga al nodo SecurityPEP incluye campos de identidad del árbol de propiedades. Estos campos están vacíos, a menos que un nodo de entrada con la seguridad habilitada (o un nodo SecurityPEP anterior) ya haya extraído señales y haya llevado a cabo posiblemente algunas operaciones de seguridad.
- Cuando un mensaje llega a un SecurityPEP, la presencia de un perfil de seguridad asociado al nodo indica si se ha configurado la seguridad del flujo de mensajes. Se llama al gestor de seguridad del intermediario para leer el perfil, que especifica la combinación de propagación, autenticación, autorización y correlación que se debe realizar con la identidad del mensaje. También se especifica el proveedor de seguridad externo (también conocido como
Policy Decision Point o PDP) que se debe utilizar.
Puede crear perfiles de seguridad utilizando el mandato mqsicreateconfigurableservice o un editor en WebSphere Message Broker Explorer. A continuación, utilice el editor de archivador de intermediarios para configurar el perfil de seguridad en un nodo individual o en el flujo de mensajes completo. Si asocia el perfil de seguridad al flujo de mensajes, el perfil de seguridad se aplicará a todos los nodos de entrada y salida con seguridad habilitada y a los nodos SecurityPEP del flujo de mensajes. Sin embargo, un perfil de seguridad que esté asociado a un nodo individual tendrá prioridad antes un perfil de seguridad que esté asociado al flujo de mensajes. Se proporcionan perfiles de seguridad predefinidos para establecer la propagación de identidad y para establecer de forma explícita un nodo sin seguridad.
- Si se asocia un perfil de seguridad al nodo SecurityPEP o a un flujo de mensajes, el nodo extrae la información de identidad del árbol de mensajes en función de la configuración del nodo y establece los elementos de identidad de origen en la carpeta Propiedades. Si el nodo establece un tipo de señal de Señal actual, se utilizarán las señales de identidad existentes en los campos de propiedades de identidad correlacionada (si los hay); si no hay hay señales de identidad en los campos de propiedades de identidad correlacionada, se utilizarán las señales de los campos de propiedades de identidad de origen. Si las señales de seguridad no se pueden extraer satisfactoriamente, se genera una excepción de seguridad y se propaga al terminal de anomalías (si está cableado).
- Si se especifica la autenticación en el perfil de seguridad, el gestor de seguridad llama al proveedor de seguridad configurado para autenticar la identidad. Una anomalía provoca que se devuelva al nodo una excepción de seguridad. Los proveedores de seguridad que admite el intermediario de mensajes para la autenticación son servidores de señales de seguridad LDAP compatibles con WS-Trust v1.3 (como, por ejemplo, TFIM V6.2) y TFIM V6.1.
Se proporciona una memoria caché de seguridad para el resultado de autenticación, lo que permite que los mensajes posteriores (con las mismas credenciales) que lleguen al flujo de mensajes se completen con el resultado copiado en la memoria caché, si no ha caducado.
- Si se especifica la correlación de identidad en el perfil de seguridad, el gestor
de seguridad llama al proveedor de seguridad configurado para correlacionar la identidad con una identidad
alternativa. Una anomalía provoca que se devuelva al nodo una excepción de seguridad. De lo contrario, la información de
identidad correlacionada se establece en Elementos de identidad correlacionados
de la carpeta Propiedades.
Los proveedores de seguridad que admite el intermediario de mensajes para la correlación de identidad son servidores de señales de seguridad compatibles con WS-Trust V1.3 (como, por ejemplo, TFIM V6.2) y TFIM V6.1.
Se proporciona una memoria caché de seguridad para el resultado de la correlación de identidad.
- Si se especifica la autorización en el perfil de seguridad, el gestor de seguridad
llama al proveedor de seguridad configurado para autorizar que la identidad (ya sea correlacionada o fuente) tenga acceso a este flujo
de mensajes.
Una anomalía provoca que se devuelva al nodo una excepción de seguridad.
Los proveedores de seguridad que admite el intermediario mensajes para su autorización son servidores de seguridad LDAP combatibles con WS-Trust V1.3 (como, por ejemplo, TFIM V6.2) y TFIM V6.1.
Se proporciona una memoria caché de seguridad para el resultado de autorización.
- Cuando se ha completado todo el proceso de seguridad, o cuando el gestor de seguridad del flujo de mensajes genera una excepción de seguridad, se devuelve el control
al nodo SecurityPEP.
Cuando se devuelve una excepción de seguridad al nodo SecurityPEP, la excepción se propaga al terminal de anomalías si está conectado o se devuelve al nodo anterior como excepción recuperable. El nodo SecurityPEP se propaga al terminal de salida solamente si todas las operaciones configuradas en el perfil de seguridad asociado se han completado satisfactoriamente.
- El mensaje, incluyendo la carpeta Propiedades llena y la información de identidad
de origen y correlacionada, se propaga hacia abajo en el flujo de mensajes.
- Cuando esté desarrollando
un flujo de mensajes, puede utilizar los campos de identidad de la carpeta Propiedades
para el proceso de aplicaciones (por ejemplo, el direccionamiento basado en identidad
o la creación de contenido basada en identidad). Si la identidad se debe propagar a un mensaje de salida desde un nodo de salida o de solicitud que no dé soporte a la propagación de la señal, puede utilizar un nodo Compute (incluido un nodo Compute, JavaCompute, PHPCompute o Mapping) para mover la señal de identidad a la ubicación de la cabecera de transporte o del cuerpo del mensaje que convenga.
- Cuando el mensaje alcanza un nodo de salida, un perfil de seguridad asociado al nodo puede indicar si se debe tomar una identidad de la carpeta Propiedades y propagarla cuando se envía el mensaje. Solamente los nodos específicos del transporte pueden propagar señales que son los valores predeterminados para el transporte; los demás tipos de señales deben gestionarlos un nodo Compute, tal como se describía anteriormente.