Moving to Production Mode

Tutorial 17: Securing Application and URL (Web) Resources Using the Administration Console

This tutorial describes how to secure application and URL (Web) resources using the Administration Console. It includes step-by-step procedures for creating users, groups, and global security roles. It also provides procedures for creating security policies at various levels in the application and URL (Web) resource hierarchies.

The tutorial includes the following sections:

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.
Read the following sections in Securing WebLogic Resources:

Procedure

Follow these steps to secure application and URL (Web) resources using the Administration Console:

Step 1: Specify security realm settings.

Start a Web browser and type http://localhost:7101/console/.
Enter weblogic as the username and weblogic as the password, then click Sign In to sign in to the Administration Console for MedRecServer.
In the navigation tree at the left side of the Administration Console, expand Security->Realms.
Click the myrealm security realm.
On the General tab, from the Check Roles and Policies drop-down menu, select All Web Applications and EJBs.

This setting means that the WebLogic Security Service will 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.
From the On Future Redeploys drop-down menu, select Ignore Roles and Policies From DD.

This setting means that you will set security for Web Application and EJB resources in the Administration Console, not in deployment descriptors. For more information, see Understanding What to Do on Future Redeploys of the WebLogic Resource in Securing WebLogic Resources.
Click Apply to save your changes.
Restart MedRecServer. (See Starting and Stopping Servers: Quick Reference in Configuring and Managing WebLogic Server.)

Step 2: Create groups.

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

The Groups page displays all groups currently defined in the WebLogic Authentication provider's database.
Click the Configure a new Group link to display the Create Group page.
On the General tab, in the Name field, type MedRecAdmins.
In the Description field, type MedRecAdmins can log on to the MedRec Administrators website.
Click Apply to save your changes.
Repeat steps 4 - 7 to create a group named MedRecPatients, with a description of MedRecPatients can log on to the MedRec Patients website.
In the navigation tree, click Groups, and confirm that the groups have been added.

The Groups page shows the groups added to the WebLogic Authentication provider's database.

Step 3: Create users and add the users to groups.

In the navigation tree, click Users.

The Users page displays all users currently defined in the WebLogic Authentication provider's database.
Click the Configure a new User link to display the Create User page.
On the General tab, in the Name field, type admin@avitek.com.
In the Description field, type MedRec administrator.
In the Password and Confirm Password fields, type weblogic.
Click Apply to save your changes.
Select the Groups tab.
In the Possible Groups list box, highlight the MedRecAdmins group.
Click the highlighted arrow to move the MedRecAdmins group from the Possible Groups list box to the Current Groups list box.
Click Apply to save your changes.
Repeat steps 2 - 10 to create a user named larry@celtics.com, a MedRec patient who also uses the weblogic password and belongs in the MedRecPatients group.
In the navigation tree, click Users, and confirm that the users have been added.

The Users page shows the users added to the WebLogic Authentication provider's database.

Step 4: Create global roles and grant the global roles to the groups.

In the navigation tree, click Global Roles.

The Global Roles page displays all global roles currently defined in the WebLogic Role Mapping provider's database.
Click the Configure a new Global Role link to display the Create Global Role page.
On the General tab, in the Name field, type MedRecAdmin.
Click Apply to save your changes.
Select the Conditions tab.
In the Role Condition list box, highlight Caller is a Member of the Group.
Click Add to display the Groups window.
In the Enter Group Name field, type MedRecAdmins.
Click Add, then click OK.

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

Caller is a Member of the Group

MedRecAdmins
Click Apply to save your changes.
Repeat steps 2 - 11 to create a global role named MedRecPatient and to grant this global role to the MedRecPatients group.
In the navigation tree, click Global Roles, and confirm that the global roles have been added.

The Global Roles page shows the global roles added to the WebLogic Role Mapping provider's database.

Step 5: Secure the MedRecEAR application.

In the navigation tree, expand Deployments->Applications.
Right-click MedRecEAR.
From the menu, select Define Security Policy to display the Policy Editor page.

Selecting this option enables you to create a security policy that will encompass all components in the deployed Enterprise Application.
In the Policy Condition list box, highlight Caller is Granted the Role.
Click Add to display the Roles window.
In the Enter Role Name field, type MedRecAdmin.
Click Add, then click OK.

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

Caller is Granted the Role

MedRecAdmin
Click Apply to save your changes.

Step 6: Attempt to access a JSP in the MedRecEAR application.

Open a new Web browser and type http://localhost:7101/start.jsp.

The browser prompts you for a username and password.
In the username field, type larry@celtics.com, and in the password field, type weblogic, then click OK.

The browser re-prompts you for a username and password.
In the username field, type admin@avitek.com, and in the password field, type weblogic, then click OK.

The browser displays the page shown in Figure 1.

Figure 1: Avitek Medical Records Start Page

User larry@celtics.com was denied access because you previously secured all components of MedRecEAR (including start.jsp, part of MainWAR) with a security policy based on the global security role MedRecAdmin, which user admin@avitek.com is granted but user larry@celtics.com is not.

Step 7: Secure the Patient Web Application.

In the navigation tree at the left side of the Administration Console, expand Deployments->Applications->MedRecEAR, then right-click on the patient Web Application.
From the menu, select Define Security Policy to display the General tab.

Selecting this option enables you to create a security policy for this particular Web Application or a particular component within the Web Application.
In the URL Pattern field, type: /*

The URL pattern of /* will secure all components, including JSPs and servlets.
Click the Define Security Policy button to display the Policy Editor page.
In the Policy Condition list box, highlight Caller is Granted the Role.

Do not modify the value shown in the Methods drop-down menu. (It should read: ALL.)
Click Add to display the Roles window.
In the Enter Role Name field, type Anonymous.

Unlike the MedRecAdmin and MedRecPatient global roles you created and used in previous steps, the Anonymous role is a default global role that is predefined in WebLogic Server.
Click Add, then click OK.
The Roles window closes. The Policy Statement list box reads:

Caller is Granted the Role

Anonymous
By defining this security policy on PatientWAR, you are overriding the security policy that has already been defined for all components of the MedRecEAR in Step 5: Secure the MedRecEAR application.. Specifically, you are overriding the inherited policy statement of:
```
Caller is Granted the Role
```
```
      MedRecAdmin
```
that is shown in the Inherited Policy Statements list box.

By overriding the security policy to grant access to users in the Anonymous global role (rather than the MedRecAdmin global role), you are actually making access on these pages less restrictive. (All users are granted the Anonymous global role.)
Click Apply to save your changes.

Step 8: Attempt to access a JSP in the PatientWAR.

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

The browser displays the page shown in Figure 2: Figure 2: Patient Login Page

This page is displayed because you secured all components of PatientWAR with a security policy based on the global security role Anonymous, a security role that all users are granted. Therefore, no login is required to access the login.do page. (The user name and password fields are shown because of the login.do page's design.)

Step 9: Secure the medicalrecord.do page.

In the navigation tree at the left side of the Administration Console, right-click on the patient Web Application.
From the menu, select Define Security Policy to display the General tab.

Selecting this option enables you to create a security policy for this particular Web Application or a particular component within the Web application.

Notice that the URL pattern you typed in Step 7: Secure the Patient Web Application. appears as a link under the title: Already Defined URL Patterns. This allows you to modify existing security policies more easily.
In the URL Pattern field, type medicalrecord.do.

Because you are creating the security policy on PatientWAR, the context path of /patient is implied in the URL pattern. (WebLogic Server obtains this context path from the Web Application's deployment descriptor.)
Click the Define Security Policy button to display the Policy Editor page.
In the Policy Condition list box, highlight Caller is Granted the Role.

Do not modify the value shown in the Methods drop-down menu. (It should read ALL.)
Click Add to display the Roles window.
In the Enter Role Name field, type MedRecPatient.
Click Add, then click OK.
The Roles window closes. The Policy Statement list box reads:

Caller is Granted the Role

MedRecPatient
By defining this security policy on medicalrecord.do, you are overriding the security policy that has already been defined for all components within PatientWAR in Step 7: Secure the Patient Web Application.. Specifically, you are overriding the inherited policy statement of:
```
Caller is Granted the Role
```
```
      Anonymous
```
that is shown in the Inherited Policy Statements list box.
Click Apply to save your changes.

Step 10: Attempt to access the medicalrecord.do page.

Open a new Web browser and type http://localhost:7101/patient/medicalrecord.do.

The browser redirects you to the login page shown in Figure 2:. This result occurs because only users who are granted the MedRecPatient global role can access the medicalrecord.do page, but all users (who are granted the Anonymous global role) can still access login.do.
In the username field, type admin@avitek.com, and in the password field, type weblogic, then click Login.

The browser redisplays the login page shown in Figure 2: and indicates that you have entered an invalid username and/or password. This result occurs because only users who are granted the MedRecPatient global role can access the medicalrecord.do page, and user admin@avitek.com is granted the global role MedRecAdmin.
In the username field, type larry@celtics.com, and in the password field, type weblogic, then click Login.

The browser redirects you to Larry's Medical Records page, shown in Figure 3:. This result occurs because user larry@celtics.com is granted the MedRecPatient global role, which is required to access the medicalrecord.do page.

Figure 3: Larry's Medical Records Page

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.
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 a specific URL pattern in a Web application overrides a security policy on the Web application. 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).
Take care to ensure that you understand the security policies and the security role mappings on each URL pattern. If there are any URL patterns that you do not expect, be sure to investigate.
Be sure you understand the precedence of servlet mappings to URL patterns as specified in Chapter 11 of the Servlet 2.3 specification. This describes which URL pattern will have precedence when an URL matches multiple URL patterns.
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 URL (Web) 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 URL (Web) resources for both MedRec administrators and patients.