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.
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.)
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.
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.
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.