Download (direct link):
Orchestration Products and Technologies
Back in 2000, Microsoft's BizTalk Server was released for the purpose of orchestrating Web service and enterprise applications. BizTalk uses XLANG, Microsoft's XML-based orchestration language, to define process flow and conversations between Web services. At the same time, other products, such as BEA, Iona, and IBM have developed similar products. IBM later developed Web Services Flow Language (WSFL) to describe how Web services can be composed into new Web services. WSFL describes interactions between multiple Web services and is similar in purpose to XLANG. Many believe that IBM's
WSFL and Microsoft's XLANG will agree to submit a joint proposal to the W3C to create a standard orchestration language.
Securing Web Services
One of the biggest concerns in the deployment of Web services today is security. In a distributed Internet environment where portals may talk to other Web services, which in turn talk to other Web services, how can we know the identity of who's getting the information? How can we know what information that user is allowed to see? With online transactions, how can we have some assurance that the transaction is valid? How can we keep sensitive information transfers confidential? How can we prove, in a court of law, that someone accessed information? How can we know that a user's transmission hasn't been intercepted and changed? In this section we address some of these issues and discuss evolving security solutions.
Although some of the questions related to Web services and Internet security may seem troubling, the good news is that for most internal Web service architectures (intranet and, to some extent, extranet), these security issues can be minimized.
This is why internal EAI projects will be the first areas of major Web service rollouts. Another good piece of news is that Web services security standards are evolving rapidly. We provide an overview in this chapter.
One of the reasons that many system integrators appreciate Web services is that SOAP rides on a standard protocol. Because SOAP lies on an HTTP transport, firewalls that accept HTTP requests into their network allow communication to happen. In the past, system integrators have had to worry about the use of specialized network ports, such as those used for CORBAIIOP and Java RMI, and networks that wanted to communicate over those mediums had to "open up" ports in their firewalls. SOAP's firewall-accepted underlying HTTP protocol presents a double-edged sword. Unfortunately, because firewalls are not necessarily smart enough to analyze SOAP requests, the security protection now lies on the implementation of the Web services themselves. Many security analysts believe that allowing SOAP procedure calls into your network, without additional security measures, opens up potential vulnerabilities. Many cryptanalysts, such as Counterpane's Bruce Schneier, argue that the mind-set of promoting SOAP specifically for "security avoidance" in firewalls, needs to go.1 Believe it or not, this is only one of the issues involved in Web services security.
1Bruce Schneier, "Cryptogram Monthly Newsletter," February 15, 2002, http://www .counterpane.com/crypto-gram-0202.html#2.
Understanding Web Services
For the purpose of simplicity, we will list a few basic terms that will establish a common vocabulary of security concerns and explain how they are related to Web services security:
Authentication. This means validating identity. In a Web services environment, it may be important to initially validate a user's identity in certain transactions. Usually, an organization's infrastructure provides mechanisms for proving a user's identity. Mutual authentication means proving the identity of both parties involved in communication, and this is done using special security protocols. Message origin authentication is used to make certain that the message was sent by the expected sender and that it was not "replayed."
Authorization. Once a user's identity is validated, it is important to know what the user has permission to do. Authorization means determining a user's permissions. Usually, an organization's infrastructure provides mechanisms (such as access control lists and directories) for finding a user's permissions and roles.
Single sign-on (SSO). Although this term may not fit with the other security terms in this list, it is a popular feature that should be discussed. SSO is a concept, or a technical mechanism, that allows the user to only authenticate once to her client, so that she does not have to memorize many usernames and passwords for other Web sites, Web services, and server applications. SSO blends the concepts of authentication and authorization; enabling other servers to validate a user's identity and what the user is allowed to do. There are many technology enablers for SSO, including Kerberos, Secure Assertion Markup Language (SAML), and other cryptographic protocols.