For this scenario, we assume that the preceding interfaces have been implemented on an application server containing J2EE, CORBA, COM+, or .NET components. A typ- ical interaction would go something like this: A customer is first authenticated to ePor- tal.com, and ePortal then gets a list of products and prices from eBusiness, using getProducts and getPrice. The customer then places an order for products into his or her account, which ePortal requests from eBusiness.com, using placeOrder. Sometime later the customer settles the orders with a credit card number, which ePortal requests from eBusiness.com by calling settleOrder. Figure 1.7 eBusiness Web Service interfaces. Users ePortal.com Visitors Customers Members Staff eBusiness.com Web Services interface Product ProductID getPrice setPrice interface Account placeOrder deleteOrder listOrders settleOrder interface ProductManager lookup getProducts 1 0 * 1 0 * interface AccountManager Create lookup delete CustomerID Overview of Web Services Security 21 Scenario Security Requirements The Web Service security policies that we define in later chapters are based on the busi- ness requirements for this example. Generally, it’s the combination of ePortal and eBusiness security mechanisms that enforces the overall business requirements for our example. We describe the business requirements for each class of user below. Visitors. To entice new customers, ePortal permits visitors who are unauthenti- cated users to browse the site. Visitors are permitted very limited access. Visitors may: ■■ See the product list, but not their prices. ■■ Register to become a customer. Visitors may create an Account, which turns the visitor into a Customer. Customers. Most users accessing ePortal are customers who are permitted to order regular products. Customers may: ■■ See the product list and prices for regular products, but not the prices for special products, which are only offered to members. ■■ Place, delete, and settle (pay for) orders. A customer may not delete his or her Account, however, and must ask someone on the ePortal staff to per- form this task. ePortal wants to make it difficult for customers to remove their affiliation with the company. Members. If approved by ePortal, some customers may become members. Mem- bers have a longstanding relationship with ePortal and are offered price breaks on special products. Other than having access to special products and prices, members exhibit the same behavior as customers. Members may: ■■ See the product list and prices for regular and special products. ■■ Place, delete, and settle (pay for) orders. A member may not delete his or her Account, however, and must ask someone on the ePortal staff to per- form this task. ePortal wants to make it difficult for members to remove their affiliation with the company. Staff. ePortal and eBusiness company staff members are responsible for admin- istering all aspects of the site. However, ePortal and eBusiness are concerned about someone on the staff committing fraud by creating fictitious customers and using stolen credit card numbers to order merchandise. To prevent this exposure, people on the staff are not permitted to settle orders on behalf of cus- tomers or members. Staff may: ■■ See the product list and prices for regular and special products and set product prices. ■■ Assist a customer or member by placing, deleting, or listing orders on their behalf. Staff may not settle orders, however—customers and members must settle their own orders. ■■ Administer customer and member accounts, including the creation, dele- tion, and looking up of the accounts. 22 Chapter 1 Summary In this chapter, we covered a large expanse of material to introduce you to the wide world of Web Services security. We started with a quick overview of Web Services and described how they are focused on helping applications communicate with each other, enabling interactions between applications residing in different companies using dif- ferent processing environments. We then described how security is an enabler for many Web Services applications: without a good security solution in place, many new e-business opportunities would not be feasible. We also discussed the concept of risk management, which balances the level of security that is required according to the business factors of cost, performance, and functionality. We showed that information security is a serious concern for many businesses, in terms of both external and internal (insider) attacks. Next, we described the need for controlling access to Web Services data without impeding the exchange of data. We described Web Services security requirements in terms of authentication, authorization, cryptography, accountability, and security administration. We then enumerated the patchwork of security mechanisms that can be used to support Web Services security: operating system security, digital signatures, J2EE, CORBA, COM+, .NET, SSO, WS-Security, and SAML, among others. We introduced Enterprise Application Security Integration (EASI), which we use to unify the many different security technologies needed to secure Web Services. We defined perimeter, middle, and back-office tiers of security and described how they all work together to provide end-to-end security. We defined an EASI solution in terms of a security framework, technologies, and integration techniques that hook those tech- nologies together. Recall that the EASI framework consists of a number of layers, including the applications, APIs, core security services, framework security services, and underlying security products. The EASI framework enables architects to design security systems that are flexible and able to meet future needs as business require- ments and technologies evolve. Finally, we introduced the eBuyer, ePortal, and eBusiness business scenario, Web Services interfaces, and security requirements. This example will be used as the basis of our security discussions in several of the later chapters. In the rest of this book we’ll expand on many of the concepts that we’ve just intro- duced. Hopefully, this chapter has laid the groundwork for your basic understanding of the security issues of Web Services. In several of the chapters, you’ll see code and XML fragments that refer to security integration technology. Rather than focus on any specific set of products, this book addresses issues that are relevant to many different application servers and security products. At Quadrasis, we have worked on a variety of Web Services security solu- tions, so we explain what we have learned about integrating security into J2EE, CORBA, COM+, and .NET environments. Our work is based on security integration in many application platform environments, including Microsoft .NET and COM+, BEA WebLogic, IBM WebSphere, Sun FORTE and JWSDP, Sysinet WASP, Hitachi TPBroker, Iona Orbix, and Inprise Visibroker. We’ve integrated application servers with many different security products, including Quadrasis Security Unifier, Netegrity Site- Minder, Entrust getAccess, and IBM/Tivoli PolicyDirector to name a few. Overview of Web Services Security 23 25 Web Services provide a way to access business or application logic using Internet- compatible protocols such as HTTP, SMTP, or FTP. Because of the widespread adoption of these protocols and formats such as XML, we expect Web Services to address many of the requirements for interoperability across independent processing environments and domains. Web Services can overcome differences in platforms, development lan- guages, and architectures, allowing organizations to perform processing tasks cooper- atively. Using XML and SOAP, systems from different domains with independent environments, different architectures, and different platforms can engage in a distrib- uted endeavor to address business needs. Distributed Computing Pressures to share information and cooperatively share processing lead to the notion of distributed processing. Traditional distributed processing models assume that there is a common environment or architecture between cooperating entities. When both par- ties try to accomplish a processing task using J2EE or COM+, a common architecture exists for the invocation of operations or sharing of data. This makes it relatively easy to connect applications. While a common architecture does not guarantee interoper- ability, it makes it easier to achieve. Web Services CHAPTER 2 It isn’t always possible for all the participants in distributed processing activities to use the same architecture and processing environment. When processing must be spread across organizations, their architectures, platforms, and development languages are likely to be different. Complications arising from mismatches in environments can exist between companies and can even exist between departments or divisions within the same company. An organization with a large investment in an existing infrastruc- ture cannot afford to change its architecture and processing capabilities, even if suc- cessful distributed processing depends on it. And, if one organization is willing to make the change to accommodate another organization, there are probably other groups it needs to work with that can’t make such an all-encompassing change. As a result, it’s unlikely that organizations will be able to use a common environment. Current processing architectures are single domain, but multitiered. That is, the pro- cessing load within a domain is spread among several systems, each handling a well- defined portion of a transaction. The systems can work sequentially or in parallel. A common division of responsibility is to have a front-end processor that handles data presentation and user interaction, a middle tier that is responsible for implementing business logic, and a back-end system that may be a data repository or a mainframe that performs batch processing. A logical extension of multitiered processing is multidomain processing. A process- ing domain is a computing facility under the control of a single organization. A domain may include many computers and utilize different processing architectures. A depart- ment or a division within a company may control a domain, or a domain may be under the control of a company. Within a large company, there may be an accounting domain and a purchasing domain. We want the accounting system to know of purchases occur- ring in the purchasing system so that the bills can be paid automatically. Between com- panies, it may be desirable for a purchasing system to request bids from and send purchase orders to vendors’ systems. Multidomain processing is generally very difficult to implement because of the dis- parate platforms, environments, and languages in different domains. One notable attempt at achieving multidomain processing is Electronic Data Inter- change (EDI). EDI is a standard format for exchanging financial or commercial infor- mation. Two versions of EDI are in use. They are Accredited Standards Committee (ASC) X12 and the International Standards Organization’s Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT). The latter standard is often referred to as UN/EDIFACT, since it was originally developed by a United Nations working party. With EDI, a company can transmit a purchase order to its vendor. Banks use EDI to send funds transfer information to financial clearinghouses. Value-added networks are used to transfer the EDI messages. EDI has existed since about 1980, and it has been used successfully by many companies. By dealing with the structure and format of data exchanged, EDI frees each party to the transaction from the requirement for a uniform computing environment. So long as the sender can construct the correct message, it does not matter what platform, operat- ing system, or application created the message. Likewise, on the receiving side, so long as the receiver can parse the message, identify the elements of interest, and process them appropriately, the processing environment at the receiver’s end is of no conse- quence. The transaction has been processed by two loosely coupled systems located in two separate domains. 26 Chapter 2 There are several reasons why EDI is not used more widely. EDI messages are rigid. The data is not self-defining, and it is presented in a prescribed order with a fixed rep- resentation. This rigid structure often needs modification when users discover needs that cannot be accommodated by the existing fields. However, EDI’s rigidity makes changes, such as adding new fields, difficult to implement. This leads to a multitude of vendor- and customer-specific implementations. Another reason for EDI’s limited acceptance is that specialized software is required, which can be very expensive. EDI documents are often transferred via specialized, value added networks, increasing cost and support requirements. Implementing EDI can be very costly, and a company needs a very compelling reason before choosing to adopt it. Distributed Processing across the Web Extensible Markup Language (XML), which is a platform-independent way to specify information, is the foundation of Web Services. SOAP, which originally stood for Sim- ple Object Access Protocol (newer versions of the specification do not use it as an acronym), builds on XML and supports the exchange of information in a decentralized and distributed environment. SOAP consists of a set of rules for encoding information and a way to represent remote procedure calls and responses, allowing true distrib- uted processing across the Web. XML and SOAP enable platform- and data-indepen- dent interfaces to applications. Because Web Services are usually built on HTTP, they can be delivered with little change to existing infrastructures, including firewalls. UDDI and WSDL also support Web Services. Universal Description, Discovery, and Integration (UDDI) is a mechanism for discovering where specific Web Services are provided and who provides them. Web Services Description Language (WSDL) speci- fies the interfaces to these Web Services, what data must be provided, and what is returned. SOAP, UDDI, and WSDL are the underlying technologies upon which Web Services are based. Using these protocols (shown in Figure 2.1), systems from different domains, independent environments, or with different architectures can engage in a cooperative manner to implement business functions. SOAP, UDDI, and WSDL are built using XML and various Internet protocols such as HTTP. Figure 2.1 Web Services building blocks. Web Services XML and other XML related standards Internet Protocols smtphttp ftp UDDISOAP WSDL Web Services 27 SOAP, UDDI and WSDL are used in different phases, called publishing, finding, and binding, in the Web Services development cycle. The Publish, Find, and Bind Model is shown in Figure 2.2. The model begins with the publish phase, when an organization decides to offer a Web Service (1). The Web Service can be an existing application with a new Web Ser- vice front end, or it can be a totally new application. Once an enterprise has developed the application and made it available as a Web Service, the enterprise describes the interface to the application so that potential users interested in subscribing to it can understand how to access it. This description can be oral, in some human language such as English, or it can be in a form, such as WSDL, that can be understood by Web Services development tools. To facilitate automated lookups, the service provider advertises the existence of the service by publishing it in a registry (2). Paper publica- tions or traditional Web Services can provide this service, or UDDI directories can advertise the existence of the Web Service. The next step of the model is the find phase. Once the service is advertised in a UDDI registry, potential subscribers can search for possible providers (3 and 4) and implement applications that utilize the service (5). Potential subscribers use the entries in the registry to learn about the company offering the service, the service being offered, and the interface to the service. The final phase of the model is the bind phase. When a subscriber decides to use a published service, it must implement the service interface, also called binding to the service, and negotiate with the service provider for the use of the service. The negotia- tion can cover mutual responsibilities, fees, and service levels. When the application has been implemented and the business relationships resolved, the Web Service is utilized operationally. The only participants at this point are the service subscriber, who requests the service (6), and the service provider, who delivers the service (7). WSDL and UDDI registries are generally only used during the initial discovery of the service and the design of the application. Figure 2.2 Web Services development phases. Universal Description Discovery and Integration (UDDI) Registry Service Provider 1. Develop service, document interface 5. Develop application and bind to service Service Subscriber/ Requester 4. List of Service Providers and Descriptions 2. Publish service in directory 3. Find Service Providers 6. Request Service 7. Deliver Service 28 Chapter 2 Web Services Pros and Cons Web Services have many advantages that were not enjoyed by earlier attempts at cross- domain interoperability. Since Web Services are in the early phase of adoption, we can- not readily point to many actual implementations that prove Web Services live up to expectations. Nevertheless, Web Services have many characteristics that set them apart from solutions that came before them and make Web Services more likely to succeed. The advantages of Web Services are: ■■ Web Services processing is loosely coupled. Earlier attempts to address cross-domain interoperability often assumed a common application environ- ment at both ends of a transaction. Web Services allow the subscriber and provider to adopt the technology that is most suited to their needs to do the actual processing. ■■ Web Services use XML-based messages. Web Services using XML have a flexible model for data interchange that is independent of the computing environment. ■■ Participating in Web Services does not require abandoning existing invest- ments in software. Existing applications can be used for Web Services by adding a Web Services front end. This makes possible the gradual adoption of Web Services. ■■ Software vendors are coming out with tools to support the use of Web Services. Organizations can use currently available tools from vendors such as IBM, Microsoft, Sun, and others. There is no delay between interest in the technology and the availability of tools to implement and use Web Services. ■■ There is a lot of emphasis on the interoperability of Web Services. Web Services tool developers are working to demonstrate interoperability between imple- mentations. It’s likely that this will pay off and allow developers to choose tools from one vendor and be confident that they will be able to interoperate with other implementations. ■■ The modular way Web Services are being defined allows implementers to pick and choose what techniques they will adopt. Other than having a basis in XML, SOAP, UDDI, and WSDL, the building blocks of Web Services have related, but independent capabilities. They are not tightly coupled and don’t depend on each other to function. ■■ Use of Internet standard protocols means that most organizations already have much of the communications software and infrastructure needed to support Web Services. Few new protocols need to be supported, and existing develop- ment environments and languages can be used. ■■ Web Services can be built and interoperate independently of the underlying programming language and operating system. In organizations where there isn’t a single standard, Web Services make interoperability possible, even when one part of the organization uses .NET, while another portion uses Java, to build their Web services, and other organizations use other technologies. Web Services 29 Reservations about Web Services fall into two categories. First, Web Services are not proven technology; there is some suspicion that Web Services are the fashionable solu- tion of the day. That is, some think that Web Services are the current fad, and like many other solutions to the distributed processing problem from the past, they will not deliver. While we cannot disprove this, the advantages that Web Services have over past solutions are significant. The second reservation about Web Services centers on its reliance on XML. While there are many advantages to XML, size is not one of them. Use of XML expands the size of data several times over. The size of a SOAP message translates into more stor- age and transmission time. The flexibility of SOAP means that more processing is needed to format and parse messages. Do the advantages of XML outweigh the addi- tional storage requirements, transmission time, and processing needed? The answer is a qualified yes. The flexibility offered by XML is required when trying to connect two dissimilar processing environments in a useful way. Spanning processing domains requires a flexible representation. However, once a message is within a single environ- ment, on either side of the connection, implementers must decide the extent to which XML is required. XML will not always be the choice to represent data within a single processing domain. Extensible Markup Language In order to understand Web Services, the reader must understand XML. Much of what we’ll be discussing in this chapter, and other chapters in this book, is based on XML. You’ll see it in many of our examples. XML is a derivative of the Standard General Markup Language (SGML) (ISO 1986). SGML is an international standard for defining electronic documents and has existed as an ISO standard since 1986. SGML is a meta document definition language used for describing many document types. It specifies ways to describe portions of a document with identifying tags. Specific document types are defined by a document type defini- tion (DTD). A DTD may have an associated parser, which is software that processes that document type. HTML, an SGML application, has been well accepted on the Web but regarded as limited because of its fixed set of tags and attributes. What was needed was a way to define other kinds of Internet documents with their own markups, which led to the creation of XML. Work on XML began in 1996, under the auspices of the World Wide Web Consortium (W3C). The XML Special Interest Group, chaired by Jon Bosak of Sun Microsystems, took on the work. It was adopted as a W3C Recommendation in 1998 (W3C 2000). XML is a specialized version of SGML used to describe electronic documents avail- able over the Internet. Like SGML, XML is a document definition metalanguage. Since XML is a subset of SGML, XML documents are legal SGML documents. However, not all SGML documents are legal XML documents. XML describes the structure of electronic documents by specifying the tags that identify and delimit portions of documents. Each of these portions is called an element. Elements can be nested. The top-level element is called the root. Elements enclosed by the root are its child elements. Each one of these elements can, in turn, have its own 30 Chapter 2 [...]... support mid-tier security services include component-based security servers, cryptographic protocols, and entitlement servers We discuss componentbased security servers extensively in Chapter 7, Security of Infrastructures for Web Services, ” since much of the security infrastructure for Web Services is built on top of component-based systems such as J2EE, COM+, NET, and CORBA Security services in the... detection in Chapter 12, “Planning and Building a Secure Web Services Architecture.” Next, we briefly describe mid-tier and back-office security so you have some perspective on how Web Services security relates to other security mechanisms used throughout the enterprise For more advanced applications, you’ll need to understand in more detail how Web Services security fits together with other security technologies... March 20 00, IBM joined the group and worked on the SOAP 1.1 specification The 1.1 version was adopted by the W3C as a recommendation SOAP version 1 .2 currently exists as a series of working drafts (W3C 20 02e, W3C 20 02f) In addition to the working drafts, there is a SOAP 1 .2 Primer (W3C 20 02d) that takes the information in the working drafts and describes SOAP features using actual SOAP messages Web Services. .. tier security services focus on cryptography, authentication, authorization, and accountability Technologies supporting back-office security services include mainframe security and database security, which we discuss in Chapter 12 In the sections that follow, we provide the basics on a set of security technologies for the perimeter tier that will be enough to get you started with Web Services security. .. specific Web Services WSDL is a formal way to describe a Web Service interface While Web Services make it possible for applications to interoperate, they complicate 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. .. describing security fundamentals that are the basis of all security architectures Whether you are building a Web Service application for a small mom-and-pop storefront or a huge multinational conglomerate, you need to understand these fundamental security requirements We then walk you through a Web Services security example that takes advantage of the basic security functionality provided by NET Security. .. client invoking on a target or accessing back-office resources ■ ■ Security administration, which maintains the security policy embodied in user profiles, access control lists (ACLs), passwords, and other data relevant to the security technology Getting Started with Web Services Security Perimeter Security Mid-tier Security Back-office Security First line of defense; protection against external hackers:... of back-end servers: Component-based security Cryptography Entitlement servers Mainframe security Database security Firewalls/VPNs Cryptography Web- based security servers Intrusion detection Legacy Connectors Application Server HTTP Client Web Server Application Server Data Access Data Stores Application Server Figure 3.1 Enterprise security technologies Security services in the perimeter tier face... published it as a note (W3C 20 01b) in March 20 01 The W3C Web Services Description Working Group is now working on further development of the language Earlier, we discussed concerns about the verbosity of XML WSDL expands XML several times over Luckily, WSDL is usually only used during design and development of Web Services applications We should also note that even though WSDL is Web Services text-based,... end-to-end solution Chapter 12 discusses this topic in depth in the context of building integrated Web Services systems Security services in the mid-tier provide a general set of protection mechanisms for the business logic Mid-tier security technologies are, in effect, extensions to the underlying operating system because they provide security at the application layer similar to the security that operating . security products, including Quadrasis Security Unifier, Netegrity Site- Minder, Entrust getAccess, and IBM/Tivoli PolicyDirector to name a few. Overview of Web Services Security 23 25 Web Services. other technologies. Web Services 29 Reservations about Web Services fall into two categories. First, Web Services are not proven technology; there is some suspicion that Web Services are the fashionable. protocols such as HTTP. Figure 2. 1 Web Services building blocks. Web Services XML and other XML related standards Internet Protocols smtphttp ftp UDDISOAP WSDL Web Services 27 SOAP, UDDI and WSDL are