XML and Java: Developing Web Applications, Second Edition

14.2 Security Requirements on B2B Systems

The first thing you need to do when planning to secure your system is to determine your security requirements梩hat is, what you need to protect from what kinds of attacks, based on your security policy. We review two types of the most common security requirements seen in B2B systems.

14.2.1 Security of Communication

First, let us consider the security requirements for network communication.

Historically, Internet technology has been weak in security because in its early days, the Internet was used by a small group of cooperating, trusted people. Ethernet packets are visible to anyone who has a locally attached machine because Ethernet is essentially a broadcast medium. If sensitive information is sent over the Internet, it must be protected against eavesdropping.

Internet packets are also vulnerable to alteration. Anybody who can access network cables or routers can modify the contents of a communication. You cannot know whether any changes have been made to the contents since the sender created the message.

Even when you are confident that the contents of a message are protected against eavesdropping and forgery, your communication is vulnerable if your communication peer is not who it claims to be. In a TCP/IP connection, the sender of a packet is identified by the sender's IP address and the port number in the packet header, and these fields are easy to modify, as we discussed. So we must have proof of the identity of the message sender.

In real businesses, exchanging data or documents between companies often constitutes a step or steps of an agreement or a contract. Sending a purchase order to a supplier is a good example. In these cases, the business must keep an audit log that can be used as evidence of the transaction. A simple communication log does not make good evidence, because it is fairly easy to modify the contents of a communication log without being noticed.

In summary, there are four security requirements in B2B communication.

• Confidentiality桵essage contents cannot be monitored or copied by an unauthorized entity.

• Integrity桵essage contents cannot be altered by an unauthorized entity.

• Authentication桸o one can disguise themselves as the legitimate communication party.

• Nonrepudiation桾he message sender cannot deny the fact of sending a message and the contents of the message.

The recent development of cryptography technologies makes it possible to satisfy these security requirements at a reasonable level. For example, SSL (more recently known as TLS) satisfies the first three security requirements. In Section 14.3, we show you how you can use SSL/TLS in your Java-based B2B applications. The fourth requirement, nonrepudiation, can be achieved by using digital signature technology. In Section 14.4, we discuss the XML Digital Signature specification and how you can use it in your XML applications.

14.2.2 Access Control

We have covered the security requirements of B2B communication. Once a message is received from a secured communication channel, you need to determine what kinds of operations are allowed to process the message based on your security policy and the identity of the requester. Suppose that you received a message from a company named XYZ Corp. requesting access to your purchase order database to review its purchase order history. Because this message came from a secure communication channel with a proper authentication mechanism, you can be sure that the sender of the message is in fact XYZ Corp. Should you allow this company to access your database and return the requested information?

The answer to this question depends on your policy. For example, you may have an access control policy for your purchase order application as follows.

• All properly authenticated companies can access the product catalog database.

• All companies in the "trusted" category can submit a new purchase order.

• A company can review the history of a purchase order that has been issued by the same company.

As you can see from this example, an access control policy determines who can do what operation on what data.

Access control is sometimes confused with authentication. This is understandable because in many cases, an access control mechanism and an authentication mechanism are integrated into a single mechanism. For example, you can access the password-protected Web pages of the Apache Web Server only when you are properly authenticated. However, in general cases, you should distinguish access control from authentication. Authentication is used to prove the identity of your communication peer. In a large system, the authentication database sometimes contains the userids and passwords of many users, but only a subset of this population is allowed to access a particular component.^[2] Therefore, access control should be discussed separately from authentication. In Section 14.5, we discuss the available options in Java-based B2B systems.

^[2] In UNIX, authentication is logging in to the operating system. Access control is done through protection bits associated with files.