Tutorial 18: Securing Enterprise JavaBean (EJB) Resources Using the Administration Console
This tutorial describes how to secure Enterprise JavaBean (EJB) resources using the Administration Console. It includes step-by-step procedures for creating scoped roles and security policies at various levels in the EJB resource hierarchy.
The error page shown in Figure 3 is displayed because access to the findNewUsers() method in AdminSessionEJB, an EJB within the SessionEJB JAR you previously secured, is needed to view pending requests. User admin@avitek.com is not granted the MedRecSessionEJBPatient scoped role that was used to create the security policy, and is therefore is not granted access.
Instead of displaying the error page for step 3, the browser displays the View Pending Requests page shown in Figure 4.
Figure 4: View Pending Requests
This result occurs because user admin@avitek.com is granted the MedRecEJBSessionAdmin scoped role. This scoped role was used to create the security policy for AdminSessionEJB, the EJB containing the findNewUsers() method that is needed to view pending requests.
The browser displays the error page shown in Figure 3. This result occurs because only users granted the scoped role MedRecSessionEJBPatient can access the findNewUsers() method, which is needed to view pending requests. User admin@avitek.com is not granted the scoped role that was used to create the security policy, and therefore is not granted access.
Best Practices
The security realm settings are extremely important. If you want to secure URL (Web) resources using the WebLogic Server Administration Console rather than deployment descriptors, you must use the Check Roles and Policies/On Future Redeploys combination specified in Step 1: Specify security realm settings..
If you have deployed an application (or module) with the On Future Redeploys drop-down menu set to Ignore Roles and Policies From DD one or more times before setting it to Initialize Roles and Policies From DD, you can still set security policies and security roles using the Administration Console. These changes will override any security specified in deployment descriptors.
Do not use blank spaces, commas, hyphens, or any characters in this comma-separated list for user, group, or security role names: \t, < >, #, |, &, ~, ?, ( ), { }. User, group, and security role names are case sensitive. The proper syntax for a security role name is as defined for an Nmtoken in the Extensible Markup Language (XML) recommendation. The BEA convention is that group names are plural, and security role names are singular.
It is inadvisable to create global roles and scoped roles with the same name. However, if you have a valid reason for doing this, know that the scoped role will override the global role if used in a Caller is Granted the Role policy condition.
Scoped roles can be used in security policies from the level in the hierarchy where they are defined and below.
BEA recommends assigning users to groups, then creating role statements using the Caller is a Member of the Group role condition. Individual users could also be granted a security role, but this is a less typical practice.
BEA recommends using security roles (rather than users or groups) to secure WebLogic resources. Following this process makes it more efficient for administrators who work with large numbers of users.
Create policy statements based on your organization's established business procedures.
When creating new security policies, look for policy statements in the Inherited Policy Statement box of the Policy Editor page. If inherited policy statements exist, you will be overriding them.
Remember that more-specific security policies override less-specific security policies. For example, a security policy on an EJB method overrides a security policy on the same EJB. Take care when overriding with less restrictive security policies (that is, giving a wider set of users access to a smaller set of components or WebLogic resources).
You can delete all security settings for an application (or module) by deleting it entirely from the WebLogic Server domain and then redeploying it.
The Big Picture
This tutorial shows you how to secure application and various Enterprise JavaBean (EJB) resources using some examples. These examples may or may not be different from those used in the full MedRec application. However, the full MedRec application uses these same principles (as well as programmatic security) to secure EJB resources for both MedRec administrators and patients.