Using the User-Defined DataPower Component (Pipeline)
Learn how to add a processing rule defined in the WebSphere DataPower Appliance to the User-Defined DataPower Component.
Table of Contents
- Using Contexts with User-Defined DataPower Policy
- Using User Defined Authentication Policy with Contract Authorization
The User-Defined DataPower Policy Component is a Policy Manager pipeline component that references a policy defined in IBM WebSphere DataPower in the form of reusable user-defined processing rules located on the WebSphere DataPower Appliance. A processing rule must first be defined on the WebSphere DataPower Appliance before it can be used with this component. The Rule Name assigned to the processing rule in the WebSphere DataPower Appliance must match the name specified in the DataPower Processing Rule Name field of this component. DataPower rule content can also be uploaded directly to the component.
This component is used if you have performed a DataPower Integration by installing the Akana Platform and installing and configuring the Akana Policy Manager for IBM WebSphere DataPower feature.
Using Contexts with User-Defined DataPower Policy
When enforcing the User-Defined DataPower Policy Component, DataPower will call out to a user defined processing rule previously defined as a Processing Rule object in the DataPower domain being governed. This rule will perform an important user-defined function such as security processing or transformation.
When authoring this rule, the proper use of DataPower contexts is critical to the functioning of the rule and the larger service.
The following lists the key points that should be followed for the proper use of contexts.
- If actions in the user defined processing rule need to read the current request or response message, their input context should be set to INPUT.
- The INPUT context within the user defined processing rule contains the request or response message as it has been modified over the course of DataPower processing up to the invocation of the user defined rule. It does not contain the original message as received by DataPower.
- If actions in the user defined processing rule need to modify the current request or response message, their input context should be set to OUTPUT. The context written to this output will be represented in the response message to the DataPower consumer.
- The OUTPUT context within the user defined processing rule will be used as the OUTPUT context of the larger transaction once the user defined processing policy completes. That content will be available to other downstream user defined processing rules via the INPUT context for that rule as per normal functionality.
- If a user defined processing rule action does not need access to the INPUT context for the action's input or OUTPUT context for the action's output, it should use the NULL context instead.
Using User Defined Authentication Policy with Contract Authorization
The User-Defined DataPower Policy Component can be used to include an AAA authentication policy in your Policy Manager for DataPower deployed services. If you want the authenticated identity resulting from this policy to be the identity used when DataPower performs contract authorization, you must make DataPower aware of this identity.
This can be done by setting two DataPower variables as part of the post processing of your AAA authentication policy. These variables should be set as follows:
- var://context/soa/authenticatedidentities/consumer/identity/username –a string value containing the username of the authenticated identity. For example, 'johndoe'.
- var://context/soa/authenticatedidentities/consumer/identity/domain –a string value containing the Policy Manager domain that the username is a part of. For example, 'Local Domain'.
For example, the following code sets the identity information:
dp:set-variable name="'var://context/soa/authenticatedidentities/consumer/identity/username'" value="'johndoe'" />
dp:set-variable name="'var://context/soa/authenticatedidentities/consumer/identity/domain'" value="'Local Domain'" />
Let's take a quick walkthrough of the User-Defined DataPower Policy Component configuration process to get you started.
Note: A User-Defined DataPower Policy (non-pipeline) version must be added using the Add Policy Wizard and defined and configured prior to this configuration as the User-Defined Category from this policy is referenced in the pipeline version of the policy.
Step 1: Add Policy
You can create a Pipeline Policy instance using Add Policy in the Policies > Operational Policies section.
Step 2: Modify Policy
When you Modify the Pipeline Policy, and use Add Component to add the User-Defined DataPower Policy Component, the Modify Pipeline Policy will look like this:
This policy is used in the Request Configuration, Response Configuration, and Fault Configuration and can be positioned anywhere in the request, response, or fault.
Step 3: Configure
The process of configuring the User-Defined DataPower Policy Component involves adding a processing rule that is defined in the WebSphere DataPower appliance.
To configure the User-Defined DataPower Policy Component, select the policy and click Modify Component and configure the following options on the Modify User-Defined DataPower Policy Component screen.
- DataPower Processing Rule Name—Add a Rule Name assigned to the processing rule in the WebSphere DataPower Appliance.
Note: The Rule Name specified in the DataPower Processing Rule Name field must match the Rule Name assigned to the WebSphere DataPower Appliance.
- Authenticate Consumer Identity—Select if you would like the rule to perform authentication of the consumer identity.
- Use Uploaded DataPower Configuration—If you would like to store the rule configuration in Policy Manager, select this option and upload the rule content. Note that the DataPower Processing Rule Name must still be specified in the DataPower Processing Rule Name field when using this option.
Step 4: Attach Policy
After you have saved your policy you can attach it to a web service or you can attach the policy at the Organization level and the policy will be active for all services defined within the organization.