Mastering Web Services Security phần 3 docx

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. 68 Chapter 3 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. Getting Started with Web Services Security 69 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. 70 Chapter 3 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. Getting Started with Web Services Security 71 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. Public Key Algorithms As you recall from Chapter 3, public key or asymmetric cryptography uses two different, but mathematically related, keys. There are several public key algorithms. Although there are differences in their operation, they can be divided into two general approaches for encryption and two for digital signature. ENCRYPTION ■■ RSA ■■ Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) XML Security and WS-Security CHAPTER 4 DIGITAL SIGNATURE ■■ RSA ■■ Digital Signature Algorithm (DSA) or Elliptic Curve DSA (ECDSA) When a public key algorithm is incorporated into a system, it is combined with a faster algorithm that makes the system useable with large amounts of data. We will first discuss encryption and then digital signatures. Encryption Encryption provides confidentiality. It does this by preventing data from being under- stood except by the intended recipient. This is true even if the encrypted data falls into the hands of unintended recipients. Encryption provides a form of access control by virtue of the management of keys. Only the intended recipient or recipients have the keys needed to decrypt the data and thus access it. There are two generally used public key techniques that support the encryption of data: RSA and Diffie-Hellman. We say support because public key algorithms are too computationally expensive to use for data encryption. That is, using public key cryp- tography for encryption is time consuming and eats into performance. So, instead of encrypting data directly, public key algorithms are used with a symmetric key algo- rithm to protect data. RSA RSA, named for Ronald Rivest, Adi Shamir, and Leonard Adleman, the developers of the algorithm, is the best known of all the public key algorithms. When people are asked to describe public key cryptography, they describe the operation of RSA. The key feature of RSA is that it is a reversible algorithm. (Technically, RSA, or any public key algorithm, is not reversible. Public key algorithms are one-way functions. We say RSA is reversible because the data that was transformed with one key can be recovered with a different key.) With RSA, we can use a private key to recover the data that was previously encrypted using the public key. This concept is illustrated in Figure 4.1. With RSA, the public key is used to encrypt data. The private key is used to decrypt the data. Since the public key is available to anyone, but only the owner of the key pair has the private key, anyone can encrypt data meant for the key’s owner, and only the key’s owner can decrypt the data. Figure 4.1 RSA encryption and decryption. RSA Encryption Encrypted Data Unencrypted Data Unencrypted Data RSA Decryption Public Key Private Key 74 Chapter 4 Figure 4.2 RSA-based encryption and decryption system. When implemented as part of an encryption system, RSA is used to encrypt a sym- metric key that actually encrypts the data. This is illustrated in Figure 4.2. In this exam- ple, Bob wants to send Alice information in such a way that only Alice is able to understand it. 1. Bob begins by generating a symmetric key. 2. He uses this key to encrypt the data with a symmetric algorithm such as DES. 3. Using Alice’s public key, he encrypts the symmetric key, which is then appended to the encrypted message. This encryption ensures that only Alice can decrypt and make use of the symmetric key. 4. Once the message is received, Alice extracts the encrypted symmetric key from the message and decrypts it using her private key. 5. Using the recovered symmetric key, Alice decrypts the entire message. Diffie-Hellman, Elliptic Curve Diffie-Hellman Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) are key agreement algorithms. The algorithm is named for Whitfield Diffie and Martin Hellman, the developers of the algorithm. In key agreement, two parties exchange information that allows them to derive a shared secret. Unauthorized parties can intercept the informa- tion exchanged but they are not able to determine the shared secret. This shared secret can then be used as a key for a symmetric algorithm. The DH key agreement process is shown in Figure 4.3. In the figure, two parties, Bob and Alice, wish to exchange sensi- tive information so they use encryption. RSA Encryption (3) Alice's Public Key RSA Decryption (4) Alice's Private Key Generate Symmetric Key (1) Symmetric Key Encryption (2) Symmetric Key Symmetric Key Encrypted Symmetric Key Encrypted Data Encrypted Data + Encrypted Key Encrypted Data Unencrypted Data Unencrypted Data Symmetric Key Decryption (5) XML Security and WS-Security 75 Figure 4.3 Diffie-Hellman key agreement. 1. Bob sends Alice his public keying material. (This isn’t a key. Instead, it is infor- mation that allows a key to be derived.) 2. Alice sends Bob her public keying material. 3. Each uses this information and the DH algorithm to derive a common secret. 4. Bob uses the secret as a key to encrypt data sent to Alice using a symmetric key algorithm. 5. Alice uses the secret to decrypt the data Bob sends. Figure 4.4 shows how DH can be used as part of an encryption system. The exchange of the keying material does not have to be as interactive as the previous dis- cussion implies. It does not have to be synchronous. Public keying material can be pub- lished in a well-known location, well in advance so that one party can readily pick up the data when he or she needs it, rather than counting on the other party to send it. The following scenario demonstrates an asynchronous exchange: 1. Alice places her keying material in a directory for Bob to pick up when he wants. 2. Bob gets Alice’s DH public keying information from the directory. 3. He generates unique keying material for this particular exchange. This is dis- tinct from the keying material that he may already have published for himself in a directory. It prevents the reuse of the same symmetric key for all communi- cation between the two of them. Alice's Public Keying Material (2) Bob's Public Keying Material (1) Unencrypted Data Decryption Data Symmetric Key Encryption (4) Diffie- Hellman Key Agreement (3) Diffie- Hellman Key Agreement (3) Bob Bob's Private Keying Material Alice Alice's Private Keying Material Key = X Symmetric Key Encryption (5) Key = X Alice's Private Keying Material, Bob's Public Keying Material Bob's Private Keying Material, Alice's Public Keying Material Encrypted Data 76 Chapter 4 4. Bob uses his private keying material with Alice’s published, public keying material to derive the symmetric key for this message exchange. 5. Using the symmetric key, he encrypts the message to Alice. 6. He appends his public keying material for this message exchange onto the encrypted message and sends the combination to Alice. 7. She extracts Bob’s keying information, combines it with her private keying material and derives the symmetric key. 8. She uses this key to decrypt the message. One drawback to the Diffie-Hellman system is that the symmetric key used for the encryption depends on information sent from the sender and the receiver. If a message is destined to go to multiple recipients, it must be encrypted multiple times. With RSA, the message is encrypted once, and only the symmetric key is encrypted multiple times, once using the public key of each recipient. The preceding discussion used Diffie-Hellman as the key agreement algorithm. If we had used ECDH, the process would have been very similar. However, in elliptic curve cryptography, we use points defined by an elliptic curve in a finite field rather than using the integers modulo, some prime number, as in Diffie-Hellman. Figure 4.4 Diffie-Hellman-based encryption system. Encrypted Data Encrypted Data + Bob's Public Keying Material (6) Bob's Public Keying Material Alice's Public Keying Material (2) Alice's Public Keying Material (1) Unencrypted Data Unencrypted Data Symmetric Key Encryption (5) Diffie- Hellman Key Agreement (4) Diffie- Hellman Key Agreement (7) Bob Alice Alice's Private Keying Material Key = X Symmetric Key Decryption (8) Key = X Encrypted Data Generate Public/ Private Keying Material (3) Alice's Private Keying Material Bob's Private Keying Material, Alice's Public Keying Material XML Security and WS-Security 77 [...]... structure XML Security and WS -Security WS -Security IBM and Microsoft have begun a joint initiative to define an architecture and roadmap to address gaps between existing security standards and Web Services and SOAP The first results of the initiative have been published in Security in a Web Services World: A Proposed Architecture and Roadmap (IBM and Microsoft 2002a) and Web Services Security (WS -Security) ,... available It addresses single-message, end-toend security There are specific security services for ensuring Web Services message integrity and confidentiality and for associating security- related claims with Web Services messages The specification team extensively leveraged XML Signature and XML Encryption for Web Services message integrity and confidentiality WS -Security requires compliance with both these... in Chapter 5, Security Assertion Markup Language,” and Chapter 10, “Interoperability of Web Services Security Technologies.” The WS -Security initiative defines a single security model that abstracts security services, thereby separating the functional security characteristics of the system from the specifics of the implementation The model serves as a means to unify formerly dissimilar security technologies... business Several of the later chapters describe various ways that the XML security and WS -Security standards may be used to secure Web Services implementations CHAPTER 5 Security Assertion Markup Language One of the main problems that needs to be solved in distributed Web Services security is how to unambiguously interpret security context information when that data has been transferred from a source... proof, or a security token service can provide the proof Sometimes, proof-of-possession in combination with other claims will be accepted as adequate proof XML Security and WS -Security Security Element WS -Security defines a security element of the SOAP message The security element is contained in the SOAP message header and is targeted at a specific role This means that there can be multiple security. .. 97 98 Chapter 4 . 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 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. 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,