Securing WebLogic Resources

Security Policies

A security policy specifies who can access a WebLogic Server resource. You can create simple policies, such as "allow access if user is in Admin role," or more complex policies, such as "between the hours of 8 and 5, allow access if user is in Admin role."

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

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.

You can create a root-level policy that applies to all instances of a specific resource type (all new instances of that WebLogic resource inherit the security policy). For example, you can define a root level policy that will be inherited by all JMS resources in your domain. This inheritance of security policies means that you can secure multiple WebLogic resources efficiently. WebLogic Server provides a set of default, root-level policies. See Default Root Level Security Policies.

You can also create a policy that applies to a specific resource instance. If the instance contains other resources, the policy will apply to the included resource as well. For example, you can create a policy for an entire enterprise application (EAR), an EJB JAR containing multiple EJBs, a particular EJB within that JAR, or a single method within that EJB.

The policy of the narrower scope overrides the policy of a broader scope. For example, if you create a security policy for an EAR and a policy for an EJB that is in the EAR, the EJB will be protected by its own policy and will ignore the policy for the EAR.

Security Policy Storage and Prerequisites for Use

Security policies for all resources other than Web Application resources and EJB resources are always stored in the security provider database of the Authorization provider that is configured in the default (active) security realm. The security realm that WebLogic Server provides stores policies in the embedded LDAP server.

For Web Application resources and EJB resources, the location of policies depends on the following:

If you implement security using JACC (Java Authorization Contract for Containers as defined in JSR 115), the policies are stored in the Web application or EJB deployment descriptors.
If you use the DDOnly model to secure a Web application or EJB, the policies are stored in the deployment descriptors.
If you use a security model that ignores the policies in the descriptors, then the Authorization provider determines where the policies are stored. The security realm that WebLogic Server provides stores policies in the embedded LDAP server.
If you use the Advanced security model, the location of policies depends on how you configure the model.

See Options for Securing Web Application and EJB Resources.

Each user or group that you add to a security policy must be defined in the security provider database of the Authentication provider that is configured in the active security realm. Each role that you add must be defined in the security provider database of the Role Mapping provider that is configured in the active security realm. The security realm that WebLogic Server provides is configured to use the WebLogic Authentication and WebLogic XACML Role Mapping providers, which store users, groups, and roles in 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 Root Level Security Policies

A root level policy is inherited by all instances of a specific resource type. Table 5-1 describes the default root level policies that are defined in the security realm that WebLogic Server installs. For information about the roles and groups that are named in these policies, see Users, Groups, And Security Roles.

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

Table 5-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 root level 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). See MBean Security Layer.

Security Policy Conditions

To determine who can access a resource, a policy contains one or more conditions. The most basic policy simply contains the name of a security role or a principal. For example, a basic policy might simply name the "Admin" global role. At runtime, the WebLogic Security Service interprets this policy as "allow access if user is in Admin 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 prohibit access under the specified condition.

The WebLogic Server Authorization 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 Authorization provider or the WebLogic XACML Authorization provider. If your security realm uses a third-party Authorization provider, refer to the third-party documentation for information on its capabilities.

Basic Policy Conditions

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

User—Allows a specific user to access the resource. For example, you might create a condition indicating that only the user John can access the Deposit EJB.
Group—Allows all users or groups in the specified group to access the resource unless a User or Role condition contradicts the Group condition.
Role—Allows all users or groups in the specified role to access the resource unless a User or Group condition contradicts the Role condition. For example, if you create a Role condition that specifies "Admin" and a User condition that negates "joe", then user joe will be denied access even if he is in the Admin role.
Server is in Development Mode—Allows access if the server that hosts the resource is running in development mode. See Differences Between Domain Startup Modes in Creating WebLogic Domains Using the Configuration Wizard.
Allow access to everyone—Allows access for all users, groups, and roles.
Deny access to everyone—Prohibits access for all users, groups, and roles.
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 conditions. The date and time policy conditions available in this release of WebLogic Server are:

Access occurs between specified hours—Allows access during a specified time period. For example, you might create a condition granting access to users only during business hours.
Access occurs after—Allows access 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—Allows access 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—Allows access 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—Allows access 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—Allows access 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—Allows access 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—Allows access based on the existence of a specified attribute or parameter.
Context element's value equals a numeric constant—Allows access 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—Allows access 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—Allows access 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—Allows access based on a specified attribute or parameter's string value being equal to a specified string.

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 6-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 Security Layer. 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 The WebLogic Server Administration Console in 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 Understanding WebLogic Server MBeans in Developing Custom Management Utilities with JMX.

Using the Administration Console to Manage Security Policies

Note: This section describes the features and functions that are available in security realms that are using the WebLogic Authorization provider or the WebLogic XACML Authorization provider. If your security realm uses a third-party Authorization provider, refer to the third-party documentation for information on how to add polices to the provider database.

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.