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.