Securing WebLogic Resources
The following sections describe the types of resources included in WebLogic Server:
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.
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.
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.
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.
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.
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.
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.
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.
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.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.
The following sections provide more information about the layered security scheme 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).
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.
When an administrator tries to interact with a Server resource, the WebLogic Security Service:
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
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.)
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.
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.
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
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.
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:
Admin
global role access to a Server resource.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.
Deployer
global role.For more information about security policies, see Working with Security Policies.
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:
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.
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 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.
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).
The following sections describe the different techniques for securing URL (Web) and EJB (Enterprise JavaBean) resources in more detail:
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.
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.
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.
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:
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.
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:
-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.
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.
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: 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.
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:
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.
To change the values of the Check Roles and Policies and Future Redeploys settings:
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.
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:
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.
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:
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.
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.
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.
For instructions about how to deploy Web Application and EJB modules, see Deploying WebLogic Server Applications.
To verify the copied security policies, follow the instructions shown in the appropriate column of Table 2-2.
To verify the copied security policies, follow the instructions shown in the appropriate column of Table 2-3.
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.
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.
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.
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:
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.
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.
For instructions about how to deploy Web Application and EJB modules, see Deploying WebLogic Server Applications.
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.
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.
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.
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.
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:
For more information about WebLogic Web Services, see Programming WebLogic Web Services.