Securing WebLogic Resources

Options for Securing EJB and Web Application Resources

The following sections describe resource security configuration options for Enterprise Java Bean (EJB) and Web Application resources:

• Security Techniques and Security Models
• Choose a Security Technique
• Choose a Security Model
• Using the Advanced Security Model

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

 

---

Security Techniques and Security Models

Because the 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 Web application and EJB resources. You can use deployment descriptors exclusively, the Administration Console exclusively, or you can combine deployment descriptors and the console for certain situations. See Choose a Security Technique.

When you deploy your application, you select a security model based on the technique you want to use. WebLogic supports three different security models for individual deployments, and an Advanced security model for realm-wide configurations. See Choose a Security Model.

JAAC Security

If you are implementing security using JACC (Java authorization Contract for Containers) as defined in JSR 115) the security functions for Web applications and EJBs in the Administration Console are disabled. You must define security using deployment descriptors only. See Using Deployment Descriptors.

 

---

Choose a Security Technique

You can choose from among three techniques for securing Web application and EJB resources:

• Using the WebLogic Server Administration Console
• Using Deployment Descriptors
• Using the Administration Console and Deployment Descriptors

Using the WebLogic Server Administration Console

The primary benefit of using the Administration Console to secure Web application 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.

Using Deployment Descriptors

The primary benefit of securing your Web application 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.

Using the Administration Console and Deployment Descriptors

Some organizations currently using deployment descriptors to secure their Web application and EJB resources may want to take advantage of the unified security management capabilities that the WebLogic Server Administration Console provides. The Administration Console can copy security configurations from existing deployment descriptors upon deployment of a Web application or EJB module. Once these security configurations are copied into the Role Mapping and Authorization providers' databases, you use the Administration Console for subsequent updates to security roles and security policies.

 

---

Choose a Security Model

A security model depends on the security technique that you choose (see Choose a Security Technique). When you are ready to deploy an application you can choose from among several security models. If you are using the Deployment tool in the WebLogic Server Administration Console, the options appear as follows:

Figure 4-1 Administration Console: Security Section of the Deployment Assistant

The security model you choose applies for the lifetime of the deployment. To change a security model you need to delete the deployment and create a new one.

Note: You can set the default deployment security model using the Security Model realm setting. For more information, see Set the default security deployment model in Administration Console Online Help.

the following sections describe each model:

• Deployment Descriptors Only Model
• Customize Roles Model
• Customize Roles and Policies Model
• Security Realm Configuration (Advanced Model)

Deployment Descriptors Only Model

This model corresponds to the first Security option shown in Figure 4-1 above.

This security model uses only roles and policies defined by a developer in the J2EE deployment descriptor (DD) and the WebLogic Server DD. The administrator verifies that the security Principals (groups or users) are mapped properly. Table 4-1 shows a typical scenario:

Table 4-1 Deployment Descriptors Only: Typical Scenario

Company A, Developer	Company A, Admin/Deployer
Maps EJBs and/or Web URLs to roles in the J2EE DD. Maps roles to Principals in the WebLogic Server DD. Turns application over to the Admin/Deployer.	Uses the WebLogic Server Administration Console to ensure that groups exist and are properly mapped to users.

For more information, see the Using Declarative Security With Web Applications and Using Declarative Security With EJBs sections of Programming WebLogic Security.

If you select Deployment Descriptors Only, WebLogic Server uses combined role mapping by default. For more information, see Understanding the Combined Role Mapping Enabled Setting.

Customize Roles Model

This model corresponds to the second Security option shown in Figure 4-1 above.

This security model uses policies defined in the J2EE DD, and ignores any Principal mappings in the WebLogic Server DD. The administrator completes the role mappings using the Administration Console. Table 4-2 shows a typical scenario:

Table 4-2 Customize Roles Only: Typical Scenario

Company A, ISV Developer or Company B, Developer	Company B, Admin/Deployer
Maps EJBs/URLs to roles in J2EE deployment descriptor. Turns application over to Admin/Deployer	Uses the WebLogic Server Administration Console to define security roles.

For more information, see Create scoped security roles in Administration Console Online Help.

Customize Roles and Policies Model

This model corresponds to the third Security option shown in Figure 4-1 above.

This security model ignores any roles and policies defined in deployment descriptors The administrator uses the Administration Console to secure the resources.Table 4-3 shows a typical scenario:

Table 4-3 Customize roles and Policies: Typical Scenario

Company A, Developer	Company A, Admin/Deployer
Provides no mappings in the J2EE or WebLogic Server DD. Turns application over to Admin/Deployer	Uses the WebLogic Administration Console to define roles and policies for EJBs and Web applications.

For more information, see Create scoped security roles and Create security policies in Administration Console Online Help.

Security Realm Configuration (Advanced Model)

This model corresponds to the fourth Security option shown in Figure 4-1 above.

This security model lets you define a single security model for all deployments containing EJB and Web application resources in the security realm. With this model you can choose one of the following security techniques:

• All EBJ and Web application deployments will be secured using deployment descriptors only.
• All EBJ and Web application deployments will be secured using the Administration Console only.
• On the initial deployment, security roles and policies will be copied from the deployment descriptors, but the Administration Console will control security thereafter: The deployment descriptors will be ignored for subsequent deployments. (Combined technique).

Note: Prior to the current release of WebLogic Server, this was the only security model available. Select Advanced Security if you want to continue to secure EJBs and Web Applications as in the previous release.

If you choose the Advanced option you need to set the following realm security configurations after the initial deployment:

• Check Security Roles and Security Policies.
• On Future Redeploys

For details see Using the Advanced Security Model.

 

---

Using the Advanced Security Model

Note: This section applies only if you choose to control security for EJBs and Web Applications at the security realm level rather than for each deployment (Advanced security option).

Whether using the WebLogic Server Administration Console or deployment descriptors to secure your Web application 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 Web application or EJB resources using the Advanced security option, read the following sections:

• Understanding How to Check Security Roles and Security Policies
• Understanding the On Future Redeploys Setting
• How The Check Roles and Policies and On Future Redeploys Settings Interact
• How The Check Roles and Policies and On Future Redeploys Settings Interact
• Understanding the Combined Role Mapping Enabled Setting

Understanding How to Check Security Roles and Security Policies

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

Figure 4-2 Administration Console: Realms Settings for Advanced Security Model

• 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 Web application 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 Web application and EJB resources, regardless of whether there are any security settings in the deployment descriptors 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 the On Future Redeploys Setting.

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 control security on Web application and EJB resources using the fullyDelegateAuthorization flag, a command line argument that you set when you start WebLogic Server.

Note: This setting applies only when using the Advanced security model.

When the value of the fullyDelegateAuthorization flag is false, the WebLogic Security Service only performs security checks on Web application and EJB resources that have security specified in their associated deployment descriptors.

To set this flag, t 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.

Understanding the On Future Redeploys Setting

If you decide that the WebLogic Security Service should control security 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 Web application and EJB resources. (See Choose a Security Technique for more information.) Specify this preference in the Future Redeploys drop-down menu highlighted in Figure 4-2.

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

• To secure Web application and EJB resources using only the WebLogic Server Administration Console, select Ignore Roles and Policies From DD (Deployment Descriptors). At this point you can begin to use the Administration Console to secure the resources. see Create scoped security roles and Create security policies in Administration Console Online Help.
• To secure Web application 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 Using Declarative Security With Web Applications and Using Declarative Security With EJBs sections of Programming WebLogic Security, respectively.

Warning: Switching the value of the Future Redeploys setting is not advised because it 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), follow the instructions in Using the Combined Technique with the Advanced Security Model.

How The Check Roles and Policies and On Future Redeploys Settings Interact

Table 4-4 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 4-4 Interaction Between Check Roles and Policies Setting and On Future Redeploys Setting

If you want to control security for...	and set security for Web application and EJB resources...	then set Check Roles and Policies to...	and set On Future Redeploys to...
All Web application and EJB resources	using only the Administration Console	All Web applications and EJBs	Ignore Roles and Policies from DD
All Web application 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 resource is deployed, then use one of the other techniques to modify security roles and security policies Note: Security data is copied/reinitialized each time the Web application or EJB resource is deployed.	All Web applications and EJBs	Initialize Roles and Policies from DD
Only on Web applications and EJB methods that are specified in the deployment descriptors (default configuration)	using only the deployment descriptors	Web applications and EJBs Protected in DD	--

How to Modify Check Roles and Policies and On Future Redeploys Settings

Use the Administration Console to change this setting. For more information, see Revert the On Future Deploys setting in Administration Console Online Help.

Using the Combined Technique with the Advanced Security Model

As described Using the Administration Console and Deployment Descriptors, you can combine settings in the WebLogic Server Administration Console and J2EE/WebLogic deployment descriptors. You 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 resources. This process enables you to use the Administration Console for subsequent modifications to security roles and security policies.
• To reinitialize security configurations for Web application and EJB resources to their original state, as specified in the deployment descriptors.

Caution: Use of the combined technique for any other purposes is not recommended.

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

• Copying Security Configurations From a Deployment Descriptor
• Reinitializing Security Configurations

Copying Security Configurations From a Deployment Descriptor

These instructions are intended for administrators using the Advanced security model or upgrading from WebLogic server version 8.x who presently secure Web application and EJB 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—this is a step toward migrating to full security administration using the Administration Console.

Caution: When using the combined technique, it is possible to override security configurations for Web application and EJB resources. Therefore, take extra care to ensure that the appropriate security configuration is in place Web application and EJB resources.

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

• Step 1: Modify the Security Realms settings and deploy the resource.
• See Copy security configurations from a deployment descriptor in Administration Console Online Help.
• Step 2: Verify the Copied Security Policies (Optional)
• Step 3: Verify the Copied Security Roles (Optional)
• Step 4: Revert the On future Deploys setting.
• See Revert the On Future Deploys setting in Administration Console Online Help.
• Step 5: Modify security roles and policies using the administration Console.
• See Create scoped security roles and Create security policies in Administration Console Online Help

Step 2: Verify the Copied Security Policies (Optional)

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

Table 4-5 Verifying Copied Security Policies, Based on Resource Type 

Step	Web Application 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.
2	Using the Administration console to view the security policies and associated security roles for each resource. See Access policies for Web application resources in Administration Console Online Help.	Using the Administration console to view the security policies and associated security roles for each resource. See Access policies for EJB resources in Administration Console Online Help.

Step 3: Verify the Copied Security Roles (Optional)

To verify the copied security roles, follow the instructions shown in the appropriate column of Table 4-6.

Table 4-6 Verifying Copied Security Roles, Based on Resource Type 

Step	Web Application 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 Administration console to view the security roles for each resource. See Access roles for Web application resources in Administration Console Online Help.	Using the Administration console to view the security roles for each resource. See Access roles for EJB resources in Administration Console Online Help.

Reinitializing Security Configurations

To reinitialize security configurations for Web application and EJB resources to their original state as specified in their deployment descriptors, follow these steps:

• Step 1: Modify the Security Realms settings and deploy the resource.
• See Reinitialize security configurations from a deployment descriptor in Administration Console Online Help.
• Step 2: Verify the reinitialized security policies and security roles (Optional)
• Follow the instructions shown in the appropriate column of Table 4-5 and Table 4-6
• Step 3: Revert the On future Deploys setting.
• See Revert the On Future Deploys setting in Administration Console Online Help.
• Step 4: Modify security roles and policies using the Administration Console.
• See Create scoped security roles and Create security policies in Administration Console Online Help

Understanding the Combined Role Mapping Enabled Setting

The CombinedRoleMappingEnabled setting is provided for backward compatibility with the previous version (8.x) of WebLogic Server. For all applications initially deployed in version 9.x, the default value for this setting "true." (enabled). For all applications previously deployed in version 8.1 and upgraded to version 9.x, the default value is "false" (disabled).

The Combined Role Mapping Enabled setting determines how the role mappings in the Enterprise Application, Web application, and EJB containers interact. Table 4-7 shows a summary of the contrasting behaviors:

Table 4-7 Contrasting Behaviors For CombinedRoleMappingEnabled Flag

When CombinedRoleMapping is disabled...	When CombinedRoleMapping is enabled...
By default, role mappings for each container are exclusive to other containers, unless defined by the <externally-defined> descriptor element.	Application role mappings are combined with EJB and Web application mappings such that all principal mappings are included.
Unless a role mapping is defined in the Web application, the Web application container assumes any role mapping defined in web.xml.	The Web application container uses the base reference for roles in web.xml to create an empty role map.
Role mappings for EJBs must be defined in web.xml. Role mappings defined in the other containers are not used unless <externally-defined>	The EJB container uses the base reference for roles in web.xml to create an empty role map

Usage examples

The following examples show the differences in role mapping behaviors depending on whether CombinedRoleMappingEnabled is enabled or disabled.

Example for EAR, WAR and EJB

MyAppEar contains MyAppWAR which contains MyEJB. Role to Principal mappings (p1 and p2) are as follows:

• EAR descriptor, myRole = p1
• WAR descriptor, myRole = p2
• EJB-JAR descriptor, myRole = empty

When Combined Role Mapping is enabled, the role mappings would be:

• For the Ear container, myRole maps to p1.
• For the WAR container, myRole maps to p1 or p2.
• For the EJB container, myRole maps to p1.

When Combined Role Mapping is disabled, the role mappings would be

• For the Ear container, myRole maps to p1.
• For the WAR container, myRole maps to p2.
• For the EJB container: Must be externally-defined or the deployment fails.

Example for EAR and WAR

MyAppEar contains MyAppWAR. Role to Principal mappings are as follows:

• In MyAppEAR descriptor, myRole = p1
• In MyAppWAR descriptor, myRole = (none defined)

When Combined Role Mapping is enabled, the role mappings would be:

• For the Ear container, myRole maps to p1.
• For the WAR container, myRole maps to p1.

The mapping is the same because of the combined role behavior.

When Combined Role Mapping is disabled, the role mappings would be

• For the Ear container, myRole maps to p1.
• For the WAR container, myRole maps to MyRole.

The mapping is the same because if there is no mapping defined for the Web application, WebLogic Server copies the EAR mapping to the WAR mapping.

Changing the default setting

There are two reasons why you might want to change the default value for Combined Roles Enabled:

• You selected the Advanced security model for an 8.x application upgrade and want to use the combine role mapping behavior available in version 9.x.
• You selected the Advanced security model for a 9.x application and want to use the role mapping behavior in version 8.x.