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

Invocación de la seguridad de flujos de mensajes utilizando un nodo de entrada con seguridad habilitada

Puede invocar el gestor de seguridad de flujos de mensajes configurando un nodo de entrada habilitado con seguridad.

En el diagrama siguiente se muestra un flujo de mensajes de ejemplo y se ofrece una visión general de la secuencia de sucesos que se producen cuando un nodo de entrada con seguridad habilitada recibe un mensaje de entrada en el flujo de mensajes:

Diagrama que muestra la secuencia de sucesos que se producen cuando un mensaje llega a un nodo de entrada habilitado con seguridad en un flujo de mensajes.
En los pasos siguientes se explica la secuencia de suceso que se produce cuando un mensaje llega a un nodo de entrada con seguridad habilitada del flujo de mensajes. Los números corresponden a los del diagrama anterior:
  1. Cuando llega un mensaje a un nodo de entrada con seguridad habilitada (MQ, HTTP, SCA o SOAP), la presencia de un perfil de seguridad asociado con el nodo indica si se ha configurado la seguridad del flujo de mensajes. Los nodos SOAP pueden implementar algunas prestaciones de WS-Security sin tener que utilizar el gestor de seguridad del intermediario; para obtener más información, consulte Implementar WS-Security. 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 proporciona un perfil de seguridad predefinido, denominado Propagación determinada, para establecer la propagación de la identidad. Para establecer de forma explícita que no haya seguridad en un nodo, establezca el perfil de seguridad en Sin seguridad.

  2. Si hay un perfil de seguridad asociado al nodo o al flujo de mensajes, el nodo de entrada con seguridad habilitada extrae la información de identidad del mensaje de entrada (en función de la configuración de la página de propiedades Seguridad del nodo) y establece los elementos de identidad de origen en la carpeta Propiedades. Si las señales de seguridad no se pueden extraer satisfactoriamente, se genera una excepción de seguridad.

    Si necesita un nodo SOAPInput para utilizar la identidad en la cabecera WS-Security (en lugar de una identidad de transporte subyacente), también debe definir y especificar un conjunto de políticas apropiado y enlaces para el perfil de señales adecuados. Para obtener más información, consulte Conjuntos de políticas.

    Para los nodos de entrada MQ, HTTP o SCA, se utiliza la página de propiedades Seguridad para configurar la extracción de la identidad. Así se toma el valor predeterminado Valor predeterminado del transporte. Por ejemplo, un nodo HTTPInput extrae un nombre de usuario y una contraseña de la cabecera BasicAuth de HTTP. La página de propiedades Seguridad permite que el tipo de señal de identidad y su ubicación se configuren de forma explícita para controlar la extracción. Esta información de identidad de origen puede estar en una cabecera de mensaje, en el cuerpo del mensaje o en ambos lugares.

    Para obtener información sobre las señales que admite cada nodo, consulte Identidad.

  3. 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 Message Broker admite para su 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.

  4. 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 Message Broker admite 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 lo prefiere, puede utilizar un nodo SecurityPEP en cualquier punto del flujo de mensajes para correlacionar la identidad que se ha autenticado en el nodo de entrada con seguridad habilitada. Para obtener más información, consulte Invocación de la seguridad del flujo de mensajes utilizando un nodo SecurityPEP.

  5. 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 Message Broker admite para su 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 autorización.

    Si lo prefiere, puede utilizar un nodo SecurityPEP en cualquier punto del flujo de mensajes para autorizar la identidad que se ha autenticado en el nodo de entrada con seguridad habilitada. Para obtener más información, consulte Invocación de la seguridad del flujo de mensajes utilizando un nodo SecurityPEP.

  6. 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 de entrada.

    Cuando se devuelve una excepción de seguridad al nodo de entrada con seguridad habilitada, se lleva a cabo la gestión de transporte pertinente y finaliza la transacción del flujo de mensajes. Por ejemplo, un nodo HTTPInput devuelve una cabecera HTTP con un código de respuesta HTTP 401, sin propagarse a ningún terminal de salida. Un nodo SOAPInput devuelve un error SOAP, indicando la excepción de seguridad. Si lo prefiere, si la propiedad Tratar las excepciones de seguridad como excepciones normales se ha establecido en el nodo de entrada con seguridad habilitada, se propagará una excepción de seguridad al terminal de anomalías del nodo. El nodo de entrada con seguridad habilitada se propaga al terminal de salida solamente si todas las operaciones configuradas en el perfil de seguridad asociado se han completado satisfactoriamente.

  7. El mensaje, incluyendo la carpeta Propiedades y la información de identidad de origen y correlacionada, se propaga hacia abajo en el flujo de mensajes.
  8. En los nodos subsiguientes del flujo de mensajes es posible que sea necesario utilizar una identidad para acceder a un recurso, por ejemplo una base de datos. La identidad utilizada para acceder a dicho recurso es una identidad de proxy, la identidad del intermediario o una identidad configurada para el recurso específico utilizando el mandato mqsisetdbparms.
  9. 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). Además, como alternativa a invocar la correlación a través de SST habilitado para WS-Trust V1.3 (como, por ejemplo, TFIM V6.2) o TFIM V6.1, puede establecer los campos de identidad correlacionados en un nodo Compute como, por ejemplo, un nodo Compute, JavaCompute, PHPCompute o Mapping.
  10. Cuando el mensaje alcanza un nodo de salida o de solicitud con seguridad habilitada (MQOutput, HTTPRequest, SOAPRequest o SOAPAsyncRequest), un perfil de seguridad (con la propagación habilitada) asociado al nodo indica que la señal de identidad actual se debe propagar cuando se envíe el mensaje.

    Si el perfil de seguridad indica que la propagación es necesaria, se utiliza la identidad correlacionada. Si no se establece la identidad correlacionada, o si tiene un tipo de señal que no recibe soporte del nodo, se utilizará la identidad de origen. Si no se establece la identidad, o si la identidad correlacionado o de origen tiene un tipo de señal admitido por el nodo, se devuelve al nodo una excepción de seguridad.

    Los nodos SOAP también necesitan el conjunto de políticas y enlaces correspondientes para que el perfil de señales se asocie al nodo.

    Si desea incluir una señal de seguridad en el mensaje que se emite a un nodo de salida, y si el nodo de salida no puede propagar ese tipo de señal, puede utilizar un nodo Compute (antes del nodo de salida) para colocar la señal del árbol de propiedades en la ubicación de mensajes relevante.

    Para obtener información sobre las señales que admite cada nodo, consulte Propagación de la señal de seguridad e identidad.

  11. La identidad propagada se incluye en la cabecera de mensaje apropiada cuando ésta se envía.
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:01:38


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