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 resource against unauthorized access.

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

 

Security Policy Granularity and Inheritance

Security policies are always scoped to a resource, but because 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 (Enterprise JavaBean) 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 resource (for example, EJB resources), all new instances of that resource inherit the security policy. (For more information about the types of resources, see Types of WebLogic Resources.) This inheritance of security policies means that you can secure multiple resources efficiently. Out of the box, WebLogic Server secures each resource type with a default security policy that is inherited by all instances of that resource. For more information, see Default Security Policies.

A security policy created for a specific instance of a resource will override any security policy assigned to the 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).

Note: 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 below. These security policies are defined for each type of resource described in Types of WebLogic Resources, and are based on the default global roles and default groups.

Resource Default Role Default Group
Administrative Admin None
Application None None
EIS None Everyone
EJB None Everyone
COM None None
JDBC None Everyone
JNDI None Everyone
JMS None Everyone
Server Admin
Operator 		None
URL None Everyone
Web Services None 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).

For more information about the resources shown in Table 5-1, see Types of WebLogic Resources.

You can add to the default security policies by creating your own. See Working with Security Policies for more information.

 

Protected Public Interfaces

The WebLogic Server Administration Console, the weblogic.Admin command, and MBean APIs are secured using the default security policies, which are based on the default global roles and default groups described in Table 4-1 and Table 4-6. 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.Admin command - The WebLogic Security Service verifies whether a particular user has permission to execute a 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 Protected MBean Attributes and Operations and weblogic.Admin Command-Line Reference" in the WebLogic Server Command Line Reference.

    Note: The weblogic.Admin command is a convenience utility that abstracts the interaction with the MBean APIs (described below). Therefore, for any administrative task you can perform using the weblogic.Admin command, 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 Programming WebLogic JMX Services.

 

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

A policy condition is a condition under which a security policy will be created. The policy conditions that are available in this release of WebLogic Server are:

  • User Name of the Caller - 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.
  • Caller is a Member of the 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.
  • Caller is Granted the 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.
  • Hours of Access are Between - Creates a condition for a security policy based on a specified time period. For example, you might create a condition indicating that the BankTeller security role can only access the Deposit EJB when the bank is open.
  • Server is in Development Mode - Creates a condition for a security policy based on whether the server is running in development mode.
  • 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.

These policy conditions, along with the specific information you supply for the condition (such as an actual user name, group, or security role, or start/stop times), are called expressions. An example of an expression that you may see in the WebLogic Server Administration Console is shown in Figure 5-1.

Figure 5-1 Expression Example

Expression Example

In this expression example, the first line is the policy condition, the second line is the specific information you supply for the condition - in this case, a group called FullTimeBankEmployees.

A policy statement is the collection of expressions that define who is granted access to a resource, and is therefore the main part of any security policy you create. The ability to use multiple expressions means that you can create complex security policies that meet your organization's security requirements. The use of and and or between these expressions, as well as the ordering of the expressions, is also an important feature:

  • And is used to specify that all the expressions must be true in order for the security policy to be applied.
  • Or is used to specify that at least one of the expressions must be true in order for the security policy to be applied.

Notes: The entire policy statement must be true in order for security policy to be applied. More restrictive expressions should come later in a policy statement.

An example of a policy statement that you may see in the Administration Console is shown in Figure 5-2.

Figure 5-2 Policy Statement Example

Policy Statement Example

In this policy statement example, there are two expressions: the first and second lines contain an expression based on the Caller is Granted the Role policy condition, and the third and fourth lines contain another expression based on the Hours of Access are Between policy condition.

 

Working with Security Policies

The following sections provide instructions for working with security policies for the various types of resources:

 

Creating Security Policies

The instructions for working with security policies vary slightly from resource to resource. Be sure to follow any variations noted in this procedure that pertain to the type of resource with which you are working. For more information, see Types of WebLogic Resources.

Note: In this version of WebLogic Server, keep track of the security policies you create. With the exception of those created for URL (Web) resources, there is currently no listing mechanism for previously created security policies in the WebLogic Server Administration Console.

 

Step 1: Select the WebLogic Resource

Follow the instructions in the appropriate section to select the type of resource:

 

Administrative Resources

In the left pane of the WebLogic Server Administration Console, right-click the name of the WebLogic Server domain (for example, examples), and choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

Note: In this version of WebLogic Server, you can only secure the unlockuser method. For more information about user lockouts, see Protecting User Accounts" in Managing WebLogic Security.

Notice the Caller is Granted the Role: Admin policy statement that the Administrative resource you selected has inherited from the default security policy associated with the Administrative resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

 

Application Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments - > Applications.

    Optionally, expand the Enterprise Application (EAR) for which you are creating a scoped role to see the different types of resources it contains.

  2. Right-click the name of the Enterprise Application and choose Define Security Policy... to display the Policy Editor page (see Figure 5-3).

    Figure 5-3 Policy Editor Page

    Policy Editor Page

    Notice that there are no default policy statements for Application resources. (For more information, see Default Security Policies.)

 

COM Resources

If a package of EJB classes (such as ejb20.basic.beanManaged.*) will be accessed by a COM client:

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments - > EJB.

    The EJB node expands to show the EJB JARs that are currently deployed.

  2. Right-click the name of an EJB JAR containing the EJB that will be used to access the package, and choose Define Policies and Roles for Individual Beans... to display a list of EJBs.
  3. Click the [Define JCOM Policies] link that is located in the same row as the EJB that will be used to access the package.

    The General tab's COM Class field already shows the name of the package for which you want to create the security policy.

    The value in the COM class field is a Java class or package name that is exposed to COM via the jCOM bridge.

  4. Click the Define Policy... button to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    Note: If you create a security policy for a package of EJB classes that will be accessed by a COM client and want to use scoped roles in the Caller is Granted the Role condition, be sure to use the scoped role you associated with the package of EJB classes (described in COM Resources).

If a package of Java classes (such as java.util.*) or individual classes (such as java.util.Collection) will be accessed by a COM client:

  1. In the left pane of the WebLogic Server Administration Console, expand Services.
  2. Right-click the JCOM node and choose Define Policy....
  3. On the General tab, in the COM class field, enter the name of the Java class or package you want to protect, then click the Define Policy... button to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    The value you enter in the COM class field is a Java class or package name that is exposed to COM via the jCOM bridge.

    Notice that there are no default policy statements for COM resources. (For more information, see Default Security Policies.)

 

EIS Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments.

    The Deployments node expands to show the types of resources that can be deployed.

  2. Right-click at the level of the EIS resource at which you want to create the security policy, and choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9.

    If you will be creating a security policy for all Connectors, right-click Connector Modules in the navigation tree. If you will be creating a security policy for a particular Connector, expand Connector Modules, then right-click the name of a Connector. Figure 5-4 illustrates where you might click, using the basic-connector Connector as an example.

    Figure 5-4 Deployments Portion of the Administration Console Navigation Tree

    Deployments Portion of the Administration Console Navigation Tree

    Notice the Caller is Granted the Role: Everyone policy statement that the EIS resource you selected has inherited from the default security policy associated with the EIS resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

 

EJB Resources

Note: These instructions also apply to Message-Driven Beans (MDBs).

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments.

    The Deployments node expands to show the types of resources that can be deployed.

  2. Right-click at the level of the EJB resource at which you want to create the security policy.

    If you will be creating a security policy for all the EJB JARs with a single security policy, right-click EJB Modules in the navigation tree. If you will be creating a security policy for a particular EJB JAR, an EJB within a JAR, or a method on one of the EJBs within a JAR, expand EJB Modules, then right-click the name of an EJB JAR. Figure 5-5 illustrates where you might click, using the basic-ejbapp JAR as an example.

    Figure 5-5 Deployments Portion of the Administration Console Navigation Tree

    Deployments Portion of the Administration Console Navigation Tree

  3. If you will be creating a security policy for all EJB JARs or for a particular EJB JAR, choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    If you will be creating a security policy for a particular EJB within an EJB JAR, or a method on one of the EJBs within the JAR, follow these steps:

    1. Choose Define Policies and Roles for Individual Beans... to display a list of EJBs.
    2. Click the [Define Security Policies] link that corresponds to the particular EJB you want to secure (regardless of whether you want to secure the entire EJB or a particular method within the EJB) to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

      Notice the Caller is Granted the Role: Everyone policy statement that the EJB resource you selected has inherited from the default security policy associated with the EJB resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

  4. If will be creating a security policy for a particular EJB within an EJB JAR, specify which EJB method you want to protect, or select ALL to protect all methods.

 

JDBC Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Services - > JDBC.

    The JDBC node expands to show nodes for various JDBC components (connection pools, MultiPools, and data sources).

  2. Right-click at the level of the JDBC resource at which you want to create the security policy, and choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    If you will be creating a security policy for all the connection pools with a single security policy, right-click Connection Pools in the navigation tree. If you will be creating a security policy for a particular connection pool, expand Connection Pools, then right-click the name of a connection pool. If you will be creating a security policy for individual MultiPools, expand MultiPools, then right-click the name of a MultiPool.

    Notes: You cannot secure all MultiPools with a single security policy.

    If a security policy controls access to a connection pool that is in a MultiPool, access checks will be performed at both levels of the JDBC resource hierarchy (once at the MultiPool level, and again at the individual connection pool level). As with all types of resources, this double checking ensures that the most restrictive security policy controls access.

    Figure 5-10 illustrates where you might click, using various connection pools and a MultiPool as an example.

    Figure 5-6 Services Portion of the Administration Console Navigation Tree

    Services Portion of the Administration Console Navigation Tree

    Notice the Caller is Granted the Role: Everyone policy statement that the JDBC resource you selected has inherited from the default security policy associated with the JDBC resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

  3. If you will be creating a security policy for a particular connection pool, use the Methods drop-down menu to specify a method that you want to protect, or select ALL to protect all methods.

 

JMS Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Services - > JMS.

    The JMS node expands to show nodes for various JMS components (connection factories, templates, destination keys, and so on).

  2. Right-click at the level of the JMS resource for which you want to create the security policy, and choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    If you will be creating a security policy for all JMS components, right-click JMS in the navigation tree. If you will be creating a security policy for a particular destination (JMS queue or JMS topic) on a JMS server, expand Servers, then the JMS server and the Destinations node, then right-click the name of a destination. Figure 5-7 illustrates where you might click, using various destinations on the examplesJMSServer as an example.

    Figure 5-7 Services Portion of the Administration Console Navigation Tree

    Services Portion of the Administration Console Navigation Tree

    Notice the Caller is Granted the Role: Everyone policy statement that the JMS resource you selected has inherited from the default security policy associated with the JMS resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

  3. If you will be creating a security policy for a particular destination on a JMS server, use the Methods drop-down menu to specify a method that you want to protect, or select ALL to protect all methods.

 

JNDI Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Servers.

    The Servers node expands to show the servers available in the current WebLogic Server domain.

  2. Right-click the name of the server that contains the JNDI resource for which you want to create the security policy. (For example, myserver.)
  3. From the menu that appears, select the View JNDI Tree option.

    The JNDI tree for the server appears in a new Administration Console window.

  4. In the new Administration Console window, right-click at the level of the JNDI tree at which you want to create the security policy, and choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    To create a security policy for a group of objects, right-click the node in the navigation tree that represents that object type. To create a security policy for a particular object, expand the node that represents that object, then right-click the name of an object. Figure 5-8 illustrates where you might click, using the examplesServer JNDI tree as an example.

    Figure 5-8 New Administration Console Window for examplesServer JNDI Tree

    New Administration Console Window for examplesServer JNDI Tree

    Notice the Caller is Granted the Role: Everyone policy statement that the JNDI resource you selected has inherited from the default security policy associated with the JNDI resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

  5. Using the Methods drop-down menu, specify which JNDI method you want to protect, or select ALL to protect all methods.

 

Server Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Servers.

    The Servers node expands to show the different server resources that can be secured.

  2. Right-click at the level of the Server resource at which you want to create a security policy, and choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    If you will be creating a security policy for all servers, right-click Servers in the navigation tree. If you will be creating a security policy for a particular server, expand Servers, then right-click the name of a server. Figure 5-9 illustrates where you might click, using the examplesServer as an example.

    Figure 5-9 Servers Portion of the Administration Console Navigation Tree

    Servers Portion of the Administration Console Navigation Tree

    Notice the Caller is Granted the Role: Admin or Caller is Granted the Role: Operator policy statement that the server resource you selected has inherited from the default security policy associated with the server resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

  3. Using the Methods drop-down menu, specify a method that you want to protect, or select ALL to protect all methods.

 

URL Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments.

    The Deployments node expands to show the types of resources that can be deployed.

  2. Right-click at the level of the Web Application resource at which you want to create the security policy.

    If you will be creating a security policy for all Web Applications (WARs), right-click Web Application Modules in the navigation tree. If you will be creating a security policy for a particular WAR or a component of a WAR (for example, a specific servlet or JSP), expand Web Application Modules, then right-click the name of a Web Application (WAR). Figure 5-10 illustrates where you might click, using the basic-webapp WAR as an example.

    Figure 5-10 Deployments Portion of the Administration Console Navigation Tree

    Deployments Portion of the Administration Console Navigation Tree

  3. If you will be creating a security policy for all Web Applications (WARs), choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    If you will be creating the security policy for a particular WAR or component of the WAR, follow these steps:

    1. Choose Define Security Policy....
    2. On the General tab, enter a URL pattern in the text field.

      A URL pattern is a path to a specific servlet within a Web Application. Or, you can use /* to protect all servlets within the Web Application.

    3. Click the Define Security Policy... button to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

      Notice the Caller is Granted the Role: Everyone policy statement that the URL resource you selected has inherited from the default security policy associated with the URL resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

  4. If you will be creating a security policy for a particular WAR or component of a particular WAR, specify which method you want to protect, or select ALL to protect all methods.

 

Web Service Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments.
  2. If the Web Service is packaged as an EAR file, expand Applications, then expand the name of the application that contains the Web Service. The application expands to show the components that make up the application, including the Web Service Web Application.

    If the Web Service is packaged as a stand-alone Web Application, expand Web Application Modules.

    Note: The Web Services icon designates a Web Service.

  3. Right-click the Web Service.

    If you will be creating a security policy for an entire Web Service, choose Define Security Policy... to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

    If you will be creating the security policy for a particular operation of the Web Service, follow these steps:

    1. Choose Define Policies and Roles for Individual services... to display a list of Web Services.
    2. Click the [Define Security Policies] link that corresponds to the particular Web Service you want to secure to display the Policy Editor page (see Figure 5-3, "Policy Editor Page," on page 5-9).

      Notice the Caller is Granted the Role: Everyone policy statement that the Web Service resource you selected has inherited from the default security policy associated with the Web Service resource type. If you proceed to Step 2: Create the Policy Conditions, you will be overriding this default security policy. For more information, see Default Security Policies and Security Policy Granularity and Inheritance.

  4. If you will be creating a security policy for a particular operation of the Web Service, specify which method you want to protect, or select ALL to protect all methods.

 

Step 2: Create the Policy Conditions

  1. In the Policy Condition list box, select one of the conditions. (For more information about the different policy conditions, see Components of a Security Policy: Policy Conditions, Expressions, and Policy Statements.)

    BEA recommends that you create expressions using the Caller is Granted the Role condition where possible. Basing expressions on security roles allows you to create one security policy that takes into account multiple users or groups, and is a more efficient method of management.

  2. Click Add to display a customized window. Click Add to display a customized window. (See Figure 5-11.)

    Figure 5-11 Customized Window for Caller is Granted the Role Condition

    Customized Window for Caller is Granted the Role Condition

    Note: If you selected the Server is in Development Mode condition in step 1, no customized window appears. Rather, the completed expression appears in the Policy Statement list box. Therefore, you can skip to step 5.

  3. If you selected the Hours of Access are Between condition, use the Time Constraint window to select start and end times, then click OK. The window closes and an expression appears in the Policy Statement list box. (See Figure 5-12 for an example.)

    Because the JMS subsystem performs its security check only once and this condition requires a subsequent security check, you should not use the Hours of Access are Between condition if you are securing a JMS resource.

    If you are securing a Web Services resource, and you selected the Element Requires Signature By condition, follow these steps to fill out the Signature Predicate window:

    1. Select whether a group or user is required to sign the SOAP element using the Of Type drop-down box.
    2. Enter the name of the SOAP message element that must be digitally signed in the Signed by Type text box. Use the following format: 
      LocalPart:Namespace

      where LocalPart refers to the name of the element in the SOAP message that must be digitally signed and Namespace refers to its namespace. Use the WSDL of the Web Service to get these values.

Caution: You can specify only those elements that have already been configured to be digitally signed in the web-services.xml deployment descriptor of the Web Service. For details, see Configuring Security" in Programming WebLogic Web Services.

    1. Enter the name of the group or user that must sign the element in the Valued At field.
    2. Click OK. An expression appears in the Policy Statement list box. (See Figure 5-12 for an example.)

    If you selected one of the other conditions, follow these steps:

    1. Use the Users, Groups, or Roles window to enter the name of a user, group, or security role, then click Add. An expression appears in the list box.

      You can repeat this step multiple times to add more than one user, group, or security role.

    2. If necessary, use the buttons located to the right of the list box to modify the expressions:

      Move Up and Move Down change the ordering of the highlighted user or group name, and therefore the order in which they are evaluated. Change switches the highlighted and and or statements between expressions. Remove deletes the highlighted user or group name.

    3. Click OK to add the expression to the policy statement. The window closes and an expression appears in the Policy Statement list box. (See Figure 5-12.)

      Figure 5-12 Example Expression in Policy Statement List Box

      Example Expression in Policy Statement List Box

  1. If needed, repeat steps 1 - 3 to add expressions based on different policy conditions.
  2. If necessary, use the buttons located to the right of the Policy Statement list box to modify the expressions:

    • Move Up and Move Down change the ordering of the highlighted expression, and therefore the order in which they are evaluated.
    • Change switches the highlighted and and or statements between expressions.
    • Edit... reopens the customized window for the highlighted expression and allows you to modify the expression.
    • Remove deletes the highlighted expression.
  3. When all the expressions in the Policy Statement list box are correct, scroll down the page and click Apply.

    Note: You can also click Reset at the bottom of the Policy Editor page to restore the page to its original state (that is, to undo any of your changes).

 

Modifying Security Policies

To modify a security policy for a resource:

  1. Navigate to the Policy Editor page for the resource, as described in Step 1: Select the WebLogic Resource.

    Pay special attention to the Inherited Policy Statement list box to ensure that you understand which security policies you may be overriding.

  2. Make your changes, using Step 2: Create the Policy Conditions as a guide.
  3. Click Apply to save your changes.

 

Deleting Security Policies

To delete a security policy for a resource:

  1. Navigate to the Policy Editor page for the resource, as described in Step 1: Select the WebLogic Resource.
  2. Click Delete to delete the entire security policy.
  3. Click Apply to save your changes.