It's logical then that Java 2 Platform, Enterprise Edition, v5.0, which has just been blessed by the Java Community Process executive committee, should offer some support for WS-Security to address the problem of security context propagation. Surprisingly Java EE 5.0 contains almost no changes in Web Services security and doesn't address the problems I delineated in the previous section.

Fortunately IBM, BEA, and JBoss support the WS-Security standard in their WebSphere 6.0.x, WebLogic 9.1, and JBoss 4.0.4. WebLogic even uses it for security context propagation and SSO while WebSphere and JBoss limit themselves to authentication, encryption, and digital signing.

WebSphere, WebLogic, and JBoss implement version 1.0 of the WS-Security standard and support the following specifications:

• SOAP Message Security
• UsernameToken Profile
• X.509 Certificate Token Profile

WebLogic also implements the SAML Token Profile so it can offer Web Services SSO and a security context propagation experience.

Beside the SSO qualities in WebLogic, the servers achieve the following additional security characteristics with the help of WS-Security:

1. Authentication at the SOAP message level using plaintext name passwords and X.509 Version 3 certificates;
2. On WebLogic, authentication at the SOAP message level using SAML tokens;
3. On WebSphere, authentication at the SOAP message level using LTPA tokens;
4. Encryption of SOAP messages or parts thereof using symmetric cryptography. Secret keys can be encrypted and put in messages too. Essentially, the application servers support most of the required and some of the optional encryption-related algorithms specified in the XML Encryption Syntax and Processing specification that the WS-Security standard builds on.
5. Digital signing and verifying SOAP messages or portions thereof. This is an important item because it achieves non-repudiation - something that's not possible with RMI-IIOP- and RMI-JRMP-based transports and wasn't possible in the Java EE security model in the past. The application servers implement most of the required portions of the XML-Signature Syntax and Processing specification, which also underlies the WS-Security standard.
6. Means of defeating replay attacks by using nonces and timestamps in SOAP headers.

As I mentioned earlier, Java EE v 1.4/5.0 is silent on the subject of the WS-Security standard. One unpleasant consequence of that silence is that you need to use container-specific deployment descriptors to specify all the WS-Security related information in your application, which obviously limits the portability of your application. WebLogic is an interesting exception. BEA chose to adopt WS-Policy as a standard means of specifying WS-Security-related configuration of its Web Service endpoints (Microsoft has done the same thing in its .NET Framework.) And JBoss is moving toward embracing WS-Policy (see http://jira.jboss.com/jira/browse/JBWS-856 for more information).

The lack of WS-Security support in Java EE 1.4/5.0 means that Sun Microsystem's technology conformance kits for Java EE (which an application server must pass for it to be declared compliant) exclude any related testing and so vendors can deviate from one another in their WS-Security implemetations.

As is the case with most crucial Web services specifications, the WS-I Consortium (the producer of the Basic Profile - a specification that ensures interoperability among Web service components today) - is defining a subset of the WS-Security standard and its constituent specifications that all the vendors will have to support in the same way. This effort is known as the Basic Security Profile and is now in draft. Until it's completed and all the vendors have incorporated it in their products, interoperability issues are inevitable (largely because of the extensiveness the WS-Security standard and the plethora of decisions that a vendor has to make when implementing it). (The following article will give you an idea of what problems you might run into if you use products from different vendors: http://www-128.ibm.com/developerworks/webservices/library/ws-was-net/ind... %20%20%20%20%20%20%20%20%20%20%20%20%20%20Articles.)

Conclusion
Clearly the new Web Services object distributed model in Java Enterprise Edition 1.4/5.0 could supplant RMI-IIOP and RMI-JRMP in Enterprise Java as the object distribution protocol that offers the same or better security services. At the moment, however, the level of support that the Java Enterprise Edition v. 1.4/5.0 specification required is clearly insufficient for that to happen over night. Still, given the current industry trends and with more and more vendors committing themselves to WS-Security and its Basic Security Profile counterpart, it is more a question of when than if.

The fact that support for WS-I Basic Security Profile isn't prevalent yet in Java EE applications servers and that the profile is still subject to change has consequences for those who develop portable Java EE applications. If the portability of your application is a concern, you'd be better off limiting yourself to the guaranteed Java EE 1.4/5.0 Web Services security features and avoiding WS-Security for a time being. This is the approach we took in our forthcoming OptimalJ product since we needed to shield our users from the specifics of any particular vendor implementations.

References

• Moving to SOA in J2EE 1.4: java.sys-con.com/read/180362.htm
• Java 2 Platform Enterprise Edition Specification, v1.4: http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf
• Java 2 Platform, Enterprise Edition, v5.0: http://jcp.org/aboutJava/communityprocess/pr/jsr244/
• The SSL Protocol, Version 3.0: http://home.netscape.com/eng/ssl3/draft302.txt
• RFC 2246: The TLS Protocol, Version 1.0: www.ietf.org/rfc/rfc2246.txt
• RFC 2459: Internet X.509 Public Key Infrastructure, Certificate and CRL Profile: www.ietf.org/rfc/rfc2459.txt
• RFC 2712: The Addition of Kerberos Cipher Suites to Transport Layer Security (TLS): www.ietf.org/rfc/rfc2712.txt
• RFC 2945: The SRP Authentication and Key Exchange System: www.ietf.org/rfc/rfc2945.txt
• Making Login Services Independent of Authentication Technologies: http://java.sun.com/security/jaas/doc/pam.html
• JAAS in the Enterprise: http://jdj.sys-con.com/read/171477.htm
• Common Secure Interoperability, Version 2: www.omg.org/technology/documents/formal/omg_security.htm#CSIv2
• Certificate and Certificate Revocation List (CRL) Profile: www.ietf.org/rfc/rfc3280.txt
• OASIS Web Services Security (WSS): www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
• Web Services Trust Language (WS-Trust): www6.software.ibm.com/software/developer/library/ws-trust.pdf
• Web Services Secure Conversation Language (WS-SecureConversation): www6.software.ibm.com/software/developer/library/ws-secureconversation.pdf
• XML Encryption Syntax and Processing: www.w3.org/TR/xmlenc-core/
• XML-Signature Syntax and Processing: www.w3.org/TR/xmldsig-core/
• Web Services Policy Framework (WSPolicy): http://specs.xmlsoap.org/ws/2004/09/policy/ws-policy.pdf
• Basic Security Profile: www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity

Sidenote 1

What Is JAAS?
JAAS stands for Java Authentication and Authorization Service. It provides a Java implementation of the Pluggable Authentication Module (PAM) framework that was pioneered in the Solaris operating system.

Modern application servers use JAAS to authenticate principals accessing resources running in the server. It is also used heavily by Java clients running in an application container as a way of authenticating themselves to the application server and benefiting from single sign-on.

The article "JAAS in the Enterprise" gives a pretty good idea of the future direction that this specification is likely to take in upcoming releases of Java Enterprise Edition.

Sidenote 2

Application Client Containers
Application client containers are a way of giving remote J2SE clients access to the components and services of a Java EE application server.

Despite its rather imposing name, an application client container can be nothing more than a set of .jar libraries that let a standalone Java application access the JNDI tree of an Java EE application server, whereby gaining access to the Enterprise Beans and other enterprise services such as JMS, container-managed JDBC data sources, and JavaMail.

For JBoss AS the set of .jar libraries is all that's required to set up a client container on a host where a Java SE runtime is installed (see http://wiki.jboss.org/wiki/Wiki.jsp?page=J2EEClient for more information).

For WebSphere and WebLogic, the setup is more involved - both require that a client host have access to the AS installation and provide an application client launch program that must be used to execute a client program.