El ejemplo Punto de aplicación de políticas (PEP) de seguridad muestra cómo utilizar el Punto de aplicación de políticas (PEP) de seguridad como el punto de aplicación de políticas en un flujo de mensajes.
En este ejemplo, la información de identidad que contiene el mensaje la utiliza el Punto de aplicación de políticas (PEP) de seguridad para aplicar 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 Punto de aplicación de políticas (PEP) de seguridad.
Este ejemplo muestra cómo ejecutar las siguientes tareas:
Este ejemplo muestra los siguientes escenarios:
Para obtener información detallada sobre los conceptos relacionados con la seguridad de flujo de mensajes, consulte Visión general de la seguridad de flujo de mensajes en la documentación de IBM Integration Bus.
El diagrama siguiente muestra el flujo de mensajes principal del ejemplo Punto de aplicación de políticas (PEP) de seguridad, que es SecurityPEPNodeSampleFlow.msgflow en el proyecto de Integración 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.
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:
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:
Este flujo contiene el nodo HTTPInput "HTTP WS Request", que recibe la solicitud WS-Trust que realiza el gestor de seguridad de IBM Integration, 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.
Se proporcionan tres mensajes de entrada para ejecutar el ejemplo Punto de aplicación de políticas (PEP) de seguridad.
<?xml version="1.0" encoding="UTF-8"?> <Envelope> <Body> <MessageIdentity> <Username>broker01</Username> <Password>passw0rd01</Password> <IssuedBy>Issuer1</IssuedBy> <DemonstrateTokenType>SAML</DemonstrateTokenType> </MessageIdentity> </Body> </Envelope>
El mensaje se proporciona en los siguientes archivos:
El archivo .xml se encuentra en la siguiente subcarpeta: SecurityPEPNodeSampleApplicationProject/SampleTestMessages/TestMessage_UPA1_MAP2SAML2.0_A1.xml
<?xml version="1.0" encoding="UTF-8"?> <Envelope> <Body> <MessageIdentity> <Username>broker01</Username> <Password>passw0rd01</Password> <IssuedBy>Issuer1</IssuedBy> <DemonstrateTokenType>UP</DemonstrateTokenType> </MessageIdentity> </Body> </Envelope>
El mensaje se proporciona en los siguientes archivos:
El archivo .xml se encuentra en la siguiente subcarpeta: SecurityPEPNodeSampleApplicationProject/SampleTestMessages/TestMessge_UP_A1A2.xml
<?xml version="1.0" encoding="UTF-8"?> <Envelope> <Body> <MessageIdentity> <Username>dummy_usr</Username> <Password>passw0rd01</Password> <IssuedBy>Issuer1</IssuedBy> <DemonstrateTokenType>UP</DemonstrateTokenType> </MessageIdentity> </Body> </Envelope>
El mensaje se proporciona en los siguientes archivos:
El archivo .xml se encuentra en la siguiente subcarpeta: SecurityPEPNodeSampleApplicationProject/SampleTestMessages/TestMessage_UP_A1_failure.xml