This example manages to provide a reasonable degree of security for ePortal and eBusiness. However, our security scenario does have several limitations, which we explore below.
We have set up this example with Microsoft technology exclusively. Using technol- ogy from any one vendor is always the easiest, because vendors want to ensure that the solutions they provide are self-contained. However, a single-technology solution is not acceptable for many Web Services deployments. In fact, one of the main advantages of Web Services is their ability to support cross-vendor applications, such as .NET sys- tems connecting to J2EE environments. Users of Web Services want to connect applica- tions across enterprise lines of business, or across enterprise boundaries. If the security technologies used by Web Services clients and servers are required to be identical, this limitation eliminates one of the primary advantages of Web Services. Much of this book discusses how to apply Web Services security when Web Services clients and servers use different and potentially incompatible security technologies. We discuss techniques to support secure interoperability in Chapter 10, “Interoperability of Web Services Security Technologies.”
Our example relies heavily on IIS security mechanisms, both to authenticate users and protect traffic. Web servers from all vendors, and from Microsoft in particular, have come under heavy attack as sources of vulnerability. We see a constant stream of Web server patches to address new vulnerabilities, which continue to be discovered at an alarming rate. This is not a surprise, considering the extensive and complex features offered by Web Services products—there are plenty of ways to inadvertently create security holes in any complex software. Because a primary purpose of Web Services is to enable flexible remote procedure call (RPC) access to applications, the stakes for Web server vulnerabilities become much higher. A weakness that is exploited in the Web server could expose your entire corporate network.
If IIS security were compromised in this sample system, eBusiness applications would be wide open, and attackers could potentially commit fraudulent purchases. A better approach would be to provide additional layers of protection so that if an IIS security weakness were exploited other protective mechanisms would limit the dam- age that could occur. Many of the later chapters in this book discuss techniques to enforce security at multiple tiers in the architecture and avoid a single point of failure. Our example provides no accountability service to record accesses in a security audit log. Such a service would be valuable for tracing the source of an attack after it has occurred. Because Web Services are so new there is little available in terms of secu- rity auditing. However, as described in Chapter 7, many of the underlying infrastruc- tures for Web Services provide a basic security auditing capability.
Cryptography
Our example uses SSL, which does a fine job of protecting the contents of a message as it travels across the network. However, security mechanisms like SSL have their limi- tations.
First, because SSL works at the transport layer, it’s all-or-nothing security—either the entire message body is encrypted or none of it is. For small messages, encrypting the entire message is acceptable, but for very large messages the overhead of encrypt- ing the entire message may make the process too slow. In cases where a lot of data is transmitted but only a small fraction of it needs to be protected, transport layer secu- rity is not a good solution.
In addition, SSL transport layer protects traffic in a point-to-point fashion, but it exposes the data contents at intermediate locations. In our example, the HTTP traffic is encrypted when traveling from browser to ePortal, decrypted and exposed within the ePortal site, reencrypted when traveling from ePortal, and then decrypted at eBusi- ness. When ePortal is a completely trustworthy site, permitting it to view all traffic content is an acceptable risk, but in some cases this model may not be appropriate. For example, eBusiness may not be willing to permit ePortal to view credit card informa- tion, even though ePortal provides this information on behalf of its clients. In our example, there is no reason for ePortal to have access to credit card information since eBusiness is handling the order processing.
In both of these cases, a better approach is to encrypt only the small portion of the message that needs to be protected rather than relying on SSL transport. Allowing clients to selectively encrypt data lets them send data through ePortal to eBusiness without ePortal being able to view or manipulate the data. This approach requires message-level security, which we describe in Chapter 4.
Authentication
The password authentication mechanism we use for the example is easy to set up, but it has a number of problems that you should be aware of.
As we have mentioned previously, password-based authentication provides weak security, and it is risky to use for high-value transactions. The human-engineering issues relating to passwords are difficult to address. On one hand simple passwords are easy to guess; on the other hand complex passwords are easy to steal (no one can remember them, so people write them down). At least our example ensures that the passwords are not exposed on the Internet, which would make them highly vulnerable.
A more subtle limitation is the impersonation model used by the example. The client sends its username and password to ePortal, and ePortal impersonates the user when making the SOAP request to eBusiness by forwarding the same username and pass- word. As far as eBusiness is concerned, it thinks it is receiving the request directly from the user. If the eBusiness StoreFrontService needs to access other applications (such as the COM+ server), StoreFrontService will again impersonate the user by forwarding the same username and password.
It doesn’t take much thought to realize that this approach can cause passwords to proliferate to many different servers. In fact, there is no way to tell where a user’s pass- word may end up. This model assumes that all servers are equally trustworthy, and that is a bad assumption to make in most distributed systems. If an attacker compro- mises any one of those systems, all of the passwords will be discovered, and the rest of the systems will fall like dominoes. Further, there is nothing to prevent an insider attack on a server like ePortal, to abuse its ability to impersonate users and perform actions that were not intended by the user, such as buying extra merchandise that dis- appears off the loading dock.
As we discussed earlier, sharing the same password authentication technology between ePortal and eBusiness made this example easy to implement and allowed us to use Microsoft products that can transparently handle the password credentials.
However, it would be more likely for Web Services applications to use different authentication mechanisms and databases. If ePortal and eBusiness were different companies, there would not be much of a chance that they would share their database of users and passwords as they do in this example. Furthermore, authentication schemes like this one that are tightly coupled to OS accounts do not scale well to very large distributed applications with many thousands of users. Web Services applica- tions with large numbers of users would probably not use OS-based authentication, and would use a Web SSO authentication system instead.
A more typical cross-enterprise scenario would be for ePortal to authenticate the user with its own database, and then pass evidence of that authentication (rather than the password itself) to eBusiness. In addition, ePortal might keep track of the customer, member, and staff role memberships, and pass both the user’s identity and role to eBusiness. In this case, eBusiness would not need to reauthenticate the user but instead would verify that the user and role information came from a trustworthy source (namely ePortal) that vouches for the authentication information. We describe cross- enterprise security issues in Chapters 6 and 10.
Authorization
Finally, we come to our choice of authorization, which is barely adequate even for this simple example. We chose to use DACLs to enforce security based on Windows file system OS protections. Windows will perform this check transparently for us, but the difficulty in the granularity of the access check is that file system access is too coarse for our Web Services model. We want to enforce access to different Web Services methods based on the user roles, but file system protections will not provide this for us. All methods for an ASP.NET Web Service are defined within the same file, so the OS can- not tell the difference between one method and another.
Consequently, we will have a very difficult time enforcing the authorization policy we want in our example. We could split up our single StoreFrontService into separate ones for visitors, customers, members, and staff, but this approach would be awkward and would require redundant implementations for the methods that are used by more than one role. We discuss better and more sophisticated approaches to enforce fine- grained authorization in Chapters 7, 8, and 9.
Summary
In this chapter, we provided an overview to a variety of security technologies that are the basis for all security architectures. We gave an overview of perimeter, middle, and back-office tier security services. Perimeter security serves as the first line of defense and primarily protects against hostile attackers who are outside of an organization. Mid-tier security serves as the second line of defense, providing another layer of pro- tection against external attackers, and also protecting against attackers who are within an organization. Back-office security provides the third layer of defense by protecting the back-end servers, ensuring that an organization’s most valuable resources are safe from unauthorized access.
We then concentrated on the set of perimeter security technologies that are the start- ing point for Web Services security: cryptography, authentication, and authorization. We introduced the concepts of secret and public key cryptography, and public key cer- tificates. Authentication starts with passwords and then expands to stronger forms of security that have cryptographic foundations, such as the SSL and Kerberos protocols. The various authentication mechanisms may be used to provide authentication sys- tems such as OS-based, Web server-based, token-based, Web SSO, Client-server SSO, and biometrics. Authentication, in turn, serves as the foundation on which to make authorization decisions. The security services described in this chapter define only the bare essentials; several subsequent chapters expand on these topics and explore more advanced security mechanisms.
We then walked you through a Web Services security example that takes advantage of the basic security functionality provided by .NET. This example gives a fairly complete initial view of Web Services security issues and demonstrates that security doesn’t have to be very complex to implement. However, we describe several signifi- cant limitations of the example that should help you think through your own Web Ser- vices security requirements. We hope that these limitations give you motivation to read on through the rest of the book, which provides guidance and solutions for the issues we raised in this chapter.
The next chapters explore a number of different aspects of Web Services in the real world that are well beyond the simple example we presented here. Chapters 4, 5, 6, and 7 discuss the underlying technologies for securing Web Services including XML doc- ument security, Security Assertion Markup Language (SAML), Web Services security principles, and application platform security infrastructure. When you get through these chapters, you will have a good understanding of what makes a Web Service secure, and you will be ready for the advanced topics described in the remaining chapters.
73
This chapter discusses measures that can be used with XML and SOAP messages to secure them. As you will see, these measures are based on cryptography. In Chapter 3, “Getting Started with Web Services Security,” we introduced the basic concept of pub- lic key cryptography. In this chapter, we expand on this topic and show how cryptog- raphy can be applied to XML. Finally, we discuss how such measures are being tailored to SOAP and Web Services using WS-Security.