Chapter 25 Configuring Web Application Security

Configuring Web application security

This section describes how to configure security for your Web application from Jaguar Manager.

To access the security properties of your Web application:

Highlight the Web Applications or the Installed Web Applications folder.
Highlight the Web application for which you are establishing security.
Select File | Web Application Properties.
Select the Security tab from the Web Applications Property window.

You can now define the authentication method of your Web application and security constraints on the various elements within your Web application.

Authentication method

The types of Web application authentication methods available from the drop-down list include:

None - no authentication is required.
Basic - the server asks the client for its user name and password. You also provide a Realm name. The realm adds additional information to the client who is logging in to your site. For example, if you do not provide a realm name when a client visits your site, the browser displays a message to the client that states "The server at host:port wants you to log in". If you enter a realm name of "Human Resources Web site", the browser displays "The server at Human Resources Web site at host:port wants you to log in".
When an HTTP client sends the HTTP basic authentication header:
- The server authenticates the client using the server-defined authentication scheme and invokes any defined customized authentication component.
- If the request is intended for PowerDynamo, the server still authenticates the client, but the request is denied, and HTTP status code 401 (Unauthorized) is sent back to the client.
- If the authentication fails, the request fails and an error message is sent back to the client. If the request is intended for a Web application, then the Web application manages error handling.
- If the request is intended for a regular static page, the request is denied, and HTTP status code 401 (Unauthorized) is sent back to the client.
Form - the Web application developer creates an HTML login page, where the client enters a user name and password. The entire HTML page is sent to the server. You also create an error page that is returned to the client in the event of a server error.
- Login page - enter the location of the login page that is supplied to the client at login. For example, /login.jsp might be your login page.
- Error page - enter the location of the error page that the client is directed to should a server error occur during login. For example, /error.jsp might be your error page.
Login and error pages can vary from a very simple HTML page to a complex page that includes servlets and JSPs.
The location of the error and login pages is relative to the WebApp directory whether or not a "/" is used. For example, if you specify /error.jsp or error.jsp as the location of your error page, the servlet engine assumes that it is contained in the WebApp context.

Below is an example of a form login and error page. The action of the form login page must always be j_security_check. The username and password fields should be j_username and j_password respectively.

Form login page:
```
<html>
<body>
<h1>Login page</h1>

<form method="POST" action="j_security_check" >
<input type="text" name="j_username">
<input type="password" name="j_password">

<input type="submit" name="j_security_check">
</form>

</body>
</html>
```
Form error page:
```
<html>
<head>
<title>Login Error</title>
</head>
<body> Login error -- please try <a href="login.html">again</a>.
</body>
</html>
```
These examples assume that login.html is the login page, and that the error page and login page are in the same directory.
Client-cert - the client connects to the server using SSL tunneled within HTTP. The client must provide a certificate that the server accepts and authenticates. For more information about SSL, refer to the Jaguar CTS System Administration Guide.

Form login requirements in a Web application when using HTTPS (SSL)

To use the form login mechanism in your Web application, the client must support cookies. The client can be a browser or a standalone HTTP client. To convert your Web application, which uses the form login mechanism in conjunction with HTTPS, then the transport guarantee for the form login page and the pages that require authorization must be identical. Otherwise, the client will receive multiple HTTP redirects to the same page, resulting in an error.

Here are the steps required to enable HTTPS for the eStore application, which is a large, comprehensive sample application developed by Sun Microsystems to run on J2EE-compliant servers. eStore simulates an online pet store implemented with Java Server Pages, Java servlets, and Enterprise Java Beans. You can download eStore as part of the Sun Microsystems J2EE Blueprints

Change the transport guarantee for the existing two security constraints from None to Confidentiality or Integrity.
Add a new security constraint. Set the transport guarantee for the new security constraint to the same value as the existing two security constraints.
Add a Web resource collection to the new security constraint. Define a Web Resource, set the URL pattern to "/login.jsp", which is the URL of the form login page.
Refresh the eStore application. Connect to the eStore application from your browser. The form login and subsequent communication occurs using HTTPS.

Security constraints

Security constraints enable you to set various levels of security within the elements of your Web application. You create J2EE roles and map them to Jaguar roles, then limit access to JSPs, servlets, and HTML pages to entities that belong to an authorized J2EE role. In addition, you can define which HTTP methods have access to which URLs, and establish levels of transport guarantee.

For example, you could create a security constraint that blocks access to all users at the Web application level. You could then grant access to resources (HTML pages, JSPs, servlets) within the Web application to authorized users. To do this, you need at least two security constraints:

Create a top-level security constraint and assign to it a Web resource collection with an urlpattern set to "/*".
Establish an authorized role for the security constraint that contains no users. For example, you could create the role of "None" and assign it to the security constraint.
Create another security constraint and assign to it a Web resource collection with a urlpattern set to the URL locations for which you are providing access.
Establish an authorized role that contains the users that are allowed access to the Web resources protected by this security constraint.
Create additional security constraints and allow access to other Web resources as needed.

Use this same approach to define security constraints that require specific levels of transport guarantee.

To define a security constraint from the Web Application Properties Security tab:

Create a security constraint - click Add to create a security constraint. Security constraints are automatically named SC0, SC1, and so on.

To delete a security constraint, highlight the constraint and click Delete.
Define a Web resource collection - Web resource collections contain a list of URL patterns and HTTP methods available for those URLs. To define a Web resource collection:
1. Highlight the security constraint to which the Web resource collection belongs, and click Edit.
2. Click Add to create a collection name. Provide a description.
3. Highlight the collection to which you are adding the Web resources you are protecting.
4. Add a URL pattern to be protected by clicking Add in the URL Patterns window.
5. Double-click "urlPattern" and enter the URL to be protected. Add additional URL patterns for this collection by repeating this step.
  The URL pattern can have two forms:
  - /url_name - specifies an individual URL.
  - /url_location/* - specifies all of the URLs located in the url_location directory.
6. Select the HTTP operations that are allowed access to the defined URL patterns. HTTP operations include:
  - GET - the most common method used by browsers. GET receives its input through a query string.
  - POST - similar to a GET except that the input data is sent through standard input instead of using the query string. The POST method is normally used for an HTML form.
  - PUT - same as POST except PUT usually implies that the operation take effect immediately whereas POSTs action may be delayed.
  - OPTIONS - determines what HTTP options are supported.
  - DELETE - removes some entity.
  - TRACE - causes a response with a message containing all of the headers sent in the trace request.
Establish authorized roles - define the authorized roles that have access to the HTTP methods for the URLs defined for this security constraint. Before establishing an authorized role, you must map Jaguar roles to J2EE roles. See "Role mapping" for more information. To assign an authorized role to a security constraint:
1. Highlight the security constraint to which you are adding authorized roles.
2. Click the Authorized Roles Edit button.
3. A list of mapped Jaguar roles displays. Click the check box for the roles that have permission for the Web resources protected by this security constraint.
There are no role restrictions on the corresponding Web resources if there are no authorized roles assigned to a security constraint.
Transport guarantee - establish a level of transport security for each security constraint appropriate for the Web resources you are protecting. If you use basic or form-based authentication, passwords and other sensitive information is not protected for confidentiality. If you have sensitive information that you want to protect, establish a security constraint that uses a greater level of protection. Supported transport guarantee levels are:
- None - uses insecure HTTP. Using SSL-protected sessions has more overhead than insecure HTTP sessions. Use None for transport guarantee if you do not need the added confidentiality of SSL.
- Integral - uses an SSL-protected session that checks for data integrity.
- Confidential - uses an SSL-protected session to ensure that all message content, including the client authenticators, are protected for confidentiality as well as data integrity. A Confidential transport guarantee has more overhead than None.

Role mapping

This section describes how to map Jaguar roles to J2EE roles. Members of J2EE roles can be granted permission to access Web resources protected by security constraints.

To map a Jaguar role to a J2EE role:

Select the Role Mapping tab from the Web application properties window.
Click Add. Double-click the J2EE role and enter a name. You can also enter a description for the role in the provided field.
Select a Jaguar role from the drop-down list. This is the role from which the J2EE role inherits its permissions and members.

See the Jaguar System Administration Guide for more information about Jaguar roles.