Programming WebLogic Security
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
This section covers the following topics:
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.
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 section covers the following topics:
To implement connection filtering, write a class that implements the connection filter interfaces. The following weblogic.security.net
interfaces are provided for implementing connection filters:
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.
For code examples that demonstrate of how to use this interface, see Connection Filter Examples.
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, 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: 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.
For a code example of how to use this interface, see Connection Filter Examples.
Two weblogic.security.net
classes are provided for implementing connection filters:
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.
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()
.
For a code example of how to use this class, see Listing 6-1.
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 Connection Filter Examples on page 6-8 demonstrate both methods.
The following sections provide information and guidelines for writing connection filter rules:
The syntax of connection filter rules is as follows:
#
) is the comment character. Everything after a pound sign on a line is ignored. 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.
targetAddress localAddress localPort action protocols
targetAddress action protocols
targetAddress
specifies one or more systems to filter. localAddress
defines the host address of the WebLogic Server instance. (If you specify an asterisk (*
), the match returns all local IP addresses.) localPort
defines the port on which the WebLogic Server instance is listening. (If you specify an asterisk (*
), the match returns all available ports on the server). action
specifies the action to perform. This value must be allow
or deny
. protocols
is the list of protocol names to match. The following protocols may be specified: http
, https
, t3
, t3s
, ldap
, ldaps
, iiop
, iiops
, and com
. (Although the giop
, giops
, and dcom
protocol names are still supported, their use is deprecated as of release 9.0; you should use the equivalent iiop
, iiops
, and com
protocol names.)Note: The SecurityConfigurationMBean
provides a CompatibilityConnectionFiltersEnabled
attribute for enabling compatibility with previous connection filters.
Two types of filter rules are recognized:
A fast rule applies to a hostname or IP address with an optional netmask. If a hostname corresponds to multiple IP addresses, multiple rules are generated (in no particular order). Netmasks can be specified either in numeric or dotted-quad form. For example:
dialup-555-1212.pa.example.net 127.0.0.1 7001 deny t3 t3s #http(s) OK
192.168.81.0/255.255.254.0 127.0.0.1 8001 allow #23-bit netmask
192.168.0.0/16 127.0.0.1 8002 deny #like /255.255.0.0
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 hostname. BEA recommends using numeric IP addresses instead.
A slow rule applies to part of a domain name. Because a slow rule requires a connect-time DNS lookup on the client-side in order to perform a match, it may take much longer to run than a 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.
To further protect your server and only allow connections from certain addresses, specify the last rule as:
0.0.0.0/0 * * 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
0.0.0.0/0 * * 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 (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 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.
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.
To develop custom connection filters with WebLogic Server, perform the following steps:
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.
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 the Configuring Connection Filtering section in Securing WebLogic Server. For an example of how to use a flat file to implement connection filtering, see the referenced SimpleConnectionFilter.java
file in Connection Filter Examples on page 6-8.ConnectionFilterRulesListener
interface to implement connection filtering, see the referenced SimpleConnectionFilter2.java
file in Connection Filter Examples on page 6-8.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.
This section refers to sample code which is available online at BEA's dev2dev web site. The net
directory contains ant
build files, a package.html
file which contains instructions, a connection filter
file, and the following Java files which include examples of two connection filters:
FastFilterEntry.java
FilterEntry.java
SimpleConnectionFilter.java
SimpleConnectionFilter2.java
SlowFilterEntry.java
Each connection filter example provides an efficient, generalized connection filter which parses the rules and sets 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 might, 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-summary.html
file included with in the examples.
The SimpleConnectionFilter
example implements the ConnectionFilter
interface and filters connections using rules that you define in the filter file.
public class SimpleConnectionFilter implements ConnectionFilter {
public static final String FILTER_FILE = "filter";
private FilterEntry[] rules;
...
The SimpleConnectionFilter2
example implements the ConnectionFilter
and ConnectionFilterRulesListener
interfaces and filters connections using the rules that you define using the Administration Console.
public class SimpleConnectionFilter2
implements ConnectionFilter, ConnectionFilterRulesListener {
private FilterEntry[] rules;
private Vector entries;
...
In Listing 6-1, WebLogic Server calls the SimpleConnectionFilter.accept()
method with a ConnectionEvent
. The 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 example.
Listing 6-1 Example of Filtering Network Connections
public void accept(ConnectionEvent evt)
throws FilterException
{
InetAddress remoteAddress = evt.getRemoteAddress();
String protocol = evt.getProtocol().toLowerCase();
int bit = protocolToMaskBit(protocol);
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))
{
case FilterEntry.ALLOW:
return;
case FilterEntry.DENY:
throw new FilterException("rule " + (i + 1));
case FilterEntry.IGNORE:
break;
default:
throw new RuntimeException("connection filter internal error!");
}
}
// If no rule matched, we allow the connection to succeed.
return;
}
![]() ![]() |
![]() |
![]() |