Securing WebLogic Resources
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The J2EE platform already provides a standard model for securing Web applications and EJBs. In this standard model, you define role mappings and policies in the Web application or EJB deployment descriptors.
Because this J2EE standard can be too inflexible for some environments, WebLogic Server offers a choice of other, more flexible models in addition to supporting the J2EE standard.
Note: If you are implementing security using JACC (Java Authorization Contract for Containers as defined in JSR 115), you must use the J2EE standard model. Other WebLogic Server models are not available and the security functions for Web applications and EJBs in the Administration Console are disabled. See Using the Java Authorization Contract for Containers in Programming WebLogic Security.
You choose a security model when you deploy each Web application or EJB, and your choice is immutable for the lifetime of the deployment. If you want to use a different model, you must delete and redeploy the Web application or EJB.
The following sections describe options for securing Web application and Enterprise Java Bean (EJB) resources:
Note: The instructions for EJB resources provided in this section also apply to Message-Driven Beans (MDBs).
Each security model defines two types of behaviors for securing Web applications and EJBs: where roles and policies are defined and which URL patterns and EJB methods trigger the Security Service to perform security checks. Table 4-1 compares the models.
The following sections describe each model and suggest scenarios under which each is appropriate.
This is the standard J2EE model and is therefore a widely known technique for adding declarative security to Web applications and EJBs. It uses only roles and policies defined by a developer in the J2EE deployment descriptor (DD) and the WebLogic Server DD. It requires the security administrator to verify that the security principals (groups or users) in the deployment descriptors exist and are mapped properly in the security realm.
If a developer changes roles or policies in a deployment descriptor, WebLogic Server recognizes the change as soon as you redeploy the Web application or EJB.
This model is appropriate if developers and security administrators can closely coordinate their work, both upon initial deployment of the Web application or EJB and upon subsequent redeployments. Table 4-2 shows a typical scenario:
This security model uses policies defined in the J2EE DD and ignores any principal mappings in the WebLogic Server DD. The security administrator completes the role mappings using the Administration Console.
The model enables team members to focus on their areas of expertise. Web application and EJB developers need only to declare which URL patterns or EJB methods should be secured. Then the security administrator creates role mappings that fit within the existing hierarchy of roles and principals for a given realm.
If a developer changes policies in a deployment descriptor, WebLogic Server recognizes the change as soon as you redeploy the Web application or EJB. If an administrator changes role mappings, the changes take effect immediately without requiring a redeployment.
This model is appropriate if developers and administrators cannot closely coordinate their work or if role mappings change frequently. Table 4-3 shows a typical scenario:
This security model offers unified and dynamic security management. It uses roles and policies that a security administrator has created using the Administration Console and ignores any roles and policies defined in deployment descriptors.
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.
This model is appropriate if you require only that entire Web applications or EJBs be secured, but is less appropriate if you require fine-grained control of a large number of specific URL patterns or EJB methods. Such fine-grained control requires a developer to provide to administrators detailed information about the URL patterns or EJB methods that must be secured. If you require such fine-grained control, consider using the Custom Roles model (see Custom Roles Model).
The model also introduces a slight performance degradation because it checks permissions regardless of which URL a client requests or EJB method a client attempts to invoke.
Table 4-4 shows a typical scenario:
WebLogic Server provides this model primarily for backwards compatibility with releases prior to 9.0.
You can configure the following behaviors for this model (see Understanding the Combined Role Mapping Enabled Setting):
Warning: Importing security data introduces risks to the integrity of your security data. Each time you import the data, the Security Service attempts to remove all associated data from the provider databases and re-imports data from the deployment descriptors. If you modified the imported security data, then your modifications could become invalid or could be removed. If you import security data, follow the recommendations in Manage Security for Web Applications and EJBs in the Administration Console Help.
If you change the configuration of this model, the change applies to all Web applications and EJBs that use this model. For example, you configure the Advanced model to perform security checks for all URLs and methods, and then you deploy several EJBs and configure them to use the Advanced model. The EJB container will request a security check any time a client tries to invoke any method in any of the several EJBs. If you then modify the Advance model to perform security checks only for the EJB methods that are protected in deployment descriptors, then the EJB container immediately begins to request security checks only for protected methods for the several EJBs.
Note: This section applies only for those Web applications and EJBs that use the Advanced security model.
Three settings in the Administration Console configure the Advanced model: Check Roles and Policies, When Deploying Web Applications or EJBs, and Combined Role Mapping Enabled. Failure to understand these settings could result in incorrect or lost security data.
If you change the configuration of this model, the change applies to all Web applications and EJBs that use this model.
The following sections describe the settings for the Advanced security model:
The Check Roles and Policies setting determines whether the Security Service performs security checks for all URLs and EJB methods or only those that are protected in the deployment descriptors.
Set the value of Check Roles and Policies as follows:
Note: This selection is analogous to the Deployment Descriptor Only security model: the Security Service uses only roles and policies defined in a Web application or EJB's deployment descriptors.
Note: With this selection, you can also configure the When Deploying Web Applications or EJBs setting.
The When Deploying Web Applications or EJBs setting determines whether the Security Service ignores role and policy data in deployment descriptors or imports the data into role mapping and authorization provider databases each time you deploy a Web application or EJB.
Note: This setting is valid only if you have set Check Roles and Policies to All Web applications and EJBs.
Set the value of When Deploying Web Applications or EJBs as follows:
Warning: Importing security data introduces risks to the integrity of your security data. Each time you import security data, the Security Service attempts to remove all associated security data from the provider databases and re-imports data from the deployment descriptors. If you modified the imported security data, then your modifications could become invalid or could be removed. If you import security data, follow the recommended procedures in Manage Security for Web Applications and EJBs in the Administration Console Help.
Table 4-5 shows how to achieve the behavior you want from the WebLogic Security Service using different combinations of the Check Roles and Policies and When Deploying Web Applications and EJBs settings.
The Combined Role Mapping Enabled setting determines how the role mappings in the Enterprise Application, Web application, and EJB containers interact.
WebLogic Server provides this setting for backwards compatibility with 8.x versions. For all applications initially deployed in version 9.x, the default value for this setting is "true" (enabled). For all applications previously deployed in version 8.1 and upgraded to version 9.x, the default value is "false" (disabled). If either of the following is true, consider changing the default value for Combined Role Mapping Enabled:
Table 4-6 compares how this setting affects security for Web applications and EJBs:
The following examples show the differences in role mapping behaviors depending on whether Combined Role Mapping is enabled or disabled.
MyAppEar contains MyAppWAR which contains MyEJB. Role to Principal mappings (p1 and p2) are as follows:
When Combined Role Mapping is enabled, the role mappings would be:
When Combined Role Mapping is disabled, the role mappings would be
MyAppEar contains MyAppWAR. Role to Principal mappings are as follows:
When Combined Role Mapping is enabled, the role mappings would be:
The mapping is the same because of the combined role behavior.
When Combined Role Mapping is disabled, the role mappings would be
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.
You choose a security model when you deploy each Web application or EJB, and your choice is immutable for the lifetime of the deployment. If you want to use a different model, you must delete and redeploy the Web application or EJB.
For information on using the Administration Console to deploy applications, choose a security model, modify roles and polices, and complete other related tasks, see Manage Security for Web Applications and EJBs in the Administration Console Help.
If you plan to use deployment descriptors to secure Web applications or EJBs, see Using Declarative Security With Web Applications and Using Declarative Security With EJBs in Programming WebLogic Security.
![]() ![]() |
![]() |
![]() |