5 Security Policies

Understand the features and functions of security policies, which specify 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".

This chapter includes the following sections:

• Security Policy Storage and Prerequisites for Use

• Default Root Level Security Policies

• Security Policy Conditions

• Chunk1028650589.html#GUID-C387F8E2-B32D-4D85-897D-7C8CD77AE3DD

• Using to Manage Security Policies

For information on using security policies to protect multiple resources, see Using Policies to Protect Multiple Resources.

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 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 Jakarta Authorization, deployment-descriptor security constraints are translated into permissions in the configured authorization policy provider. The deployment descriptors declare the constraints; they are not the provider's policy store.

• 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.

See WebLogic Security Providers in Understanding Security for Oracle WebLogic Server.

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 . See Security Policies in Oracle WebLogic Remote 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
Coherence resources	Default group: Everyone

Note:

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 Maintaining a Consistent Security Scheme.

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 run time, 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 :

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

• Chunk1028650589.html#GUID-1793FD41-5CA6-41AB-B88C-50CA6EE25569

• Context Element Policy Conditions

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.

  Note:

  Instead of the User condition, Oracle recommends adding the user to a Group and using the Group condition in the security policy. If you do use the User condition, ensure that you update any existing policies when the user is deleted from the authentication store.

• 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 Creating a WebLogic Domain 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—(Used only when securing Web Services resources) 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 a user who is named joe.

  To create an Element requires signature by condition, provide the following information:

  • Specify whether a group or a user is required to sign the SOAP element.

    For example, enter user to specify that a user must sign the element.

  • The name of the user or group that must sign the element.

  • The name of the SOAP message element that must be digitally signed. Use the following format:

    {Namespace}LocalPart 
    

    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.

    For example:

    {http://schemas.xmlsoap.org/soap/envelope/}AccountNumber 

    Note:

    You can specify only those elements that have already been configured to be digitally signed in the WS-Policy of the Web Service. For details, see Configuring Message-Level Security in Securing WebLogic Web Services for Oracle WebLogic Server.

Example of Using the @Policy and @Policies JWS Annotations

The following example shows how to use the @Policy and @Policies JWS annotations, with the relevant sections shown in bold:

Example 5-1 Using @Policy and @Policies Annotations

package wssp12.wss10;

import weblogic.jws.WLHttpTransport; 
import weblogic.jws.Policy; 
import weblogic.jws.Policies; 

import jakarta.jws.WebService;
import jakarta.jws.WebMethod;
import jakarta.jws.Oneway;

/**
 * This web service demonstrates how to use WS-SecurityPolicy 1.2
 * to enable message-level security specified in WS-Security 1.0.
 * 
 * The service authenticates the client with a username token. 
 * Both the request and response messages are signed and encrypted with X509
 certificates.
 *  
*/
@WebService(name="Simple", targetNamespace="http://example.org") 
@WLHttpTransport(contextPath="/wssp12/wss10", 
 serviceUri="UsernameTokenPlainX509SignAndEncrypt") 
@Policy(uri="policy:Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml") 
public class UsernameTokenPlainX509SignAndEncrypt {

  @WebMethod
  @Policies({ 
      @Policy(uri="policy:Wssp1.2-2007-SignBody.xml"), 
      @Policy(uri="policy:Wssp1.2-2007-EncryptBody.xml")}) 
  public String echo(String s) {

    return s;
  }

  @WebMethod
  @Policies({ 
      @Policy(uri="policy:Wssp1.2-2007-SignBody.xml"), 
      @Policy(uri="policy:Wssp1.2-2007-Sign-Wsa-Headers.xml")}) 
  public String echoWithWsa(String s) {
    return s;
  }

  @WebMethod
  @Policy(uri="policy:Wssp1.2-2007-SignBody.xml", 
 direction=Policy.Direction.inbound) 
  @Oneway 
  public void echoOneway(String s) {
    System.out.println("s = " + s);
  }

  @WebMethod
  @Policies({
      @Policy(uri="policy:Wssp1.2-2007-Wss1.0-X509-Basic256.xml", 
direction=Policy.Direction.inbound),
      @Policy(uri="policy:Wssp1.2-2007-SignBody.xml", 
direction=Policy.Direction.inbound) 
  })
  @Oneway
  public void echoOnewayX509(String s) {
    System.out.println("X509SignEncrypt.echoOneway: " + s);
  }
}

The following section of the example is the binding policy for the web service, specifying the policy:

@WebService(name="Simple", targetNamespace="http://example.org")
@WLHttpTransport(contextPath="/wssp12/wss10",
 serviceUri="UsernameTokenPlainX509SignAndEncrypt")
@Policy(uri="policy:Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml")

In the example, security policy files are attached to the web service at the method level. The specified policy files are those predefined with WebLogic Server, which means that the developers do not need to create their own files or package them in the corresponding archive.

The Wssp1.2-2007-SignBody.xml policy file specifies that the body and WebLogic system headers of both the request and response SOAP message be digitally signed. The Wssp1.2-2007-EncryptBody.xml policy file specifies that the body of both the request and response SOAP messages be encrypted.

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. See ContextHandlers and WebLogic Resources in Developing Security Providers for Oracle 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.

Attaching OWSM Security Policies to JAX-WS Web Services

The OWSM WS-Security policy attachment model is similar to that of the WebLogic web service policies. You can attach OWSM policies to WebLogic JAX-WS web services using one of the following methods:

• Policy annotations at design time, as described in Attaching Policies to Java EE Web Services and Clients Using Annotations in Securing Web Services and Managing Policies with Oracle Web Services Manager.

• Fusion Middleware Control or WLST at runtime, as described in the following sections in Securing Web Services and Managing Policies with Oracle Web Services Manager:

  • Attaching Policies Directly Using Fusion Middleware Control

  • Attaching Policies Globally Using Fusion Middleware Control

  • Attaching Policies Directly to Java EE Web Services Using WLST

  • Attaching Policies Globally Using WLST

You can attach only one type of security policy to a web service, either WebLogic web service security policies or OWSM policies. You cannot attach both WebLogic web service policies and OWSM policies to the same web service, through either the annotation mechanism, Fusion Middleware Control, or a combination of the tools.

You can attach an OWSM security policy only to a JAX-WS web service.

Using 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 policies to the provider database.

You can use the to access WebLogic resources for creating and modifying security policies. See Security Policies and Roles in Oracle WebLogic Remote Console Online Help.