En WebSphere Message Broker, una identidad es una señal de seguridad que identifica unívocamente a un individuo, o que proporciona un conjunto de afirmaciones que pueden validarse.
Cuando se configura un nodo SecurityPEP o un nodo de entrada soportado con un perfil de seguridad, la identidad extraída se mantiene en el intermediario en forma de ocho propiedades en la carpeta Propiedades de la estructura de árbol de mensajes. Estas propiedades definen dos identidades en el intermediario: de origen y correlacionada. Para las entidades de origen y correlacionadas, se mantienen valores para las propiedades Type, Token, Password, e IssuedBy:
La propiedad Tipo de señal de identidad de los nodos de entrada con seguridad habilitada puede establecerse en un valor de la propiedad Valor predeterminado de transporte, que hace que el tipo de señal se cree a partir de la cabecera o los campos de identidad predeterminada del transporte. Para WebSphere MQ, Valor predeterminado de transporte proporciona un tipo de identidad de NombreUsuario. Para HTTP, Valor predeterminado de transporte proporciona un tipo de identidad de NombreUsuario y Contraseña. La propiedad del tipo de señal de identidad en el nodo SecurityPEP se puede establecer en Señal actual, que la habilita para utilizar la identidad de los campos Carpeta de propiedades en lugar de extraer una identidad nueva del mensaje.
La tabla siguiente muestra el soporte que se proporciona (mediante el gestor de seguridad de flujo de mensajes y los proveedores de seguridad externos) para la extracción de diferentes tipos de señales de seguridad. Para obtener información sobre los tipos de señal que admiten propagación de identidad, consulte Propagación de la señal de seguridad e identidad.
Tipo de señal (formato) | Soporte de gestor de seguridad de intermediario para la extracción de señales | Soporte de proveedor de seguridad externa |
---|---|---|
Nombre de usuario | Se da soporte a las señales de nombre de usuario para su extracción mediante los nodos siguientes:
La señal se obtiene de una de las cabeceras del transporte siguiente:
El valor de serie literal literal utilizado por el intermediario (y que puede utilizarse para especificar el tipo de señal en un programa ESQL o Java™) es nombreUsuario. |
LDAP: Autorización |
Nombre de usuario y contraseña |
Se da soporte a las señales de nombre de usuario y contraseña para su extracción mediante los nodos siguientes:
La señal se obtiene de una de las cabeceras del transporte siguiente:
La señal de contraseña puede llevar a cabo una acción de borrado de contraseña de texto o PassTicket RACF. Si está utilizando un STS de WS-Trust V1.3 (como, por ejemplo, TFIM V6.2), puede utilizarlo para correlacionar (emitir) o validar PassTickets RACF, especificando el tipo de señal como NombreUsuario y contraseña. Este soporte está disponible con los nodos de entrada con seguridad habilitada y con los nodos SecurityPEP. El valor de serie literal utilizado por el intermediario (y que puede utilizarse para especificar el tipo de señal en un programa ESQL o Java) es usernameAndPassword. |
LDAP:
|
Aserción SAML | Se da soporte a las señales SAML para su extracción mediante los nodos siguientes:
La señal se obtiene de uno de estos lugares:
El valor de serie literal literal utilizado por el intermediario (y que puede utilizarse para especificar el tipo de señal en un programa ESQL o Java) es SAML. |
STS WS-Trust V1.3 (incluyendo TFIM V6.2):
|
Kerberos GSS v5 AP_REQ | Se da soporte a los tiquets Kerberos para su proceso mediante el gestor de seguridad de flujo de mensajes desde el nodo SecurityPEP. Los siguientes nodos SOAP dan soporte a un perfil de señal Kerberos de WS-Security, pero en este caso, se comunica directamente con el KDC (Key Distribution Center) de Kerberos y la carpeta de propiedades se rellena con una señal de nombre de usuario que representa el asunto Kerberos:
La señal se obtiene de cualquier parte del árbol de mensajes en un nodo SecurityPEP, si se ha especificado la ubicación de la señal utilizando una expresión XPath o una vía de acceso ESQL. El valor de serie literal utilizado por el intermediario (y que puede utilizarse para especificar el tipo de señal en un programa ESQL o Java) es kerberosTicket. |
STS WS-Trust V1.3 (incluyendo TFIM V6.2):
|
Señal LTPA v2 | Se da soporte a las señales LTPA para su extracción mediante los nodos siguientes:
La señal se obtiene de cualquier parte del árbol de mensajes en un nodo SecurityPEP, si se ha especificado la ubicación de la señal utilizando una expresión XPath o una vía de acceso ESQL. El valor de serie literal literal utilizado por el intermediario (y que puede utilizarse para especificar el tipo de señal en un programa ESQL o Java) es LTPA. |
STS WS-Trust V1.3 (incluyendo TFIM V6.2):
|
Certificado X.509 | Se da soporte a las señales X.509 para su extracción mediante los nodos siguientes:
La señal se obtiene de uno de estos lugares:
El valor de serie literal utilizado por el intermediario (y que puede utilizarse para especificar el tipo de señal en un programa ESQL o Java) es X.509. |
TFIM V6.1:
|
Señal WSSE universal | Se da soporte a las señales WSSE universal para su extracción solamente mediante el nodo SecurityPEP. La señal se obtiene de cualquier parte del árbol de mensajes en un nodo SecurityPEP, si se ha especificado la ubicación de la señal utilizando una expresión XPath o una vía de acceso ESQL. El valor de serie literal utilizado por el intermediario (y que puede utilizarse para especificar el tipo de señal en un programa ESQL o Java) es UniversalWsse. |
STS WS-Trust V1.3 (incluyendo TFIM V6.2):
|
La identidad de origen la establece el nodo SecurityPEP o nodo de entrada sólo si se asocia un perfil de seguridad con el nodo. La información para completar estos campos se encuentra normalmente en las cabeceras de un mensaje pero también puede estar ubicada en el cuerpo (a condición de que el nodo se haya configurado con una referencia de vía de acceso ESQL o XPath para las diversas propiedades). Si están disponibles varias identidades (por ejemplo si está utilizando la agregación de mensajes), se utiliza la primera identidad. La extracción de señal es específica de transporte y sólo se puede realizar utilizando transportes que soportan el flujo de identidades. Estos transportes son: WebSphere MQ, HTTP(S) y SOAP. Consulte el Nodo MQInput y el Nodo HTTPInput para obtener más información.
Puede modificar los valores en las propiedades (por ejemplo desde ESQL), pero no grabar en los valores de IdentitySource*. Por ejemplo, puede crear una rutina de correlación de identidad personalizada en ESQL o Java utilizando los valores deIdentitySource* para crear valores de IdentityMapped* personalizados.
-- Parse the mapped SAML2.0 token in the properties folder and set it in the message body
CREATE LASTCHILD OF OutputRoot DOMAIN('XMLNSC') PARSE(InputRoot.Properties.IdentityMappedToken,
InputProperties.Encoding, InputProperties.CodedCharSetId);
Para establecer
las señales SAML o Universal WSSE en los campos de propiedades, debe obtener la corriente de bits
de un árbol; por ejemplo, utilizando la función
ASBITSTREAM de ESQL.