US Department of Energy signs on to J2EE

Create a secure single sign-on Web service for multiple n-tier Web applications

As part of the Energy Information Administration's (EIA) ongoing commitment to provide better products and services with increasing efficiency, the EIA's Office of Information Technology (OIT) promised to deliver Web-based data-collection services in limited time and with minimal expense. Therefore, the OIT's technical team developed applications serially, with little opportunity to deploy highly generalized, reusable components. Meanwhile, as development progressed, the IT industry made significant technology advances, and EIA acquired many new technologies at the infrastructure level. In the industry, Java 2 Platform, Enterprise Edition (J2EE) standards and specifications evolved, and many vendors started to support them at different levels. At EIA, we purchased new hardware; acquired licenses for a J2EE server that could support Enterprise JavaBeans (EJB), including session beans and entity beans; and deployed many other new key infrastructure components, such as Virtual Private Network (VPN) and Oracle's Virtual Private Database (VPD), as well as researched LDAP (lightweight directory access protocol) and Kerbero authentication in our intranet and Internet environment. We both played key roles in architecting the EIA's Web applications and setting up their security. Jian Zhong is the technical lead on most OIT Internet data-collection projects, while Mike Lehr acts as OIT's senior application security architect on those same projects.

Based on Zhong's simple methodology, first introduced in "Step into the J2EE Architecture and Process" (JavaWorld, September 2001), we built the first Java Web application using J2EE technologies at EIA. This project won the US Department of Energy's 2001 Technical Excellence Award and helped us gain approval for a second project—a similar Web application with a legacy database containing about 85 tables. The second project involved Web-enabling the data-collection process for one EIA survey. This project, which is going live as we write this article, took only about four months to complete. It went more smoothly than the first project, and we again satisfied the customer's requirements and delivered on time with minimal cost. As each success within the organization improved our position and enlarged our codebase, we thought more seriously about productive, reusable technologies that would require a small degree of up-front investment.

The circumstances and the challenge before us were both commonplace: we needed to find a practical way of gradually implementing more efficient technology and, if possible, retrofitting it to existing applications. After consulting with management, we decided to implement a reusable single sign-on (SSO) component. Two familiar business requirements drove this decision:

  1. The need to accommodate large projected increases in e-business partners. The EIA has two main classes of e-business partners: respondents, who submit survey data electronically, and employees (both federal and contractor).
  2. Heightened security concerns in response to terrorist activity. Respondents no longer send paper forms because of recent terrorist events, and thus we have an urgent need to deploy electronic submissions for many surveys. Many respondents will submit for more than one survey as well.

In this scenario, SSO has several advantages. Developing one relatively high-quality SSO component allows better safeguards than developing individual SSO modules. SSO enables more consistent, centralized, and efficient user administration. It allows security personnel some standard and centralized resources—for monitoring failed and successful logons, for example. Equally important, users can conduct their business more quickly and conveniently, partly because they avoid the nuisance of repeated logins, and partly because they can easily change their profiles in one place. The Open Group's "Introduction to Single Sign-On" discusses SSO's advantages in more detail.

Business process and requirements analysis

The EIA manages more than 80 energy information surveys. Each program office division manages its own surveys. Currently, only a few surveys are Web enabled. Some users respond to many surveys, while other users respond to the same survey on behalf of many firms. Survey data are submitted via fax, email, telephone, and so on, and are processed in ways appropriate to the particular survey.

We envision that virtually all surveys will be Web enabled so that respondents can at least submit survey data directly from their browsers. As each survey Web application comes online, user authentication will be required, and some respondents will need to authenticate to many applications. The EIA is also bringing intranet applications online, for which EIA contractors and staff require authentication services.

Figure 1 shows the network topology of our enterprise architecture.

Figure 1. Network topology for many n-tier Web applications in an enterprise

How the architecture works from a user's perspective

The SSO application is really a Web service to other Web applications, although this might not be apparent from a user's perspective. For users, the ideal situation would follow these steps:

  1. A user (respondent, contractor, or staff member) goes to the EIA-wide sign-on page
  2. The page asks the user to provide a username and credentials
  3. If the credentials are verified, the user sees a list of Web applications (e.g., surveys) that he has permission to access
  4. If a respondent or internal user tries to access a Web application without authentication, he is redirected to the EIA-wide sign-on page
  5. When visiting other Web applications for which he is authorized, the user is not challenged about his identity because he is already authenticated
  6. When the user signs off from one application, he remains logged in to other applications

How the architecture works from a developer's perspective

From the user's viewpoint, the requirements look simple. Now let's further examine how we could develop each of the many Web applications. We find the first factor common in organizational life: the many Web applications we wish to support are managed by different divisions, developed by different contractors (at different times), and deployed on different application servers (see Figure 2's UML diagram). A key success factor for us was defining an architecture that would accommodate these realities, and then properly defining the SSO solution's scope and staging. A large-scope solution must accommodate a range of somewhat dissimilar tools and provide for the fact that applications cannot all migrate at once. On the other hand, a project covering too small a scope would not be worthwhile.

Figure 2. UML for the development process of many n-tier Web applications

How the architecture works from an architect's perspective

Clearly, a suitable architecture for us had to meet several design goals. It needed to:

  • Provide SSO services to many n-tier Web applications
  • Support centralized, enforceable, and efficient security administration
  • Allow gradual deployment (i.e., not all Web applications need to adopt it at once)
  • Be consistent with J2EE standards and suitable for use with generic J2EE applications (including those not yet designed)
  • Extend to non-J2EE applications
  • Support federation (sharing) of user identities across enterprises
  • Be simple and quick to develop (to keep costs down)
  • Provide quick and easy retrofitting to existing J2EE applications
  • Work with commercial off-the-shelf (COTS) tools (e.g., LDAP) when they are available or when they represent the most appropriate source of desired functionality
  • Support different kinds of credentials for different users—both passwords and certificates, for example
  • Comply with existing security standards, such as password requirements

Approaches to authentication and SSO

We wanted a good context in which to evaluate different solutions to our problem, so we reviewed the current state of industry standards and products for authentication and SSO. We first looked at relevant parts of the J2EE specification and at the J2EE BluePrints program. Then we reviewed COTS offerings from several vendors.

What is in the J2EE spec?

Both the servlet and Enterprise JavaBean (EJB) specifications offer similar methods for accessing user identity and role information after the user authenticates. However, the servlet and EJB specifications do not define how to achieve authentication or SSO; that is left to individual vendors. In javax.servlet, programmatic security consists of the following javax.servlet.http.HttpServletRequest methods:

  • java.lang.String getRemoteUser()
  • boolean isUserInRole(String role)
  • getUserPrincipal()

The getRemoteUser() method returns the client's authentication username. The isUserInRole() method determines if a remote user is in a specified security role. The getUserPrincipal() method determines the principal name of the current user and returns a object.

The EJB container must provide access to the caller's security context information from the enterprise beans' instances via the getCallerPrincipal() and isCallerInRole(String role-Name) methods. The security methods in javax.ejb.EJBContext are:

  • getCallerPrincipal();
  • boolean isCallerInRole(String roleName);

How do BluePrints handle authentication?

As evidence that the specifications for authentication and SSO are not yet stable, we note that successive versions of J2EE BluePrints (i.e., for the Java Pet Store) have offered different solutions to these problems. Version 1.0.1 offered a form-based architecture solution, 1.1.2 offered a servlet-based architecture, and 1.3 offered a filter architecture. We considered each architecture and its strengths and weaknesses.

Java Pet Store 1.0.1 uses form-based authentication to authenticate these interactions. In form-based authentication, a Web container designates an application-specific page containing an HTML login form. This page contains an HTML form that prompts for a username and password and displays when the user tries to access a protected resource. This solution is not portable across containers.

In Java Pet Store 1.1.2, a new servlet-based sign-in/sign-out architecture with a handler to centralize requests replaces the previous form-based login approach, enabling you to deploy the Java Pet Store on all possible J2EE platforms without modifying code. This solution is portable across containers, but the application manages it. Implementing getRemoteUser(), isUserInRole(), or getUserPrincipal() is difficult at best.

In Java Pet Store 1.3, the application implements an authentication filter to prevent unauthorized access to resources. In this approach, the filter intercepts all HTTP requests and responses. At sign-on, a flag raises in the user's session, and the filter checks for this flag in response to each request. However, in scanning the source code, we did not see calls to getRemoteUser(), isUserInRole(), or getUserPrincipal(). This leads us to conjecture that we cannot use these three methods in the current implementation. Consequently, if we developed a reusable authentication or SSO module, we could not use the standard interface between it and applications. If wrappers for the request and response were available, this would be a powerful approach.

How software vendors handle SSO

As a result of our review, it became clear that the J2EE specification does not define standard authentication or SSO approaches. Also, the BluePrints, which constantly evolve, do not offer a clear road map. Therefore, we looked at several industry offerings, three of which we describe in some detail here.

Microsoft .Net Passport

Microsoft first provided its Hotmail service at no cost, amassing more than 150 million user identities. It then used this list as the base for its .Net Passport service—an authentication service for participating Websites and services. Together with the dominance of the Windows OS and the Internet Explorer Web browser, the .Net Passport Web service could essentially make Microsoft the Internet gatekeeper. Thus far, Passport is the Web service with the largest number of registered users. And the technology behind it is simple. In our opinion, Passport's key concept is HTTP redirect:

  1. When a registered .Net Passport user clicks the standard sign-in link on a .Net Passport Single Sign-In (SSI) participating site, and he is not yet authenticated for that site, an HTTP redirect displays Microsoft's .Net Passport sign-in page.
  2. On the sign-in page, the user enters his .Net Passport sign-in name and password. The .Net Passport authenticates the user and writes a cookie to his browser.
  3. The Microsoft Passport server redirects the browser to the participating site's Web server with authentication information as parameters on the HTTP query string.
  4. The participating Web server receives the request. A server-side component, Microsoft's Passport Manager, decrypts the information received from the Microsoft Passport Server and caches the user's authentication in cookies in the user's browser. The Passport Manager also serves as a gatekeeper to verify whether an HTTP request authenticates.

For our applications, we had two objections to .Net Passport. First, it runs only on the Microsoft platform. Second, we don't want to surrender our user authentication to Microsoft.

Netegrity SiteMinder

1 2 Page 1
Page 1 of 2