Configuring the Policy Enforcement Point

The DataPower® appliance is the Policy Enforcement Point (PEP) of the IBM® SOA Policy Gateway Pattern. When the Application Domain is deployed, it is possible to create the content of that domain.

Procedure

Create a Web Service Proxy (WSP):

  1. From the DataPower Control Panel, click Web Service Proxy.
  2. Click Add and enter a name for the Proxy.
  3. Open the WSRR Subscription tab. In the WSRR Server list, click WSRRSVR.
  4. Provide the other information required, such as the Front Side Handler, the namespace, the object name, and so on, to create the configuration of the Web Service Proxy.

Create policies for the WSP:

  1. Open the Policy tab for the WSP Editor.
  2. Click Processing Rules at the appropriate level. You can either create a new rule or edit the default rule provided. The key policy action to add is the AAA Action. This handles the Identification, Authentication, and Authorization that are key to the pattern.

    Key things you must specify for the AAA action include the Input and Output, as well as the AAA Policy. You can create the policy whilst in the process of creating the AAA Policy Action, or you might have created it prior to this using the AAA editor.

    • Identification is the step where the user is Identified. In our sample, there were two forms of identification used. In the StoreAddLTPA XML firewall, the identification was performed with basic authentication. In the StoreWSP firewall, identification was provided by LTPA token.
    • Authentication is the step where the user is proven to be a user who is known to the system. There are many options to choose from. In the sample, we showed you two examples; the first where the user was looked up using LDAP, and the second that accepted a valid LTPA Token.
    • Authorization is the step where the user is authorized to the resource, in this case the web service operations. The following key elements need to be specified to use XACML on-box PDP authorization:
      • The Method: Use XACML Authorization.
      • The XACML Version; for example, 2.0.
      • PDP Type; for example, deny based PDP.
      • Use On box PDP: On
      • The name of the PDP, which has the XACML specified.
      • Configure the PDP. For more information, see Altering the XACML PDP on DataPower.
      • The custom XSL style sheet to bind AAA and XACML: use apil-xacml-bindingnew.xsl as a starting point.

To configure the gateway to use Redaction:

  1. Modify the XACML .xml file to match the particular security policies you wish to enforce for the redaction.
  2. Create an XML Firewall with an AAA action that follows the redaction sample.
  3. Modify the PDP used by the above AAA action to point to the style sheet you are using to enforce redaction.
  4. Copy and modify the storeCallPDP.xsl stylesheet, that creates the SOAP payload for the XACML service. In particular, make sure that the Action and Resource match your requirements for the XACML policy document you created.
  5. Make sure that your modified style sheet calls the correct port for your new XACML XML Firewall.

What to do next

In addition to creating a Domain and setting up a WSRR Server Configuration in the SOA Policy Gateway Advanced Runtime and SOA Policy Gateway Basic Runtime patterns, it is possible to extend the domain by running a custom CLI script. The CLI script should be in the root of the DomainZipFile.zip structure; for example, /cli.cli. The CLI can run any standard CLI commands, but all artifacts that the CLI refers to must exist or be accessible by the DataPower Domain created by the pattern. When you deploy an instance of the SOA Policy Gateway Advanced Runtime or SOA Policy Gateway Basic Runtime patterns you will be prompted for the CLI file name in the Security package parameters.


Task Task

Feedback

Timestamp icon Last updated: Thursday, 3 July 2014
http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr.doc/topics/tsoa2_PEP_config.htm