Java and Security, Part 1

Editor's note: In part one in a two-part series of excerpts from Chapter 17 of WebLogic: The Definitive Guide, authors Avinash Chugh and Jon Mountjoy examine WebLogic's various security mechanisms, beginning with a look at the Java Security Manager and how WebLogic filters connection requests. They also cover WebLogic's
authentication and authorization framework and how it supports the
standard J2EE security services.

WebLogic provides a comprehensive suite of security services that can be used to
protect all aspects of a domain and its deployments. These security services affect all
aspects of your domain: from the lowest level provided by the Java Security Manager,
to connection-level security, to application-level security in which you can protect
your administered and deployed objects (such as EJBs, web services, and JDBC
pools), and finally to domain-level security in which you can establish trust between
two domains. These security services target three distinct sets of users: application
developers who can use the services to secure their applications; administrators who
need to configure security for the system and deployments; and security vendors or
customers who can change and extend the facilities provided by WebLogic.

Let's begin at the JVMlevel. Here, the Java Security Manager uses a security policy
file to restrict access to specific runtime operations. This ensures that programs running
on the JVM, including WebLogic Server itself, can access protected resources in
permitted ways only. For instance, you can configure the Java Security Manager so
that all Java threads have write-access only to specific directories in the filesystem.
WebLogic enhances the Security Manager by allowing you to define additional security
policies for resource adapters and EJBs, thereby ensuring that these components
have access to defined resources only. There are also other global, higher-level security
permissions that apply to these resources and application code.

WebLogic can filter connection requests from clients. A connection filter defines rules
that determine what basis the server accepts or denies client connections. These rules
are based on several parameters: typically, the client's IP address and port; the protocol
used to establish the connection; and the server's listen address and port. You
can assign multiple connection filters to a server, or perhaps even write your own
connection filter class that implements custom filtering logic. Using connection filters,
you can easily ensure that the server accepts only T3 connections from within
your intranet, for example. SSL security is another mechanism available at the socket
level, which we encountered in Chapter 16. SSL protects network communication
provided through its support for data integrity, confidentiality, and authentication.

WebLogic provides partial support for standard JAAS. The JAAS framework is a
standard extension to J2SE v1.3 and is now part of the J2SE v1.4 platform. Authentication
enables the server to verify the identity of the user who is running the Java
code, whether it is an applet, servlet, EJB, or application. Authorization is the server's
ability to enforce access control based on the user's identity, security privileges, and
policies. WebLogic allows Java clients to use JAAS authentication, and login modules
are implemented using JAAS. If you need to use JAAS authorization, you will
have to code your own schema above WebLogic's infrastructure.

WebLogic's security infrastructure is founded on a set of modular, extensible security
service provider interfaces (SSPIs). This architecture allows you to plug in new
security providers, swap out old ones, and run WebLogic's default providers alongside
your own. Your WebLogic distribution is equipped with a set of security providers
that provide the default implementations for the SSPIs. WebLogic's security
providers implement the underlying security framework for your J2EE applications.
That is, the standard J2EE-defined security mechanisms are implemented (and
extended) through the SSPIs. Often, WebLogic's security providers will refine the
existing security constraints. For instance, the standard ejb-jar.xml deployment
descriptor allows you to restrict access to an EJB method to authenticated users in a
specific role. WebLogic allows you to refine this constraint by ensuring that the user
has access only during certain times of the day. In fact, the SSPIs are an open architecture,
and you can easily plug in a third-party security provider from a security vendor.
Alternatively, you can build new security services by implementing your own
security providers.

WebLogic's default security providers are quite versatile. A security realm is a logical
grouping of users, groups, roles, and security policies, along with the complete set of
security providers. Security policies assigned to server resources can be used to determine
who is authorized to access the resource. WebLogic lets you protect a whole
range of resources: individual EJB methods, a web application, a collection of web
pages, connection pools, data sources, or any administered object. You even can protect
a branch within the JNDI tree, thereby preventing unauthorized clients from
looking up objects in the JNDI tree. All this security data is stored in an embedded
LDAP server. WebLogic also can be configured to use an external LDAP repository,
such as Open LDAP, Active Directory, or Novell NDS. These external repositories
can be used for authentication only, not authorization.

Finally, WebLogic allows you to set up a trust mechanism between two domains.
This ensures that authenticated users from one domain can then access resources in
another domain.

This chapter examines all of these security mechanisms. Although they are all quite
different from each other, they complement each other quite well. We begin with a
look at the Java Security Manager and how WebLogic is able to filter connection
requests. We then examine WebLogic's authentication and authorization framework
and learn how it supports the standard J2EE security services. We also coverthe various security providers available within a security realm and their default
implementations. Finally, we end with a look at how to authenticate using JAAS, and
examples of Authentication and Identity Assertion providers.

The Java Security Manager

At the JVMlevel, WebLogic can use the standard Java Security Manager to prevent
untrusted code from performing unwanted actions. Using a security policy file, you
can configure the JVMso that all threads running on the JVMhave restricted access
to sensitive runtime operations. The security policy file encapsulates a set of permissions
that are granted to (or revoked from) all classes loaded within the current
instance of the JVM. You can define a whole range of security permissions to control
access to particular resources—e.g., "write" access to certain folders on the filesystem,
"connect" access to a particular host and range of ports, "read" access to environment
variables, "get" access to the current class loader, and more. Refer to your
JDK documentation for more information on the Security Manager and security policy
files.

Java's Security Manager ensures that any code running within WebLogic accesses these
critical resources only in the permitted ways. This low level of access control may be
useful for third-party untrusted code. The Java Security Manager also can interact with
J2EE deployment settings. For instance, you can use the standard ra.xml deployment
descriptor to define security permissions that apply to the resource adapter. WebLogic
also provides similar access control for web applications and EJBs.

Note that WebLogic itself requires a policy file to be in place before it can run. The
startWebLogic scripts load the policy file located at WL_HOME/server/lib/weblogic.
policy by default.

Configuring the Security Manager

In order to use the Java Security Manager, you need to supply two options from the
command line when starting WebLogic Server:

You must use the –Djava.security.manager option to ensure that the default
security manager is installed, and that the JVM is subjected to policy checks.

You must use the –Djava.security.policy option to specify the location of a
security policy file.

By default, the JVMuses security policies defined in the java.security and java.policy
files located under the JAVA_HOME/jre/lib/security folder. Here is the syntax for
starting WebLogic Server using a custom security policy file:

The default startup scripts created by WebLogic refer to the sample security policy
file located at WL_HOME/server/lib/weblogic.policy. Notice how we've used the ==
(double equal sign) when specifying the java.security.policy argument. This persuades
the Security Manager to use c:\oreilly.policy as its only source of policies. If we
had used a single equal sign instead, the policy file would be used in conjunction
with default security policy files provided by your JDK installation.

Usually the JVMwill use the security policy file to enforce access control over any
code running within WebLogic. The only deviation from this rule is when WebLogic
Server starts up. When a server boots up, WebLogic partially disables the Java Security
Manager and replaces it with a variation that disables the checkRead( ) method.
While this approach improves the performance of the startup sequence, it also
reduces the security of the JVMduring startup. In addition, it means that the startup
classes for WebLogic will run using this modified security manager. You will need to
ensure that these classes cause no security breaches.

Note: Because the policy file determines access privileges for all classes running
within WebLogic's JVM, we recommend that only the Administrator
has read and write access to the security policy file. No other
users should be allowed to access the policy file.

Global Security Policies

WebLogic allows you to define security policies for EJBs, resource adapters, and web
applications in the weblogic.policy file. Table 17-1 lists the codebases under which
the default permissions for these component types may be defined.

You can use these codebases to grant special privileges to particular J2EE component
types. Note that any security policies defined under these codebases apply to all
EJBs, resource adapters, and web applications deployed to that particular server
instance.

Application-Specific Security Policies

You also can define security policies that are specific to an EJB component or
resource adapter, and thereby ensure that only particular components are targeted.
To achieve this, you must modify their deployment descriptors, and not the policy file itself. Resource adapters support this mechanism as part of the J2EE standard, and you need only modify the standard ra.xml descriptor file. For EJBs, you need to modify the weblogic-ejb-jar.xml descriptor file. In both cases, it is the securitypermission element that allows you to define additional security policies.

Let's look at specifying permissions for EJBs. The security-permission element in
the weblogic-ejb-jar.xml descriptor specifies security privileges that apply to all EJBs
packaged in the EJB JAR. The following example grants read and write access to a
temporary directory on the server's filesystem for the EJBs:

Notice how the security-permission-spec element defines a grant permission using
the same syntax for security policy files. The only restriction to this syntax is that you
cannot use the codebase or signedBy clauses.

Tracing the Security Manager

BEA provides a Recording Security Manager that can be used to trace any permission
problems caused by the Java Security Manager. When installed, the tool detects
and records all access control exceptions that occur at runtime. In this way, you can
easily pinpoint problems in your access control policy and later reconfigure the security
policy to remove these errors. The tool is not distributed with WebLogic Server.
However, it can be downloaded from BEA's dev2dev web site (http://www.dev2dev.bea.com).

Connection Filtering

At the connection level, WebLogic provides two security features: filtering and SSL.
Chapter 16 provides a detailed look at SSL. Let's take a look at connection filtering
here. A connection filter allows the server to reject unwanted connections based on
some criteria. For example, a connection filter would allow you to configure WebLogic to permit T3 or IIOP connections only from within your intranet, and reject any T3 or IIOP connection request from outside the intranet. So, connection
filtering provides network-level access control.

WebLogic comes equipped with a default connection filter that examines one or
more connection filter rules defined in the Administration Console. Alternatively,
you can create your own custom connection filter that evaluates the basis that
incoming connections are accepted by the server. A custom connection filter is a Java
class that implements WebLogic's ConnectionFilter interface. The interface is dead
simple—the class must implement the accept() method, which simply throws a FilterException
to indicate that an incoming connection request should not be allowed through. Here is an example of a connection filter that refuses T3 connections from hosts unless their IP address matches 10.*.*.*:

This filter simply throws a FilterException whenever the filter criteria have been violated.
If the method completes without throwing any exceptions, the connection is
allowed through. The method receives a single parameter, a ConnectionEvent object,
that encapsulates vital information about the connection request. Typically, you will
use this information to implement the acceptance criteria for the filter. The ConnectionEvent class provides various methods to access this information:

getProtocol()Retrieves a string value that represents the protocol used to establish the
connection.

getRemoteAddress()Retrieves a java.net.InetAddress object that represents the client’s address.

getRemotePort()Returns the client's port number used to establish the connection.

getLocalAddress()Retrieves a java.net.InetAddress object that represents the server’s listen
address.

getLocalPort()Obtains the server's port number to which the connection is being made.

Once you have compiled the filter class, you need to install it. First, you need to
ensure the class can be located from the server's classpath. Then, using the Administration
Console, expand the topmost node indicating your domain and choose the
View Domain-Wide Security Settings option. The Configuration/Filter tab contains
the settings for connection filters. WebLogic 7.0 users should select the Security/Filter
tab after expanding the domain node from the left pane.

Enter the name of your connection filter class in the Connection Filter setting. You
will also notice the Connection Filter Rules setting. Use this option if your filter class
also implements the optional ConnectionFilterRulesListener interface. In this case,
the connection filter will be able to receive and process filter rules defined in the
Administration Console.

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:

Protecting User Accounts

WebLogic provides a user lockout facility to prevent abuse of user accounts. A user
is locked out when a set threshold number of failed login attempts are made. When
this happens, the user account is locked for a configurable period of time, or until an
Administrator unlocks the user account. During this period, the user is prohibited
from using those credentials to access the server. In order to configure user lockout,
select the realm from under Security/Realms node in the left frame of the Administration
Console. You then can use the User Lockout tab to adjust the lockout features
and view lockout statistics.

Table 17-2 lists the various configuration options available under the User Lockout
tab. By default, these settings are configured for maximum security.

Table 17-2. Configuring user lockout

Setting

Description

Default

Lockout Enabled

This setting indicates whether the lockout facility is enabled. You will
need to disable this feature if you use an alternative Authentication Provider
that supports its own mechanism for protecting user accounts.

true

Lockout Threshold

This setting determines the maximum number of failed login attempts
that are permitted before the user is locked out.

5

Lockout Reset Duration

Suppose the Lockout Threshold is 5 minutes and the Lockout Reset Duration
is 3 minutes. If a user makes five failed login attempts within 3 minutes,
the user account will be locked out. If the five failed attempts do not
occur within 3 minutes, the account still will remain alive.

5 minutes

Lockout Duration

This setting determines the duration (in minutes) that a user will not be
able to access his account after being locked out.

30 minutes

Lockout Cache Size

This setting specifies the size of the cache that holds the invalid login
attempts.

5

Lockout GC Threshold

This setting determines the maximum number of invalid login attempts
that are held in memory. When the number of invalid login records
exceeds this value, WebLogic’s garbage collector removes all records that
have expired— i.e., when the associated user has been locked out.

400

While a user is locked out, a Details link appears under the Locked column in the
user list (under the Users node). If you select this link for any user in the list, you can
view the number of failed login attempts for the user and the time when the last login
attempt failed. You also can choose the Unlock option to manually reactivate the
user's account.

Roles

Unlike a group, a role represents a dynamic collection of users. Role membership can
be defined in terms of the following criteria:

Username
You can specify a number of usernames. If the authenticated user matches one of
the names in the list, and it satisfies all other criteria, it automatically becomes a
member of the role.

Group names
You can specify a number of group names. If the authenticated user is a member
of any of the groups in the list, and it satisfies all other criteria, it automatically
becomes a member of the role.

Hours of access
You can define a number of time periods during which users are allowed access.
If the user tries to access a resource during one of the time periods specified and
satisfies all other criteria, it automatically becomes a member of the role.

You can combine these rules in various ways, using logical AND and OR relationships.
For instance, you could create RoleA based on the criteria that the user belongs
to the group UKSeller and hours of access are between 8:00 a.m. and 9:00 p.m. Any
user who then tries to access a resource between these hours and also is a member of
the UKSeller group will be a member of RoleA. Alternatively, you could create RoleB
based on the criteria that the user belongs to the group UKSeller or the hours of
access are between 8:00 a.m and 9:00 p.m. In this case, any member of UKSeller will
always be in the role, and any user who tries to access a resource between 8:00 a.m
and 9:00 p.m also will be a member of the role, regardless of the groups it belongs to.
The membership conditions for the role are evaluated at runtime when a user
attempts to access a resource that is protected by a policy statement defined in terms
of that role. Thus, the membership conditions help evaluate whether the user is in
the role at a point in time.

In general, WebLogic's default Role Mapping Provider manages the information
about all the roles defined in a security realm. In fact, two kinds of roles can be
defined: global and scoped roles.

Global Roles

Global roles are available to all resources within a security domain. A default set of
global roles is created automatically when you create a new domain; it is used to
grant access to various operations. These prefabricated global roles are associated
with default security policies that implement the factory-set security configuration
for your WebLogic domain:

Admin
Users that belong to this role have complete access to all areas of the domain.
This includes the ability to view and edit the domain configuration, start and
stop servers, deploy applications (EJBs, JMS factories, web applications), and
more. Any user that belongs to the Administrators group automatically inherits
the Admin role. That is, the membership condition for the Admin role is that the
user must belong to the Administrators group.

Deployer
Users in this role are allowed to view the domain configuration, view and edit
deployment descriptors, and deploy applications, EJBs, startup and shutdown
classes, J2EE connectors, and web service components. The membership condition
for the Deployer role is that the user must belong to the Deployers group.

Operator
Users in this role can view the server configuration, as well as start, stop and
resume server instances. The membership condition for the Operator role is that
the user must belong to the Operators group.

Monitor
Users in this role are allowed only to view the server's configuration. The membership
condition for the Monitor role is that the user must belong to the
Monitors group.

In order to create or modify existing global roles, select the realm from the left frame
of the Administration Console and then select the Global Roles node.

WebLogic also provides a global role called anonymous. Its membership is defined to
include all users in the everyone group. Even though the anonymous role does not
appear in the roles listed in the Administration Console, you still can use it to define
policies on resources.

Scoped Roles

Most roles are scoped, meaning that they apply to a particular resource or branch of a
JNDI tree. Unlike global roles that are independent of any resource and can be managed
centrally via the Administration Console, scoped roles are distributed across
various resources. You have to select a particular resource in order to view the associated
scoped roles. Regardless of the actual resource, the underlying principle for creating
a scoped role is the same. Locate the resource from the left pane of the
Administration Console, then right-click and select Define Scoped Role. In some
cases, you can define scoped roles and their brethren, scoped policies, on even finer
aspects. For example, you can define a scoped role and policy on a per-method basis
for EJBs, on a per-operation basis for web services, and on an HTTP method type
(POST, GET, HEAD, etc.) basis for web resources within a web application. Let’s
now look at how to create scoped roles for particular resources, and at some precautions
you need to take during setup.

Connection pools and multipools

JDBC resources are located under the Services/JDBC subtree. You can right-click a
chosen resource (e.g., connection pool) and select Define Scoped Role to define a
role for the resource. You also can delete or modify previously assigned roles.

JDBC roles are hierarchical. If you right-click the JDBC/Connection Pools node, you
can follow the same procedure to create a scoped role that is applicable to all connection
pools.

JNDI branches

You can assign a role to a specific node or branch of the JNDI tree for a server. Select
the server from the left frame of the Administration Console, then right-click and
select the "View JNDI tree" option. This launches a new browser window that lets
you explore the JNDI tree for the chosen server. You then can select any node in the
tree, right-click, and select the Define Scoped Role option.

Web applications

The role and policy assignment for web applications is slightly different, in the sense
that the roles and policies are scoped to particular URLs within the web application.
Choose the web application from the left pane of the Administration Console and
then select the Define Scoped Role option. You then will be asked to supply a URL
pattern and a role that will be used to restrict access to the URL pattern. Later, you
can apply a policy statement to the web application using the same URL pattern and
scoped role. For example, you may wish to scope a role and policy to a particular
servlet only, in which case you can use a URL pattern such as /servletname. If you
want the role to apply to all resources in the web application, use the URL pattern /*.

Web services

Web service components are typically packaged in an EAR. You can locate the web
service by expanding the node representing the application under the Deployments/
Applications node. In WebLogic 7.0, you can locate the web service from under the
Deployments/Web Services node.

Right-click a service and select the Define Scoped Role option. This will let you
define a role for all of the services in the selected web service module. You also can
select the Define Policies and Roles for Individual Services option, which provides
you with a table listing all web services. For each web service, you can choose the
Define Scoped Role option to create a scoped role for that web service alone. When
you define a scoped policy in this way, you also will be able to choose to which operations
the policy should be applied.

The web service roles and policies are hierarchical. In essence, if you set up a role or
policy on a web service module using the Define Roles option, all services within the
module inherit the role and policy. You also can set a policy on the application that
bundles the web service module. In this case, all web service modules and all web
services within the modules will inherit the role and policy.

EJBs

The assignment of scoped roles to EJBs is very similar to that for web services. If you
select the EJB Modules node, any role or policy you define will be inherited by all
EJBs. If you select a particular EJB module and choose the Define Scoped Role
option, any roles you define will be scoped to all EJBs within that module. Finally, if
you select the Define Policies and Roles for Individual Beans option, you will be presented
with a list of EJBs, thus allowing you to assign the scoped role or policy individually
to each EJB. If you define a policy for a particular EJB in this manner, you
also can specify to which EJB methods the policy should be applied. An alternative
approach to defining scoped roles for all the EJBs in an application is to simply
define a global role instead.

JMS destinations

To assign a scoped role to a JMS destination, select the JMS destination under the
JMS server node that hosts it, right-click, and select the Define Scoped Role option.

Using the deployment descriptors

For a J2EE component (e.g., EJB, web application), the role information also can be
obtained from the deployment descriptors, as demonstrated earlier in the web application
example. When you deploy a J2EE component, the roles are automatically
created and populated with the data held in the deployment descriptors. If you subsequently
make changes to the new security roles, these changes are not persisted
back to the deployment descriptors. Ideally, once the J2EE component is deployed,
you need to reconfigure WebLogic so that it doesn’t refresh the roles when the component
is redeployed. Later, we'll see how to alter this default behavior of the security
providers by instructing them to ignore the security constraints in the
deployment descriptors.

The externally-defined Element

Recall how we used the weblogic.xml descriptor file for a web application to map the
security roles defined earlier in the standard web.xml descriptor file to actual principals
in WebLogic's security realm. For example, the following portion from the
weblogic.xml descriptor file shows how to list the principals associated with the role
mysecrole:

Alternatively, you could use the externally-defined* element to indicate to
WebLogic that the security role defined in the web.xml descriptor file actually points
to a role in the security realm created manually using the Administration Console.
This approach means that you don’t need to explicitly map the security role to existing
WebLogic users and groups. Instead, you can defer the membership conditions
for the security role until after the web application is deployed. For instance, suppose
the weblogic.xml descriptor file for our web application includes the following
security information:

This indicates that the security constraints for the web application's descriptor rely
on a role called mysecrole that already has been configured for the realm. When you
deploy the web application, WebLogic will look for mysecrole within its security
realm and use this security role to configure a policy statement on the web application.
In this case, the policy statement will specify the following condition: "Caller is
a member of the role mysecrole." In this way, WebLogic can ensure that only users
who are members of the security role mysecrole may invoke the protected resource.
Of course, mysecrole now must be configured for the realm using the Administration
Console, either as a global role or as a scoped role for this particular web application.
A similar technique can be used for EJBs.

An important benefit of the externally-defined element is that you don't need to
modify the way in which WebLogic handles security information in the deployment
descriptors (see the section "Ignoring the Deployment Descriptors" later in this
chapter). Because the security constraints are implemented through a policy statement
defined in terms of a security role that only can be populated using the Administration
Console, there is no chance of overwriting this role and policy assignment.
The major difference between this element and the traditional J2EE role assignment
is that any security role assignment that lists the principals in the weblogic.xml
descriptor file will create a role whose membership conditions are defined in terms of
these principals. If you use the externally-defined element, the security role assignment
must refer to a role that you’ve configured for the realm using the Administration
Console.

Policies

Security policies let you protect a wide variety of server resources. For instance, you
can decide who has access to the Administration Console, who can start and stop the
servers, and who can access the connection pools, web applications, EJBs, enterprise
applications, J2EE connectors, a particular branch of the JNDI tree, and more. Security
policies offer very tight control over the authorization settings within the
WebLogic domain. Although scoped roles look very similar to policies, policies
define access control while roles do not. In summary:

A policy statement is used to protect a resource.

A policy statement lets you specify a number of conditions under which users
may access the resource.

A security policy uses a superset of the conditions that are available to a role. You
can define a policy in terms of a logical combination of usernames, group names,
time-of-day settings, and roles. The roles used in a policy can be either global roles,
or those scoped to the resource for which you are defining the policy.

Note: A WebLogic resource is protected only when it has been assigned a
security policy. Some WebLogic resources come with a set of default
policies applied to them.

Whereas role information is stored by the Role Mapping Provider, policy information
is stored by the Authorization Provider. Even though you may configure the
security policies in the same way as the roles, we recommend that you set up roles to
identify user responsibilities and create policies to specify access restrictions using
these roles. That is, you should define roles in terms of existing users, groups, and
time-of-day settings, and then you can use these roles to configure a policy statement
for the resource. This scheme fits nicely with the J2EE role-based security
model covered earlier in the section "Overview."

A policy can be assigned in a number of ways:

WebLogic can assign policies to web applications and EJBs automatically, after
it has read their deployment descriptors.

The Administrator can assign policies to WebLogic resources manually and
tweak their configuration.

WebLogic provides default security policies that are applied to many resources.

Using the Administration Console

An Administrator can explicitly define security policies that help protect WebLogic
resources. You can assign a security policy in the same way that you define a scoped
role for a resource. Simply select the resource from the left pane of the Administration
Console, then right-click and choose the Define Security Policy option instead.
EJBs offer an additional option, "Define Security Policies and Roles for Individual
beans," that allows you to define a policy for a particular EJB and to further limit this
policy to selected EJB methods. Web service modules offer similar functionality,
allowing you to define a policy for a particular web service within a module and to
further limit the policy to selected web service operations. This same functionality
exists for JMS destinations, whereby the policy can be limited to either a send,
receive, or browse operation on a queue, or to a send or receive operation on a topic.

Enabling user-defined policies

In WebLogic 8.1, new policies that you create using the Administration Console will,
by default, not be applied. Instead, only those policies that were defined using
deployment descriptors will be in operation. For example, if you add a new scoped
policy for all .html files in a web application, and assuming that you had no such
security constraint defined in the deployment descriptors, your new scoped policy
will not be operational. To toggle this behavior, you need to select the security realm
from the left pane of the Administration Console and then select the General tab.
The Check Roles and Policies setting can assume two possible values.

Web Applications and EJBs Protected by DD
This option ensures that WebLogic honors only those security constraints
defined in the deployment descriptors of web applications and EJB modules.
This is the default behavior of the security realm.
All Web Applications and EJBs
This option ensures that WebLogic honors any security policies that are configured
for the web applications and EJB modules using the Administration
Console.

All Web Applications and EJBs
This option ensures that WebLogic honors any security policies that are configured
for the web applications and EJB modules using the Administration
Console.

Thus, you must change the value of the Check Roles and Policies setting to the latter
option if you need to enable the policies defined using the Administration Console.

Using the deployment descriptors

WebLogic supports the J2EE security model, which relies on the security roles defined
in the descriptor files to determine access privileges. WebLogic's Authorization Provider
examines the deployment descriptors when the EAR or WAR is deployed and
creates internal security roles based on the configuration settings. In addition, the provider
defines a security policy that grants access to all principals that belong to these
roles. Later, we'll see how to alter the default behavior of the providers by instructing
them to ignore the security data held in the deployment descriptors.

Default policies

WebLogic comes equipped with a number of default security policies—for example,
WebLogic supports a default policy that restricts access to the Administration
Console. The following security policies are based on role membership:

Administrative resources
The Administration Console and other administrative resources are protected by
a security policy that demands that the caller be in one of the following roles:
Admin, Deployer, Operator, or Monitor.

Server resources
Resources under the Server node in the Administration Console are protected by
a security policy that demands that the caller be either in the Admin or Operator
roles.

COM resources
Resources under the Services/jCOMnode in the left pane of the Administration
Console are protected by a policy that demands that the caller be in the JCOM
role.

By default, all application-specific resources, such as those related to JDBC, JMS,
EJB, EIS, MBean, and Web Services, are accessible to all users. This is possible
because these resources are protected by the default policy, which demands that the
caller be in the everyone group. You can always view the default security policy that applies to a WebLogic resource. For instance, if you right-click the Connection Pool node under the Services/JDBC node and then choose the Define Security Policy
option, you can view the default policy for all connection pools.

When you configure a new resource—for example, a new JDBC pool or a web services
component - it automatically inherits the default security policy. Any new
security policy associated with a resource also uses the inherited policy conditions.
However, if you define a new security policy for a resource with new policy conditions,
these settings override the inherited policy conditions. That is, if you define a
policy for a resource, the inherited policy conditions are ignored. For instance, if you
define a policy constraint for a JDBC pool that requires that the caller be in the role
MyRole, it overrides the default policy constraint that the caller be a member of the
group everyone.

Ignoring the Deployment Descriptors

When an application is deployed, WebLogic inspects the security constraints defined
in the deployment descriptors and sets up the appropriate role and policy statements
in the various providers. Because these roles and policy statements are not persisted
to the deployment descriptors (but rather to an internal store), reading this information
from the descriptor files the next time the application is deployed means that
WebLogic may overwrite any changes that you make to the role and policy information.
You can prevent this overwriting behavior by instructing WebLogic to ignore
the security constraints in the deployment descriptors the next time the application is
deployed. To configure this, navigate to the security realm using the left pane of the
Administration Console, and then in the General tab change the value of the On
Future Re-Deploys* attribute. The default value for this setting—i.e., initialize roles
and "policies" from DD—ensures that WebLogic does create the roles and policies
based on the security information held in the deployment descriptors. If you set the
attribute to "ignore roles and policies from DD," you can prevent WebLogic from
reading the security information held within the deployment descriptors.

Because the providers manage all the information about the roles and policy statements,
you have greater control over this access control information now that you
can decide when WebLogic should ignore the security data in the deployment
descriptors. You have two basic options, each with their own security implications:

If you choose to ignore the deployment descriptors before actually deploying an
application, the security constraints for the application need to be configured
manually from the Administration Console. The providers will persist the access
control information in their own stores, and the security data in the deployment
descriptors will be ignored completely.

If you choose to ignore the deployment descriptors after deploying the application,
the providers already will be populated with the security constraints in the
descriptor files, which you can later further refine from the Administration Console.
Once again, the providers will store this information in their own stores.
However, because the security settings in the descriptor files have been ignored,
they can no longer override any changes you’ve made to the roles and policy
statements.

Summary

Figure 17-1 summarizes the security architecture that we have just described.

Figure 17-1. Static structure of authentication components

As you can see from the figure, users may belong to groups, and groups may contain
other groups. Roles may be defined in terms of users and/or groups. Roles can either
be global or scoped to a particular kind of resource. Here we haven’t shown all
resources—just the hierarchical connection pool resources. A particular connection
pool is contained in the Connection Pools resource.

Note: Strictly speaking, policies are applied to a ResourceMBean. At runtime, a
ResourceMBean will exist that represents each actual JDBC Connection
Pool, all of which extend to another MBean that represents the "container"
holding all of the connection pools. Inheritance of policies
works because the ResourceMBean extend each other in this way.

Scoped roles and policies may be associated either with the Connection Pools container
(in which case it is inherited by all its instances), or with a particular JDBC
Pool itself. All policies are scoped because they are always associated with a particular
resource.

Next week's excerpts from Chapter 17 of WebLogic: The Definitive Guide will cover WebLogic's various security providers and their default implementations, along with a look at how to authenticate using JAAS, and examples of Authentication and Identity Assertion Providers.

Avinash Chugh, Jon Mountjoy
presently works as Senior Development Manager for a firm that produces software for the regulated industries (finance, energy, pharmaceutics).