Java EE and .NET Security Interoperability
This chapter is from the book
This chapter is from the book
This chapter is from the book
Security by Default
Security exploits and vulnerabilities are often causes of huge financial loss and disruption of business services. The Computer Security Institute (refer to [CSI] for details) has reported a worldwide financial loss of circa US$130 million that resulted from virus, unauthorized access, and theft of proprietary information in 2005, a US$7.3 million loss (compared to US$65 million loss in 2003) due to denial of service attacks, and an average US$355,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 [WindowsAuthFlaw]) or Java platform (such as a flaw in the JVM in [JavaVMFlaw]). 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 platform 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. Also refer to [WSI-countermeasure] for the details of security scenarios and the counter-measures to the security threats.
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 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 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 chapter recapitulates the features of Java and .NET security that make interoperability easier. It also 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. Finally, two interoperability strategies are discussed.