Sun ONE logo      Previous      Contents      Index      Next     

Sun ONE Application Server 7 Developer's Guide to Web Applications

Chapter 5
Securing Web Applications

This chapter describes how to write a secure web application for the Sun ONE Application Server with components that perform user authentication and access authorization.

This chapter contains the following sections:

User Authentication by Servlets

The web-based login mechanisms required by the J2EE Specification, v1.3 are supported by the Sun ONE Application Server. These mechanisms include:

The login-config element in the web.xml deployment descriptor file describes the authentication method used, the application’s realm name displayed by the HTTP basic authentication, and the form login mechanism’s attributes.

The login-config element syntax is as follows:

<!ELEMENT login-config (auth-method?,realm-name?,form-login-config?)>


The auth-method subelement of login-config is officially optional, but if it is not included, the server defaults to HTTP Basic Authentication, which is not very secure.

For more information regarding web.xml elements, see Chapter 13, “Deployment Descriptor,” of the Java Servlet Specification, v2.3.

For more information regarding sun-web.xml elements, see Chapter 6, "Assembling and Deploying Web Modules".

For information about programmatic login, see the Sun ONE Application Server Developer’s Guide.

HTTP Basic Authentication

HTTP basic authentication (RFC2068) is supported by the Sun ONE Application Server. Because passwords are sent with base64 encoding, this authentication type is not very secure. Use of SSL or another equivalent transport encryption is recommended to protect the password during transmission.

SSL Mutual Authentication

Secure Socket Layer (SSL) 3.0 and the means to perform mutual (client/server) certificate-based authentication is a J2EE Specification, v1.3 requirement. This security mechanism provides user authentication using HTTPS (HTTP over SSL).

The Sun ONE Application Server SSL mutual authentication mechanism (also known as HTTPS authentication) supports the following cipher suites:


Form-Based Login

The login screen’s look and feel cannot be controlled with the HTTP browser’s built-in mechanisms. J2EE introduces the ability to package a standard HTML or Servlet/JSP based form for logging in. The login form is associated with a web protection domain (an HTTP realm) and is used to authenticate previously unauthenticated users.

Because passwords are sent in the clear (unless protected by the underlying transport), this authentication type is not very secure.Use of SSL or another equivalent transport encryption is recommended to protect the password during transmission.

In order for the authentication to proceed appropriately, the login form action must always be j_security_check.

The following is an HTML sample showing how to program the form in an HTML page:

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

You can specify the parameter encoding for the form. For details, see "parameter-encoding".

User Authentication for Single Sign-on

The single sign-on across applications on the Sun ONE Application Server is supported by the Sun ONE Application Server servlets and JSPs. This feature allows multiple applications that require the same user sign-on information to share this information between them, rather than having the user sign-on separately for each application. These applications are created to authenticate the user one time, and when needed this authentication information is propagated to all other involved applications.

An example application using the single sign-on scenario could be a consolidated airline booking service that searches all airlines and provides links to different airline web sites. Once the user signs on to the consolidated booking service, the user information can be used by each individual airline site without requiring another sign-on.

Single sign-on operates according to the following rules:

The single sign-on feature utilizes HTTP cookies to transmit a token that associates each request with the saved user identity, so it can only be used in client environments that support cookies.

To configure single sign-on, set the following properties in the virtual-server element of the server.xml file:

Here is an example configuration with all default values:

<virtual-server id="server1" ... >
  <property name="sso-enabled" value="true"/>
  <property name="sso-max-inactive-seconds" value="300"/>
  <property name="sso-reap-interval-seconds" value="60"/>

User Authorization by Servlets

Servlets can be configured to only permit access to users with the appropriate authorization level. This section covers the following topics:

Defining Roles

You define roles in the J2EE deployment descriptor file, web.xml, and the corresponding role mappings in the Sun ONE Application Server deployment descriptor file, sun-application.xml (or sun-web.xml for individually deployed web modules). For more information about sun-web.xml, see Chapter 6, "Assembling and Deploying Web Modules".

Each security-role-mapping element in the sun-application.xml or sun-web.xml file maps a role name permitted by the web application to principals and groups. For example, a sun-web.xml file for an individually deployed web module might contain the following:


Note that the role-name in this example must match the role-name in the security-role element of the corresponding web.xml file.

Note that for J2EE applications (EAR files), all security role mappings for the application modules must be specified in the sun-application.xml file. For individually deployed web modules, the roles are always specified in the sun-web.xml file. A role can be mapped to either specific principals or to groups (or both). The principal or group names used must be valid principals or groups in the current default realm.

Defining Servlet Authorization Constraints

On the servlet level, you define access permissions using the auth-constraint element of the web.xml file.

The auth-constraint element on the resource collection must be used to indicate the user roles permitted to the resource collection. Refer to the Servlet specification for details on configuring servlet authorization constraints.

Fetching the Client Certificate

When you enable SSL and require client certificate authorization, your servlets have access to the client certificate as shown in the following example:

if (request.isSecure()) {[] certs;
  certs = request.getAttribute("javax.servlet.request.X509Certificate");
  if (certs != null) {
    clientCert = certs[0];
    if (clientCert != null) {
      // Get the Distinguised Name for the user. userDN = clientCert.getSubjectDN();

The userDn is the fully qualified Distinguished Name for the user.

Security for SHTML and CGI

For security, server-parsed HTML tags and CGI scripts depend on the server’s security configuration. The following J2EE-only security features are not available for server-parsed HTML tags and CGI scripts:

For more information about the server’s security configuration, see the Sun ONE Application Server Administrator's Guide to Security.

Previous      Contents      Index      Next     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.