Java EE .Net security interoperability

Security exploits and vulnerabilities are often causes of huge financial loss and disruption of business services. The Computer Security Institute has reported a worldwide financial loss of circa 30 million that resulted from viruses, unauthorized access, and theft of proprietary information in 2005, a .3 million loss (compared to 5 million loss in 2003) due to denial-of-service attacks, and an average 55,552 (2005) loss per incident for proprietary information theft in 2003. A business application that was considered “secure” running on a Unix or Windows platform (for example, protected by firewall and anti-virus application) is not necessarily vulnerability-free when exchanging sensitive business data with another business application running on a different platform. This is because the interoperable solution is exposed to security vulnerabilities if one of the applications (either the sender or recipient) is exploited or is being attacked by hackers.

There are historic incidents of vulnerabilities in the Windows platform (such as flaw authentication) or Java platform (such as a flaw in the JVM). These incidents are critical and can become the Achilles’ heel (a critical problem that causes financial loss or disruption to the business service) for the mission-critical Java EE .Net interoperable solutions. Although the individual vulnerability incident may not be a direct root cause to security exploits of a Java EE .Net interoperable solution, any vulnerability exposed on either Solaris OE, Unix, Linux, or Windows platforms becomes a “weakest link” to the security of the interoperable solution.

Web Services Interoperability (WS-I) identifies the following security threats that can impact Java EE .Net interoperability:

• Message alteration: Changing the message header or body during the transit
• Attachment alteration: Changing the SOAP attachment during the transit
• Confidentiality: The capability to ensure no unauthorized access is made to the message
• Falsified messages: The message is falsified by using a different identity of the sender
• Man-in-the-middle: The message is being spoofed or tampered with during transit
• Principal spoofing: The information about the user or subject is being spoofed during transit
• Repudiation: The sender or recipient denied or repudiated about the message being sent or received
• Forged claims: The claim about sending the message is forged by tampering with the message content
• Message replay (or replay of message parts): The message was once spoofed and modified for resending the message
• Denial of service: A malicious action to replay a message continuously or to overload the target service provider until the service provider is out of service

To make a Java EE .Net interoperable solution secure by default, security architects and developers should consider the following security requirements:

• Always customize security settings. Do not take the default security settings of vendor products in the operating environment. Many business applications are not designed and deployed with security by default—they are designed with unused system services turned on when deployed, which may be open to security exploits and vulnerabilities that can severely impact the interoperable solution.
• Use open standards for interoperability. Web Services Security is currently an open standard for SOAP-based Web services. WS-I Basic Security Profile (BSP) 1.0 addresses these security threats. In essence, BSP 1.0 extends Web Services Security to handle SOAP attachments. These standards ensure that the applications are interoperable.
• Use strong authentication mechanisms.
• Use secure transport mechanisms. Use of secure transport mechanisms such as Secure Socket Layer/Transport Layer Security (SSL/TLS) should address principal spoofing.
• Use digital signature. Use of digital signature should address the security risks of message alteration, attachment alteration, confidentiality, repudiation, and forged claims. Signing the SOAP message header once, creation time, and optional user data over a secure transport layer such as SSL/TLS are able to address the security risk of message replay.
• Use encryption. Use of encryption should address the security risks of confidentiality.

This article discusses different technologies (such as authentication in the presentation tier) and the open standards (such as Web Services Security) where Java and .Net applications can interact.

Security for interoperability

Java and .Net applications can interoperate synchronously or asynchronously in different architecture tiers. As security is end-to-end, security for interoperability should not be limited to a single application component (for example, .Net bridge) or a specific architecture tier (for example, Web tier). Further, the security requirements for interoperability in each architecture tier are different. This section discusses the security requirements and what enabling technologies and security standards are available to address these requirements. Adopting interoperability technologies that support security standards allows wider choice of vendor products and easier implementation.

The figure below depicts the areas of security for interoperability that have support for security standards such as WS-I Basic Security Profile and WS-Security. A Java client should be able to perform a single sign-on with the .Net application and similarly for a .Net client with a Java application. To ensure client-to-server communication is secure, developers can use HTTPS or SSL/TLS to encrypt the communication channel.

In both the Web and the business tiers, the client should be able to initiate service requests or exchange business data synchronously or asynchronously using Web services (with WS-I BSP and WS-Security). This should allow a servlet, JSP (JavaServer Pages) page, or JSF (JavaServer Faces) component under the Web tier to interoperate with a .Net service component under the business tier—or an ASP.Net page under the Web tier to interoperate with an EJB (Enterprise JavaBeans) object under the business tier. In the resource tier, a Java servlet or EJB component can also request access to resources such as business data and database objects implemented by means of the data access layer using a policy language such as WS-Policy, XACML (Extensible Access Control Markup Language), and Web Services Policy Language. Similarly, a .Net-serviced component can also share the same policy language (provided that they are available in both .Net and Java language) when requesting access to resources via data access objects or entity beans.

There are always business scenarios in the existing or legacy environment that the figure above does not cover. As most of these scenarios use nonstandard interoperability technologies that are usually proprietary or highly customized on a case-by-case basis, they require additional cost and efforts to analyze the potential security risks and to mitigate the vulnerabilities. For example, if a bridge technology is used for Java EE .Net interoperability, developers and security architects need to analyze the risks of the bridge technology and the customized application codes that connect to the bridge. The bridge would become an easier target for hacking or the single point of failure attacks. Even though the security for the bridge is strong, there may be considerable unknown risks for the customized application codes related to it.

The following sections elaborate on the security requirements of Java EE .Net interoperability and discuss the technologies available to mitigate the security risks.

Secure transport

The client-to-server session is often a target of security spoofing. A basic security requirement for interoperability when exchanging user credentials or sensitive business data is secure data transport. Java and .Net applications can use HTTPS or SSL/TLS in the data transport layer to secure the client-to-server session. Secure data transport can ensure confidentiality and reduce the risk of principal spoofing.

Security interoperability by tiers

Interoperability at the Web tier

A Java client can authenticate with an active directory or a directory server using a JAAS (Java Authentication and Authorization Service) login module. Similarly, a .Net client can authenticate with a directory server. Digital certificates can be used as a common user credential; however, Java and .Net clients need to create shared session state in order to interoperate in a heterogeneous environment. The capability to authenticate with both Java and .Net application servers and to create shared common session data are key security requirements for interoperability. These security requirements allow the principal to share session information between the Java and .Net environments and not necessitate re-login. A Java client can authenticate with a .Net application using the shared authentication approach. Similarly, a .Net client can also authenticate with a Java application using the same shared authentication approach. Shared authentication here refers to the use of form-based authentication and customization of shared session data for both Java and .Net applications.

Form-based authentication allows page-level authentication to a Web application. Shared session data can be stored in a customized shared session state database or a directory server using existing session APIs in both Java and .Net platforms—for example, Java has many APIs under the javax.servlet.http.HttpSession class and .Net has Shared Session object.

Nevertheless, customized processing logic for shared authentication and shared session data are often proprietary and are specific to certain implementations. The use of Web SSO MEX (Single Sign-on Metadata Exchange) protocols is a proposed standard for Java EE .Net interoperability to achieve single sign-on and should be recommended.

Shared authentication, shared session data, and single sign-on using the Web SSO MEX protocol are mechanisms to address broken authentication and session management. They also rely on strong authentication mechanisms—for example, use of digital certificates and strong user passwords—and reliable authentication infrastructure, such as a directory server. For Web services such as asynchronous SOAP messages, it is critical to use the WS-I Basic Security Profile (BSP) and WS-Security standards. WS-I BSP ensures that both Java and .Net applications are using a common semantic for SOAP messages. WS-Security supports service requests or replies that are digitally signed and/or encrypted to ensure confidentiality. It addresses the risk of message alteration, attachment alteration, falsified messages, repudiation, forged claims, and message replay.

Interoperability at the business tier

Security interoperability requirements for the business tier are similar to those for the Web tier. The key difference is that the business tier interaction is often server-to-server, not client-to-server. Interaction between .Net-serviced components and EJBs or service requests from the Web tier are often point-to-point, and these components do not use SSL/TLS, which is used for client-to-server communication. Customized and point-to-point security processing logic (for example, encrypted transactions) that secures the business transactions in the business tier is usually proprietary and is unlikely to be reusable in another environment. For interoperability using Web services, WS-I BSP and WS-Security provide an open standard to secure business transactions. For interoperability using a bridge technology, developers need to rely on customized encryption or a proprietary security mechanism.

Interoperability at the resource tier

Both Java and .Net platforms support a variety of access control mechanisms to determine which resources are accessible to the service requesters. They may either embed the access control processing logic into the programming codes or use a policy framework. Using a policy framework, developers can decouple the custom access control processing logic from the application codes. Because the access control processing logic is separate from the application codes, it will be more flexible, allowing management of changes without the need to recompile or retest the entire application for every security policy change.

Without a common policy framework, an interoperability solution needs to rely on two different access control systems. If the two policy frameworks are “out of sync,” the service requester may be denied access. It is also time-consuming to troubleshoot which side of the policy framework is problematic.

The use of common and standard security policies, such as WS-Policy and XACML, across Java and .Net platforms addresses the risk of broken access control. For example, Microsoft’s Web Services Enhancement provides support for WS-Policy, and Sun’s XACML Kit is available on both Java and .Net platforms.

Support of audit control and compliance

In recent years, support of audit control and compliance (for example, Sarbanes-Oxley, Gramm-Leach-Bliley Act of 1994, HIPPA or Health Insurance Privacy and Portability Act of 1996) has become a key security interoperability requirement. These compliance requirements are focused in building the capability for tracking unusual or suspicious user activities, ranging from unauthorized access to suspicious high volume business transactions. They also require a timely report of the unusual or suspicious security events, and tracing the source of the service requesters. Thus, it is extremely important that the Java and .Net interoperability design should be able to have risk mitigation mechanisms for security attacks, and to build up capability for “track and trace” of any unusual security events and service requests.

Summary

Interoperability for security is a challenging subject, and dealing with security on one single platform is already complex. Making two different application platforms interoperate on the security is more complicated. Thus adopting open standards for security interoperability would be a good approach.