Filter Action in DataPower
Here in this blog, we are going to learn about Filter Action in DataPower.
Filter action:
- The Filter action will check against the incoming payload.
- The result of the filter action will either accept or reject the payload after checking it over the given criteria.
- A transform file is required to check the criteria for filtering the message.
Filter action is Performed in the following ways:
- Replay Filter.
- Required Element Filter.
- Standard Filter
- WS-Security Message Layout Filter.
Adding a Standard Filter:
- This Standard filter will either accept or reject the Input XML Document.
- In DataPower there are two in build Store file
- To accept all XML documents, the filter uses the store:///filter-accept-all.xsl stylesheet.
- To reject all XML documents, the filter uses the store:///filter-reject-all.xsl stylesheet.
- We can customize out own xsl file to check the condition over Input XML File.
- Click DONE and Configure the remaining service as required.
Adding a Replay Filter
- This Filter will use a cache
- Replay filters need to extract some value from the message to act as the basis of detecting potential replays.
- There are two predetermined replay values:
- WS-Addressing message ID elements
- WS-Security Username Token nonce elements (used in conjunction with the WS-Security password digest feature).
- Also, an arbitrary XPath expression can be used to create the extracted replay value
- Time that the extracted value will be used to check against potential replays. The duration must be greater than zero.
Adding required elements filter:
- This Filter will checks the document for the presence of required elements in the SOAP header.
- The result of the expression must be present in the message.
- The required element will be specified in store:///dp required element filter file.
Adding a WS-Security Message Layout Filter :
- This filter determines whether to accept or reject documents based approximately elements in the WS-Security header.
- WS-SecurityPolicy defines four assertions to restrict the ordering of elements within the WS-Security header:
- StrictLax
- Lax
- TimestampFirstLax
- TimestampLast
- Strict requires that tokens, in general, are declared before use. Lax layout policies have no such requirement; though the LaxTimestampFirst and LaxTimestampLast layout policies do require a WS-Security timestamp as either the first or last element in the security header, respectively.
Let us create a sample service to demonstrate this use case:
- In IBM DataPower Gateway, create a sample rule for a sample policy.
- Grag the filter action to the flow and configure the policy.
- Now let us configure the filter action as shown below.
- Here we are using a standard filter policy by using the SQL-Injection-filter action which is present in the store
- This xsl file will inspect the input payload over a set of specified keywords, which are present in an xml file.
- If any SQL-Injection attacks are detected this action stop the process and reject the message saying the message is containing some malicious data.
Let us test this scenario in both success and failure case.