Skip navigation.

Securing WebLogic Resources

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

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

WebLogic Server defines the groups shown in Table 5-1. By default, WebLogic Server assigns some of these groups to corresponding global security roles. See Default Global Roles.

Table 5-1 Default Groups 

Group Name



Users, when they log in (for example, through a Web page).

The users group includes all users except the <anonymous> user.


Every user is a member of this group.

The users group is nested within the everyone group.


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 Adding Users To Administrators Group.


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


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


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


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

Adding Users To Administrators Group

You should 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".


Using the Administration Console to Manage Users and Groups

You can use the WebLogic Administration Console to add and mange users and group for a security realm using WebLogic Authentication provider. For more information, see Manage Users and Groups in Administration Console Online Help.

Note: The instructions for the using the Administration Console apply to users and groups in the WebLogic Authentication provider only. If you customize the default security configuration to use a custom Authentication provider, use the administration tools supplied by that security provider to create a user.

If you are upgrading to the WebLogic Authentication provider, you can load existing users and groups into its database. For more information, see Migrating Security Data in Securing WebLogic Server.


Overview of Security Roles

A security role is a privilege granted to users or groups based on specific conditions. Like groups, security roles allow you to restrict access to WebLogic resources for several users at once. Security roles differ from groups as follows:

Granting a security role to a user or a group confers the defined access privileges to that user or group, as long as the user or group is "in" the security role. For example, an administrator may define a security role called AppAdmin, which has write access to a particular Web application's resources. Any user or group granted the AppAdmin security role would then have write access to that Web application resource. Multiple users or groups can be granted a single security role.


Dynamic Role Mapping

At runtime, the WebLogic Security Service compares users or groups against a role condition to determine whether they should be dynamically granted a security role. This process is referred to as role mapping, and occurs just prior to when 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.

Note: For more information about role conditions and access decisions, see Components of a Security Role: Conditions, Expressions, and Statements and Access Decisions in Developing Security Providers for WebLogic Server, respectively.

This dynamic mapping of security roles to users or groups provides a very important benefit: users or groups can be granted a security role based on business rules, or the context of the request. For example, a user may be allowed to be in a Manager security role only while the actual manager is away. Dynamically granting this security role means that you do not need to change or redeploy your application to allow for such a temporarily arrangement. You simply specify the hours between which the temporary manager should have special privileges. Further, you do not need to remember to revoke these special privileges when the actual manager returns, as you would if you temporarily added the user to a management group.

Dynamic Role Mapping and Security Policies

Security policies also work dynamically, in that authorization decisions are made at runtime. (See Security Policies.) The use of dynamic role mapping in conjunction with security policies provides additional flexibility. Generally speaking, if your authorization decision is based on the resource rather than the entities (roles) accessing the resource, you would add security expressions to the security policy. If authorization is focused on who is accessing the resource, then you would add expressions to the security role.


Types of Security Roles: Global Roles and Scoped Roles

There are two types of security roles in WebLogic Server: global roles and scoped roles.

Combining role types (either global or scoped) is allowed when creating a security policy for a WebLogic resource. (For more information, see Security Policies.)

While BEA recommends creating and using security roles (rather than users or groups) to secure WebLogic resources, you do not need to use a particular type of security role. 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.

You may never need to use scoped roles. They are provided for their flexibility and are an extra feature for advanced customers.


Default Global Roles

By default, WebLogic Server defines the global roles shown in Table 5-2. The table summarizes the privileges that users or groups in these security roles are granted, and the default group assignments for each role. When a user is added to one of the groups, that user is automatically granted the global role.

The default global roles are used in the default security policies that protect most types of WebLogic resources. In addition, the default global roles are used to provide additional security for Server resources that are exposed as MBeans. For details, see Protected MBean Attributes and Operations.

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

Global Role


Default Group Assignments


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.



  • View the server configuration, including the encrypted value of some encrypted attributes.

  • Modify the entire server configuration.

  • Deploy Enterprise Applications, startup and shutdown classes, and Web application, EJB, J2EE Connector, and Web Service modules.

  • Start, resume, and stop servers by default.



  • 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 JSR-88 deployment operations.



  • View the server configuration, except for encrypted attributes.

  • Start, resume, and stop servers by default.



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.



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.



Protected MBean Attributes and Operations

WebLogic server protects access to MBeans by assigning one or more default global roles to individual MBeans and MBean attributes (See Default Global Roles.) Note that the Admin role grants full access to all MBean resources.

For a complete listing of global role access to MBeans, see Security Roles for MBeans in WebLogic Server MBean Reference.


Components of a Security Role: Conditions, Expressions, and Statements

Role Conditions

A role condition is a condition under which a security role (global or scoped) is granted to a user or group at runtime. Weblogic provides three kinds of built-in role conditions. You can use these conditions in any logical combination:

Basic Role Conditions

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

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:

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:

Role Expressions

Role conditions, combined with specific information you supply for the condition (such as an actual user name, group, or start/stop times), are called expressions. One or more expressions that define the role are known collectively as a role statement (see Role Expressions). The simplest role statement would have one expression: for example, you might have a group as the only condition for the role.

Role Statement

A role statement is a collection of expressions that define how a security role is granted. The ability to use multiple expressions means that you can create complex security roles that meet your organization's security requirements. You can also use and or operators between expressions, and you can reorder and negate expressions. For details, see Create scoped security roles in Administration Console Online Help

The entire role statement must be true in order for a user or group to be granted the security role. More restrictive expressions should come later in a role statement.


Using the Administration Console to Manage Security Roles

You can use the WebLogic Administration Console to create global security roles and to access Weblogic resources for creating, modifying, and removing scoped security roles. For more information, see Manage Security Roles in Administration Console Online Help.


Skip navigation bar  Back to Top Previous Next