An important difference is that previous distributed interactions were point-to-point, e.g. client/server or a call to a trusted Web server, which sent the message to the final recipient. In contrast, Web services send a message, which travels from an initiating client through, potentially, a number of intermediates before it reaches its final destination. The client has no or limited knowledge of the possible path between itself and the final application, which supplies the service. A number of security solutions were developed for the point-to-point transactions. A popular one is the Secure Sockets Layer, SSL. This protocol encrypts the message sent over the wire. However, the message is decrypted at each hop, so that if any of the intermediates were compromised, the whole message would be compromised, including the authentication evidence.
A second difference is that the previous distributed models were homogenous, e.g. DCOM clients could only interact with DCOM servers or CORBA with CORBA or DCE with DCE. Binary bridges between pairs of the models were developed but security was always a sticking point. In general there was no model for security to interoperate between multiple models. (EJB and CORBA was an exception with development of the CSIv2 specification.) Web services, on the other hand, promise limitless interoperability between operating systems, platforms and software systems. Consequently, the security models must also support the same interoperability.
A third difference is that a Web service passes a document which can be very large and contain different pieces information that should only be seen by selected parties along the path. For example, the admissions office at a hospital requires the name, address and insurance company, whereas sensitive medical information in the same document should not be seen by the admissions office, or anyone except, say, the attending physicians. Previous security models could not handle this sort of message-based distinction, whereas the new Web services security algorithms and protocols can.
Turning to the second part of your question, the security community has a good idea of the methods to solve the problems in the Web security space and is actively developing specification along this line. Implementations are beginning to appear for these specifications. However, they have not been time-tested and do not yet address some of the more complex Web services use cases. (I addressed these problems in my 03 June and 15 July 2003 answers and will summarize those answers here. For a more complete discussion please refer to the 03 June and 15 July answers.) With today's Web services security products and the limited experience with these implementations, I believe that the present security products may be used for secure intranet interactions and in a controlled manner, on the extranet. Except for protecting relatively low value resources; we are not ready to use the wide-open Internet or some of the more complex Web services scenarios. We need more experience using these new paradigms in controlled situations (intranet and extranet) and we need the higher-level security specifications, which were discussed in my previous answers and which are still under development.
This was first published in August 2003