Users, Groups, And Security Roles

6 Users, Groups, And Security Roles

Understand the features and functions of users, groups, and security roles within security realms in WebLogic Server.

This chapter includes the following sections:

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 Users

When you create a WebLogic Server domain, three user accounts are created in the security realm by default: the Administration user account that you define during domain creation, OracleSystemUser and LCMUser.

The default WebLogic Administrator user account for the domain is used to boot and connect to the domain's Administration Server. You specify the user name and password for this account when you create the domain. You should make note of these credentials because you will need them to start and access the Administration Server, and to log into the Administration Console.

Note:
- For additional security, avoid choosing an obvious name such as system, admin, administrator, or weblogic for your system administrator user accounts. If you enable secured production mode, then WebLogic Server logs warnings if users in the administrator group have these obvious user names.
- You should create at least one additional user and assign them the Admin security role. Be sure to use unique names that cannot be easily guessed. Having at least two system administrator user accounts helps to ensure that one user maintains account access in case another user becomes locked out by a dictionary/brute force attack.
OracleSystemUser facilitates the installation of Fusion Middleware components that run on WebLogic Server, such as Oracle SOA Suite, and is the default user for Fusion Middleware components such as Oracle Web Services Manager.

Note:
- OracleSystemUser is assigned the same password that you specify for the default Administration user when you create the domain. If necessary, you can change this password in the Administration Console.
- OracleSystemUser is assigned to the OracleSystemGroup and is granted the OracleSystemRole by default. This user is not a member of any of the default WebLogic Server groups or global roles. Therefore, it does not have access to WebLogic Server resources and would not represent any security concerns.
- Although you can remove OracleSystemUser with no issues if you have a standalone WebLogic Server installation, if you do so you will encounter problems if you attempt to install Fusion Middleware components on top of WebLogic Server at a later date, or use Oracle Web Services Manager.
LCMUser is an internal WebLogic account that is required for software features such as Lifecycle Manager, RESTful Management Services, and Fusion Middleware Control.

Note:
- The password for LCMUser is randomly generated, therefore you cannot log into the Administration Console as this user. Oracle recommends that you do not change this password.
- Do not remove the LCMUser account. If you remove LCMUser from the WebLogic security realm, then you are disabling the maintenance capability of the Lifecycle Manager tool and you may encounter errors if you later attempt to upgrade your installation.
- If you replace the embedded LDAP with an external provider and you plan to use the WebLogic Server Lifecycle Manager functionality, then you need to recreate this user in the new provider. See Configuring Authentication Providers in Administering Security for Oracle WebLogic Server.

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

Run Time Groups

At run time, 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 WebLogic Server 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 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 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. Table 6-3 summarizes the permissions in the WebLogic Server Administration Console for the Admin, Deployer, Operator, and Monitor global roles.

Note:

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.

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, Java EE Connector, and Web Service modules. Start, resume, and stop servers.	`Administrators`
`AdminChannelUser`	Access the administrative channel, `AdminChannel`.	`AdminChannelUsers`, `Administrators`, `Deployers`, `Operators`, `Monitors`, and `AppTesters`
`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 Deployment Descriptor Elements in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server and weblogic-ejb-jar.xml Deployment Descriptor Reference in Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.	`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, Java EE Connector, Web Service, and WebLogic Tuxedo Connector components. If applicable, edit deployment descriptors. Access deployment operations in the Java EE Deployment Implementation (JSR-88). See Understanding WebLogic Server Deployment in Deploying Applications to Oracle WebLogic Server.	`Deployers`
`Operator`	View the server configuration, except for encrypted attributes. Start, resume, and stop servers. Start and stop applications using MBean APIs and WLST. You cannot start and stop applications in the WebLogic Server Administration Console. See Table 6-3.	`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. See Administration Mode for Isolating Production Applications in Deploying Applications to Oracle WebLogic Server.	`AppTesters`
`CrossDomainConnector`	Make inter-domain calls from foreign domains. See Enabling Trust Between WebLogic Server Domains in Administering Security for Oracle WebLogic Server.	`CrossDomainConnectors`

Table 6-3 summarizes the privileges provided in the WebLogic Server Administration Console for the Admin, Deployer, Operator, and Monitor global roles. Note that the information provided in the table is based on the default out-of-the-box security policy for WebLogic Resources and MBeans. You can manage the default security policies in the Administration Console, as described in Use Roles and Policies to Secure Resources in Oracle WebLogic Server Administration Console Online Help.

Table 6-3 WebLogic Server Administration Console Privileges for Default Global Roles

Privileges	Administrator	Deployer	Operator	Monitor
Edit session operations: start or release session, activate or undo changes	Yes	Yes	No	No
Server, Cluster, Template, or Machine
Lifecyle operations: create, delete	Yes	No	No	No
Modify configuration	Yes	No	No	No
Control operations: start, stop, resume	Yes	No	Yes	No
View configuration	Yes	Yes	Yes	Yes
Application Deployments
Lifecycle operations: deploy, undeploy, redeploy	Yes	Yes	No	No
Modify configuration	Yes	Yes	No	No
Control operations: start, stop	Yes	Yes	No	No
JDBC and JMS resources
Lifecyle operations: create, delete	Yes	Yes	No	No
Modify configuration	Yes	Yes	No	No
Control operations: start, stop	Yes	No	No	No
View configuration	Yes	Yes	Yes	Yes
Startup and Shutdown Classes, Coherence Clusters
Lifecyle operations: create, delete	Yes	No	No	No
Modify configuration	Yes	Yes	No	No
View configuration	Yes	Yes	Yes	Yes

Security Role Conditions

To determine who is in a security role at run time, a role contains one or more conditions. For example, a basic role might simply be the Administrator group. At run time, 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.

In the WebLogic Server Administration Console, the WebLogic Server Role Mapping providers display the three built-in policy conditions described in the following sections:

Note:

The following 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 about 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.

Note:
Instead of the User condition, Oracle recommends adding the user to a Group and using the Group condition in the security role. If you do use the User condition, ensure that you update any existing roles when the user is deleted from the authentication store.
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 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. 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 Online Help.

For information on creating security roles, see Manage security roles in Oracle WebLogic Server Administration Console Online Help.