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

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	Membership
`users`	Users, when they log in (for example, through a Web page). The `users` group includes all users except the `<anonymous>` user.
`everyone`	Every user is a member of this group. The `users` group is nested within the `everyone` group.
`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 Adding Users To 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.

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:

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

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.

A security role that applies to all WebLogic resources deployed within a security realm (and thus the entire WebLogic Server domain) is called a global role.

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 security role that applies to a specific instance of a WebLogic resource deployed in a security realm (such as a method on an EJB or a branch of a JNDI tree) is called a scoped role. You define scoped security roles for any of Weblogic resources described in Types of WebLogic Resources.

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	Privileges	Default Group Assignments
`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`
`Admin`	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.	`Administrators`
`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 JSR-88 deployment operations.	`Deployers`
`Operator`	View the server configuration, except for encrypted attributes. Start, resume, and stop servers by default.	`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`

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:

Group—Creates a condition for a security role based on a group. 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.

User—Creates a condition for a security role based on a user name. For example, you might create a condition indicating that only the user John can be granted the BankTeller security role.
Server is in development mode—Creates a condition for a security policy based on whether the server is running in development mode.
Allow access to everyone—Creates a condition for a security policy that includes all users and groups.
Deny access to everyone—Creates a condition for a security policy that excludes all users and groups.

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—Creates a condition for a security role based on a 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—Creates a condition for a security role based on a time 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—Creates a condition for a security role based on a time 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—Creates a condition for a security role based 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—Creates a condition for a security role based 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—Creates a condition for a security role based on a time 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—Creates a condition for a security role based on the existence of a specified attribute or parameter.
Context element's value equals a numeric constant—Creates a condition for a security 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—Creates a condition for a security 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—Creates a condition for a security 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—Creates a condition for a security role based on a specified attribute or parameter's string value being equal to a specified string.

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.