Mastering Web Services Security - part 2

Overview of Web Services Security 21 For this scenario, we assume that the preceding interfaces have been implemented on an application server containing J2EE, CORBA, COM+, or .NET components. Atyp-ical interaction would go something like this: Acustomer 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. eBusiness.com Web Services interface ProductManager lookup getProducts 1 Users ePortal.com 0..* interface Product ProductID getPrice setPrice Visitors Customers Members Staff interface AccountManager Create lookup delete 1 0..* interface Account CustomerID placeOrder deleteOrder listOrders settleOrder Figure 1.7 eBusiness Web Service interfaces. 22 Chapter 1 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. Acustomer 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. Amember 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. Overview of Web Services Security 23 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. CHAPTER 2 Web Services 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. 25 ... - tailieumienphi.vn