8.5. Using Programmatic Security with SSL

SSL can be used with security that is entirely servlet managed, just as it can be with container-managed security (see Section 7.1). As is typical with servlet-managed security, this approach is more portable but requires significantly more effort.

The use of SSL in programmatic security may require one or more of the following capabilities not needed in normal programmatic security.

• Determining if SSL is in use.

• Redirecting non-SSL requests.

• Discovering the number of bits in the key.

• Looking up the encryption algorithm.

• Accessing client X509 certificates.

Details on these capabilities follow.

Determining If SSL Is in Use

The ServletRequest interface provides two methods that let you find out if SSL is in use. The getScheme method returns "http" for regular requests and "https" for SSL requests. The isSecure method returns false for regular requests and true for SSL requests.

Redirecting Non-SSL Requests

With container-managed security, you can use the transport-guarantee subelement of user-data-constraint to ensure that the server redirects regular (http) requests to the SSL (https) equivalent. See Section 7.1 for details.

In programmatic security, you might want to explicitly do what the server automatically does with container-managed security. Once you have a URL, redirection is straightforward: use response.sendRedirect (Section 2.7).

The difficulty is in generating the URL in the first place. Unfortunately, there is no built-in method that says “give me the complete incoming URL with http changed to https.” So, you have to call request.getRequestURL to get the main URL, change http to https manually, then tack on any form data by using request.getQueryString. You pass that result to response.sendRedirect.

Even this tedious manual approach runs some portability risks. For example: what if the server is running SSL on a port other than 443 (the default SSL port)? In such a case, the approach outlined here redirects to the wrong port. Unfortunately, there is no general solution to this problem; you simply have to know something about how the server is configured in order to redirect to a nonstandard SSL port. However, since you have to know that the server supports SSL in the first place, this additional burden is not too onerous.

Discovering the Number of Bits in the Key

Suppose that you have a servlet or JSP page that lets authorized users access your company’s financial records. You might want to ensure that the most sensitive data is only sent to users that have the strongest (128-bit) level of encryption. Users whose browsers use comparatively weak 40-bit keys should be denied access. To accomplish this task, you need to be able to discover the level of encryption being used.

In version 2.3 of the servlet API, SSL requests automatically result in an attribute named javax.servlet.request.key_size being placed in the request object. You can access it by calling request.getAttribute with the specified name. The value is an Integer that tells you the length of the encryption key. However, since the return type of getAttribute is Object, you have to perform a typecast to Integer. In version 2.2 and earlier, there was no portable way to determine the key size. So, be sure to check if the result is null in order to handle non-SSL requests and SSL requests in servers compatible only with version 2.2 of the servlet API. Here is a simple example.

String keyAttribute = "javax.servlet.request.key_size"; 
Integer keySize = 
  (Integer)request.getAttribute(keyAttribute); 
if (keySize == null) { ... } 

Looking Up the Encryption Algorithm

In version 2.3 of the servlet API, SSL requests also result in an attribute named javax.servlet.request.cipher_suite being placed in the request object. You can access it by calling request.getAttribute with the specified name. The value is a String that describes the encryption algorithm being used. However, since the return type of getAttribute is Object, you have to perform a typecast to String. Be sure to check if the result is null in order to handle non-SSL requests and SSL requests in servers compatible only with version 2.2 of the servlet API. Here is a simple example.

String cipherAttribute = "javax.servlet.request.cipher_suite"; 
String cipherSuite = 
  (String)request.getAttribute(cipherAttribute); 
if (cipherSuite == null) { ... } 

Accessing Client X509 Certificates

Rather than using a simple username and password, some browsers permit users to authenticate themselves with X509 certificates. X509 certificates are discussed in RFC 1421. To retrieve RFCs, start at http://www.rfc-editor.org/ to get a current list of the RFC archive sites.

If the client authenticates himself with an X509 certificate, that certificate is available by means of the javax.servlet.request.X509Certificate attribute of the request object. This attribute is available in both version 2.2 and 2.3 of the servlet API. The value is an object of type java.security.cert.X509Certificate that contains exhaustive information about the certificate. However, since the return type of getAttribute is Object, you have to perform a typecast to X509Certificate. Be sure to check if the result is null in order to handle non-SSL requests and SSL requests that include no certificate. A simple example follows.

String certAttribute = "javax.servlet.request.X509Certificate"; 
X509Certificate certificate = 
  (X509Certificate)request.getAttribute(certAttribute); 
if (certificate == null) { ... } 

Once you have an X509 certificate, you can look up the issuer’s distinguished name, the serial number, the raw signature value, the public key, and a number of other pieces of information. For details, see http://java.sun.com/j2se/1.3/docs/api/java/security/cert/X509Certificate.html.