Skip navigation.

Securing WebLogic Resources

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

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


EIS (Resource Adapter) resources

Default group: Everyone

EJB resources

Default group: Everyone

COM resources


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.


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:

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:

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:

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.


Back to Top Previous Next