Programming WebLogic Security

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Using Network Connection Filters

This section covers the following topics:


The Benefits of Using Network Connection Filters

Security roles and security policies let you secure WebLogic resources at the domain level, the application level, and the application-component level. Connection filters let you deny access at the network level. Thus, network connection filters provide an additional layer of security. Connection filters can be used to protect server resources on individual servers, server clusters, or an entire internal network.

Connection filters are particularly useful for controlling access through the Administration port. Depending on your network firewall configuration, you might be able to use a connection filter to further restrict administration access. A typical use is to restrict access to the Administration port to only the servers and machines in the domain. Even if an attacker gets access to a machine inside the firewall, they will not be able to perform administration operations unless they are on one of the permitted machines.

Network connection filters are a type of firewall in that they can be configured to filter on protocols, IP addresses, and DNS node names. For example, you can deny any non-SSL connections originating outside of your corporate network. This would ensure that all access from systems on the Internet would be secure.


Network Connection Filter API

This section describes the package. This API provides interfaces and classes for developing network connection filters. It also includes a class, ConnectionFilterImpl, which is a ready-to-use implementation of a network connection filter. For more information, see Javadocs for WebLogic Classes for this release of WebLogic Server.

This section covers the following topics:

Connection Filter Interfaces

To implement connection filtering, write a class that implements the connection filter interfaces. The following interfaces are provided for implementing connection filters:

ConnectionFilter Interface

This interface defines the accept() method, which is used to implement connection filtering. To program the server to perform connection filtering, instantiate a class that implements this interface and then configure that class in the Administration Console. This interface is the minimum implementation requirement for connection filtering.

Note: Implementing this interface alone does not permit the use of the Administration Console to enter and modify filtering rules to restrict client connections; you must use some other form (such as a flat file, which is defined in the Administration Console) for that purpose. To use the Administration Console to enter and modify filtering rules, you must also implement the ConnectionFilterRulesListener interface. For a description of the ConnectionFilterRulesListener interface, see ConnectionFilterRulesListener Interface.

ConnectionFilterRulesListener Interface

The server uses this interface to determine whether the rules specified in the Administration Console in the ConnectionFilterRules field are valid during startup and at runtime.

Note: You can implement this interface or just use the WebLogic connection filter implementation,, which is provided as part of the WebLogic Server product.

This interface defines two methods that are used to implement connection filtering: setRules() and checkRules(). Implementing this interface in addition to the ConnectionFilter interface allows the use of the Administration Console to enter filtering rules to restrict client connections.

Note: In order to enter and edit connection filtering rules on the Administration Console, you must implement the ConnectionFilterRulesListener interface; otherwise some other means must be used. For example, you could use a flat file.

Connection Filter Classes

Two classes are provided for implementing connection filters:

ConnectionFilterImpl Class

This class is the WebLogic connection filter implementation of the ConnectionFilter and ConnectionFilterRulesListener interfaces. Once configured using the Administration Console, this connection filter accepts all incoming connections by default, and also provides static factory methods that allow the server to obtain the current connection filter. To use this connection to deny access, simply enter connection filter rules using the Administration Console.

This class is provided as part of the WebLogic Server product. To configure this class for use, see Configuring the WebLogic Connection Filter.

ConnectionEvent Class

This is the class from which all event state objects are derived. All events are constructed with a reference to the object, that is, the source that is logically deemed to be the object upon which a specific event initially occurred. To create a new ConnectionEvent instance, applications use the methods provided by this class: getLocalAddress(), getLocalPort(), getRemoteAddress(), getRemotePort(), and hashcode().


Guidelines for Writing Connection Filter Rules

This section describes how connection filter rules are written and evaluated. If no connection rules are specified, all connections are accepted.

Depending on how you implement connection filtering, connection filter rules can be written in a flat file or input directly on the Administration Console.

The following sections provide information and guidelines for writing connection filter rules:

Connection Filter Rules Syntax

The syntax of connection filter rules is as follows:

The format of filter rules differ depending on whether you are using a filter file to enter the filter rules or you enter the filter rules on the Administration Console.

Types of Connection Filter Rules

Two types of filter rules are recognized:

How Connection Filter Rules are Evaluated

When a client connects to WebLogic Server, the rules are evaluated in the order in which they were written. The first rule to match determines how the connection is treated. If no rules match, the connection is permitted.

To further protect your server and only allow connections from certain addresses, specify the last rule as:  *  *  deny

With this as the last rule, only connections that are allowed by preceding rules are allowed, all others are denied. For example, if you specify the following rules:

<Remote IP Address> * * allow https * * deny

Only machines with the Remote IP Address are allowed to access the instance of WebLogic Server running connection filter. All other systems are denied access.

Note: The default connection filter implementation interprets a target address of 0 ( as meaning “the rule should apply to all IP addresses.” By design, the default filter does not evaluate the port or the local address, just the action. To clearly specify restrictions when using the default filter, modify the rules.
Note: Another option is to implement a custom connection filter.


Configuring the WebLogic Connection Filter

WebLogic Server provides an out-of-the-box network connection filter. To use the filter, simply configure it using the Administration Console. For information on how to configure connection filters, see Securing WebLogic Server.


Developing Custom Connection Filters

If you decide not to use the WebLogic connection filter and want to develop you own, your can use the application programming interface (API) provided in the package to do so. For a description of this API, see Network Connection Filter API.

To develop custom connection filters with WebLogic Server, perform the following steps:

  1. Write a class that implements the ConnectionFilter interface (minimum requirement).
  2. Or, optionally, if you want to use the Administration Console to enter and modify the connection filtering rules directly, write a class that implements both the ConnectionFilter interface and the ConnectionFilterRulesListener interface.

  3. If you choose the minimum requirement in step 1 (only implementing the ConnectionFilter interface), enter the connection filtering rules in a flat file and define the location of the flat file in the class that implements the ConnectionFilter interface. Then use the Administration Console to configure the class in WebLogic Server. For instructions for configuring the class in the Administration Console, see “Configuring Connection Filtering” in Securing WebLogic Server.
  4. If you choose to implement both interfaces in step 1, use the Administration Console to configure the class and to enter the connection filtering rules. For instructions on configuring the class in the Administration Console, see “Configuring Connection Filtering” in Securing WebLogic Server.

Note that if connection filtering is implemented when a Java or Web browser client tries to connect to a WebLogic Server instance, The WebLogic Server instance constructs a ConnectionEvent object and passes it to the accept() method of your connection filter class. The connection filter class examines the ConnectionEvent object and accepts the connection by returning, or denies the connection by throwing a FilterException.

Both implemented classes (the class that implements only the ConnectionFilter interface and the class that implements both the ConnectionFilter interface and the ConnectionFilterRulesListener interface) must call the accept() method after gathering information about the client connection. However, if you only implement the ConnectionFilter interface, the information gathered includes the remote IP address and the connection protocol: http, https, t3, t3s, ldap, ldaps, iiop, iiops, or com. If you implement both interfaces, the information gathered includes the remote IP address, remote port number, local IP address, local port number and the connection protocol.

  Back to Top       Previous  Next