Programming WebLogic Security
Security roles and security policies allow you to secure WebLogic resources at the domain level, the application level, and the application-component level, however, connection filters allow you to deny access at the network level. Thus, network connection filters are used to add an additional layer of security. Connection filters can be used to protect server resources on individual servers, server clusters, or an entire internal network, or Intranet.
Connection filters are particularly useful when using the Administration port. Depending on your network firewall configuration, you may be able to use a connection filter to further restrict administration access. A typical use might be 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.
This section describes the
weblogic.security.net 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 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, rather, some other form (such as a flat file, which is defined in the Administration Console) must be used 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.
For code examples that demonstrate of how to use this interface, see Connection Filter Examples.
The server uses this interface to determine if the rules specified in the Administration Console in the
ConnectionFilterRules field are valid during startup and at runtime based on the
Note: You can optionally implement this interface or just use the WebLogic connection filter implementation,
weblogic.security.net.ConnectionFilterImpl, which is provided as part of the WebLogic Server product.
This interface defines two methods that are used to implement connection filtering:
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: To be able 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.
For a code example of how to use this interface, see Connection Filter Examples.
This class is the WebLogic connection filter implementation. It implements the
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.
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. Applications use the methods provided by this class (
hashcode()) to create a new
For a code example of how to use this class, see Listing 6-1.
Connection filter rules can be written in a flat file or input directly on the Administration Console, depending on how you implement connection filtering. The Network Connection Filter code examples demonstrate both methods. The Network Connection Filter code examples are http://dev2dev.bea.com/code/wls.jsp available at on the BEA dev2dev Web site.
#) is the comment character. Everything after a pound sign on a line is ignored.
targetspecifies one or more systems to filter.
localAddressdefines the host address of the WebLogic Server instance. (If you specify an asterisk (
*), the match returns all local IP addresses.)
localPortdefines the port on which the WebLogic Server instance is listening. (If you specify an asterisk, the match returns all available ports on the server).
actionspecifies the action to perform. This value must be
protocolsis the list of protocol names to match. The following protocols may be specified:
ldap. If no protocol is defined, all protocols will match a rule.
Hostnames for fast rules are looked up once at startup of the WebLogic Server instance. While this design greatly reduces overhead at connect time, it can result in the filter obtaining out of date information about what addresses correspond to a host name. BEA recommends using numeric IP addresses instead.
A slow rule applies to part of a domain name. Since a rule requires a connect-time DNS lookup on the client-side in order to perform a match, a slow rule may be much slower than the fast rule. Slow rules are also subject to DNS spoofing. Slow rules are specified as follows:
An asterisk only matches at the head of a pattern. If you specify an asterisk anywhere else in a rule, it is treated as part of the pattern. Note that the pattern will never match a domain name since an asterisk is not a legal part of a domain name.
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.
Note: The default connection filter implementation interprets a target address of 0 (0.0.0.0/0) as meaning "the rule should apply to all IP addresses." By design, the default filter does not evaluate the port, just the action. To clearly specify restrictions when using the default filter, modify the rules.
Another option is to implement a custom connection filter. A sample filter is available at http://dev.bea.com/code/security.jsp; the
FastFilterEntry.java example contains
match() methods, which determine how to process the rules.
WebLogic Server provides a network connection filter as part of the product. It is ready to use out of the box. To use it, simply configure it using the Administration Console. For information on how to configure connection filters, see Managing WebLogic Security.
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
weblogic.security.net package to do so. For a description of this API, see Network Connection Filter API.
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
ConnectionFilterinterface), enter the connection filtering rules in a flat file and define the location of the flat file in the class that implements the
ConnectionFilterinterface. Then use the Administration Console to configure the class in WebLogic Server. For instructions for configuring the class in the Administration Console, see the Configuring Connection Filtering section in Managing WebLogic Security. For an example of how to use a flat file to implement connection filtering, see the
SimpleConnectionFilter.javafile in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site.
ConnectionFilterRulesListenerinterface to implement connection filtering, see the
SimpleConnectionFilter2.javafile in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site.
Notes: 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
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, GIOP, GIOPS, DCOM, FTP, or LDAP). 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.
Two connection filter examples are available for use with WebLogic Server. Both examples provide an efficient, generalized connection filter. To download the connection filter examples, go to http://dev2dev.bea.com/code/wls.jsp. Both examples parse the rules and set up a rule-matching algorithm so that connection filtering adds minimal overhead to a WebLogic Server connection. If necessary, you can modify this sample code and reuse it. You may, for example, want to accommodate the local or remote port number in your filter or a more site-specific algorithm that will reduce filtering overhead. For instructions on how to build, configure, and run these samples, see the
package.html file included with in the Network Connection Filter code examples.
examples.security.net.SimpleConnectionFilter example is included in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site. This example implements the
ConnectionFilter interface and filters connections using rules that you define in the filter file.
examples.security.net.SimpleConnectionFilter2 example is included in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site. This example implements the
ConnectionFilterRulesListener interfaces and filters connections using the rules that you define using the Administration Console.
In Listing 6-1, WebLogic Server calls the
SimpleConnectionFilter.accept() method with a
SimpleConnectionFilter.accept() method gets the remote address and protocol and converts the protocol to a bitmask to avoid string comparisons in rule-matching. Then the
SimpleConnectionFilter.accept() method compares the remote address and protocol against each rule until it finds a match.
This code fragment is taken from the
SimpleConnectionFilter.java file in the Network Connection Filter code examples, which are available at http://dev2dev.bea.com/code/wls.jsp on the BEA dev2dev Web site.
public void accept(ConnectionEvent evt)
InetAddress remoteAddress = evt.getRemoteAddress();
String protocol = evt.getProtocol().toLowerCase();
int bit = protocolToMaskBit(protocol);
// this special bitmask indicates that the
// connection does not use one of the recognized
if (bit == 0xdeadbeef)
bit = 0;
// Check rules in the order in which they were written.
for (int i = 0; i < rules.length; i++)
switch (rules[i].check(remoteAddress, bit))
throw new FilterException("rule " + (i + 1));
throw new RuntimeException("connection filter internal error!");
// If no rule matched, we allow the connection to succeed.