In discussing authentication, our analysis will focus on the interaction between ePortal and eBusiness and what these entities need to operate securely. The authenticated identity of several entities involved in producing and satisfying the Web Services request will be required. Ways to determine those identities are not obvious and require the cooperation of the participants in the process.
Authentication Requirements
The authenticated identities of several entities are needed to process and fulfill a request. ePortal must verify the identity of the buyer, Joe, before initiating the request. That is, a customer of ePortal wants to see how much 5,000 ball bearings will cost. Before ePortal starts to process the request, it makes sure that it knows who made the request so that it can decide if the request is legitimate. In this particular example, Joe uses a browser.
While we have chosen to use a person at a browser, the reader should keep in mind that another computer could represent the customer. Rather than using a browser, the customer could use a special-purpose client, or the customer may even have emailed a purchase order to ePortal. This is the case with eBuyer. However the request was received, ePortal must verify the identity of the sender, even if the sender is another computer.
When ePortal determines that it must request a Web Service from eBusiness, eBusi- ness now needs two authenticated identities. First, it needs to verify who sent the request. This is important because eBusiness’s business relationship is with ePortal, and only companies with which it has a business relationship are entitled to make requests. eBusiness also wants to make sure that it will be paid for providing the Web Service, and ePortal is responsible for payment.
Second, eBusiness needs to know who initiated the request. This is particularly important when eBusiness must take action on behalf of the initiator. For instance, eBusiness may not mind responding with pricing information and sharing it with Joe. But, it doesn’t want to ship merchandise unless it knows that Joe is a legitimate buyer. Web Services complicate business-to-business authentication because the path from ePortal to eBusiness may not be direct, and intermediaries (SOAP and otherwise) may be in the path, handle the SOAP message, and even modify the message. However many entities have touched and relayed the message, we need to make sure that the requests in the message came from a business partner of ePortal’s.
In our scenario, it is not possible for eBusiness to directly authenticate Joe. As a workaround, eBusiness agrees to accept ePortal’s customer authentication. The two companies have established a trust relationship. Since ePortal has already authenticated and authorized the initiating user, eBusiness can carry out the request based on ePor- tal’s word that Joe is who he says he is, and ePortal’s authority to request the Service.
Passing a user’s identity is more complicated in a multidomain application than in a single-domain, multitiered application. In the case of a single-domain, multitiered application, which is shown in Figure 6.2, a Web server can authenticate a user, and rather than the application server’s authenticating the user again, the application server trusts the identity passed to it by the Web server. Often, this identity is passed in
the clear between the two systems. That is, the identity is not encrypted as it passes across the internal network from one system to the other. Also, there is no authentica- tion that the source of the identification information was the Web server.
The reason that this approach is so popular is that the user does not want to go through authentication multiple times, and it is also burdensome for the application server to have to maintain a list of users and their passwords, essentially duplicating functionality already performed at the Web server. While there is some risk in accept- ing the user’s identity without authenticating its source, many organizations feel that the risk is acceptable, since the data is being moved over internal networks, not the Internet.
For Web Services, which operate in the multidomain, multitiered environment shown in Figure 6.3, messages flow across the more hostile Internet. Passing the cus- tomer’s identity in the clear and without any further protection is more difficult to accept. eBusiness has to trust ePortal to authenticate the initiator. However, since the two companies are not connected over internal networks but, instead, are connected over the Internet, passing this information can no longer be done in the clear, without any authentication of the source of the information.
Finally, eBusiness would like to make sure that it is exchanging information with ePortal and ePortal alone. It wants to know that it is sending potentially sensitive infor- mation to the correct receiver.
We have identified at least four requirements for authenticated identity during the interaction between eBusiness and ePortal, and others may be needed. The four required authenticated identities are:
■■ ePortal must know who the initiator is.
■■ eBusiness must be sure that it received a SOAP request from ePortal.
■■ eBusiness must reliably know who the initiator is.
■■ ePortal must be sure that eBusiness sent the SOAP response.
Of these requirements, the first, ePortal knowing that the initiator is Joe is not, strictly speaking, a Web Services issue since it does not occur at the Web Services inter- face. Nevertheless, it is significant and we will discuss why later.
Figure 6.2 Single domain, multitiered environment.
User Presentation Tier Application Component Tier
Single Enterprise Back-office Tier Web Server Display Preparation/ Business Logic Data Repository/ System of Record 136 Chapter 6
Figure 6.3 Multidomain, multitiered environment.