Securing WebLogic Resources

Users, Groups, And Security Roles

The following sections describe the features and functions of users, groups, and security roles:

Overview of Users and Groups

A user is an entity that can be authenticated. A user can be a person or a software entity, such as a Java client. Each user is given a unique identity within a security realm. For efficient security management, BEA recommends adding users to groups. A group is a collection of users who usually have something in common, such as working in the same department in a company.

Default Groups

Table 6-1 lists the groups that WebLogic Server defines in the security realm that it installs. By default, if you add a user to one of these groups, you also place the user in one of the default global security roles (see Default Global Roles).

Table 6-1 Default Groups

Group Name	Membership
`Administrators`	By default, this group contains the user information entered as part of the installation process (that is, the Configuration Wizard), and the `system` user if the WebLogic Server instance is running Compatibility security. Any user assigned to the `Administrators` group is granted the `Admin` security role by default. See Best Practices: Add a User To the Administrators Group.
`Deployers`	By default, this group is empty. Any user assigned to the `Deployers` group is granted the `Deployer` security role by default.
`Operators`	By default, this group is empty. Any user assigned to the `Operators` group is granted the `Operator` security role by default.
`Monitors`	By default, this group is empty. Any user assigned to the `Monitors` group is granted the `Monitor` security role by default.
AppTesters	By default, this group is empty. Any user assigned to the `AppTesters` group is granted the `AppTester` security role by default.

Runtime Groups

At runtime, WebLogic Server places all users in the following groups:

users. This group contains all users who have been authenticated.
everyone. This group contains all anonymous users and, because it contains the users group, all users who have been authenticated.

Unlike the groups in Table 6-1 (or other groups that you create), you cannot add or remove users directly to these groups; WebLogic Server assigns users to them dynamically. These groups do not appear in the Administration Console's Groups tab and they are not exported with the authentication database.

Best Practices: Add a User To the Administrators Group

BEA recommends that you add at least one user to the Administrators group in addition to the user you defined at installation (using the Configuration wizard). Having at least two administrators at all times helps protect against a single admin user being locked out from a potential security breach. Also, avoid using predictable user names like "system", "admin", or "Administrator".

Overview of Security Roles

A security role is an identity granted to users or groups based on specific conditions. Multiple users or groups can be granted the same security role and a user or group can be in more than one security role. Security roles are used by policies to determine who can access a WebLogic resource. (See Security Policies.)

Like a security group, a role grants an identity to a user. Security roles differ from groups as follows:

Security roles can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain. Groups, on the other hand, are always scoped to an entire WebLogic Server domain. See Types of Security Roles: Global Roles and Scoped Roles.
Security roles are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day. Groups are static.

The process of computing and granting roles is referred to as role mapping and occurs just before the WebLogic Security Service renders an access decision for a protected WebLogic resource. An access decision is the component of an Authorization provider that determines whether a subject has permission to perform a given operation on a WebLogic resource. (See Access Decisions in Developing Security Providers for WebLogic Server.)

Types of Security Roles: Global Roles and Scoped Roles

There are two types of security roles in WebLogic Server:

A global security role can be used in any security policy. BEA provides several default global roles that you can use out of the box to secure your WebLogic resources; these are described in Default Global Roles.

Note: If you are implementing security using JACC (Java authorization Contract for Containers as defined in JSR 115) global security roles cannot be used.

A scoped role can be used only in policies that are defined for a specific instance of a WebLogic resource (such as a method on an EJB or a branch of a JNDI tree). You might never need to use scoped roles. They are provided for their flexibility and are an extra feature for advanced customers.

Default Global Roles

Table 6-2 lists the global roles that WebLogic Server defines in the security realm that it installs. The table also summarizes the access that the default security policies grant to each role and indicates which groups are in each role by default.

Caution: Do not delete these roles. They are used in the default security policies that protect most types of WebLogic resources. In addition, they are used by the MBean security layer. If you delete the Admin role, no one will be able to modify the configuration of a running domain. See MBean Security Layer.

Table 6-2 Default Global Roles, Privileges, and Default Group Assignments

Global Role	Default Policies Grant Access To...	Default Conditions Include This Group...
`Admin`	View the server configuration, including the encrypted value of some encrypted attributes. Modify the entire server configuration. Deploy Enterprise Applications and Web application, EJB, J2EE Connector, and Web Service modules. Start, resume, and stop servers.	`Administrators`
`Anonymous`	All users (the group `everyone`) are granted this global role. Note: This global role is provided as a convenience, and can be specified in the `weblogic.xml` and `weblogic-ejb-jar.xml` deployment descriptors. See weblogic.xml schema and ejb-jar deployment descriptor reference.	`everyone`
`Deployer`	View the server configuration, including some encrypted attributes related to deployment activities. Change startup and shutdown classes, Web applications, JDBC data pool connections, EJB, J2EE Connector, Web Service, and WebLogic Tuxedo Connector components. If applicable, edit deployment descriptors. Access deployment operations in the J2EE 1.4 Deployment Implementation (JSR-88). See Deployment Standards in Deploying Applications to WebLogic Server.	`Deployers`
`Operator`	View the server configuration, except for encrypted attributes. Start, resume, and stop servers.	`Operators`
`Monitor`	View the server configuration, except for encrypted attributes. This security role effectively provides read-only access to the WebLogic Server Administration Console, `WLST,` and MBean APIs.	`Monitors`
AppTester	Access applications for testing purposes that are running in Administration mode. For more information, see Administration Mode for Isolating Production Applications in Understanding WebLogic Server Deployment.	`AppTesters`

Security Role Conditions

To determine who is in a security role at runtime, a role contains one or more conditions. For example, a basic role might simply name the "Administrator" group. At runtime, the WebLogic Security Service interprets this policy as "place the Administrator group in this role." You can create more complex conditions and combine them using the logical operators AND and OR (which is an inclusive OR). You can also negate any condition, which would make sure that a user is not in the role. The entire collection of conditions must be true for a user or group to be granted the security role. More restrictive expressions should come later in a role statement.

The WebLogic Server Role Mapping providers display three kinds of built-in policy conditions in the Administration Console:

Note: These sections describe the conditions that are available in realms that use the WebLogic Role Mapping provider or the WebLogic XACML Role Mapping provider. If your security realm uses a third-party Role Mapping provider, refer to the third-party documentation for information on its capabilities.

Basic Role Conditions

The basic role conditions available in this release of WebLogic Server are:

User—Adds the specified user to the role. For example, you might create a condition indicating that only the user John can be granted the BankTeller security role.
Group—Adds the specified group to the role. For example, you might create a condition indicating that only users in the group FullTimeBankEmployees can be granted the BankTeller security role.

As a minimum requirement, BEA recommends this role condition for more efficient security management.

Server is in development mode—Adds principals to the role only when the server is running in development mode. See Differences Between Domain Startup Modes in Creating WebLogic Domains Using the Configuration Wizard.
Allow access to everyone—Adds all users and groups to the role.
Deny access to everyone—Prevents any user or group from being in the role.

Date and Time Role Conditions

When you use any of the date and time role conditions, the security role is granted to all users for the date or time you specify, unless you further restrict the users by adding one of the other role conditions. The date and time role conditions available in this release of WebLogic Server are:

Access occurs between specified hours—Adds principals to the role only during the specified time period. For example, you might create a condition indicating that the BankTeller security role can only be granted to users when the bank is open.
Access occurs after—Adds principals to the role only if the current time is after a specified time. For example, you might create a condition indicating that the BankTeller security role can only be granted to users after the bank opens or after a certain date and time.
Access occurs before—Adds principals to the role only if the current time is before a specified time. For example, you might create a condition indicating that the BankTeller security role can only be granted to users before the bank closes or before a certain date and time.
Access occurs on specified days of the week—Adds principals to the role only on specified days. For example, you might create a condition indicating that the BankTeller security role can only be granted to users on week days.
Access occurs on the specified day of the month—Adds principals to the role only on an ordinal day of the month. For example, you might create a condition indicating that the BankTeller security role can only be granted to users on the first day of each month.
Access occurs after the specified day of the month—Creates a condition for a security role based on a time after an ordinal day in the month. For example, you might create a condition indicating that the BankTeller security role can only be granted to users after the 15th day of the month.
Access occurs before the specified day of the month—Adds principals to the role only if the current day is before an ordinal day in the month. For example, you might create a condition indicating that the BankTeller security role can only be granted to users before the 15th day of the month.

Context Element Role Conditions

You can use the context element conditions to create security roles based on the value of HTTP Servlet Request attributes, HTTP Session attributes, and EJB method parameters. WebLogic Server retrieves this information from the ContextHandler object and allows you to defined role conditions based on the values. When using any of these conditions, it is your responsibility to ensure that the attribute or parameter/value pairs apply to the context in which you are using them. For more information, see ContextHandlers and WebLogic Resources in Developing Security Providers for WebLogic Server.

The context element role conditions available in this release of WebLogic Server are:

Context element defined—Adds principals to the role based on the existence of a specified attribute or parameter.
Context element's value equals a numeric constant—Adds principals to the role based on a specified attribute or parameter's number value (or string representing a double number) being equal to a specified double number.
Context element's value is greater than a numeric constant—Adds principals to the role based on a specified attribute or parameter's number value (or string representing a double number) being greater than a specified double number.
Context element's value is less than a numeric constant—Adds principals to the role based on a specified attribute or parameter's number value (or string representing a double number) being less than a specified double number
Context element's value equals a string constant—Adds principals to the role based on a specified attribute or parameter's string value being equal to a specified string.

Using the Administration Console to Manage Users, Groups, and Roles

Note: This section describes the features that are available in realms that use the WebLogic Authentication provider and the WebLogic Role Mapping provider or the WebLogic XACML Role Mapping provider. If your security realm uses a third-party Authentication or Role Mapping provider, refer to the third-party documentation for information on its capabilities.

For information on adding users and groups to a security realm, see Manage Users and Groups in Administration Console Online Help.

For information on creating security roles, see Manage Security Roles in Administration Console Online Help.