Moving to Production Mode

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 tutorial includes the following sections:

- Prerequisites
- Procedure
- Best Practices
- The Big Picture
- Related Reading

Prerequisites

Before starting this tutorial:

- Create MedRecDomain and MedRecServer, and start MedRecServer. See Tutorial 1: Creating a WebLogic Domain and Server Instance for Development.
- Deploy the Enterprise Application named MedRecEar. See Tutorial 15: Deploying the MedRec Package for Production.
- If you did not complete Tutorial 17: Securing Application and URL (Web) Resources Using the Administration Console, create the users and groups described in Step 2: Create groups. and Step 3: Create users and add the users to groups. sections of that tutorial.
- Read the following sections in Securing WebLogic Resources:

- Types of WebLogic Resources

- Techniques for Securing URL (Web) and EJB Resources

- Prerequisites for Securing URL (Web) and EJB Resources

- Types of Security Roles: Global Roles and Scoped Roles

Procedure

Follow these steps to secure Enterprise JavaBean (EJB) resources using the Administration Console:

- Step 1: Specify security realm settings.
- Step 2: Create scoped roles and grant the scoped roles to groups.
- Step 3: Secure the SessionEJB JAR.
- Step 4: Attempt to access an EJB in the SessionEJB JAR.
- Step 5: Secure the AdminSessionEJB.
- Step 6: Attempt to access AdminSessionEJB.
- Step 7: Secure the findNewUsers() EJB method.
- Step 8: Attempt to access the findNewUsers() EJB method.

Step 1: Specify security realm settings.

Note: If you completed this step as part of Tutorial 17: Securing Application and URL (Web) Resources Using the Administration Console, you can skip to Step 2: Create scoped roles and grant the scoped roles to groups..

1. Start a Web browser and type http://localhost:7101/console/.

2. Enter weblogic as the username and weblogic as the password, then click Sign In to sign in to the Administration Console for the MedRecServer.

3. In the navigation tree at the left side of the Administration Console, expand Security->Realms.

4. Click the myrealm security realm.

5. On the General tab, from the Check Roles and Policies drop-down menu, select All Web Applications and EJBs.

   This setting causes the WebLogic Security Service to perform security checks on all URL (Web) and EJB resources. For more information, see Understanding How to Check Security Roles and Security Policies in Securing WebLogic Resources.

6. From the Future Redeploys drop-down menu, select Ignore Roles and Polices From DD.

   This setting indicates that you will set security for Web application and EJB resources using the Administration Console, not deployment descriptors. For more information, see Understanding What to Do on Future Redeploys of the WebLogic Resource in Securing WebLogic Resources.

7. Click Apply to save your changes.

8. Restart MedRecServer. (For help, see Starting and Stopping Servers: Quick Reference in the Configuring and Managing WebLogic Server.)

Step 2: Create scoped roles and grant the scoped roles to groups.

1. In the navigation tree, expand Deployments->Applications->MedRecEar.

2. Right-click sessionEjbs.

3. From the menu, select Define Scoped Role to display the Scoped Roles page.

   This page displays all the scoped roles currently defined in the WebLogic Role Mapping provider's database.

   Selecting this option enables you to create a security role that is scoped to this particular EJB JAR. Thereafter, the scoped role can be used in a security policy for this EJB JAR.

4. Click the Configure a new Scoped Role link to display the Create Scoped Role page.

5. On the General tab, in the Name field, type MedRecSessionEJBPatient.

6. Click Apply to save your changes.

7. Select the Conditions tab.

8. In the Role Condition list box, highlight Caller is a Member of the Group.

9. Click Add to open the Groups window.

10. In the Enter Group Name field, type MedRecPatients.

    Note: You created the MedRecPatients group as part of Tutorial 17: Securing Application and URL (Web) Resources Using the Administration Console. Recall that user larry@celtics.com is the only user in this group.

11. Click Add, then click OK.

    The Groups window closes. The Role Statement list box reads:

    Caller is a Member of the Group

    MedRecPatients

12. Click Apply to save your changes.

13. In the navigation tree, click the + sign next to MedRecEAR, then right-click on sessionEjbs.

14. From the menu, select Define Policies and Roles for Individual Beans.

    A table listing all the EJBs that are in the JAR file appears.

    Note: Selecting this option allows you to create a scoped role for a particular EJB within an EJB JAR.

15. Click the [Define Scoped Roles] link for AdminSessionEJB.

16. Repeat steps 4 - 12 to create the scoped role named MedRecSessionEJBAdmin and grant this scoped role to the MedRecAdmins group.

Step 3: Secure the SessionEJB JAR.

1. In the navigation tree, right-click sessionEjbs.

2. From the menu, select Define Security Policy to display the Policy Editor page.

   Selecting this option indicates that you are creating a security policy at the EJB JAR level, which includes all EJBs within the JAR, and all methods within those EJBs.

3. In the Policy Condition list box, highlight Caller is Granted the Role.

4. Click Add to open the Roles window.

5. In the Enter Role Name field, type MedRecSessionEJBPatient.

6. Click Add, then click OK.

   The Roles window closes. The Policy Statement list box reads:

   Caller is Granted the Role

   MedRecSessionEJBPatient

   By defining this security policy for the SessionEJB JAR, you are overriding any security policies that have already been defined for the EJB resource type. If you completed Tutorial 17: Securing Application and URL (Web) Resources Using the Administration Console, you are overriding the inherited policy statement:

   >     Caller is Granted the Role

   >           MedRecAdmin

   that is shown in the Inherited Policy Statements list box. Otherwise, you will be overriding the default security policy:

   >     Caller is a Member of the Group

   >           Everyone

   For more information about default security policies, see Default Security Policies in Securing WebLogic Resources.

7. Click Apply to save your changes.

Step 4: Attempt to access an EJB in the SessionEJB JAR.

1. Open a new Web browser and type http://localhost:7101/admin/login.do.

   The browser displays the login page shown in Figure 1.

   Figure 1: Admin Login Page

2. In the username field, type admin@avitek.com, and in the password field, type weblogic, then click Login.

   Figure 2: Administration Tasks Page

3. On the Administration Tasks page shown in Figure 2, click the View Pending Requests link.

   Figure 3: Error Page

   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.

Step 5: Secure the AdminSessionEJB.

1. In the navigation tree at the left side of the Administration Console, right-click sessionEjbs.

2. From the menu, select Define Policies and Roles for Individual Beans.

   A table listing all the EJBs that are in the JAR file appears.

   Selecting this option enables you to create a security policy at the EJB level (meaning the security policy will apply to all methods within the EJB), or a particular method within the EJB.

3. Click the [Define Security Policies] link for AdminSessionEJB to display the Policy Editor page.

4. In the Policy Condition list box, highlight Caller is Granted the Role.

   Note: Do not modify the value shown in the Methods drop-down menu. (It should read: ALL.)

5. Click Add to open the Roles window.

6. In the Enter Role Name field, type MedRecSessionEJBAdmin.

7. Click Add, then click OK.

   The Roles window closes. The Policy Statement list box reads:

   Caller is Granted the Role

   MedRecSessionEJBAdmin

   By defining this security policy for AdminSessionEJB, you are overriding the security policy that has already been defined for the EJB JAR in Step 3: Secure the SessionEJB JAR. Specifically, you are overriding the inherited policy statement of:

   Caller is Granted the Role

   MedRecSessionEJBPatient

   that is shown in the Inherited Policy Statements list box.

8. Click Apply to save your changes.

Step 6: Attempt to access AdminSessionEJB.

Repeat steps 1 - 3 in Step 4: Attempt to access an EJB in the SessionEJB JAR..

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.

Step 7: Secure the findNewUsers() EJB method.

1. In the navigation tree at the left side of the Administration Console, right-click sessionEjbs.

2. From the menu, select Define Policies and Roles for Individual Beans.

   A table listing all the EJBs that are in the JAR file appears.

   Selecting this option enables you to create a security policy at the EJB level (meaning the security policy will apply to all methods within the EJB), or for a particular method within the EJB.

3. Click the [Define Security Policies] link for AdminSessionEJB to display the Policy Editor page.

4. Using the Methods drop-down menu, select the findNewUsers() - REMOTE method.

5. In the Policy Condition list box, highlight Caller is Granted the Role.

6. Click Add to open the Roles window.

7. In the Enter Role Name field, type MedRecSessionEJBPatient.

   You defined this scoped role on SessionEJB, but because the findNewUsers() method is a component of AdminSessionEJB (itself a component of SessionEJB), you can also use it here.

8. Click Add, then click OK.

   The Roles window closes. The Policy Statement list box reads:

   Caller is Granted the Role

   MedRecSessionEJBPatient

   By defining this security policy on the findNewUsers() method, you are overriding the security policy that has already been defined for AdminSessionEJB in Step 5: Secure the AdminSessionEJB.. Specifically, you are overriding the inherited policy statement of:

   >     Caller is Granted the Role

   >           MedRecSessionEJBAdmin

   that is shown in the Policy Statement list box when ALL is selected from the Methods drop-down menu.

9. Click Apply to save your changes.

Step 8: Attempt to access the findNewUsers() EJB method.

Repeat steps 1 - 3 in Step 4: Attempt to access an EJB in the SessionEJB JAR..

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.

Related Reading

- Securing WebLogic Resources
- Tutorial 17: Securing Application and URL (Web) Resources Using the Administration Console
- Tutorial 19: Copying and Reinitializing Security Configurations