Securing WebLogic Resources

Types of WebLogic Resources

The following sections describe the types of resources included in WebLogic Server:

Overview of WebLogic Resource Types

WebLogic resources are hierarchical. Therefore, the level at which you define security roles and security policies is up to you. For example, you can define security roles and security policies for an entire Enterprise Application (EAR), an Enterprise JavaBean (EJB) JAR containing multiple EJBs, a particular EJB within that JAR, or a single method within that EJB.

Administrative Resources

An Administrative resource is a type of WebLogic resource that allows users to perform administrative tasks. Examples of Administrative resources include the WebLogic Server Administration Console, the weblogic.Admin tool, and MBean APIs.

Administrative resources are limited in scope. Currently, you can only secure the User Lockout operation on an Administrative resource using the WebLogic Server Administration Console. This operation provides compatibility with WebLogic Server 6.x., and allows users who meet the security requirements to unlock users who have been locked out of their accounts. For more information about user lockout, see Protecting User Accounts in Managing WebLogic Security.

Application Resources

An Application resource is a type of WebLogic resource that represents an Enterprise Application, packaged as an EAR (Enterprise Application aRchive) file. Unlike the other types of WebLogic resources, the hierarchy of an Application resource is a mechanism for containment, rather than a type hierarchy. You secure an Application resource when you want to protect multiple WebLogic resources that constitute the Enterprise Application (for example, EJB resources, URL resources, and Web Service resources). In other words, securing an Enterprise Application will cause all the WebLogic resources within that application to inherit its security configuration.

You can also secure, on an individual basis, the WebLogic resources that constitute an Enterprise Application (EAR). Securing a resource by both means causes the individual security configuration to override the security configuration inherited from the Enterprise Application for that WebLogic resource.

Enterprise Information Systems (EIS) Resources

A J2EE Connector is a system-level software driver used by an application server such as WebLogic Server to connect to an Enterprise Information System (EIS). BEA supports Connectors developed by EIS vendors and third-party application developers that can be deployed in any application server supporting the Sun Microsystems J2EE Platform Specification, Version 1.3. Connectors, also known as Resource Adapters, contain the Java, and if necessary, the native components required to interact with the EIS.

An Enterprise Information System (EIS) resource is a specific type of WebLogic resource that is designed as a Connector. To secure access to an EIS, you create security policies and security roles for all Connectors as a group, or for individual Connectors.

Information about securing EIS resources can be found both in this document, and in the Security section of Programming WebLogic J2EE Connectors. Instructions for creating the credential maps for use with EIS resources are available in the Single Sign-On with Enterprise Information Systems section of Managing WebLogic Security.

COM Resources

WebLogic jCOM is a software bridge that allows bidirectional access between Java/J2EE objects deployed in WebLogic Server, and Microsoft ActiveX components available within the Microsoft Office family of products, Visual Basic and C++ objects, and other Component Object Model/Distributed Component Object Model (COM/DCOM) environments.

A COM resource is a specific type of WebLogic resource that is designed as a program component object according to Microsoft's framework. To secure COM components accessed through BEA's bi-directional COM-Java (jCOM) bridging tool, you create security policies and security roles for packages containing multiple COM classes, or for individual COM classes.

Information about securing COM resources can be found both in this document and in the Configuring Access Control section of Programming WebLogic jCOM.

Java DataBase Connectivity (JDBC) Resources

A Java DataBase Connectivity (JDBC) resource is a specific type of WebLogic resource that is related to JDBC. To secure JDBC database access, you can create security policies and security roles for all connection pools as a group, individual connection pools, and MultiPools. When you secure individual connection pools, you can choose whether to protect all operations on the connection pool, or protect one of the following operations:

admin—The following methods on the JDBCConnectionPoolRuntimeMBean are invoked as admin operations: clearStatementCache, destroy, disableDroppingUsers, disableFreezingUsers, enable, forceDestroy, forceShutdown, forceSuspend, getProperties, poolExists, resume, shutdown, shutdownHard, shutdownSoft, and suspend.
reserve—Applications reserve a connection in the connection pool by looking up the data source that points to the connection pool and then calling getConnection.

Note: Giving a user the reserve permission enables them to execute vendor-specific operations on the connection. Depending on the database vendor, some of these operations may have database security implications.

shrink—Shrinks the connection pool to the maximum of the currently reserved connections or the initial size.
reset—Resets the database connection pool by shutting down and re-establishing all physical database connections. This also clears the statement cache for each connection in the connection pool. You can only reset a normally running connection pool.

Note: If a security policy controls access to a connection pool that is in a MultiPool, access checks are 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 WebLogic resources, this double-checking ensures that the most restrictive security policy controls access.

Note: If you are an Oracle user, you can also control access to JDBC resources using an Oracle Virtual Private Database (VPD). For more information, see Programming with Oracle Private Virtual Databases in Using Third-Party Drivers with WebLogic Server.

Java Messaging Service (JMS) Resources

A Java Messaging Service (JMS) resource is a specific type of WebLogic resource that is related to JMS. To secure JMS destinations, you create security policies and security roles for all destinations (JMS queues and JMS topics) as a group, or an individual destination (JMS queue or JMS topic) on a JMS server. When you secure a particular destination on a JMS server, you can protect all operations on the destination, or protect one of the following operations:

send—Required to send a message to a queue or a topic. This includes calls to the MessageProducer.send(), QueueSender.send(), and TopicPublisher.publish() methods, as well as the Messaging Bridge.
receive—Required to create a consumer on a queue or a topic. This includes calls to the Session.createConsumer(), Session.createDurableSubscriber(), QueueSession.createReceiver(), TopicSession.createSubscriber(), TopicSession.createDurableSubscriber(), Connection.createConnectionConsumer(), Connection.createDurableConnectionConsumer(), QueueConnection.createConnectionConsumer(), TopicConnection.createConnectionConsumer(), and TopicConnection.createDurableConnectionConsumer() methods, as well as the Messaging Bridge and message-driven beans.
browse—Required to view the messages on a queue using the QueueBrowser interface.

Java Naming and Directory Interface (JNDI) Resources

JNDI provides a common-denominator interface to many existing naming services, such as Lightweight Directory Access Protocol (LDAP) and Domain Name System (DNS). These naming services maintain a set of bindings, which relate names to objects and provide the ability to look up objects by name. JNDI allows the components in distributed applications to locate each other.

JNDI is independent of any specific naming or directory service implementation. It supports the use of a number of methods for accessing various new and existing services. This support allows any service-provider implementation to be plugged into the JNDI framework using the standard service provider interface (SPI) conventions.

A Java Naming and Directory Interface (JNDI) resource is a specific type of WebLogic resource that uses the industry-standard JNDI SPI to enable connectivity to heterogeneous enterprise naming and directory services. To secure access to the JNDI tree, you create security policies and security roles for the entire JNDI tree, or for an individual branch of that tree. Regardless, you can protect all operations, or protect one of the following operations:

modify—Whenever an application modifies the JNDI tree in any way (that is, adding, removing, changing) the current user must have permission to make the modification. This includes the bind(), rebind(), createSubContext(), destroySubContext(), and unbind() methods.
lookup—Whenever an application looks up an object in the JNDI tree, the current user must have permission to perform the lookup. This includes the lookup() and lookupLink() methods.
list—Whenever an application lists the contents of a context in JNDI, the current user must have permission to perform the list. This includes the list() and listBindings() methods.

Server Resources

Many engineering teams divide administration responsibilities into distinct roles. Each project might give only one or two team members permission to deploy applications or modules, but allow all team members to view the server configuration. As described in Security Policies, WebLogic Server supports this division of responsibility by allowing administrators to secure WebLogic resources with security policies. Typically, these security policies are based on whether users or groups of users are granted a particular security role.

A Server resource is a specific type of WebLogic resource that is used to protect activities that control the running state of a WebLogic Server server instance. To secure Server resources, you create security policies and security roles for all WebLogic Server instances (servers) as a group, or individual servers. When you secure a particular server, you can protect all operations on the server, or protect one of the following operations:

boot—A user who tries to start a WebLogic Server instance, either an Administration Server or Managed Server, must have permission to do so. This action is typically initiated through a call to the java weblogic.Server command on the command line, by a configured start script (which in turn calls the java weblogic.Server command), or through the Node Manager capabilities that allow for remote start of WebLogic Server instances.
shutdown—A user who tries to shut down a running WebLogic Server instance, either an Administration Server or Managed Server, must have permission to do so. This action is typically initiated through the WebLogic Server Administration Console or the weblogic.Admin SHUTDOWN or FORCESHUTDOWN commands.
lock—A user who tries to prohibit additional logins (logins other than for privileged administrative actions) to a running WebLogic Server instance, either an Administration Server or Managed Server, must have permission to do so. This action is typically initiated through the Administration Console or the weblogic.Admin LOCK commands.
unlock—A user who tries to re-enable non-privileged logins to a running WebLogic Server instance, either an Administration Server or Managed Server, must have permission to do so. This action is typically initiated through the Administration Console or the weblogic.Admin UNLOCK commands.

Like other types of WebLogic resources, a Server resource and its operations are secured with security policies. However, because the configuration of a server is exposed through a set of MBeans, a Server resource also has additional protections that affect how administrators access MBean operations.

Layered Security Scheme for Server Resources

The following sections provide more information about the layered security scheme for Server resources:

Security Policies for Server Resources

Like other types of WebLogic resources, a Server resource is secured with security policies through the WebLogic Server Administration Console.

More specifically, all server resources inherit a default security policy that is based on the Admin and Operator default global security roles. As described in Default Global Roles, the Admin and Operator global roles are given specific privileges that are required in order for administrators to interact with administrative interfaces like the Administration Console or the weblogic.Admin command. These default global roles are based on the default groups (described in Default Group Associations). Therefore, administrators who need access to Server resources need to be members of either the Administrators or Operators default groups.

Note: Because WebLogic Server grants the four default global roles to four default groups, adding a user to one of these groups automatically grants the user the global role.

Caution: Do not modify the default security policies for Server resources to make them more restrictive. Eliminating some of the existing security roles might negatively affect 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).

MBean Protections

Each type of WebLogic resource (including a Server resource) exposes a set of its operations through its own implementation of the weblogic.security.spi.Resource interface (the weblogic.security.service.ServerResource class for Server resources). Therefore, the ServerResource class is the entity that is actually secured by the security policy described in Security Policies for Server Resources.

In WebLogic Server, the configuration of a Server resource is exposed through a set of MBeans. As such, the actions that the ServerResource class protects correspond to underlying MBean attributes and operations. For example, the Resource interface's start() method maps directly to the start operation of the ServerRuntime MBean.

The MBeans that expose the configuration of a Server resource are protected using one of the four default global roles. This protection is in addition to the security policy on the Server resource and is currently an unconfigurable protection supplied by the WebLogic Security Service. Therefore, although you can create your own global roles for securing Server resources, only users granted one of the default global roles can view or change the configuration of a server.

How the WebLogic Security Service Verifies Layered Protections

When an administrator tries to interact with a Server resource, the WebLogic Security Service:

Determines whether the user is granted one of the default global roles permitted to change the attributes of the MBean or invoke the operations of the MBean
Checks the default security policy for the Server resource to verify that the user meets the requirement defined by that security scheme

Therefore, a user must satisfy both security schemes for the request to be successful. Figure 2-1 shows how a security policy on the Server resource interacts with the security role-based protections on the underlying MBeans.

Figure 2-1 Layered Protections for Server Resources

Layered Protections for Server Resources

Because the privileges given by the MBean protections are immutable, it is necessary to maintain security policies in a way that ensures consistency. (For more information, see Maintaining a Consistent Security Scheme.)

Example of Layered Protection for a Server Resource

This example illustrates how one Server resource is protected by the layered security scheme.

An administrator with the user name JDoe wants to start the server called myserver. This administrative user (JDoe) is a member of the default group Administrators, which by default is granted the Admin global security role. You set up user-to-group and group-to-security role configuration through the WebLogic Server Administration Console, as described in other sections of this guide.

Part 1: MBean Protections

Because starting a server requires interactions with various MBeans, and because MBean protections are an unconfigurable protection supplied by the WebLogic Security Service, a user wanting to perform such an operation must be in the Admin or Operator default global roles. For example, Table 4-5 shows that access to the Server and ServerRuntime MBeans (MBeans with start operations) is a privilege given only to users in these default security roles. Because the administrative user JDoe is a member of the default group Administrators, he is also granted the Admin global security role, and therefore fulfills the first part of the dual security scheme for Server resources.

Part 2: Security Policy on the Server Resource

As the Policy Editor page in Figure 2-2 shows, the default security policy for myserver (viewed by right-clicking on myserver in the navigation tree and selecting the Define Security Policy... option) allows users granted the Admin or Operator global roles to interact with this Server resource. Because the administrative user JDoe is a member of the default group Administrators, he is also granted the Admin global security role, and therefore fulfills the second part of the layered security scheme for Server resources.

Figure 2-2 Default Security Policy for the myserver Server

Default Security Policy for the myserver Server

Notes: Had the administrative user JDoe been a member of the Operators group (and therefore granted the Operator default global role), he would have still fulfilled both parts of the dual security scheme.

For a detailed explanation of the Policy Editor page shown in Figure 2-2, Default Security Policy for the myserver Server, on page 2-10, see Components of a Security Policy: Policy Conditions, Expressions, and Policy Statements.

Maintaining a Consistent Security Scheme

The WebLogic Server default configuration of groups, global roles, security policies on Server resources, and MBean protections work together to create a consistent security scheme. You can, however, make modifications that limit access in ways that you do not intend. Be certain that any modifications you make to the default security settings do not prevent a user from being authorized by both the MBean protections and the security policy on the Server resource.

For example, if you use the WebLogic Server Administration Console to add a user to the Operator global role, but fail to use the Operator global role in the security policy defined for a Server resource, the user can call MBean operations that are used in the startup and shutdown sequence, but cannot use any Server resource operations to start or stop a server. Similarly, if you use the Administration Console to remove the Operator global role from a security policy on the Server resource, a user granted the Operator global role can still call MBean operations but cannot call the Server resource. This result occurs because MBean protections for the default global roles are part of the WebLogic Security Service and are not currently configurable.

To keep MBean protections synchronized with security policies, consider taking the following actions when you create or modify a security policy:

Always give the Admin global role access to a Server resource.
For a security policy on a server, use the Operator global role.

Failure to use the Operator global role or a security role nested within this default global role may result in problems with the WebLogic Security Service.

For a security policy on a deployable resource (such as an application, EJB module, Web Application module, Connector module, or startup/shutdown class), use the Deployer global role.

For more information about security policies, see Working with Security Policies.

Permissions for Starting and Shutting Down Servers

WebLogic Server provides two ways to start and shut down WebLogic Server instances (servers): the weblogic.Server command and the Node Manager. Because the underlying components for the weblogic.Server command and the Node Manager are different, the two commands use different authorization methods.

The following sections provide more information about the permissions for starting and shutting down servers:

Permissions for Using the weblogic.Server Command

The weblogic.Server command, which you can use to start both Administration and Managed Servers, calls methods that are protected by a security policy on the Server resource. To use this command, you must satisfy the requirements of the security policy on the Server resource.

Some weblogic.Server arguments set attributes for MBeans. However, because these arguments modify an MBean before the server is in the RUNNING state, the security policy on the Server resource, not the protection on the MBean, is the authorizer. For example, a user in the Operator global role can use the -Dweblogic.ListenPort argument to change a server's default listen port, but once the WebLogic Server instance is running, this user cannot change the listen port value.

For more information about weblogic.Server, see weblogic.Server Command-Line Reference in the WebLogic Server Command Reference.

Permissions for Using the Node Manager

The Node Manager uses both MBeans and the security policy on the Server resource to start a remote server.

If you configure a Node Manager on the host machine of a remote WebLogic Server instance, by default a user in the Admin or Operator global role can use the Node Manager to start the remote server.

For more information about the Node Manager, see Configuring, Starting, and Stopping Node Manager in Configuring and Managing WebLogic Server.

Shutting Down a WebLogic Server Instance

Shutting down a WebLogic Server instance involves both MBeans and the security policy on the Server resource. When a user issues a shutdown command, the server first determines whether that user is granted the Admin or Operator global role (per the MBean protection). Then, after the MBean operations run, the server determines whether the security policy on the Server resource authorizes the user to shut down the server.

For more information about shutting down a WebLogic Server instance, see Starting and Stopping Servers: Quick Reference in Configuring and Managing WebLogic Server.

URL (Web) and EJB (Enterprise JavaBean) Resources

A URL (Web) resource is a specific type of WebLogic resource that is related to Web Applications. To secure Web Applications, you create security policies and security roles for a WAR (Web Application aRchive) file or for individual components of a Web Application (such as servlets and JSPs). An EJB (Enterprise JavaBean) resource is a specific type of WebLogic resource that is related to EJBs. To secure EJBs, you create security policies and security roles for EJB JARs, individual EJBs within an EJB JAR, or for individual methods on an EJB.

Because the Java 2 Enterprise Edition (J2EE) platform standardizes Web Application and EJB security in deployment descriptors, WebLogic Server integrates this standard mechanism with its Security Service to give you a choice of techniques for securing URL and EJB resources. The technique you choose will affect the procedure you will follow, and will require different prerequisite settings in the WebLogic Server Administration Console. For more information, see Techniques for Securing URL and EJB Resources and Prerequisites for Securing URL and EJB Resources, respectively.

Note: The instructions for EJB resources provided in this document also apply to Message-Driven Beans (MDBs).

Techniques for Securing URL and EJB Resources

The following sections describe the different techniques for securing URL (Web) and EJB (Enterprise JavaBean) resources in more detail:

Using the WebLogic Server Administration Console

The primary benefit of using the Administration Console to secure URL and EJB resources is unified security management. Instead of requiring developers to modify multiple deployment descriptors when organizational security requirements change, administrators can modify all security configurations from a centralized, graphical user interface. Users, groups, security roles, and security policies can all be defined using the Administration Console. As a result, the process of making changes based on updated security requirements becomes more efficient.

You can secure all types of WebLogic resources using this technique. Therefore, the instructions for securing WebLogic resources contained within this document are written specifically for users of the Administration Console.

Using Deployment Descriptors

The primary benefit of securing your URL and EJB resources through J2EE and WebLogic deployment descriptors is that it is a widely known, standard technique for adding declarative security to Web Applications and EJBs. It may also be the technique with which most organizations are familiar. When using this technique, security roles and security policies are specified in the web.xml, weblogic.xml and ejb-jar.xml, weblogic-ejb-jar.xml deployment descriptors.

Note: In WebLogic Server 7.0 SP02, a special tag called <externally-defined> was introduced. This tag allows you to specify on a role-by-role basis whether a security role mapping is defined in the deployment descriptors or in the Administration Console. This tag replaces the <global-role> tag, which has been deprecated. For more information about using this tag with URL or EJB resources, see Using the <externally-defined> Tag with Web Applications or Using the <externally-defined> Tag with EJBs in Programming WebLogic Security, respectively.

You can secure only URL and EJB resources through use of deployment descriptors. The instructions for using deployment descriptors are available in the Using Declarative Security With Web Applications and Using Declarative Security With EJBs sections of Programming WebLogic Security, respectively.

Using the Administration Console and Deployment Descriptors

Some organizations currently using deployment descriptors to secure their URL and EJB resources may want to take advantage of the unified security management capabilities that the WebLogic Server Administration Console provides. In a situation like this, the Administration Console can be instructed to copy security configurations from existing deployment descriptors upon the initial deployment of a Web Application or EJB module. Once these security configurations are copied into the Role Mapping and Authorization providers' databases, the Administration Console must be used for subsequent updates to security roles and security policies. It is also possible to use this combined technique to reinitialize security configurations for URL and EJB resources to the state specified in the deployment descriptors.

Caution: When using the combined technique, it is possible to override security configurations for URL and EJB resources. Therefore, administrators using the combined technique need to take extra care to ensure that the appropriate security configuration is in place for their Web Applications and EJBs. Read Prerequisites for Securing URL and EJB Resources for important information.

For more information about using the combined technique, see Tutorial 16: Copying and Reinitializing Security Configurations.

Prerequisites for Securing URL and EJB Resources

Whether using the WebLogic Server Administration Console or deployment descriptors to secure your URL and EJB resources, there are two important settings in WebLogic Server that you need to understand: the Check Security Roles and Policies setting and the On Future Redeploys setting. Failure to understand these settings could result in incorrect or lost security configurations.

Before attempting to secure URL or EJB resources, read the following sections:

Understanding How to Check Security Roles and Security Policies

To give you control over performance, the WebLogic Server Administration Console requires you to specify how the WebLogic Security Service should perform security checks. You specify this preference through the Check Roles and Policies drop-down menu highlighted in Figure 2-3.

Figure 2-3 Administration Console: Security > Realms > myRealm > General

When the value of the Check Roles and Policies setting is Web Applications and EJBs Protected in DD, the WebLogic Security Service only performs security checks on URL (Web) and EJB resources that have security specified in their associated deployment descriptors (DDs). This is the default Check Roles and Policies setting.

When the value of the Check Roles and Policies setting is All Web Applications and EJBs, the WebLogic Security Service performs security checks on all URL (Web) and EJB resources, regardless of whether there are any security settings in the deployment descriptors (DDs) for these WebLogic resources. If you change the value of the Check Roles and Policies drop-down menu to All Web Applications and EJBs, you also need to specify what the WebLogic Security Service should do when the Web Application or EJB module is redeployed. For more information, see Understanding What to Do on Future Redeploys of the WebLogic Resource.

Note: The Check Roles and Policies setting affects all the WebLogic Server instances (servers) in the WebLogic Server domain in which it is set.

Using the fullyDelegateAuthorization Flag

You can also specify how to perform security checks on URL (Web) and EJB resources using the fullyDelegateAuthorization flag, a command-line argument that you set when you start WebLogic Server. When the value of the fullyDelegateAuthorization flag is false, the WebLogic Security Service only performs security checks on URL and EJB resources that have security specified in their associated deployment descriptors.

You can set the fullyDelegateAuthorization flag in one of three ways:

Type:

-Dweblogic.security.fullyDelegateAuthorization = boolean_value
where boolean_value is true or false on the command line each time you start a WebLogic Server instance.

Note: You should ensure that the fullyDelegateAuthorization flag is set the same way for both your Administration and Managed Servers.

Edit the startWLS script (located in the WL_HOME\server\bin directory) to include the following:

-Dweblogic.security.fullyDelegateAuthorization = boolean_value
where boolean_value is true or false. This is more efficient because it will save you from having to set the flag each time you start a WebLogic Server instance. However, keep in mind that this setting will apply to all WebLogic Server domains in the installation.

Edit the startWebLogic script (located in the WL_HOME\user_projects\domains\mydomain directory, where mydomain is the name of a WebLogic Server domain you created) to include the following in the JAVA_OPTIONS section:

set JAVA_OPTIONS=... -Dweblogic.security.fullyDelegateAuthorization=true
This method allows you to set the fullyDelegateAuthorization flag for each WebLogic Server domain, rather than all the domains in the installation.

Note: If you are using Node Manager to start your Managed Servers, the start scripts previously described are not used. Therefore, you will need to set the fullyDelegateAuthorization flag using the WebLogic Server Administration Console.

Understanding What to Do on Future Redeploys of the WebLogic Resource

If you decide that the WebLogic Security Service should perform security checks on All Web Applications and EJBs in the Check Roles and Policies drop-down menu, you also need to tell WebLogic Server which technique you want to use to secure these URL (Web) and EJB resources. (See Techniques for Securing URL and EJB Resources for more information.) You specify this preference through the Future Redeploys drop-down menu highlighted in Figure 2-3.

Set the value of the Future Redeploys drop-down menu as follows:

To secure your URL (Web) and EJB resources using only the WebLogic Server Administration Console, select Ignore Roles and Policies From DD (Deployment Descriptors) and follow steps 3a - 3c in Securing WebLogic Resources: Main Steps.
To secure your URL (Web) and EJB resources using only the deployment descriptors (that is, the web.xml, weblogic.xml, ejb-jar.xml, and weblogic-ejb-jar.xml files), select Initialize Roles and Policies from DD and refer to the Adding Declarative Security to Web Applications and Adding Declarative Security to EJBs sections of Programming WebLogic Security, respectively.

Warning: Switching the value of the Future Redeploys setting is risky and can lead to incorrect or lost security configurations. If you need to switch between these settings (specifically for the situations described in Using the Administration Console and Deployment Descriptors), you can carefully follow the instructions in Using the Combined Technique to Secure Your URL and EJB Resources.

How to Change the Check Roles and Policies and Future Redeploys Settings

To change the values of the Check Roles and Policies and Future Redeploys settings:

In the left pane of the WebLogic Server Administration Console, expand Security —> Realms.

Click the name of a security realm for which you are setting this option (for example, myrealm).

On the General tab, change the value of the Check Roles and Policies drop-down menu.

If you changed the value of the Check Roles and Policies drop-down menu to All Web Applications and EJBs, change the value of the Future Redeploys drop-down menu.

Click Apply to save your changes.

If you changed the value of the Check Roles and Policies drop-down menu, restart the server.

Understanding How These Settings Interact

Table 2-1 shows how to achieve the behavior you want from the WebLogic Security Service using different combinations of the Check Roles and Policies and Future Redeploys settings.

Table 2-1 Interaction Between Check Roles and Policies Setting and On Future Redeploys Setting

If you want to perform security checks on...	and set security for URL (Web) and EJB resources...	then set Check Roles and Policies to...	and set Future Redeploys to...
All URL (Web) and EJB resources	using only the Administration Console	All Web Applications and EJBs	Ignore Roles and Policies from DD
All URL (Web) and EJB resources	by copying or reinitializing security data from the deployment descriptors into the configured Authorization and Role Mapping providers' databases when the Web Application or EJB module is deployed, then using one of the other techniques to modify security roles and security policies Note: Security data will be copied/reinitialized each time the Web Application or EJB module is deployed.	All Web Applications and EJBs	Initialize Roles and Policies from DD
Only on URIs and EJB methods that are specified in the deployment descriptors (default configuration)	using only the deployment descriptors	Web Applications and EJBs Protected in DD	--

If you want to perform security checks on...

and set security for URL (Web) and EJB resources...

then set Check Roles and Policies to...

and set Future Redeploys to...

All URL (Web) and EJB resources

using only the Administration Console

All Web Applications and EJBs

Ignore Roles and Policies from DD

All URL (Web) and EJB resources

by copying or reinitializing security data from the deployment descriptors into the configured Authorization and Role Mapping providers' databases when the Web Application or EJB module is deployed, then using one of the other techniques to modify security roles and security policies

Note: Security data will be copied/reinitialized each time the Web Application or EJB module is deployed.

All Web Applications and EJBs

Initialize Roles and Policies from DD

Only on URIs and EJB methods that are specified in the deployment descriptors (default configuration)

using only the deployment descriptors

Web Applications and EJBs Protected in DD

Using the Combined Technique to Secure Your URL and EJB Resources

As described in Techniques for Securing URL and EJB Resources, you can combine the use of the WebLogic Server Administration Console and J2EE/WebLogic deployment descriptor techniques, and would typically do so for two reasons:

To copy security configurations from deployment descriptors into the configured Authorization and Role Mapping providers' databases, upon initial deployment of Web Application and EJB modules. This process enables you to use the Administration Console for subsequent modifications to security roles and security policies.
To reinitialize security configurations for URL and EJB resources to their original state, as specified in the deployment descriptors.

Use of the combined technique for other purposes is not recommended. Before continuing, be sure you have read Prerequisites for Securing URL and EJB Resources.

The following sections provide step-by-step instructions for using the combined technique to secure your URL and EJB resources:

You may also want to review Tutorial 16: Copying and Reinitializing Security Configurations before performing these tasks.

Copying Security Configurations

These instructions are intended for administrators who presently secure URL (Web) and EJB (Enterprise JavaBean) resources using J2EE and WebLogic deployment descriptors, but want to exclusively use the WebLogic Server Administration Console from this point forward. Note that BEA does not recommend maintaining security configurations in both the deployment descriptors and the Administration Console.

Caution: When using the combined technique, it is possible to override security configurations for URL and EJB resources. Therefore, you must take extra care to ensure that the appropriate security configuration is in place. Follow these instructions carefully to prevent data loss and to ensure that your URL and EJB resources are secured properly.

To copy security configurations for a URL or EJB resource so that you can use the WebLogic Server Administration Console for subsequent modifications, follow these steps:

Step 1: Modify the Security Realm Settings and Deploy the Resource

In the left pane of the Administration Console, expand Security —> Realms.

Click the name of your security realm (for example, myrealm).

On the General tab, select All Web Applications and EJBs as the value for the Check Roles and Policies drop-down menu.

You are telling WebLogic Server that you want the WebLogic Security Service to perform security checks on all URL (Web) and EJB resources. See Understanding How to Check Security Roles and Security Policies.

Note: If All Web Applications and EJBs was already selected as the value of the Check Roles and Policies drop-down menu, just continue to step 4.

Select Initialize Roles and Polices From DD as the value for the On Future Redeploys drop-down menu.

You are telling WebLogic Server to copy security for URL (Web) and EJB resources from the deployment descriptors into the configured Authorization and Role Mapping providers' databases each time you deploy the resource. See Understanding What to Do on Future Redeploys of the WebLogic Resource.

Click Apply to save your changes.

If you had to set the Check Roles and Policies drop-down menu to All Web Applications and EJBs in step 2 (that is, it was not already set this way), restart the server. (For help, see Starting and Stopping WebLogic Servers: Quick Reference in the WebLogic Server Administration Guide.)

Note: If you did not have to modify the value of the Check Role and Policies drop-down menu in step 3, continue to step 7 without restarting the server.

Deploy the Web Application or EJB module whose security configuration you want to copy, targeting it to the appropriate server.

For instructions about how to deploy Web Application and EJB modules, see Deploying WebLogic Server Applications.

Step 2: Verify the Copied Security Policies (Optional)

To verify the copied security policies, follow the instructions shown in the appropriate column of Table 2-2.

Table 2-2 Verifying Copied Security Policies, Based on Resource Type

Step	URL (Web) Resources	EJB Resources
1	Open the `web.xml` deployment descriptor for the Web Application, and record the content of any `<url-pattern>` and `<http-method>` elements, as well as any `<role-name>` subelements of the `<auth-constraint>` element.	Open the `ejb-jar.xml` deployment descriptor for the EJB, and record the content of any `<method-permission>` elements, specifically focusing on the `<role-name>`, `<ejb-name>`, and `<method-name>` subelements. Note: If the deployment descriptor uses the `<unchecked />` element where you would normally find a `<role-name>` element, security checks will not be performed on that method; therefore, no security data for that method will be copied.
2	Using the navigation tree at the left side of the Administration Console, right-click the name of the deployed Web Application module.	Using the navigation tree at the left side of the Administration Console, right-click the name of the deployed EJB module.
3	Select the Define Security Policy... option from the menu.	Select the Define Roles and Policies for Individual Beans... option from the menu. A table listing all the EJBs that are in the JAR file appears.
4	On the General tab, click the hyperlinked URL pattern that corresponds to the content of a single `<url-pattern>` element you recorded in step 1.	Click the [Define Security Policies] link for the EJB that corresponds to the `<ejb-name>` element you recorded in step 1.
5	On the Policy Editor page that appears, select a method from the Methods drop-down menu that corresponds to the content of a `<http-method>` element you recorded in step 1. The `Caller is Granted the Role` condition in the Policy Condition list box is highlighted, and the content of the Policy Statement list box corresponds to the content of the appropriate `<role-name>` element that you recorded in step 1.	On the Policy Editor page that appears, select a method from the Methods drop-down menu that corresponds to the content of a `<method-name>` element you recorded in step 1. The `Caller is Granted the Role` condition in the Policy Condition list box is highlighted, and the content of the Policy Statement list box corresponds to the content of the corresponding `<role-name>` element that you recorded in step 1.
6	Repeat steps 1- 5 to verify multiple security policies.	Repeat steps 1- 5 to verify multiple security policies.

Step 3: Verify the Copied Security Roles (Optional)

To verify the copied security policies, follow the instructions shown in the appropriate column of Table 2-3.

Table 2-3 Verifying Copied Security Roles, Based on Resource Type

Step	URL (Web) Resources	EJB Resources
1	Open the `weblogic.xml` deployment descriptor for the Web Application, and record the content of any `<security-role-assignment>` elements, specifically focusing on the `<role-name>` and `<principal-name>` subelements. Note: If the deployment descriptor uses the `<externally-defined>` element for a Web Application, no scoped roles are actually defined; therefore no scoped roles for the EJB can be copied.	Open the `weblogic-ejb-jar.xml` deployment descriptor for the EJB, and record the content of any `<security-role-assignment>` elements, specifically focusing on the `<role-name>` and `<principal-name>` subelements. Note: If the deployment descriptor uses the `<externally-defined>` element for an EJB, no scoped roles are actually defined; therefore no scoped roles for the EJB can be copied.
2	Using the navigation tree at the left side of the Administration Console, right-click the name of the deployed Web Application module.	Using the navigation tree at the left side of the Administration Console, right-click the name of the deployed EJB module.
3	Select the Define Scoped Role... option from the menu.	Select the Define Scoped Role... option from the menu. The Select Roles page displays all the scoped roles for this EJB that are currently defined in the WebLogic Role Mapping provider's database, including the ones from your deployment descriptor's `<role-name>` element.
4	On the General tab, click the hyperlinked URL pattern `/`. Note:* Security roles obtained from deployment descriptors are always copied into the configured Role Mapping provider's database as scoped roles, with an URL pattern of `/*`. The Select Roles page displays all the scoped roles for this Web Application that are currently defined in the WebLogic Role Mapping provider's database, including the ones from your deployment descriptor's `<role-name>` element.	Click the hyperlinked name of the scoped role.
5	Click the hyperlinked name of the scoped role.	Select the Conditions tab. The Role Statement list box contains a Role Statement based on the content of your deployment descriptor's corresponding `<principal-name>` element. Note: Because principals can be users or groups, the Role Statement list box will show two expressions: one using the contents of the `<principal-name>` element in the `User Name of the Caller` Role Condition, the other using it in a `Caller is a Member of the Group` Role Condition, linked by an `or` statement. The Administration Console presumes that a user or group of the name used in the deployment descriptor already exists. If they do not, you will need to create them.
6	Select the Conditions tab. The Role Statement list box contains a Role Statement based on the content of your deployment descriptor's corresponding `<principal-name>` element. Note: Because principals can be users or groups, the Role Statement list box will show two expressions: one using the contents of the `<principal-name>` element in the `User Name of the Caller` Role Condition, the other using it in a `Caller is a Member of the Group` Role Condition, linked by an `or` statement. The Administration Console presumes that a user or group of the name used in the deployment descriptor already exists. If they do not, you will need to create them.	Repeat steps 1- 5 to verify multiple scoped roles.
7.	Repeat steps 1- 6 to verify multiple scoped roles.	--

Step 4: Revert the On Future Redeploys Setting

Caution: You must perform this step. Failure to revert this setting may result in inconsistent security configurations when your Web Application and EJB modules are redeployed. Therefore, be sure to perform this step before you restart your server. If you do not perform this step or perform this step incorrectly, you will see the following message the next time you load the Policy Editor page:

The information presented below may not be accurate. To ensure that you are viewing accurate information, you may need to delete and redeploy your WebLogic resources.

In the left pane of the Administration Console, expand Security —> Realms.

Click the name of your security realm (for example, myrealm).

On the General tab, select Ignore Roles and Polices From DD as the value for the On Future Redeploys drop-down menu.

You are telling WebLogic Server that you will set security for URL (Web) and EJB resources using the Administration Console, not deployment descriptors. See Understanding What to Do on Future Redeploys of the WebLogic Resource.

Click Apply to save your changes.

Step 5: Modify Security Roles and Security Policies Using the Administration Console (Optional)

Follow the instructions in Modifying Global Roles and Working with Security Policies to modify your URL or EJB resource's security roles and security policies.

Reinitializing Security Configurations

To reinitialize security configurations for URL (Web) and EJB (Enterprise JavaBean) resources to their original state as specified in their deployment descriptors, follow these steps:

Step 1: Modify the Security Realm Settings and Redeploy the WebLogic Resource

In the left pane of the Administration Console, expand Security —> Realms.

Click the name of your security realm (for example, myrealm).

If All Web Applications and EJBs was already selected as the value of the Check Roles and Policies drop-down menu, skip step 4.

On the General tab, select All Web Applications and EJBs as the value for the Check Roles and Policies drop-down menu.

You are telling WebLogic Server that you want the WebLogic Security Service to perform security checks on all URL (Web) and EJB resources. See Understanding How to Check Security Roles and Security Policies.

Select Initialize Roles and Polices From DD as the value for the On Future Redeploys drop-down menu.

You are telling WebLogic Server to copy security for URL (Web) and EJB resources from the deployment descriptors into the configured Authorization and Role Mapping providers' databases each time you deploy the resource. See Understanding What to Do on Future Redeploys of the WebLogic Resource.

Click Apply to save your changes.

In the left pane of the Administration Console, expand Deployments, then click either:

Web Application Modules—for URL (Web) resources, or
EJB Modules—for EJB (Enterprise JavaBean) resources.

Click the name of a Web Application or EJB module.

A table that lists all the Web Application or EJB modules appears in the right pane.

Click the trash can icon that is located in the same row as the Web Application or EJB module for which you want to reinitialize a security configuration.

Click Yes, then the Continue link to delete the Web Application or EJB module.

The deleted Web Application or EJB module no longer appears in the table.

Re-deploy the Web Application or EJB module whose security configuration you want to initialize, targeting it to the appropriate server.

For instructions about how to deploy Web Application and EJB modules, see Deploying WebLogic Server Applications.

Step 2: Verify the Reinitialized Security Policies and Security Roles (Optional)

To verify the reinitialized security policies and security roles, follow the instructions shown in the appropriate column of Table 2-2 and Table 2-3, respectively.

Step 3: Revert the On Future Redeploys Setting

The information presented below may not be accurate. To ensure that you are viewing accurate information, you may need to delete and redeploy your WebLogic resources.

In the left pane of the Administration Console, expand Security —> Realms.

Click the name of your security realm (for example, myrealm).

On the General tab, select Ignore Roles and Polices From DD as the value for the On Future Redeploys drop-down menu.

You are telling WebLogic Server that you will set security for URL (Web) and EJB resources using the Administration Console, not deployment descriptors. See Understanding How to Check Security Roles and Security Policies.

Click Apply to save your changes.

Step 4: Modify Security Roles and Security Policies Using the Administration Console (Optional)

Follow the instructions in Modifying Global Roles and Working with Security Policies to modify your URL (Web) or EJB resource's security roles and security policies.

Web Service Resources

A WebLogic Web Service is typically packaged as an Enterprise Application that contains a special type of Web Application that includes an additional deployment descriptor called web-services.xml. If your Web Service is implemented with a Java class, then the Web Application WAR file contains the Java class files. If the Web Service is implemented with a stateless session EJB, then the Enterprise Application EAR file contains the corresponding EJB JAR file.

Note: A Web Service can also be packaged as a stand-alone Web Application WAR file if the Web Service is implemented with just a Java class. This type of packaging for a Web Service is uncommon, however; typically Web Services are packaged as EAR files.

A Web Service resource is a specific type of WebLogic resource that is related to Web Services. To secure Web Services, you can create security policies and security roles for:

The entire Web Service
A subset of the operations of the Web Service
The Web Service URL
The stateless session EJB that implements the Web Service
A subset of the methods of the stateless session EJB
The WSDL and Home Page of the Web Service

For more information about WebLogic Web Services, see Programming WebLogic Web Services.