April 16, 2011, 6:40 a.m.
posted by streetdancer
In Chapter 12, we discussed how XML could be used for data exchange and remote procedure calls. Further, in Chapter 13, we showed the new idea of combining such XML-based services to dynamically build new applications. These services can reside in a single company's intranet, but the biggest value of using XML is gained when doing data exchange between different companies over the Internet.
One of the major concerns about doing B2B data exchange over the Internet is security. The Internet is an open network, and any data flowing through it can be monitored or altered. You need to make sure that the party at the other end of the communication line is the one you believe it is. In addition, you should build some form of trust relationship with your business partners.
 Some network appliances, such as a Network Address Translation (NAT) box, modify IP packets on purpose.
In this chapter, we show you what kinds of security technologies are available for you to improve the security of your Java-based B2B system that exchanges XML data on the Internet. In Section 14.2, we cover the security requirements of such a system. Then in Section 14.3, we show how Secure Sockets Layer/Transport Layer Security (SSL/TLS) can be employed to secure your communication channel on the Internet. Section 14.4 discusses XML Digital Signature—why you need it and how you use it. Various access control mechanisms in Java applications are discussed in Section 14.5. Before concluding the chapter, we describe a brief list of upcoming technologies in Section 14.6 that will enhance the security of our systems.
1 IT System Security in General
There is one disclaimer. Although we show you the available security options for B2B systems based on XML and Java, these technologies cannot secure your entire system by themselves. Security is like a chain and can be broken at its weakest link. This means every security aspect of your system, including, but not limited to, controlling physical access to your system, patching and updating your operating systems and server software as soon as any security vulnerability is found, properly configuring and monitoring your networks (firewalls, routers, intrusion detection systems, and so on), and educating end users about managing their passwords properly and not opening any unknown e-mail attachments, and so on. Without such very broad precautions, the technologies introduced in this chapter could become meaningless.
Please understand that no information system is 100% secure. Your operating system may have security vulnerabilities that have not yet been found. Some of your employees may be using weak passwords. The network administrator may not be able to respond to intrusions quickly enough on Friday nights. Even the cryptographic algorithms that we use in this chapter are not proven to be 100% secure. They are merely believed to be secure because no one has broken them yet. It is completely possible, although unlikely, that somebody will break the RSA algorithm tomorrow.
So you need to do two things. First, define your security policy. Assess the possible losses if your system's security is broken and the cost of introducing each security countermeasure. The cost may include inconvenience to the end users because of complicated security procedures. Then decide what risks you will take, and what risks you will eliminate.
Second, not only must you implement countermeasures in your system according to the defined policy, you also need to design procedures for detecting attacks and reacting to them. We recommend that you read the book titled Secrets and Lies (John Wiley & Son, ISBN 0-471-25311-1), written by a well-known cryptographer, Bruce Schneier, which gives general ideas of what information system security is and what it is not.
Enough about the disclaimer. Now let us move on to security requirements.