Acerca del ejemplo de PEP (Policy Enforcement Point) de seguridad

El ejemplo de PEP (Policy Enforcement Point) de seguridad muestra cómo utilizar el PEP (Policy Enforcement Point) de seguridad como punto de imposición de políticas (Policy Enforcement Point) en un flujo de mensajes.

En este ejemplo, la información de identidad que contiene el mensaje la utiliza el Policy Enforcement Point (PEP) de seguridad para imponer las Operaciones de seguridad. Por ejemplo, la autenticación, autorización y la correlación utilizando un proveedor de seguridad WS-Trust v1.3, como TFIM v6.2. Dado que una implementación de seguridad se basa en un proveedor de seguridad centralizado externo, como TFIM v6.2, este ejemplo proporciona un flujo de mensajes adicional que emula algunas de las operaciones básicas de seguridad.

También se proporcionan instrucciones sobre cómo configurar TFIM v6.2 como proveedor de seguridad externo centralizado para el ejemplo, consulte Ampliar el ejemplo de PEP (Policy Enforcement Point) de seguridad.

Este ejemplo muestra cómo ejecutar las siguientes tareas:

Este ejemplo muestra los siguientes escenarios:

Para obtener detalles sobre los conceptos relacionados con la seguridad de flujos de mensajes, consulte Visión general de la seguridad de flujo de mensajes en la documentación de WebSphere Message Broker.

Los flujos de mensajes

El diagrama siguiente muestra el flujo de mensajes principal del ejemplo de PEP (Policy Enforcement Point) de seguridad, que es el SecurityPEPNodeSampleFlow.msgflow en el proyecto de Message Broker SecurityPEPNodeSampleApplicationProject. Este flujo consiste en un nodo HTTPInput y dos nodos SecurityPEP que invocan a operaciones de seguridad. También se utiliza un nodo HTTPRequest para invocar al servicio web asegurado con SAML 2.0.

Una captura de pantalla del flujo de mensajes del nodo SecurityPEP.

El nodo HTTPInput HTTP_ID extrae la identidad que se pasa en el mensaje de entrada. La ubicación del nombre de usuario y contraseña que forman la identidad en el mensaje es conocida por el nodo HTTPInput gracias a las propiedades de seguridad configuradas. El nodo HTTPInput del archivo de archivador intermediario (BAR) SecurityPEPNodeSample.bar está configurado con PEPSAMPLE_HTTP_UPA1_EMUL como perfil de seguridad. Los valores authentication y authenticationConfig del perfil de seguridad están configurados para invocar a la emulación STS para autenticar la identidad. Si la autenticación del nombre de usuario y la contraseña de la señal de identidad fallan en este nodo, se transmite la lista de excepciones al terminal de anomalías. Si la autenticación es satisfactoria, el mensaje se transmite al siguiente nodo GetAuthenticationType.

El nodo Compute GetAuthenticationType, capta el campo DemonstrateTokenType en el contenido del mensaje de entrada y lo direcciona adecuadamente. El valor del campo DemonstrateTokenType puede ser UP o SAML. Si no es ninguno de estos dos valores, se genera una excepción.

El nodo SecurityPEP PEP_UP_A1A2 extrae la identidad del nombre de usuario y contraseña del mensaje de entrada para demostrar que el nodo SecurityPEP conoce la ubicación de la identidad en el mensaje gracias a las propiedades de seguridad configuradas. El nodo PEP del archivo de archivador intermediario (BAR) SecurityPEPNodeSample.bar está configurado con el perfil de seguridad de PEPSAMPLE_PEP_UPA1A2_EMUL. Los valores authentication, authenticationConfig, authorization y authenticationConfig están configurados para invocar a la emulación STS para autenticar y autorizar la identidad. Si la autenticación y autorización de la señal UP son satisfactorias, el mensaje se transmite al nodo Compute, donde se actualiza el estado de la operación de seguridad en el cuerpo del mensaje, y se devuelve una respuesta.

El nodo SecurityPEP PEP_MAP_UP->SAML2.0 reutiliza la identidad que se ha pasado en el mensaje de entrada y la pone en los campos de seguridad del árbol de propiedades. Cuando las propiedades de seguridad configuradas están definidas con el valor Señal actual el nodo SecurityPEP utiliza la identidad actual. El nodo PEP del archivo BAR SecurityPEPNodeSample.bar está configurado con el perfil de seguridad de PEPSAMPLE_PEP_MAPUP2SAML2.0_EMUL. Los valores mapping y mappingConfig del perfil de seguridad están configurados para invocar a la emulación STS para realizar un intercambio de señales de nombre de usuario y contraseña a contenido de SAML 2.0. A continuación, la señal SAML correlacionada se pone en el cuerpo del mensaje de forma que pueda ser reenviada a un servicio a través del nodo HTTPRequest "HTTP Request-SAMLA1", que está configurado para invocar al flujo de mensajes SecurityPEPNodeReportFlow.msgflow.

El servicio HTTP al que llama el nodo HTTPRequest en el flujo de mensajes SecurityPEPNodeSampleFlow.msgflow se muestra en el siguiente diagrama de SecurityPEPNodeReportFlow.msgflow:

Una captura de pantalla del flujo de servicio web invocado con SAML2.0.

Este flujo tiene un nodo SecurityPEP que extrae el SAML2.0 presente en el cuerpo del mensaje de entrada e invoca al proveedor de seguridad para validar el SAML2.0. El nodo PEP del archivo BAR SecurityPEPNodeSample.bar está configurado con el perfil de seguridad de PEPSAMPLE_HTTP_SAMLA1_EMUL. Los valores authentication y authenticationConfig del perfil de seguridad están configurados para invocar a la emulación STS para validar el contenido SAML. Si la validación del contenido de SAML2.0 es satisfactoria, el mensaje se transmite al nodo Compute, donde se actualiza el estado de la operación de seguridad en el cuerpo del mensaje, y se devuelve una respuesta.

Este ejemplo utiliza el flujo de mensajes SecurityPEPNodeSampleSTSEmulatorFlow.msgflow para emular las operaciones de seguridad realizadas por un proveedor externo, consulte el siguiente diagrama:

Una captura de pantalla de un flujo de mensajes que emula el funcionamiento de un proveedor de seguridad

Este flujo contiene el nodo HTTPInput "HTTP WS Request", que recibe la solicitud WS-Trust que realiza el gestor de seguridad del intermediario, cuando los nodos HTTPInput y SecurityPEP del flujo de mensajes SecurityPEPNodeSampleFlow.msgflow invocan una operación de seguridad. El flujo tiene varios nodos Compute que emulan el resultado de un proveedor de seguridad y preparan una respuesta WS-Trust.

Nota: La emulación utiliza unos datos fijos que generan la misma respuesta WS-Trust en cada ejecución. En el caso de la señal SAML, los datos no se cambian dinámicamente. Por ejemplo, IssueInstant="2010-04-14T07:10:53Z", NotBefore="2010-04-14T07:00:53Z" y NotOnOrAfter="2010-04-15T07:10:53Z". Estos datos y el periodo de validez del contenido SAML no se comprueban en la emulación.

Los mensajes

Se proporcionan tres mensajes de entrada para ejecutar el ejemplo de PEP (Policy Enforcement Point) de seguridad.

Volver a la página inicial del ejemplo