Securing WebLogic Resources

Security Policies

The following sections describe the features and functions of security policies:

Overview of Security Policies

A security policy is an association between a WebLogic resource and one or more users, groups, or security roles and is designed to protect the WebLogic resource against unauthorized access.

Note: Security policies replace the access control lists (ACLs) and permissions that were used to protect WebLogic resources in previous releases of WebLogic Server.

Security Policy Granularity and Inheritance

Security policies are always scoped to a WebLogic resource, but because WebLogic resources are hierarchical, the level at which you define a security policy is up to you. For example, you can define security policies on an entire enterprise application (EAR), an EJB JAR containing multiple EJBs, a particular EJB within that JAR, or a single method within that EJB.

If you create a security policy for a type of WebLogic resource (for example, EJB resources), all new instances of that WebLogic resource inherit the security policy. This inheritance of security policies means that you can secure multiple WebLogic resources efficiently. Out of the box, WebLogic Server secures each WebLogic resource type with a default security policy that is inherited by all instances of that WebLogic resource. For more information, see Default Security Policies.

A security policy created for a specific instance of a WebLogic resource will override any security policy assigned to the WebLogic resource type. So, if you create a security policy for a particular EJB, this security policy (and not the one you created for the EJB resource type) will be used.

Security Policy Storage and Prerequisites for Use

Security policies are stored in the security provider database of the Authorization provider that is configured in the default (active) security realm. By default, the WebLogic Authorization provider is configured, and security policies are stored in the embedded LDAP server.

When creating a security policy with a user or group, the user or group must be defined in the security provider database of the Authentication provider that is configured in the default security realm. When creating a security policy with a security role, the security role (whether global or scoped) must be defined in the security provider database of the Role Mapping provider that is configured in the default security realm. By default, the WebLogic Authentication and Role Mapping providers are configured, and the default groups and default global roles are stored in the databases for these security providers (also the embedded LDAP server).

For more information about the WebLogic Authentication, Authorization, and Role Mapping providers, see The WebLogic Security Providers in Introduction to WebLogic Security.

Default Security Policies

By default, WebLogic Server defines the security policies shown in Table 6-1. These security policies are defined for each type of WebLogic resource described in Types of WebLogic Resources, and are based on the default global roles and default groups.

Note: You can access default security policies in the Administration Console. See Access root-level policies in Administration Console Online Help.

Table 6-1 Default Security Policies for WebLogic Resources

WebLogic Resource	Security Policy
Administrative resources	Default global role: `Admin`
Application resources	None
EIS (Resource Adapter) resources	Default group: `Everyone`
EJB resources	Default group: `Everyone`
COM resources	None
JDBC resources	Default group: `Everyone`
JNDI resources	Default group: `Everyone`
JMS resources	Default group: `Everyone`
Server resources	Default global roles: `Admin` `Operator`
Work Context	Default group: `Everyone`
URL resources	Default group: `Everyone`
Web Services resources	Default group: `Everyone`

Caution: Do not modify the default security policies for Administrative and Server resources to make them more restrictive. Eliminating some of the existing security roles might negatively impact the functioning of WebLogic Server. However, if you like, you can make the default security policies more inclusive (for example, by adding new security roles).

Protected Public Interfaces

The WebLogic Server Administration Console, the WebLogic Scripting Tool (WLST), and MBean APIs are secured using the default security policies, which are based on the default global roles and default groups described in Table 5-2. Therefore, to use the Administration Console, a user must belong to one of these default groups or be granted one of these global roles. Additionally, administrative operations that require interaction with MBeans are secured using the MBean protections described in MBean Protections. Therefore, interaction with the following protected public interfaces typically must satisfy both security schemes.

The WebLogic Server Administration Console—The WebLogic Security Service verifies whether a particular user can access the Administration Console when the user attempts to log in. If a user attempts to invoke an operation for which they do not have access, they see an Access Denied error.

For information about using this public interface, see the Administration Console Online Help.

The WebLogic Scripting Tool—The WebLogic Scripting Tool (WLST) is a command-line scripting interface that system administrators and operators can use to monitor and manage WebLogic Server instances and domains. The WebLogic Security Service verifies whether a particular user has permission to execute a WLST command when the user attempts to invoke the command. If a user attempts to invoke an operation for which the user does not have access, WebLogic Server throws a weblogic.management.NoAccessRuntimeException, which developers can catch explicitly in their programs. The server sends this exception to its log file, but you can also configure the server to send exceptions to standard out.

For information about using this public interface, see WebLogic Scripting Tool.

Note: WLST is a convenience utility that abstracts the interaction with the MBean APIs (described next). Therefore, for any administrative task you can perform using WLST, you can also perform using the MBean APIs.

MBean APIs—The WebLogic Security Service verifies whether a particular user has permission to access the API when the user attempts to perform an operation on the MBean. If a user attempts to invoke an operation for which the user does not have access, WebLogic Server throws a weblogic.management.NoAccessRuntimeException, which developers can catch explicitly in their programs. The server sends this exception to its log file, but you can also configure the server to send exceptions to standard out.

For information about using these APIs, see Protected MBean Attributes and Operations and Managing Security Realms with JMX in Developing Custom Management Utilities with JMX.

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

Policy Conditions

A policy condition is a condition under which a security policy will be created. WebLogic provides three kinds of built-in policy conditions. You can use these conditions in any logical combination:

Basic Policy conditions

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

Role—Creates a condition for a security policy based on a security role. For example, you might create a condition indicating that only users and groups in the BankTeller security role can access the Deposit EJB.

For some WebLogic resources, WebLogic server assigns a default security policy based on one of the built-in global security roles. For more information, see Default Global Roles and Default Security Policies.

User—Creates a condition for a security policy based on a user name. For example, you might create a condition indicating that only the user John can access the Deposit EJB.
Group—Creates a condition for a security policy based on a group. When a group is used to create a security policy, the security policy is assigned to all members of the group. For example, you might create a condition indicating that only users in the group FullTimeBankEmployees can access the Deposit EJB.
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.
Element requires signature by—Creates a condition for a security policy based on who has digitally signed an element in the SOAP request message that invokes a Web Service operation. For example, you might create a condition that says the getBalance operation can only be invoked if the AccountNumber element in the incoming SOAP request has been digitally signed by the BankTeller security role.

Note: This policy condition is used only when securing Web Services and individual Web Service operations.

Date and Time Policy Conditions

When you use any of the date and time conditions, the security policy grants access 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 policy conditions available in this release of WebLogic Server are:

Access occurs between specified hours—Creates a condition for a security policy based on a specified time period. For example, you might create a condition granting access to users only during business hours.
Access occurs after—Creates a condition for a security policy based on a time after a specified time. For example, you might create a condition that grants access to users after the business opens or after a certain date and time.
Access occurs before—Creates a condition for a security policy based on a time before a specified time. For example, you might create a condition that grants access to users before the business closes or before a certain date and time.
Access occurs on specified days of the week—Creates a condition for a security policy based on specified days. For example, you might create a condition that grants access to users on week days.
Access occurs on the specified day of the month—Creates a condition for a security policy based on an ordinal day of the month. For example, you might create a condition that grants access to users only the first day of each month.
Access occurs after the specified day of the month—Creates a condition for a security policy based on a time after an ordinal day in the month. For example, you might create a condition indicating that grants access to users after the 15th day of the month.
Access occurs before the specified day of the month—Creates a condition for a security policy based on a time before an ordinal day in the month. For example, you might create a condition that grants access to users before the 15th day of the month.

Context Element Policy Conditions

You can use the context element conditions to create security policies 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 policy 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 policy based on the existence of a specified attribute or parameter.
Context element's value equals a numeric constant—Creates a condition for a security policy 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 policy 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 policy 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 policy based on a specified attribute or parameter's string value being equal to a specified string.

Policy Expressions

Policy conditions, combined with specific information you supply for the condition (such as an actual role name, or start/stop times), are called expressions. One or more expressions that define the policy are known collectively as a policy statement (see next section). For example: only users who are included in the BankTeller security role and during regular banking hours can access a business Web application.

Policy Statement

A policy 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 Security Policies in Administration Console Online Help.

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

Using the Administration Console to Manage Security Policies

You can use the WebLogic Administration Console to access WebLogic resources for creating and modifying security policies. For more information, see Manage Security Policies in Administration Console Online Help.