Skip navigation.
Downloads | Product Documentation | Support

Avitek Medical Records Development Tutorials

# Moving to Production

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

This tutorial describes how to secure URL (Web) resources using the Administration Console. It also provides procedures for creating security policies for URL (Web) resource hierarchies.

After you finish this tutorial, the security for the MedRec application running on the domain you created for these tutorials will be the same as the security configured for the out-of-the-box MedRec application and domain.

The tutorial includes:

- 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 Medrec enterprise application. See Tutorial 15: Using WLST and the Administration Console to Deploy the MedRec Package for Production.
- Create the required users, groups, and global roles. See Tutorial 16: Creating Users, Groups, and Global Security Roles.

# Procedure

To secure URL (Web) resources by using the Administration Console:

- Step 1: Invoke the Administration Console in your browser.
- Step 2: Secure the patient Web Application of medrecEar.
- Step 3: Attempt to access the patient Web application.
- Step 4: Secure the admin Web Application of medrecEar.
- Step 5: Attempt to access the admin Web application.
- Step 6: Secure the physician Web Application of physicianEar.
- Step 7: Attempt to access the physician Web application.

## Step 1: Invoke the Administration Console in your browser.

1. With `MedRecServer` running, open the Administration Console by navigating in a browser to:

>     http://host:7101/console

where `host` refers to the computer on which MedRecServer is running. If your browser is on the same computer as MedRecServer, then you can use the URL `http://localhost:7101/console`.

2. Specify `weblogic` for both the username and password and click Log In.

## Step 2: Secure the patient Web Application of medrecEar.

1. In the left Domain Structure pane of the Administration Console, click MedRecDomain—>Deployments.
2. In the Deployments table in the left pane, expand `medrecEar`.
3. Under the Modules category, click the `patient` Web application module.
4. Select the Security—>Policies tab.
5. Click New.

An assistant appears that enables you to create a security policy for this particular Web Application or a particular component within the Web Application.

6. In the Create a New Policy URL Pattern page, enter `*.do` in the URL Pattern field.

The URL pattern of `*.do` will secure all components that have a `.do` suffix.

7. Do not change the default value of the Provider Name field.
8. Click Finish.
9. In the Web Application Module URL Patterns table, click `*.do`.
10. In the Policy Conditions section, click Add Conditions.
11. In the Predicate List drop-down list, select `Role`.
12. Click Next.
13. In the Role Argument Name field, enter `MedRecPatient`.

This policy specifies that only users with the `MedRecPatient` role are allowed to access these components.

14. Click Add.
15. Click Finish.
16. Click Save.

The Policy Conditions section includes the entry `Role MedRecPatient`.

The Overwritten Policy section includes the entry `Group everyone`.

17. Repeat steps 1 - 16 to specify that only the `MedRecPatient` role can access URL resources with the suffix `*.jsp`.

The Policy Conditions section includes the entry `Role MedRecPatient`.

The Overwritten Policy section includes the entry `Group everyone`.

18. Repeat steps 1 - 16 to specify that the `Anonymous` role can access the specific URL resource called `login.do`.

The Policy Conditions section includes the entry `Role Anonymous`.

The Overwritten Policy section includes the entry `Role MedRecPatient`.

The `Anonymous` role, unlike `MedRecPatient`, is a default global role that is predefined in WebLogic Server. This step overrides the security policy you previously defined for all `*.do` URL resources so that every user, regardless of their role, is allowed to view the `login.do` page.

19. Repeat steps 1 - 16 to specify that the `Anonymous` role can access the specific URL resource called `error.do`.

The Policy Conditions section includes the entry `Role Anonymous`.

The Overwritten Policy section includes the entry `Role MedRecPatient`.

20. Repeat steps 1 - 16 to specify that the `Anonymous` role can access the specific URL resource called `register.do`.

The Policy Conditions section includes the entry `Role Anonymous`.

The Overwritten Policy section includes the entry `Role MedRecPatient`.

21. When you are finished, the Web Application Module URL Patterns table for the `patient` Web application should include the following URL Pattern entries:

- `*.do`
- `*.jsp`
- `/error.do`
- `/login.do`
- `/register.do`

## Step 3: Attempt to access the patient Web application.

1. Open a new Web browser and type the following URL:

>     http://host:7101/patient

where `host` refers to the computer hosting `MedRecServer`. If your browser is on the same computer, then you can use the URL `http://localhost:7101/patient`.

The browser prompts you for a username and password.

2. In the username field, type `mary@md.com`, and in the password field, type `weblogic`, then click Login.

The login page returns the error `Invalid User Name and/or Password` and re-prompts you for a username and password. (If this is the first time you use the browser to navigate to this screen, it might also request information about the digital certificate being used by the application.)

3. In the username field, type `larry@bball.com`, and in the password field, type `weblogic`, then click Login.

The browser displays information for the `larry@bball.com` patient, whose full name is Larry Parrot.

User `mary@md.com` was denied access because you created a security policy for the `patient` Web Application based on the global security role `MedRecPatient`, which user `larry@bball.com` is granted but user `mary@md.com` is not.

## Step 4: Secure the admin Web Application of medrecEar.

1. In the left Domain Structure pane of the Administration Console, click MedRecDomain—>Deployments.
2. In the Deployments table in the left pane, expand `medrecEar`.
3. Under the Modules category, click the `admin` Web application module.
4. Select the Security—>Policies tab.
5. Click New.

An assistant enables you to create a security policy for this particular Web Application or a particular component within the Web Application.

6. In the Create a New Policy URL Pattern page, enter `*.do` in the URL Pattern field.

The URL pattern of `*.do` will secure all components that have a `.do` suffix.

7. Do not change the default value of the Provider Name field.
8. Click Finish.
9. In the Web Application Module URL Patterns table, click `*.do`.
10. In the Policy Conditions section, click Add Conditions.
11. In the Predicate List drop-down list, select `Role`.
12. Click Next.
13. In the Role Argument Name field, enter `MedRecAdmin`.

This policy specifies that only users with the `MedRecAdmin` role are allowed to access these components.

14. Click Add.
15. Click Finish.
16. Click Save.

The Policy Conditions section includes the entry `Role MedRecAdmin`.

The Overwritten Policy section includes the entry `Group everyone`.

17. Repeat steps 1 - 16 to specify that only the `MedRecAdmin` role can access URL resources with the suffix `*.jsp`.

The Policy Conditions section includes the entry `Role MedRecAdmin`.

The Overwritten Policy section includes the entry `Group everyone`.

18. Repeat steps 1 - 16 to specify that the `Anonymous` role can access the specific URL resource called `login.do`.

The Policy Conditions section includes the entry `Role Anonymous`.

The Overwritten Policy section includes the entry `Role MedRecAdmin`.

The `Anonymous` role, unlike `MedRecAdmin`, is a default global role that is predefined in WebLogic Server. This step overrides the security policy you previously defined for all `*.do` URL resources so that every user, regardless of their role, is allowed to view the `login.do` page.

19. Repeat steps 1 - 16 to specify that the `Anonymous` role can access the specific URL resource called `error.do`.

The Policy Conditions section includes the entry `Role Anonymous`.

The Overwritten Policy section includes the entry `Role MedRecAdmin`.

20. When you are finished, the Web Application Module URL Patterns table for the `admin` Web application should include the following URL pattern entries:

- `*.do`
- `*.jsp`
- `/error.do`
- `/login.do`

## Step 5: Attempt to access the admin Web application.

1. Open a new Web browser and type the following URL:

>     http://host:7101/admin

where `host` refers to the computer hosting `MedRecServer`. If your browser is on the same computer, then you can use the URL `http://localhost:7101/admin`.

The browser prompts you for a username and password.

2. In the username field, type `mary@md.com`, and in the password field, type `weblogic`, then click Login.

The login page returns the error `Invalid User Name and/or Password` and re-prompts you for a username and password. (If this is the first time you use the browser to navigate to this screen, it might also request information about the digital certificate being used by the application.)

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

The browser displays a list of administration tasks.

User `mary@md.com` was denied access because you created a security policy for the `admin` Web Application based on the global security role `MedRecAdmin`, which user `admin@avitek.com` is granted but user `mary@md.com` is not.

## Step 6: Secure the physician Web Application of physicianEar.

1. In the left Domain Structure pane of the Administration Console, click MedRecDomain—>Deployments.
2. In the Deployments table in the left pane, expand `physicianEar`.
3. Under the Modules category, click the `physician` Web application module.
4. Select the Security—>Policies tab.
5. Click New.

An assistant enables you to create a security policy for this particular Web Application or a particular component within the Web Application.

6. In the Create a New Policy URL Pattern page, enter `*.do` in the URL Pattern field.

The URL pattern of `*.do` will secure all components that have a `.do` suffix.

7. Do not change the default value of the Provider Name field.
8. Click Finish.
9. In the Web Application Module URL Patterns table, click `*.do`.
10. In the Policy Conditions section, click Add Condition.
11. In the Predicate List drop-down list, select `Role`.
12. Click Next.
13. In the Role Argument Name field, enter `MedRecPhysician`.

This policy specifies that only users with the `MedRecPhysician` role are allowed to access these components.

14. Click Add.
15. Click Finish.
16. Click Save.

The Policy Conditions section includes the entry `Role MedRecPhysician`.

The Overwritten Policy section includes the entry `Group everyone`.

17. Repeat steps 1 - 16 to specify that only the `MedRecPhysician` role can access URL resources with the suffix `*.jsp`.

The Policy Conditions section includes the entry `Role MedRecPhysician`.

The Overwritten Policy section includes the entry `Group everyone`.

18. Repeat steps 1 - 16 to specify that the `Anonymous` role can access the specific URL resource called `login.do`.

The Policy Conditions section includes the entry `Role Anonymous`.

The Overwritten Policy section includes the entry `Role MedRecPhysician`.

The `Anonymous` role, unlike `MedRecPhysician`, is a default global role that is predefined in WebLogic Server. This step overrides the security policy you previously defined for all `*.do` URL resources so that every user, regardless of their role, is allowed to view the `login.do` page.

19. Repeat steps 1 - 16 to specify that the `Anonymous` role can access the specific URL resource called `error.do`.

The Policy Conditions section includes the entry `Role Anonymous`.

The Overwritten Policy section includes the entry `Role MedRecPhysician`.

20. When you are finished, the Web Application Module URL Patterns table for the `physician` Web application should include the following URL pattern entries:

- `*.do`
- `*.jsp`
- `/error.do`
- `/login.do`

## Step 7: Attempt to access the physician Web application.

1. Open a new Web browser and type the following URL:

>     http://host:7101/physician

where `host` refers to the computer hosting `MedRecServer`. If your browser is on the same computer, then you can use the URL `http://localhost:7101/physician`.

The browser prompts you for a username and password.

2. In the username field, type `larry@bball.com`, and in the password field, type `weblogic`, then click Login.

The browser returns an error.

3. Navigate to the `http://host:7101/physician` page again, and this time enter `mary@md.com` in the username field and `weblogic` in the password field, then click Login.

The browser displays a search page to look up patient information.

User `larry@bball.com` was denied access because you created a security policy for the `physician` Web Application based on the global security role `MedRecPhysician`, which user `mary@md.com` is granted but user `larry@bball.com` is not.

# Best Practices

- Create policy statements based on your organization's established business procedures.
- When creating new security policies, look for policy statements in the Overwritten Policy 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 resource (`login.do`) in a Web application overrides a security policy on a group of resources (`*.do`). 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).
- Make sure 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.
- Make 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 various URL (Web) resources using the same security as that of the out-of-the-box MedRec application.

# Related Reading

- Types of WebLogic Resources
- Techniques for Securing URL (Web) and EJB Resources
- Prerequisites for Securing URL (Web) and EJB Resources
- Tutorial 16: Creating Users, Groups, and Global Security Roles
- Tutorial 18: Using the Administration Console to Secure Enterprise JavaBean (EJB) Resources