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, Oracle 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.

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.

CrossDomainConnectors

By default, this group is empty. Any user assigned to the CrossDomainConnectors group is granted the CrossDomainConnector security role by default.

AdminChannelUsers

By default, this group is empty. Any user assigned to the AdminChannelUsers group is granted the AdminChannelUser security role by default.

OracleSystemGroup

By default, this group contains the user OracleSystemUser and is granted the OracleSystemRole 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

Oracle 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 Chapter 5, "Security Policies.")

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

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 Oracle 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. Oracle 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 Maintaining a Consistent Security Scheme.

Assert identity on behalf of users whose WS-Security tokens have been authenticated.

Note: This global role is provided for use by Oracle Web Services Manager.

OracleSystemGroup

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, Oracle 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 "Creating a WebLogic Domain" in Creating 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 Oracle 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 Oracle WebLogic Server Administration Console Help.