WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Identidad

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:

Diagrama que muestra las ocho propiedades de identidad.

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.

Tabla 1. Soporte para los tipos de señales de seguridad - extracción de señales
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:
  • HTTPInput
  • MQInput
  • SCAInput
  • SCAAsyncResponse
  • SecurityPEP
  • SOAPInput
La señal se obtiene de una de las cabeceras del transporte siguiente:
  • MQ
    • Del ID de usuario MQMD
  • HTTP
    • De la cabecera HTTP BasicAuth que contiene únicamente una parte de nombre de usuario
  • SOAP
    • De una cabecera UsernameToken de WS-Security. El conjunto de políticas y el enlace (asociado con el nodo SOAP) deben definir un perfil de nombre de usuario y contraseña y wsse:UsernameToken sólo debe contener un elemento wsse:Username.
    • Del asunto Kerberos de una cabecera WS-Security. El conjunto de políticas y el enlace (asociados al nodo SOAP) deben definir un perfil Kerberos.
    • De la cabecera HTTP BasicAuth que contiene únicamente una parte de nombre de usuario si no se ha definido ningún conjunto de políticas en el nodo SOAP
O bien, de cualquier parte del árbol de mensajes cuando la ubicación de la señal se especifica (en el nodo) utilizando una expresión XPath o una vía de acceso de campo 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 nombreUsuario.

LDAP: Autorización

Nombre de usuario y contraseña
o
NombreUsuario y PassTicket RACF

Se da soporte a las señales de nombre de usuario y contraseña para su extracción mediante los nodos siguientes:
  • HTTPInput
  • MQInput
  • SCAInput
  • SecurityPEP
  • SCAAsyncResponse
  • SOAPInput
La señal se obtiene de una de las cabeceras del transporte siguiente:
  • HTTP
    • De la cabecera HTTP BasicAuth que contiene únicamente una parte de nombre de usuario y contraseña
  • SOAP
    • De una cabecera UsernameToken de WS-Security. El conjunto de políticas y el enlace (asociado con el nodo SOAP) deben definir un perfil de nombre de usuario y contraseña y wsse:UsernameToken debe contener los elementos wsse:Username y wsse:Password.
    • De la cabecera HTTP BasicAuth que contiene únicamente una parte de nombre de usuario si no se ha definido ningún conjunto de políticas en el nodo SOAP
O bien, la señal se puede obtener de cualquier parte del árbol de mensajes cuando la ubicación de la señal se especifica (en el nodo) utilizando una expresión XPath o una vía de acceso ESQL.

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:
  • Autenticación
  • Autorización
TFIM V6.1:
  • Autenticación
  • Correlación
  • Autorización
STS WS-Trust V1.3 (incluyendo TFIM V6.2):
  • Autenticación
  • Correlación
  • Autorización
Aserción SAML Se da soporte a las señales SAML para su extracción mediante los nodos siguientes:
  • SecurityPEP
  • MQInput
  • HTTPInput
  • SCAInput
  • SCAAsyncResponse
  • SOAPInput
La señal se obtiene de uno de estos lugares:
  • SOAP
    • De una cabecera WS-Security. El conjunto de políticas y el enlace (asociado con el nodo SOAP) deben definir un perfil SAML.
  • Cualquier parte de un árbol de mensajes cuando la ubicación de la señal se especifica 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 SAML.

STS WS-Trust V1.3 (incluyendo TFIM V6.2):
  • Autenticación
  • Correlación
  • Autorización
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:
  • SOAPInput

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):
  • Autenticación
  • Correlación
  • Autorización
Señal LTPA v2 Se da soporte a las señales LTPA para su extracción mediante los nodos siguientes:
  • SecurityPEP
  • SOAPInput

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):
  • Autenticación
  • Correlación
  • Autorización
Certificado X.509 Se da soporte a las señales X.509 para su extracción mediante los nodos siguientes:
  • SecurityPEP
  • MQInput
  • HTTPInput
  • SCAInput
  • SCAAsyncResponse
  • SOAPInput
La señal se obtiene de uno de estos lugares:
  • SOAP
    • De una cabecera WS-Security. El conjunto de políticas y el enlace (asociado con el nodo SOAP) deben definir un perfil X.509.
  • Cualquier parte de un árbol de mensajes cuando la ubicación de la señal se especifica 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 X.509.

TFIM V6.1:
  • Autenticación
  • Correlación
  • Autorización.
STS WS-Trust V1.3 (incluyendo TFIM V6.2):
  • Autenticación
  • Correlación
  • Autorización.
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):
  • Autenticación
  • Correlación
  • Autorización.

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.

Las señales SAML y Universal WSSE se almacenan en el campo IdentitySourceToken o IdentityMappedToken del árbol de propiedades como una corriente de bits de carácter. Para acceder a estos datos como un árbol de mensajes, analícelos en un analizador adecuado como, por ejemplo, XMLNSC:
-- 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.
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 17:00:15


Tema de conceptoTema de concepto | Versión 8.0.0.5 | ap04010_