Authenticated Sessions and WebLogic

Authenticated Sessions and WebLogic (including clusters)

When you write a J2EE app or use any of the technologies that are built on top of J2EE some aspects of what happens underneath you are one step removed from magic. That's great when you're in the development process, but when you get closer to production you may need pull back the curtain a bit so you can plan properly.

Let's say you have a very simple Servlet that does two things: tells you who you are and counts the number of times you've loaded the servlet. Something like this:

package project1;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class TestServlet extends HttpServlet {

  public void doGet(HttpServletRequest request,
                    HttpServletResponse response) throws ServletException,
                                                         IOException {
    PrintWriter out = response.getWriter();

    out.write("Username: " + request.getRemoteUser() + "\n");

    HttpSession session = request.getSession(true);
    Integer iCount = 0;
    if (!session.isNew()) {
      iCount = (Integer)session.getAttribute("count");
    }
    iCount++;
    session.setAttribute("count", iCount);

    out.write("Count: " + iCount);
  }

}

And let's say that you protect the app with Basic authentication, like so:

<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
         version="2.5" xmlns="http://java.sun.com/xml/ns/javaee">
  <servlet>
    <servlet-name>TestServlet</servlet-name>
    <servlet-class>project1.TestServlet</servlet-class>
    <load-on-startup>0</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>TestServlet</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>all</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>allusers</role-name>
      <role-name>allusers</role-name>
    </auth-constraint>
  </security-constraint>
  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Session Test</realm-name>
  </login-config>
  <security-role>
    <role-name>allusers</role-name>
  </security-role>
</web-app>

When you hit the app via HTTP the server will see that you haven't authenticated and will respond with a 401 and your browser will pop up a Basic auth box.The next time you make an HTTP request and this time include your credentials the server will:

1. validate the creds
2. see that you don't have a session
3. create a session for the user
4. squirrel the session away in memory on that server (i.e. in that JVM)
5. issue a cookie named JSESSIONID
6. and finally it will it execute the servlet.

Hit reload a few times and your browser sends the JSESSIONID cookie and the counter goes up each time the page loads.By editing the WebLogic deployment descriptor (weblogic.xml) you can tweak a bunch of those behaviors - you can rename the cookie or even tell the server not issue you a cookie at all. If you use JDeveloper you can use a simple GUI to do that for you:

When you deploy this application to one server everything just works - you know, like magic. But when it's really important that this application be available 24x7x365 you're going to want to have it running on more than one server. In fact you'll probably want to have a couple of servers here and another couple somewhere else in the world in case something goes wrong in the first data center. And you still want the counter in my little test app to increment properly, right? 
Well for that you need to deploy a cluster.There's a whole lot of info out there about WebLogic Server clustering, so I'm not going to go into the details of how the AdminServer, managed servers and clusters work. This is a blog about security stuff in the Fusion stack so you didn't come here to read about managed servers and clusters anyway.The only reason I'm writing about all of this is because there are some aspects of this that affect security in a way you might not have thought of until now.