How to configure the security of HTTP session and Single-Sign-On cookies in GlassFish

How to configure the security of HTTP session and Single-Sign-On cookies in GlassFish

How to configure the security of HTTP session and Single-Sign-On cookies in GlassFish

Overview

The javax.servlet.http.Cookie API allows servlets to mark application specific cookies as secure by calling setSecure. However, there is no programmtic support for marking container-generated cookies, such as HTTP session (aka JSESSIONID) and Single-Sign-On (aka JSESSIONIDSSO) related cookies, as secure. This blog explains how the security aspects of these types of cookies may be configured in the upcoming GlassFish v2.1 and GlassFish v3 Prelude releases.

Motivation

The syntax for cookies, as given by the cookie specification, defines a Secure attribute (with no value). This attribute serves as an indication by the server to the client that the cookie contents require protection.

The client may determine what level of security it considers appropriate for cookies marked as secure. In most cases, it will send a secure cookie back to the server only if the connection is protected with SSL.

By default, a JSESSIONID cookie inherits the security setting of the request that initiated the corresponding HTTP session: If the HTTP session has been initiated by an HTTPS request, the secure attribute of its JSESSIONID cookie will be set to true, and will remain false if the session was initiated by a plain HTTP request.

In some cases, it may be necessary to override this default behaviour. For example, if the GlassFish instance is front-ended by an SSL-offloading loadbalancer (as shown in the image below), all requests received by it will be of type HTTP, whereas the traffic between the client and the loadbalancer is over HTTPS. In this case, any JSESSIONID cookies created by the web container on the GlassFish instance must be marked as secure (even though the corresponding sessions were initiated by HTTP requests), so that their contents (in particular the session ids) will be protected as they travel between the client and the loadbalancer.

Security configuration of HTTP session cookies

The upcoming GlassFish v2.1 and GlassFish v3 Prelude releases add support for configuring a JSESSIONID cookie's secure attribute through a cookie property with name cookieSecure in sun-web.xml, as follows:

  <?xml version="1.0" encoding="UTF-8"?>
  <sun-web-app>
    <session-config>
      <cookie-properties>
        <b><property name="cookieSecure" value="[true|false|dynamic]"/></b>
      </cookie-properties>
    </session-config>
  </sun-web-app>

The semantics of the possible values of the cookieSecure property are as follows.

  • true: Any JSESSIONID cookies created by the container on behalf of the web application will be marked as secure.
  • false: Any JSESSIONID cookies created by the container on behalf of the web application will be marked as non-secure.
  • dynamic: A JSESSIONID cookie created by the container on behalf of the web application will inherit its security setting from the request that initiated the correspoding session: If the session was initiated by an HTTPS request, its JSESSIONID cookie will be marked as secure, and will remain non-secure otherwise. This is the default.

Notice that the next version of the Servlet Specification (Servlet 3.0) is going to provide programmatic configuration support (including security) for JSESSIONID cookies by defining a new javax.servlet.SessionCookieConfig class along with a new setSessionCookieConfig method on javax.servlet.ServletContext which takes an argument of type javax.servlet.SessionCookieConfig. The configuration options provided by javax.servlet.SessionCookieConfig will be equivalent to the cookie-properties in sun-web.xml (with the addition of configuration support for the httpOnly cookie property).

Security configuration of Single-Sign-On cookies

Based on a user request, GlassFish v3 Prelude adds support for configuring the security of JSESSIONIDSSO cookies used in the context of Single-Sign-On (SSO). Since multiple applications may participate in SSO, and since only applications deployed to the same virtual server and belonging to the same security realm may participate in SSO, exposing the configuration of a JSESSIONIDSSO cookie's Secure attribute at the virtual server level seemed appropriate. Therefore, GlassFish v3 Prelude defines a new virtual-server property with name ssoCookieSecure, which may be set to true, false, or dynamic. The semantics are the same as described above for JSESSIONID cookies, except that in the case of dynamic (the default), the security setting of the JSESSIONIDSSO cookie is derived from the first request that initiated a session participating in SSO.

Please send any follow-up questions, or any questions on the GlassFish webtier in general, to webtier@glassfish.dev.java.net, or post them to the webtier forum.

Comments:

Thanks for your valuable contributions!

Posted by Emily on October 16, 2008 at 06:17 PM PDT #

Does anyone know if I can do something similar win Sun One 7? I'm facing the same problem.

Posted by Walter on February 17, 2010 at 04:46 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

jluehe

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today