The work of most of the organizations previously discussed is to produce a standard. These standards address workflow, reliable delivery, and a host of other needs. The W3C, at http://www.w3.org/2000/03/29-XML-protocol-matrix, keeps a list of other XML-based protocols being developed. This list was compiled in 2000 and is
somewhat dated. However, it’s a start. There are many other protocols currently being developed, but we will not go into them here.
One area we have not touched on is application-specific activities. One notable effort is the ebXML project.
ebXML is a joint activity of OASIS and the United Nations Center For Trade Facili- tation and Electronic Business (UN/CEFACT). It is an ambitious effort aimed at defin- ing standards for the formatting and transmission of electronic commerce data, the description of business processes, and the negotiation of business terms and responsi- bilities. Because it relies on Internet standard protocols and uses XML, the specifiers expect that the cost of implementing ebXML will be less than the cost of EDI.
Besides XML, ebXML specifies SOAP as its message format. It goes beyond SOAP by defining elements for routing, trading partner information, and quality of service requirements. ebXML includes a registry and repository that is similar to, but not the same as, a UDDI registry. Two documents, the Collaboration Protocol Profile (CPP) and the Collaboration Protocol Agreement (CPA) are critical to establishing the busi- ness-to-business interoperability. The CPP specifies the interface available at a service provider, and the CPA defines the actual interface agreed to by two trading partners. Beyond this, ebXML also makes use of the Unified Modeling Language (UML) to describe the steps for designing an ebXML business process specification.
The reach of ebXML into the business process can be large. However, businesses are not required to adopt it in its entirety and can choose the parts they are comfortable adopting.
ebXML uses XML Digital Signature and XML Encryption for message security and specifies how to tailor the two standards for use with ebXML. Other security stan- dards, such as S/MIME and PGP MIME, are options for message security. In addition, the Security Assertion Markup Language (SAML) assertion is being considered as a vehicle for conveying user information for the purpose of making authorization deci- sions. We will discuss these standards in subsequent chapters of this book.
Summary
Web Services are SOAP-based interfaces to computing resources using Internet stan- dard protocols. SOAP is built on XML and XML Schema with very few required ele- ments. It is a very simple protocol that can be carried on HTTP or other Internet transport protocols. SOAP takes advantage of underlying transport protocols to pro- vide additional transport services. There are a number of complementary standards to fill in the gaps left by SOAP. UDDI registries spread the word about specific Web Ser- vices. WSDL is a formal way to describe a Web Service interface.
While Web Services make it possible for applications to interoperate, they compli- cate the security landscape. A new dimension is added to the security problem. Where end-to-end security previously meant spanning processing tiers, security must now span processing domains. The minimalist approach taken by SOAP means that the security requirements for SOAP messages are harder to understand and implement. We will discuss approaches to securing Web Services in the chapters that follow.
53
Many architects and developers will look at the diverse and complex topics described in this book and think, “I’m just building a simple Web Service application for my com- pany, and we don’t care that much about protecting sensitive data. I don’t need any- thing very fancy. Do I really need to deal with all of the security issues that you describe throughout this book?”
Perhaps not—your Web Services application may need only the bare minimum of security. If so, you may not need to implement anything more than what is described in this chapter. We give you an introduction to what you need to know to provide the most basic Web Services security solution with a minimum of effort.
Although you can work within the solution defined here, we do think that it’s important to understand what you’re notgetting when you implement something so simple. We provide several cautions and describe inherent vulnerabilities in the approach. In this manner, you can decide if a simple version of Web Services security is enough for you. If not, you will know why and have plenty of motivation for read- ing the more advanced topics in later chapters.
Although many people begin by experimenting with a simple Web Services deploy- ment, we expect that these applications are likely to evolve into more advanced archi- tectures. After all, the primary purpose of Web Services is to enable many different applications to share data across a heterogeneous environment. Web Services are expressly targeted at distributed applications that cross corporate boundaries and, consequently, are likely to have challenging security requirements. So, although you may be starting with a “harmless” Web Services application within a corporate