The Default Connection Filter

WebLogic comes preconfigured with a useful connection filter that can process a
number of filter rules defined using the Administration Console in the Connection
Filter Rules setting. The connection filter attempts to match an incoming connection
against all the rules, beginning from the first rule in the list. If a matching rule is
found, the connection is allowed (or disallowed) depending on the rule’s action. If
no matching rule is found, the incoming connection is permitted.

You can specify any number of rules; each rule should be on a single line. The syntax
for a connection filter rule is shown here:

target localAddress localPort action protocolList

Here are the definitions for the parameters of a connection filter rule:

The target parameter specifies the client hosts that the rule must examine. We
discuss its syntax later.

The localAddress parameter refers to the server's host address to which the client
connects. If you specify an asterisk (*), this matches all local IP addresses.

The localPort parameter indicates the server port to which the client connects.
If you specify an asterisk (*), this matches all available ports.

The action parameter indicates whether the rule should allow or reject the
incoming connection request. It can take two possible values: allow or deny.

Use the protocolList parameter to define a space-separated list of protocol
names that should be matched. The protocol names can be: http, https, t3, t3s,
giop, giops, dcom, or ftp. If no protocols are listed, the rule checks for all protocols.
Versions of WebLogic 7.0 and WebLogic 8.1 also permit the ldap protocol
to be specified.

You also can include a # character anywhere on the line. Any text after this character
until the end of the line is treated as a comment.

A filter rule can define the target parameter in two forms:

It can be a "fast" rule if the value for the target parameter is either a hostname or an IP address.

It can be a "slow" rule if the value for the target parameter is a domain name.

For fast rules, you can specify either the client's hostname or IP address. The IP
address can be followed by an optional netmask, the two being separated by a /
character. If you supply a hostname that resolves to a list of IP addresses, the server
automatically generates multiple versions of the same rule for each IP address when
it boots up. These rules are called "fast" because the server eventually has a list of
rules that use static IP addresses; therefore, no connect-time DNS lookups are
required once the server is up and running. All hostnames are resolved to their IP
addresses when the server boots and goes through all the filter rules. Here are a few
examples of fast rules:

For slow rules, the value for the target parameter is a domain name beginning with
an asterisk (*). An asterisk may be used only at the head of the domain name. Here is
an example of a slow rule:

*.oreilly.com 127.0.0.1 7001 allow t3

This rule allows incoming T3 connections on port 7001 from any client that runs on
a host within the oreilly.com domain. It's called a "slow" rule because it requires a
connect-time DNS lookup in order to execute the match, so it is literally slower than
the fast rules.

The following rule is very handy for denying all access to your server:

0.0.0.0/0 deny # refuse the connection request

You can define this rule at the end of the list of filter rules, and thereby deny access to
all connections that fail to match any of the previous rules in the list. In this way, you
can ensure that an incoming connection request is allowed only if it matches one of
the preceding filter rules.

The Security Provider Architecture

Let's now turn our attention to WebLogic's infrastructure for application-level security.
WebLogic defines a standard set of SSPIs that provide high-level security services.
WebLogic also supplies a default set of security providers that implement these
SSPIs. These default security providers support and enhance the standard J2EE rolebased
security framework. In fact, they also allow you to programmatically control
its behavior. There are two important characteristics of this security framework:

Modular
The SSPIs are split into discrete modules so that each security provider can deal
with different but specific aspects of WebLogic's security (e.g., authentication,
authorization, auditing, and more).

Pluggable
Because these security providers live behind a layer of SSPIs, WebLogic makes it
easier to replace or enhance the default implementation with your own or a
third-party implementation.

The SSPIs hide the actual implementation of the security providers, thereby enabling
you to plug in and play your own modules and modify selected aspects of the security.
For instance, the default Authentication Provider can be replaced with one that
supports some form of biometric recognition, or the Auditing Provider can be
replaced with one that notifies interested parties after a user has made a certain number
of failed attempts to log in.

A security realm is a logical grouping of users, groups, roles, and security policies,
along with a complete set of security providers. By default, WebLogic Server comes
equipped with two such realms: the legacy compatibility realm that provides support
for WebLogic 6.x–type security configurations, and the new default realm. The default realm which is often referred to by its default name myrealm is WebLogic's
standard implementation of the security providers. Although you can configure multiple
realms for a domain, one realm can be active only; this active realm controls all
aspects of the domain’s security.

You can determine which realm your domain is set up to use by selecting the domain
from the left frame of the Administration Console and then choosing the View
Domain-Wide Security Settings option. The Configuration/General tab displays a
Default Realm field that indicates the security realm currently being used by your
domain. The Administration Console lets you configure virtually all aspects of the
security realm. You can view and modify the realm's configuration by selecting the
realm from under the Security/Realms node in the left pane of the Administration
Console. Here, you will find subnodes for all the security providers within the realm,
together with access to the realm’s users, groups, and roles.

To understand how WebLogic's default security realm works, you need to understand
the authentication and authorization structure that WebLogic imposes on its
resources and how it integrates with the standard J2EE role-based security. The
remainder of this section is dedicated to exploring these concepts. The following section
examines the security providers in more detail.

Overview

WebLogic's authentication and authorization providers, part of the default implementation
of the SSPIs, rely on the important concepts shown in the following list.

A user, which represents a person, system, or Java client

A group, which represents a static collection of users

A role, which represents a dynamic collection of users

A security policy, which defines which users are granted access to a WebLogic
resource

You can use WebLogic to configure these entities and thereby protect any resource
within a domain, right from the call to an EJB method all the way through to a particular
operation from the Administration Console. This framework prohibits unauthorized
access both from within (e.g., a servlet invoking an EJB method) and from
without (e.g., a Java client attempting to use a JDBC data source).

To place these concepts in context, let's refer back to the "Security Configuration" section
in Chapter 2, where we examined how to protect the web resources in the /admin directory of a web application. In the standard web.xml deployment descriptor, we defined a security constraint that granted access to a security role named webadmin:

Up until this point, we have utilized the standard J2EE security features found in the
deployment descriptors. Now we have to assign the virtual security role defined in
the web.xml file to an actual physical entity in WebLogic Server. This is achieved by
associating the role name to a number of principals already configured in WebLogic
Server. The weblogic.xml descriptor file for the web application holds this mapping:

This XML fragment correlates the webadmin role defined and used within the web
application with the actual WebLogic users jmountjoy and achugh. In this way, we are
able to prohibit users who are not in the webadmin role from accessing web content
under the /admin folder. Let’s now look at just how this setup protects the web
resources in the web application.

A protected resource restricts access to only a subset of users. Any user that satisfies
the access constraints laid down on the protected resource is then authorized to
access the resource. WebLogic lets you protect a variety of resources: web applications,
URLs (as in the earlier example), individual EJB methods, web services, connection
pools, and even branches of the JNDI tree. For instance, you could ensure
that only certain users are allowed to access a connection pool or invoke a method
on a protected EJB. In the case of our sample web application, the set of URLs
matching the pattern /admin/* represents a protected resource. This means that you
can easily set up a secure environment in which applications are forced to obey the
security constraints that you’ve laid out. WebLogic also makes it easy to adapt the
configuration according to your needs with minimal code changes. In the case of our
sample web application, the security constraints are defined declaratively in the
deployment descriptors. Thus, you can adjust the security settings with no code
changes.

The access control mechanism relies on the notion of an authenticated user. The user
represents an authenticated entity—it could be a person (as in this case) or an external,
client program. A user may authenticate itself in different ways. Over the Web, a
user may be required to fill in a login form. A Java client application, on the other
hand, may rely on JAAS authentication to establish trust with WebLogic Server. In
our example, the user is determined from the username and password (login credentials)
supplied over the Web. In general, a user has a number of principals (identities)
associated with it as a result of an authentication. For instance, the principals
associated with the system user after successful authentication include the system
user itself and the group to which it belongs—i.e., the Administrators group. Some
users may not authenticate at all, in which case they will remain anonymous.

When the domain holds an overwhelming number of WebLogic users, it becomes
cumbersome to manage the security needs of each individual user. For this reason,
WebLogic lets you configure static collections of users, called groups. From a security
point of view, if a role or policy statement is applied to a group, the role or policy
is assigned to all members of the group. From an administration point of view, it
is easier to manage a handful of groups rather than (say) several hundred users.
Remember, a group is a static collection of users. An administrator explicitly defines
the members of a group at configuration time. As we saw earlier, a group can also act as a security principal. So, for instance, our weblogic.xml descriptor file could easily map the security role to the name of an existing group:

In this case, access to the web content would be restricted only to all users within
someAdminGroup.

A security role represents a dynamic collection of users whose membership is evaluated
at runtime based on the subject’s principals and other membership criteria.
Whether a user is in a role depends on whether the user satisfies the membership conditions
of the role at runtime. You can specify a number of membership conditions
for the role. These include a logical mix of usernames, group names, and times of
access during the day. For instance, you may define the membership condition for
the DayShopper role as being "any user who belongs to the Shopper group and the
time of access is between 8:00 a.m. and 5:00 p.m.". You may assign a number of
roles to a resource in order to help specify the authorization conditions of the
resource. Note that the roles themselves do not guarantee access control, they just
facilitate in the definition of a policy statement that ultimately protects access to the
target resource. In terms of the earlier example, we created a role called webadmin.
The membership conditions for the role are simple: the client has to be authenticated
as either jmountjoy or achugh before the web application considers it in the
webadmin role.

You can protect a WebLogic resource by defining a policy statement for it. A security
policy is a statement about access—it determines which users will have access to
the resource. Just as you can with roles, you can define a policy in terms of a logical
combination of a number of conditions: usernames, group names, the time of access
during the day, and role names. For instance, you could assign the following policy
to a JDBC pool: "the caller must belong to the DayShopper role or the Administrator
group." This means that only authenticated users who belong to the Administrator
group or pass the membership criteria of the DayShopper role may access the pool. If
any user fails these access control checks defined for the JDBC pool, WebLogic will
raise an authorization exception.

Now let's revisit the earlier security constraints on our web application in terms of
these concepts. The weblogic.xml descriptor file defines a webadmin role. At deploy
time, WebLogic reads this descriptor file and creates a webadmin role within its internal
security configuration. This internal security role is configured to ensure that
only the users achugh and jmountjoy can qualify for membership to this role. Thus,
the J2EE role gets mapped to a WebLogic role, whereas the role-to-principal(s)
assignment defines the membership criteria for the internal role.

In addition, WebLogic creates and assigns a policy statement to the web application
that protects all web resources that match the URL pattern /admin/*. The policy
statement will grant access to any caller satisfying the following condition: "the caller
is in the webadmin role." Through this policy statement, WebLogic can ensure that
any user who isn’t a member of the webadmin role is unable to access the web content
under the /admin folder. Thus, WebLogic relies on a behind-the-scenes policy statement
to enforce the security constraints defined by the deployment descriptors.
Later, we see how you can explicitly create your own policy statements.

Users and Groups

To list the users that belong to a realm, select the realm from the Administration
Console and choose the Users node. You then can use the righthand frame to view
all the users or filter the list. The System user account also will be part of the list—
this is the Administration user account that was defined when you used the Configuration
Wizard to create the domain. Select the "Configure a new User" option to create
a new user. For each user, you need to specify a name, a short description, and a
password. Note that all usernames within a realm must be unique. The default provider
uses case-insensitive usernames. The user may belong to one or more groups.

To list and edit all the groups that belong to a security realm, select the realm from
the Administration Console and then choose the Groups node. You can also create a
new group here. The Membership tab for a group is a little misleading, as it does not
let you view the members of the group. To see if a user is a member of a group, you
have to select the user and view its Groups tab. WebLogic allows you to add groups
to other existing groups, and the Membership tab lists all subgroups that are contained
within the selected group. You can also use this tab to add another group to
the current group.

Group membership places two important implications on your security configuration.
Imagine you’ve defined two groups, A and B, in your domain, where group B is a
member of group A. This means that:

Every user that belongs to group B also belongs to group A.

If you assign a role or policy to group A, all members of group A as well as all
members of group B will be assigned the same role or policy.

When you view the Groups tab for a user, the Administration Console lists only the
groups that the user belongs to directly. So, if a user belongs to group B, the Administration
Console lists only group B under the Groups tab, even though the user actually
belongs to both groups A and B.

When you create a new domain using the Configuration Wizard, the following
groups are created automatically and are ready for use: Administrators, Deployers,
Operators, and Monitors. Initially, the System user is the only user created, and it is
also the only member of the Administrators group in the domain.

Remember, groups simply ease the task of administration. If a user is a member of a
group, he is not automatically guaranteed any special privileges. A group inherits
access privileges only when it participates in a policy statement (either directly or
through a role). For example, the initial System user account acquires Administrative
access rights only because it is a member of the Administrators group, which in
turn is a member of a (global) Admin role, and a policy statement is in place that
grants access to all areas of the domain to the Admin role.

Two groups are not listed on the Groups page, but are automatically made available
to the security realm:

users
This group represents the set of all authenticated users. Any user that successfully
authenticates itself is a member of the users group.

everyone
This group represents the set of all WebLogic users, including anonymous users.
Any user, whether authenticated or anonymous, is a member of the group
everyone.

These groups provide a convenient way for setting up the default access control. For
instance, a resource can be made accessible to all users through the policy statement
"User is a member of the group everyone." Alternatively, you can restrict access to
only authenticated users by defining the following policy on a resource: "User is a
member of the users group." You can also programmatically check for group membership
on the server side. The following example checks whether the current user is
a member of the users or everyone group: