# Configuring Policies Manually

## Contents
Overview Configuration

## Overview
In cases where a Web Services definition file is not available in a WSDL file (Web Services Description Language), the policy used to protect a Web Service must be configured manually. The steps outlined in this tutorial describe how to do this. However, that 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: Securing a Virtual Service using Policies Configuring Security Policies from WSDL Files
## 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 simple steps: Right-click the Policies node in the tree view of the Policy Studio, and select the Add Policy menu option. Enter a suitable name (e.g. "New") for the new policy in the Name field and click the OK button. The new policy will now be visible in the tree view. Click the new policy in the tree view to start configuring the filters for the new policy. You can easily configure the policy by dragging the required filters from the filter palette on the right-hand side of the Policy Studio and dropping them onto the circuit canvas. Most policies will attempt to check characteristics of the message, such as message size and format, as well as attempting to authenticate and/or authorize the sender of the message. Once the message successfully passes all configured filters it is usually routed on to the protected Web Service. For demonstration purposes we will create a very simple policy consisting of 2 filters. The first filter will check the size of the message and the second will echo the request message back to the client if it is below a certain size. Expand the Content Filtering category of filters from the filter palette and drag and drop the Message Size filter on to the canvas. 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 will be reflected back to the client. Select all other defaults and click the Finish button. Right-click on the newly added filter and select the Set as Start menu option to indicate that this is the 1st filter to be executed in this policy. The icon for the filter will change to indicate that it is the "Start" of the policy. Now open the Utilities category of filters and drag the Reflect filter onto the canvas. This time drop it onto the previously configured Message Size filter. Select the defaults for the Reflect filter and click the Finish button. 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. 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 Enterprise Gateway Process, which will map incoming requests on a particular URI to the new policy. Complete the following steps to do this: Right-click the "Default Services" node in the tree view of the Policy Studio, which can be found under the "Oracle Enterprise Gateway" node under the "Processes" node. Select the Add Relative Path menu option. On the Configure Relative Path dialog, enter a suitable URI (for example, "/New") on which you want to receive requests that are to be processed by the new policy. To map requests received on this URI to our new policy, you simply need to select the "New" policy from the list of policies in the tree. Click the OK button when you have done this. Step 3: Deploy to the Enterprise Gateway Before the new configuration changes can take effect, you must deploy them to the Enterprise Gateway. You can do this by simply by selecting the F6 button. It is important to note that you must deploy to the server after making configuration changes. Important Note: When deploying to the Enterprise 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 (e.g. Oracle Service 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 Enterprise Gateway running on the local machine: `http://localhost:8080/New` You will notice that requests message falling between the configured size will be reflected to the client, but that those that fall outside of the configured will be "blocked" and a SOAP Fault will be returned to the client. Step 5: Next Steps Try running more complicated checks on request messages by adding new filters to the "New" policy. 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.