The Security Policy Enforcement Point (PEP) sample demonstrates how to use the Security Policy Enforcement Point (PEP) as the Policy Enforcement Point in a message flow.
In this sample, identity information carried in the message is used by the Security Policy Enforcement Point (PEP) to enforce the security operations. For example, authentication, authorization, and mapping by using a WS-Trust v1.3 security provider, such as TFIM v6.2. Because a security implementation is based on an external centralized security provider, such as TFIM v6.2, this sample provides an additional message flow that emulates some basic security operations.
Instructions are also provided detailing how to set up TFIM v6.2 as the centralized external security provider for the sample, see Extending the Security Policy Enforcement Point (PEP) sample.
This sample demonstrates how to run the following tasks:
This sample demonstrates the following scenarios:
For details about the concepts related to message flow security, see Message flow security overview in the IBM Integration Bus documentation.
The following diagram shows the main Security Policy Enforcement Point (PEP) sample message flow, which is the SecurityPEPNodeSampleFlow.msgflow in the SecurityPEPNodeSampleApplicationProject Integration project. This flow consists of an HTTPInput node and two SecurityPEP nodes that invoke security operations. An HTTPRequest node is also used to invoke the Web service secured with SAML 2.0.
The HTTP_ID HTTPInput node, extracts the identity passed in the input message. The location of the user name and password that forms the identity in the message is known to the HTTPInput node by the configured security properties. The HTTPInput node of the SecurityPEPNodeSample.bar broker archive (BAR) file is configured with PEPSAMPLE_HTTP_UPA1_EMUL as the security profile. The authentication and authenticationConfig values of the security profile are set to invoke STS emulation to authenticate the identity. If the authentication of the user name and password identity token fails at this node, the exception list is transmitted to the Failure terminal. If the authentication is successful, the message is transmitted to the next node GetAuthenticationType.
The GetAuthenticationType Compute node, fetches the DemonstrateTokenType field from the content of the input message and routes it appropriately. The DemonstrateTokenType field value can be either UP or SAML. If it is neither of these, a user exception is produced.
The PEP_UP_A1A2 SecurityPEP node extracts the user name and password identity in the input message to demonstrate that the location of the identity in the message is known to the SecurityPEP node by the configured security properties. The PEP node of the SecurityPEPNodeSample.bar broker archive (BAR) file is configured with the security profile of PEPSAMPLE_PEP_UPA1A2_EMUL. The authentication, authenticationConfig, authorization, and authenticationConfig values of the security profile are set to invoke STS emulation to both authenticate and authorize the identity. If the authentication and authorization of the UP token is successful, the message is transmitted to the Compute node, where the status of the security operation is updated in the message body, and a reply is returned.
The PEP_MAP_UP->SAML2.0 SecurityPEP node reuses the identity passed in the input message, and puts it into the properties tree security fields. When the configured security properties are set to Current token the SecurityPEP node uses the current identity. The PEP node of the SecurityPEPNodeSample.bar BAR file is configured with the security profile of PEPSAMPLE_PEP_MAPUP2SAML2.0_EMUL. The mapping and mappingConfig values of the security profile are set to invoke the STS emulation to perform a token exchange from user name and password to SAML 2.0 content. The mapped SAML token is then put into the message body so that it can be forwarded to a service through the "HTTP Request-SAMLA1" HTTPRequest node, which is configured to invoke the SecurityPEPNodeReportFlow.msgflow message flow.
The HTTP service called by the HTTPRequest node in the SecurityPEPNodeSampleFlow.msgflow message flow is shown in the following SecurityPEPNodeReportFlow.msgflow diagram:
This flow has a SecurityPEP node that extracts the SAML2.0 present in the message body of the input message and invokes the security provider to validate the SAML2.0. The PEP node of the SecurityPEPNodeSample.bar BAR file is configured with the security profile of PEPSAMPLE_HTTP_SAMLA1_EMUL. The authentication and authenticationConfig values of the security profile are set to invoke the STS emulation to validate the SAML content. If validation of the contents of SAML2.0 is successful, the message is transmitted to the Compute node, where the status of the security operation is updated in the message body, and a reply is returned.
The sample uses the SecurityPEPNodeSampleSTSEmulatorFlow.msgflow message flow to emulate the security operations performed by an external provider, see the following diagram:
This flow contains the "HTTP WS Request" HTTPInput node, that receives the WS-Trust request made by the IBM Integration security manager, when the HTTPInput and SecurityPEP nodes in the SecurityPEPNodeSampleFlow.msgflow message flow invoke a security operation. The flow has several Compute nodes that emulate the outcome of a security provider and prepare a WS-Trust response.
Note: The emulation uses fixed data that generates the same WS-Trust response at each run. In the case of the SAML token, the dates are not changed dynamically. For example, IssueInstant="2010-04-14T07:10:53Z", NotBefore="2010-04-14T07:00:53Z", and NotOnOrAfter="2010-04-15T07:10:53Z". These dates and the validity period of the SAML content are not checked by the emulation.
Three input messages are supplied for running the Security Policy Enforcement Point (PEP) sample.
<?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>
The message is provided in the following files:
The .xml file is in the following subfolder: 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>
The message is provided in the following files:
The .xml file is in the following subfolder: 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>
The message is provided in the following files:
The .xml file is in the following subfolder: SecurityPEPNodeSampleApplicationProject/SampleTestMessages/TestMessage_UP_A1_failure.xml