| Sun ONE Application Server 7 Developer's Guide to Web Applications |
Chapter 5
Securing Web ApplicationsThis 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 ServletsThe 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?)>
Note
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:
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHAForm-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">
</form>You can specify the parameter encoding for the form. For details, see "parameter-encoding".
User Authentication for Single Sign-onThe 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:
- Single sign-on applies to web applications configured for the same realm and virtual server. The realm is defined by the realm-name element in the web.xml file. For information about virtual servers, see the Sun ONE Application Server Administrator’s Guide or the Sun ONE Application Server Administrator’s Configuration File Reference.
- As long as users access only unprotected resources in any of the web applications on a virtual server, they are not challenged to authenticate themselves.
- As soon as a user accesses a protected resource in any web application associated with a virtual server, the user is challenged to authenticate himself or herself, using the login method defined for the web application currently being accessed.
- Once authenticated, the roles associated with this user are used for access control decisions across all associated web applications, without challenging the user to authenticate to each application individually.
- When the user logs out of one web application (for example, by invalidating or timing out the corresponding session if form based login is used), the user’s sessions in all web applications are invalidated. Any subsequent attempt to access a protected resource in any application requires the user to authenticate himself or herself again.
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:
- sso-enabled - If false, single sign-on is disabled for this virtual server, and users must authenticate separately to every application on the virtual server. The default is true.
- sso-max-inactive-seconds - Specifies the time after which a user’s single sign-on record becomes eligible for purging if no client activity is received. Since single sign-on applies across several applications on the same virtual server, access to any of the applications keeps the single sign-on record active. The default value is 5 minutes (300 seconds). Higher values provide longer single sign-on persistence for the users at the expense of more memory use on the server.
- sso-reap-interval-seconds - Specifies the interval between purges of expired single sign-on records. The default value is 60.
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"/>
</virtual-server>
User Authorization by ServletsServlets 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:
<sun-web-app>
<security-role-mapping>
<role-name>manager</role-name>
<principal-name>jgarcia</principal-name>
<principal-name>mwebster</principal-name>
<group-name>team-leads</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>administrator</role-name>
<principal-name>dsmith</principal-name>
</security-role-mapping>
</sun-web-app>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 CertificateWhen 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()) {
java.security.cert.X509Certificate[] certs;
certs = request.getAttribute("javax.servlet.request.X509Certificate");
if (certs != null) {
clientCert = certs[0];
if (clientCert != null) {
// Get the Distinguised Name for the user.
java.security.Principal userDN = clientCert.getSubjectDN();
...
}
}
}The userDn is the fully qualified Distinguished Name for the user.
Security for SHTML and CGIFor 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.
