La correlación de identidad es la transformación de una señal de seguridad de un formato a otro, o la federación de una identidad de un dominio a otra identidad equivalente en otro dominio.
WebSphere Message Broker proporciona soporte para la correlación de identidades (conocido también como federación de identidades), así como para la emisión y el intercambio de señales. La correlación de identidades es el proceso mediante el que se correlaciona una identidad de un dominio con una identidad de otro dominio. Por ejemplo, puede correlacionar User001 del dominio eSellers con eSellerUser01 del dominio eShipping. El proceso de emisión e intercambio de señales implica correlacionar un tipo de señal con una señal de un tipo distinto. Por ejemplo, una señal Username y Password entrante de un cliente a través de MQ puede correlacionarse con una aserción SAML equivalente, para propagarse luego a una llamada de servicios web. Como alternativa, puede intercambiar una aserción SAML 1.1 de una aplicación cliente para una aserción SAML 2.0 equivalente para un servidor de fondo actualizado.
El gestor de seguridad de WebSphere Message Broker soporta operaciones de correlación a través de servidores de señales de seguridad (STS) compatibles con WS-Trust V1.3, como IBM® Tivoli Federated Identity Manager (TFIM) V6.2. La correlación se lleva a cabo para nodos SecurityPEP y nodos de entrada que tienen un perfil de seguridad asociado que incluye una operación de correlación configurada con un STS WS-Trust V1.3.
WS-Trust V1.3 (TFIM V6.2) también puede seleccionarse para autenticación y autorización en el perfil. No obstante, si hay más de una operación de seguridad asociada con el perfil de seguridad, sólo se emite una solicitud WS-Trust al STS. Como consecuencia de ello, el STS debe configurarse para realizar todas las operaciones necesarias. Por ejemplo, si se especifica un servidor TFIM V 6.2, la cadena de módulos TFIM que se invoca debe incluir los módulos de validación, autorización y emisión necesarios. Si requiere que cada operación se lleve a cabo a través de una llamada WS-Trust distinta, debe utilizar una serie de nodos SecurityPEP, cada uno asociado con un perfil de seguridad distinto configurado sólo para una operación de seguridad (autenticación, autorización o correlación).
Si el perfil de seguridad especifica sólo una correlación con STS WS-Trust v1.3, la solicitud se envía con un tipo de solicitud Emitir, mientras que un conjunto combinado de operaciones de seguridad envía un tipo de solicitud Validar. Si se incluye la correlación, el STS debe devolver una señal en su respuesta, aun cuando sea la señal original; en caso contrario, se produce un error.
Para proporcionar compatibilidad con versiones anteriores de WebSphere Message Broker, también se ofrece soporte para TFIM V6.1.
En el intermediario, la correlación de identidades se lleva a cabo en el nodo de entrada o en el nodo SecurityPEP, después de la autenticación, pero antes de la autorización. La identidad de origen se pasa a un correlacionador de identidades para proceso. Si se configura la correlación y la autorización, la operación de autorización utiliza la señal de salida correlacionada, en lugar de utilizar la señal de origen, lo que implica que la autorización se lleva a cabo en la identidad federada.
La correlación no se realiza en los nodos de salida, incluso si el nodo se ha configurado con un perfil de seguridad.
WebSphere Message Broker soporta la correlación entre cualquier tipo de señal de seguridad que esté soportado por el proveedor de seguridad configurado. Para obtener más información acerca del soporte proporcionado, consulte Identidad.
Cuando se correlaciona desde un certificado X.509, TFIM puede validar el certificado pero no se puede verificar la identidad del remitente original. Sin embargo, si es necesario, el nodo SOAPInput puede realizar esta comprobación de integridad de verificación. Para obtener más información, consulte Mecanismos de WS-Security.
Para obtener más información acerca del uso de TFIM V6.2 para la correlación, consulte Autenticación, correlación y autorización con TFIM V6.2 y TAM.
Para obtener más información acerca del uso de TFIM V6.1, consulte Autenticación, correlación y autorización con TFIM V6.1 y TAM.
Al desarrollar un flujo de mensajes puede implementar una correlación de señal personalizada para utilizarla para la propagación de identidad. Por ejemplo, puede implementar una correlación de señal personalizada utilizando un nodo Compute (que puede ser un nodo Compute, JavaCompute o PHPCompute) a continuación del nodo de entrada. En el nodo Compute, puede leer los valores de identidad de origen de la carpeta Propiedades, procesarlos y, a continuación, escribir los valores de identidad nuevos que se deben correlacionar con los campos de identidad. Si no se proporciona ninguna identidad en el mensaje, igualmente podrá utilizar un nodo Compute para insertar algunas credenciales de identidad en los campos de identidad correlacionados. Entonces los nodos subsiguientes utilizan los campos de identidad correlacionados en lugar de los campos de identidad de origen. Las operaciones de seguridad que se configuran en el nodo de entrada se llevan a cabo utilizando la identidad de origen antes de crear una identidad nueva en los campos de identidad correlacionada (utilizando el nodo Compute). Sin embargo, puede incluir un nodo SecurityPEP después que el nodo Compute haya creado una identidad correlacionada nueva.