Configuring Policies Manually

Contents

Overview
Configuration

Overview

In cases where a Web Services definition is not available in a Web Services Description Language (WSDL) file, the policy used to protect a Web Service must be configured manually. The steps outlined in this tutorial describe how to do this.

However, the recommended way to configure a policy to protect a Web Service is to import the WSDL file for that service. If WS-Policy information is contained in the WSDL file, the policy assertions can also be used to produce a complex policy with minimum effort for administrators.

If your Web Service has WSDL-based definitions, see the following:

Configuration

The following steps outline how to manually create a policy to protect a Web Service and then test it.

Step 1: Create the Policy

To create a policy manually, complete the following steps:

  1. Right-click the Policies node in the tree view of the Policy Studio, and select the Add Policy menu option.

  2. Enter a suitable name (for example TestPolicy) for the new policy in the Name field, and click the OK button. The new policy is now visible in the tree view.

  3. Click the new policy in the tree view to start configuring the filters for the policy. You can easily configure the policy by dragging the required filters from the filter palette on the right of the Policy Studio, and dropping them on to the policy canvas.

  4. Most policies attempt to check characteristics of the message, such as message size and format, and attempt to authenticate and/or authorize the sender of the message. When the message successfully passes all configured filters, it is usually routed on to the protected Web Service.

  5. For demonstration purposes, this topic creates a simple policy consisting of two filters. The first filter checks the size of the message, and the second echoes the request message back to the client if it is below a certain size.

  6. Expand the Content Filtering category of filters from the filter palette, and drag and drop the Message Size filter on to the canvas.

  7. Enter 10 in the At least field and 1000 in the At most field to make sure that only messages between 10 bytes and 1000 bytes are reflected back to the client. Select all other defaults, and click the Finish button.

  8. Right-click the newly added filter, and select the Set as Start menu option to indicate that this is the first filter to be executed in this policy. The icon for the filter changes to indicate that it is the start of the policy.

  9. Open the Utilities category of filters, and drag the Reflect filter onto the canvas. Drop it on to the previously configured Message Size filter. Select the defaults for the Reflect filter, and click the Finish button.

  10. Because you dropped the Reflect filter on to the Message Size filter, both filters are automatically linked with a success path. This means that if the first filter runs successfully, the next filter on the success path is executed. To link in more filters, add the filters to the canvas, and click the Success Path button at the top of the palette. Click the first filter followed by the second filter in the success path to link both filters.

  11. You can also configure failure paths for filters in the same way. Failure paths are followed when the checks configured in the filter fail.

This completes the configuration of the simple policy.

Step 2: Create a New Relative Path

You must now create a Relative Path on the Oracle API Gateway Process, which maps incoming requests on a particular URI to the new policy. Complete the following steps to do this:

  1. In the tree view of the Policy Studio, right-click the Default Services node, which can be found under the Oracle API Gateway node under the Listeners node. Select the Add Relative Path menu option.

  2. On the Configure Relative Path dialog, enter a suitable URI (for example, TestPolicy) on which you want to receive requests that are to be processed by the new policy.

  3. To map requests received on this URI to our new policy, select the /TestPolicy policy from the list of policies in the tree. Click the OK button when finished.

Step 3: Deploy to the API Gateway

Before the new configuration changes can take effect, you must deploy them to the API Gateway. You can do this by clicking the Deploy button on the right of the toolbar. Alternatively, press the F6 key.

[Important] Important

You must deploy to the server after making configuration changes. When deploying to the API Gateway, the Policy Studio sends a deployment request to the server. If necessary, you can configure the socket timeout value for this connection in the Policy Studio Preferences dialog. Enter the timeout value in milliseconds in the Server Socket Connection Timeout field. For more details, see Policy Studio Preferences.

Step 4: Test the Policy

You can use the tool of your choice (for example, Oracle API Gateway Explorer) to send SOAP requests to the new policy. You should send requests of different sizes to the following URL, assuming a default installation of the API Gateway running on the local machine:

http://localhost:8080/TestPolicy

Request messages that fall between the configured size are reflected to the client. Those fall outside of the configured are blocked, and a SOAP Fault is returned to the client.

Step 5: Next Steps

Try running more complicated checks on request messages by adding new filters to the TestPolicy. Try also adding failure paths to the original Message Size filter to handle messages that fall outside of the 10-1000 byte range.

Use the Help button on each filter screen to find out more about the configuration fields that are available on each screen.

Prev  Up  Next
  Home