The way single sign-on capabilities are gained depends on the client. For Web browser clients, the Web Container uses either HTTP cookies or URL rewriting to track a session. If the browser accesses the container through HTTPS then SSL Sessions can also be used. Which of the three mechanisms is available depends on the application server and its configuration. Some servers such as WebSphere support all three, others don't.

With a Java application client, user authentication credentials are established during the JAAS login and are then kept in a thread local variable of the Java application thread that executes the code in Listing 1. The credentials will then be used for each subsequent application server access by the thread until the logout statement has been executed.

Besides the default mode in which an established client security context is propagated during inter-component communication, Java EE lets a given enterprise component specify another identity (a so-called run-as identity) that will be in effect when the component accesses other enterprise resources. The run-as identity mode is typically used only when there's no client security context (e.g., with message-driven beans and ejbTimeout callback methods of Enterprise Beans that implement the TimedObject interface). For instance, in OptimalJ-generated J2EE applications, users are given a warning whenever they model a message-driven bean or an enterprise component that uses the timer service but doesn't specify a run-as identity.

Security in J2EE 1.4 for Web Service Endpoints
By far, the most visible change in J2EE 1.4 is the introduction of Web Service endpoints, which effectively provides a viable alternative model for component distribution and interoperability that can compete with CORBA. The Web Service endpoint is a term used to describe Web Service components deployed in a J2EE container. As I explained in my earlier article, a service endpoint can be implemented using a stateless session bean, in which case it runs in the EJB container, or as a Java class that's registered as a servlet, in which case it runs in the WEB container and is called a JAX-RPC endpoint. Associated with each service endpoint is its service endpoint interface (SEI). As prescribed by the WS-I Basic Profile, J2EE limits SOAP to HTTP and HTTPS as its only interoperable underlying transport protocols.

Figure 2 shows the component landscape in J2EE 1.4. It's analogous in intent to Figure 1 and complements it by emphasizing the entries to the application server through Web Service endpoints. There are a number of important differences between Figure 1and Figure 2. For instance:

1. A Web Service component running in the WEB container can be accessed from a client program running in the application client container, which wasn't possible in J2EE 1.3;
2. A Web Service component hosted in the EJB container can be reached by an external non-Java client not only via the CORBA IIOP protocol, but also using the lighter-weight SOAP protocol;
3. J2EE components can now use four different transports for inter-component communications: 1) local invocations in the same JVM, 2) RMI-IIOP, 3) RMI-JRMP, or 4) SOAP.

Let's look at the ramifications of these changes and the mandatory Web Services security-related features supported by all complaint application servers.

The ability to reach an application server with the new SOAP protocol impacts authentication and J2EE requires that the following two authentication mechanisms be supported:

1. HTTP Basic Authentication and
2. HTTPS Mutual Authentication, which uses the certificate presented by a Web Service endpoint client during a SSL/TLS handshake.

It's fairly obvious that HTTP Basic Authentication provides no security unless combined with HTTPS. It's also apparent that with these two choices authentication occurs in the transport, which has consequences for inter-component communication that I'll discuss later.

HTTPS Mutual Authentication is a very viable authentication scheme. Unfortunately we learned that many applications servers, for example, JBoss and WebSphere (see http://jira.jboss.com/jira/browse/JBAS-3019), don't allow one to check the client certificates presented during SSL/TLS handshakes against the CRLs (Certificate Revocation Lists), which severely limits the security of this authentication method in large public enterprise applications.

To achieve integrity and confidentiality when communicating with Web Service endpoints, J2EE fully supports SSL/TLS, giving it the same level of security with regard to integrity and confidentiality as whencommunicating via RMI-IIOP or RMI-JRMP.

Using SOAP for inter-component communication in J2EE might present some surprises since no client security context propagation is supported on most application servers (JBoss, WebSphere) (http://jira.jboss.com/jira/browse/JBWS-679 explains the situation in JBoss).

You might also run into security breaches similar to http://jira.jboss.com/jira/browse/JBWS-675 - a security vulnerability I discovered in JBoss 4.0.3 and older versions that enables you to create a J2EE component (an EJB or a servlet) that would send the credentials of a user accessing it to a non-authorized party whenever the component being accessed communicates via SOAP with another one.

For J2EE applications generated by our OptimalJ product, we decided to simply prohibit our users from modeling inter-component communications via the Web Service endpoints, and I strongly recommend that you don't use Web Service endpoints for this purpose either. If you need to use SOAP for inter-component invocations, you'll have to explicitly configure security parameters for each { invokingComp/invokingModule, invokedCompWithServiceEndpoint } pair, called a Web Service Reference, in a vendor-specific deployment descriptor.

The situation with single sign-on isn't much better. Listing 2 shows a piece of Java EE application client code that accesses a Web Service endpoint. The code does the same thing as Listing 1, but I use SOAP instead of IIOP or JRMP to reach the application server.

You can see that you don't benefit from JAAS for authentication and SSO, because you have to specify the authentication data for each invocation. And uncommenting JAAS login statements would be futile - even though it will create a login session with the server - because no attempt will be made to put the established credentials in the SOAP messages generated by the calls to the enterprise components. Fortunately most application servers let you remove authentication-specific data from your code and put it into a deployment descriptor, but that still falls short of proper SSO support.

Example 2 shows you a piece of a JBoss client deployment descriptor with the necessary authentication data. The advantage of the deployment descriptor approach is that it enables you to specify security parameters for each { invokingComp/invokingModule, invokedCompWithServiceEndpoint } pair only once and does not needlessly clutter the accompanying Java code for each invocation.

Example 2

<service-ref>
   <service-ref-name>service/Bean1Service
   </service-ref-name>
   <port-component-ref>
     <service-endpoint-interface>Bean1ServiceEndpoint
     </service-endpoint-interface>
     <call-property>
       <prop-name>javax.xml.rpc.security.auth.username
       </prop-name>
       <prop-value>Name</prop-value>
     </call-property>
     <call-property>
       <prop-name>javax.xml.rpc.security.auth.password
       </prop-name>
       <prop-value>Passw</prop-value>
     </call-property>
   </port-component-ref>
</service-ref>

Security for Web Service Endpoints - The Future
If you're familiar with recent developments in Web Services security standards, you may wonder why SSO and security context propagation are still a problem. The answer is simple. When Java EE 1.4 was finalized in November of 2003 there was no approved WS specification that addressed the problem of security context propagation and SSO at the SOAP message level. The OASIS Web Services Security (WS-Security) standard was then in draft, which precluded its incorporation in the spec. Since then WSS has become an OASIS standard and has moved from version 1.0 to 1.1. Currently, the standard features two approved profiles, each of which allows you to achieve SSO: SAML Token Profile and Kerberos Token Profile. There are also two new non-OASIS specifications that potentially address this problem: WS-Trust and WS-SecureConversation. Both are currently in a public draft state and their support in existing Java EE application servers is largely absent.