|
|
The following sections describe the features and functions of users, groups, and security roles:
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.
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).
At runtime, WebLogic Server places all users in the following groups:
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.
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”.
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:
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.)
There are two types of security roles in WebLogic Server:
| Note: | If you are implementing security using JACC (Java authorization Contract for Containers as defined in JSR 115) global security roles cannot be used. |
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.
|
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. |
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. 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.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 numberContext 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.
| 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.
|