Policy Manager Service Rules

Learn how to add security to your services by adding and managing Allow and Deny rules.

Table of Contents

Rules: Overview

Policy Manager allows you to configure rules for securing XML physical and virtual web services, to help protect the services. This functionality is useful for two important Web service security practices:

  • implementation of XML filtering
  • Protection against XML denial of service (DoS) attacks.

For more information about security practices for web services, see Web services: Security practices.

Note: Policy Manager doesn't support service rules for the JMS listener protocol.

Types of rules

There are two types of rules that you can use to add security to a service:

  • Allow rules allow you to configure:
    • IP address filtering for allowing access to the current service.
    • Denial of service parameters such as maximum message size allowed.
  • Deny rules allow you to configure:
    • IP address filtering configuration parameters for denying access to the current service.

Managing rules

In Policy Manager, rules are defined in the context of a specific service within the organization.

You can:

To view existing rules

  1. In Policy Manager, select Workbench > Browse. In the left pane, find the organization, click to expand it, and then click Services. Choose the service. The summary page for the service is displayed.
  2. Click the Rules tab, as shown below.

    Rules page for a service

If there are any rules already defined for the service, they are displayed.

To add an Allow rule

  1. In Policy Manager, go to the Rules page for the service (see To view existing rules above).
  2. Click Add Allow Rule. The Add Allow Rule page is displayed, as shown below.

    Adding an Allow rule

  3. Choose configuration options. For information on the choices available, refer to:
  4. Click Apply.

To add a Deny rule

  1. In Policy Manager, go to the Rules page for the service (see To view existing rules above).
  2. Click Add Deny Rule. The Add Deny Rule page is displayed, as shown below.

    Adding a Deny rule

  3. Choose configuration options. For information on the choices available, refer to:
  4. Click Apply.

To modify a rule

  1. In Policy Manager, go to the Rules page for the service (see To view existing rules above).
  2. On the list, find the rule you want to modify and double-click to open the Modify page.
  3. Update the configuration options as needed. For information on the choices available, refer to Service Rules: Field Descriptions.
  4. Click Apply.

To delete a rule

  1. In Policy Manager, go to the Rules page for the service (see To view existing rules above).
  2. On the list, select the rule you want to delete and click Delete Rule.
  3. At the confirmation prompt, click OK. The rule is deleted.

Service Rules: Field Descriptions

The tables below provide information about the fields available for configuring Allow or Deny rules.

Note: Policy Manager doesn't support service rules for the JMS listener protocol.

There are two sets of options for Allow rules and one set for Deny rules:

Allow Rules: IP Address Filtering

The IP Address Filtering section allows you to configure the XML-based filtering using a variety of IP address combinations. XML-based filtering rules are designed to add security by reducing the "aperture of entry" into the corporate network.

For Allow rules, the message size, transaction rate, and connection duration (Denylist Time) are monitored through the specified IP Address filter. For Deny Rules, access is denied to all service requests made through the specified IP Address filter. This functionality addresses the Implement XML Filtering XML Web Service Security Practice.

An IP address consists of two parts:

  1. The first part of the address is called the network number and identifies a network on the internet.
  2. The remainder of the address identifies an individual host on the network.

An address mask determines which portion of an IP address identifies the network, and which portion identifies the host. A subnet mask is a modified address mask that is used to partition a network into two subnets.

The IP Address Filtering options for Allow rules are shown below.

Name Description
Allowed IP Address Range Allows you to perform IP filtering for an IP address range. To use this option, click Allowed IP Address Range and then enter start and end IP addresses.
Allow Subnet Allows you to perform IP filtering using a subnet mask. To use this option, click Allow Subnet and then specify the IP address and subnet mask.
Specific IP Address Allows you to perform IP filtering for a single IP address. To choose this option, click Specific IP Address and then specify the IP address.
Allow All Allows you to configure the Allow rule to disable IP filtering; however, to ensure optimum security, it's best to use the IP address filtering capability.

Allow Rules: Denial of Service

The Denial of Service section provides protection against XML Denial of Service attacks and allow you to implement reasonable constraints for incoming messages based on the XML filtering rules specified in the IP Address Filtering section. This functionality addresses the Protect Against XML Denial of Service Attacks XML Web Service Security Practice.

Name Description
Message Size Allows you to specify an allowable maximum message size in Bytes (B), Kilobytes (KB), or Megabytes (MB). When choosing a maximum message size, bear in mind your specific business requirements and your Policy Manager production site configuration. You can also choose No Limit; we do not recommend this option, since it doesn't safeguard against a Denial of Service attack.
Transaction Rate Allows you to specify the maximum allowable transaction rate in Seconds (sec), Minutes (min), and Hours (hour). When choosing a maximum transaction rate, bear in mind your specific business requirements and Policy Manager production site configuration. You can also choose No Limit; we do not recommend this option, since it doesn't safeguard against a Denial of Service attack.
Denylist Time Allows you to specify how long violators of the rules are added to the denylist and how long undesirable traffic associated with the IP Address Filter will be blocked. You can specify the denylist time in Seconds (sec), Minutes (min), or Hours (hour). During this time, traffic that violated the rule is blocked. To use this option, click Deny Access For, select the unit of measure (sec, min, hour), and then enter the numeric time period. You can also choose not to add violations to the denylist; however, to ensure optimum security, it's best to use this capability.

Deny Rules: IP Address Filtering

The IP Address Filtering options for Deny rules are shown below.

Name Description
Denied IP Address Range Allows you to perform IP filtering for an IP address range. To use this option, click Denied IP Address Range and then enter start and end IP addresses.
Deny Subnet Allows you to perform IP filtering using a subnet mask. To use this option, click Deny Subnet and then specify the IP address and subnet mask.
Specific IP Address Allows you to perform IP filtering for a single IP address. To choose this option, click Specific IP Address and then specify the IP address to block.
Deny All Allows you to configure the Deny rule to filter all IP addresses. If you choose Deny All, the full range of IP addresses, 0.0.0.0 to 255.255.255.255, is applied as the default.

Web services: Security practices

Effectively deploying a secure web service requires technologies that can:

  • Parse, filter, and transform XML and SOAP packets.
  • Apply security policies at the XML document level.

These requirements have been defined at the industry level as a set of security practices for XML Web services.

The set of Web services security practices is designed to enhance existing transport-layer security systems with XML Web Services Security. They address important security activities such as:

  • Securing the transport layer
  • Implementing XML filtering
  • Masking internal resources
  • Protecting against XML Denial of Service attacks
  • Validating, transforming, and signing all messages
  • Encrypting message fields
  • Implementing secure auditing

The key Web services security practices are summarized in the table below.

Category Recommendation
Secure the Transport Layer Recommends using transport layer security to ensure confidentiality of information during transport. This security practice also recommends the use of server certificates and client certificates during authentication.
Implement XML Filtering Recommends applying content-level filtering policies to XML documents after they are parsed and processed. This security practice ensures XML documents cannot be read or processed at wire speed.
Mask Internal Resources Recommends use of Network Address Translation (NAT) to obscure internal IP addresses.
Protect Against XML Denial of Service Attacks Recommends applying reasonable constraints to incoming messages including the ability to configure message size, transaction rate, and connection duration.
Validate All Messages Recommends using XML schema validation to ensure that incoming and outgoing messages are valid.
Transform All Messages Recommends using XSLT functionality to transform all XML messages to make internal schemas and object layouts difficult for outside parties to understand.
Sign All Messages Recommends applying signatures to all outgoing documents and providing the recipient with an option of performing signature verification for authentication.
Time-Stamp All Messages Recommends using the Network Time Protocol (NTP) or XML Digital Signatures to time-stamp all incoming and outgoing messages.
Encrypt Message Fields Recommends the encryption of individual XML documents and data fields within documents with different encryption keys. This security practice ensures that a decrypted message exposed in XML plain text format is not vulnerable to a security attack.
Implement Secure Auditing Recommends using a combination of XML Digital Signatures and time-stamping to add security to transaction logs.