One of the weaknesses of Web services that we talked about in Hour 3, “Disadvantages and Pitfalls of Web Services,” was security. The problem is not the lack of a Web services security mechanism, but the lack of agreement on what that mechanism (or mechanisms) should be. As of this writing, security is one of the topics normally relegated to the undefined part of the SOAP header.
In this hour, we will discuss some of the proposals that have a good chance of one day making up part of the standards that get adopted. We start with an overall discussion of computer program security. Following that, we will look at applying a traditional approach, the Secure Socket Layer, to Web services. Next, we will look at two established recommendations (quasi-standards)—XML Signature and XML Encryption. Finally, we look at the proposed SAML and WS-Security standards.
In this hour you will learn about
The openness of the Internet is one of its greatest assets. From the standpoint of security, however, this openness is its greatest liability. It is great to be able to connect and order an authentic South Korean Soccer Team home jersey from a Web site in Hong Kong. If you think about the number of wires that your request (that includes your credit card number) has to travel over and the number of different hubs that it must pass through to get there, you will be nervous. It you add to that fear the fact that these transactions are very attractive to criminals, you would have a justifiable panic.
Securing Web services is a conceptually simple topic. Although the details of how to program different techniques and implement different technologies can seem complex, the issues are easy to understand. For an XML transaction between your computer and mine to complete securely, you have to be able to say the following:
Authenticity—. We are certain that the Web services transaction took place between my client and your server. Another client could impersonate me, or another server could pose as you.
Privacy—. We are sure that our messages and responses were not “overheard” by any unauthorized person.
Integrity—. We are both sure that every message that the client sent to the server and that the server sent to the client arrived unaltered.
Nonrepudiation—. Both the client and the server can prove to everyone’s satisfaction (including each other) that the transaction actually took place (if a question were to arise) and that the parties involved were indeed who they said they were.
We often hear that there is no such thing as a completely secure computer transaction. This is true in the sense that someone with enough motivation, money, knowledge, and time can find a way to break into any system, regardless of the security measures taken in advance. The vast majority of all transactions, however, take place in a completely secure fashion—if only by virtue of the fact that no one is listening to or trying to hack it. If a banking system that has been running for five years is attacked successfully and a thousand transactions are observed, it is considered a serious breach.
When speaking of the seriousness of a threat, we have to consider two different measurements. The first is how likely an attack is to occur and succeed. As annoying as a stolen credit card number is, it is not really that hard to remedy, given the laws governing them. For example, most credit card companies limit the liability of the cardholder to $50 or less. This means that most of the cost of any fraudulent transactions charged to your card is born by the credit card company. If you use the Internet for a lot of transactions, there is a small chance that one day a credit card number of yours will be hijacked.
The second consideration is the amount of damage that could be caused if an attack succeeds. If you were sending a message that listed the names and addresses of all the spies in a hostile country, an interception could cause the death of many people or even the loss of a war. For this reason, threats that are unlikely, but catastrophic, are treated with great seriousness.
In this hour, we will refer to any message that you want to protect as a target. Doing work to make a target more secure will be referred to as hardening the target.
Your job, as a Web services software engineer, is to harden a target so that it is more expensive to break into than it is worth. The level of security you need to provide will vary according to the value of the target. Attractive targets, such as international money transfer messages, demand a very high level of hardening. A wire transfer withdrawal of $200.00 from a mom to her son at the bus station requires less hardening, but it still requires some. An XML draft of the presentation that you are going to make at the next Kennel Club national convention probably does not need any hardening at all.
Your job is to impose costs on any would-be snooper or electronic vandal. If the costs that you impose exceed the rewards of intercepting your message, you can reasonably expect that the criminal will simply move on to other, softer targets.
Any attempt by an unauthorized person to access a target is called an attack. Every attack has unique characteristics, but in general they can be grouped in the following categories:
Theft of Information—. Some information is very valuable to a thief. Credit card numbers and personal identification numbers (PINs) for automated teller machines (ATMs) are very popular because they can provide quick access to your money.
Unauthorized Modification—. Many messages could contain information that must arrive unaltered. Intercepting, altering, and forwarding a message could cause serious problems.
Impersonation—. Many attacks occur when your system thinks that it is communicating with an authorized user when, in reality, it is communicating with a criminal.
Some Web services have characteristics that make them more likely to be attacked in one way than in another. A banking system might be more likely to suffer from a theft of information than from unauthorized modification. Your security strategy for each Web service will need to be tailored based on these characteristics.
Fortunately for us, the Internet’s security infrastructure was created long before Web services came into being. This infrastructure was created to facilitate the transfer of private information across the Internet from browsers to Web sites. The establishment of online stores such as Amazon.com and Buy.com drove much of the demand for this.
A key piece of this infrastructure is the public key certificate. A person or organization who wants to engage in secure Internet communication can obtain a public key certificate that identifies him to actual and potential Web services trading partners. Certificate authorities such as VeriSign issue these certificates.
Certificate authorities are trusted companies who create certificates in accordance with the ITU-T X.509 Certificate Standard. They normally gather quite a bit of information about an applicant before granting him a certificate. Much of this information is placed inside the certificate before it is encoded with the authorities’ private key. Two companies who provide these certificates are VeriSign, www.verisign.com, and Thawte, www.thawte.com.
The process of creating a certificate begins with the creation of a public/private key pair. The public key is made available by the owner to anyone who wants to see it, but the owner keeps the private key secret. These two keys are related mathematically, but it is computationally infeasible to try and calculate the private key given the public key.
For example, a person armed with your public key can encrypt messages that only you can decrypt because you are the only one who possesses the private key. Public keys have two features to make them useful. It is very difficult to use only a public key to decrypt a document that was encoded with that key. Next, it must be extremely difficult to figure out the private key by examining the public key. Otherwise, you might as well send clear text. Figure 22.1 shows how public and private keys work to encrypt a message.
Note
If I send you a message that is encrypted with your public key, you can decrypt it with your private key. This keeps the contents private. On the other hand, if I send you a message that is encrypted using my private key, you can use the public key to verify that it is from me—even though the message can be decrypted by anyone who takes the time to find my public key. This answers the nonrepudiation requirement.
The simplest, but least useful way to secure your Web services message is to use the Secure Sockets Layer (SSL).
Web services that conduct electronic commerce cannot use clear text. Anyone with a laptop and some packet-sniffing software could fish out credit card numbers all day long. Netscape communications realized this and developed a protocol called the SSL to address this issue.
SSL contains two different, but related, protocols—the Secure Sockets Layer and the Transport Layer Security. These protocols are concerned with securing a socket and all of the data that passes over it rather than encrypting just a SOAP message.
You have used SSL before if you have ever typed in https: in a URL. HTTPS is a higher-level protocol built using SSL. SSL allows encrypted traffic to flow through the socket that it creates. A client sends a request to a server. The server sends an X.509 certificate back to the client, which contains the public key of the server. If the server’s key is valid, some handshaking takes place and the session begins. SSL-based software classes such as the Java Secure Socket Extension (JSSE) hide most of this detail from the user and even the programmer. Using it is very much like using a normal socket except that the secure socket is created using a special class.
All implementations of SSL use a handshaking procedure in which the client and the server exchange certain information that enables them to determine what form of communication they will use in the actual transactions. In addition, this procedure ensures that both parties in this communication are behaving in a way that the other would expect.
No unencrypted key is ever exchanged. The real beauty of this approach is in the amount of work a programmer has to do to get this to work. Aside from obtaining the proper certificate from a certificate authority, the only code that is written is similar to that used to create simple sockets.
Adding SSL to Web services doesn’t change either the business or Web services code that you write. This is all handled by the HTTP container and is transparent to the application.
Using SSL to send SOAP messages is fairly easy. All that you really need is a Web server that is capable of communicating with clients that use HTTPS as well as HTTP. After your client composes the SOAP message, it specifies that it wants to send this message to the server using HTTPS. Your client needs to be written using the JSSE or some other similar library. This library will perform all the handshaking for you automatically, and then send your message to the Web server.
The Web server will decrypt the message when it arrives and hand it to your Web service. The Web service will then work its magic and formulate a response message (normally). A response will be delivered to the client securely if that was specified. Figure 22.2 shows how this works.
Notice that everything that goes over the Internet gets encrypted, not just the sensitive parts.
SSL is like a tired workhorse. For all the good work that it has done over the years, it lacks the pep to go to the next level. The reasons for this are
The fact that it provides encryption during transport ignores the fact that encryption is also needed while some documents are stored on intermediate servers.
The whole message is encrypted and decrypted together. This keeps an intermediate end point from adding to a message without discovering its contents.
SSL, by itself, cannot provide authentication, data integrity, and nonrepudiation for the life of the message if it is routed across more than one Web server.
When gurus talk about the Web services standards being weak on security, they do not mean that hackers are running wild and stealing information at will. What they mean is that there is no mention in the specifications for the SOAP language that specifies how a message is to be secured.
This doesn’t mean that the Web services proponents are sitting on their hands and refusing to write a set of XML security standards. It means that no decision has been made, at least officially, as to what the W3C and OASIS will eventually specify. That being said, the field of Web services security is taking on a shape, and certain standards are emerging as the odds-on favorites, but it is too soon to declare a winner.
This section provides an overview of several of the proposed standards that have a direct bearing on the problems of security. Luckily, these proposal writers are aware of each other, and, thus far, they have done a good job of holding duplications to a minimum.
When you get an important document, you need to be certain, beyond a reasonable doubt, that the author of the document is who it says it is. A check is signed by the owner of the bank account, testifying that he does indeed have an account at that bank and that you now have rights to $47.33 of the money in it.
In the same way, your Web service needs to know that if John Q. Public orders a camera, he is a real person who wants a camera and intends to pay for it. Because of the similarities of this need and that of the person who accepts a check, the term digital signature is used to describe a solution.
A digital signature is not a signature at all, but rather a set of tags and values that serves the same purpose—identifying the originator or the transaction against unauthorized modification, impersonation, and repudiation. Your Web service needs protection against the equivalent of a check writer saying later, “That isn’t my signature and I never wrote that check.” Whether or not the check writer is lying, you still have a problem.
Cryptography is the basis of XML-Signature. As discussed earlier in this hour, a client needs to possess a pair of keys, one public and one private, which can be used to encrypt and decrypt messages. If you are sure of the origin of one of these keys, you can determine, via software, that the other key was used to encrypt something. This is the basis for declaring that a request is legitimate.
Secure Sockets Layer is capable of securing a message during transport. However, Web services transactions have two characteristics that SSL can’t handle at all: They are often routed across many nodes while being processed, and each node can add additional information to the message as it proceeds. If you use SSL to send Web services transactions over several nodes, the encryption and decryption has to be done on each node, exposing the secrets on every node.
XML Signatures is an open standard managed by the Organization for the Advancement of Structured Information Standards (OASIS). As the name implies, XML Signature is a set of XML tags. These tags are designed to contain sufficient information to allow a client to be verified using the public/private key pair that he must possess to participate in a signed transaction.
XML signature is powerful in that it enables an endpoint to sign only one part of a document instead of the whole thing. This is important because some SOAP messages obtain additional information as they proceed through the work flow. If the XML signature were signing the whole document, adding new information would cause the message to be cryptographically invalid—even if the modifier is a legitimate part of the transaction. Because the original signer only signed part of the document, additions do not invalidate the original signature. The following XML document fragment shows a sample XML Signature:
<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo Id="curly">
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm=
"http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="http://www.mycompany.com/news/2000/sample.htm">
<DigestMethod Algorithm=
"http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<DigestValue>oiuyhhlkeroiapoi987qhn</DigestValue>
</Reference>
<Reference URI="http://www.w3.org/TR/2000/WD-xmldsig-core- 20000228/signature-example.xml">
<DigestMethod Algorithm=
"http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<DigestValue>lkhuyiydyueuu973kdk9</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC9E-LE</SignatureValue>
<keyInfo>
<X509Data>
<X509SubjectName>CN=Steve Potts,O=Potts Company,
ST=GA,C=US</X509SubjectName>
<X509Certificate>
lkjhiouyrwelkjahdsf...8i7
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>This document contains a complete signature and references to two signed documents. The public key is contained in the X509Certificate, which is also included here.
When the recipient gets the message, he applies the public key to each document. If the algorithm says that it matches the one included, he can be sure that the document is unaltered. If the public and private signatures don’t match, he has received a fake signature.
The use of the public and private keys presents a bit of a problem. On one hand, how do you write the XML that it takes to verify the information contained in the <KeyInfo> tags of the signatures? On the other hand, how can we communicate with the certificate authorities automatically? If we have to put a person on a browser every time we need to get information from a certificate authority, there would be little point in automating the rest of the service.
The XML Key Management Specification (XKMS) consists of two separate parts:
XML Key Information Service Specification (X-KISS)—. A protocol that enables an application to delegate the validation of the key that has been sent to another Web service. This makes programming the signature-verification part simpler.
XML Key Registration Service Specification (X-KRSS)—. A protocol that allows clients and Web services to communicate with a certificate authority to bind name or extended-attribute information to a public key.
Using these two protocols, your client or Web service can communicate to other Web services in a way that is more transparent than traditional approaches to key management.
Encryption is the art of secret writing. For as long as there have been people, there has been a need for private communication. Sometimes the motivation for this privacy is national security, and sometimes it is financial. At other times, the primary motivator is just to keep private things away from nosey people.
The tried-and-true technique for maintaining privacy is to apply some sort of encoding scheme on a message before sending it. The recipient, who must know the decoding scheme, can then turn the garbled data back into clear text for processing.
The details of how encryption works is beyond the scope of this book, but it is sufficient to say that there are two basic types of encryption—symmetric, and asymmetric. Symmetric encryption uses the same key and an algorithm to convert the document from clear text into encrypted text and back again. Asymmetric encryption uses one key to encrypt and another, mathematically related, key to decrypt. Asymmetric encryption is more secure because your key doesn’t ever have to be transferred. Symmetric encryption is much faster, though.
XML Encryption is a proposed standard that is being evaluated at the World Wide Web Consortium (W3C). XML Encryption is fairly simple; the original clear-text information is encrypted and placed in between the <EncryptedData> tags. The following code fragment shows a sample that is unencrypted:
<Payment xmlns="http://sampleCreditCard.com/payment">
<Name>Bill Powell</Name>
<CreditCard Currency="USD">
<Number> 3456654323455432</Number>
<Bank>Hometown Bank</Bank>
<Expires>05/05</Expires>
</CreditCard>
</Payment>Now here is the encrypted version of the same document:
<Payment xmlns="http://sampleCreditCard.com/payment"> <Name>Bill Powell</Name> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData><CipherValue>u8ui7i8u7i7</CipherValue></CipherData> </EncryptedData> </Payment>
Notice that all the data except the name has been encrypted. This could be useful when part of the data needs to be visible to a clerk or an accountant, but he does not need to see sensitive data such as the credit card number.
Every secure Web service needs to be capable of answering the question, “Who is this person or system that is trying to engage in a conversation with me?” In addition, the service needs to be able to evaluate whether or not this client has permission to use our Web service in the way that he is attempting to use it. This topic is referred to generically as authentication and authorization.
We have all used the simplest form of authentication when we key in a username and password to access a site. While we try to use the same username and password for each system that we visit, it is normally impossible to do. Sometimes the rules of usernames and passwords disallow our favorite pair. Other times, someone else has chosen that username already, so we have to go to a second choice. The situation is so bad that many users have to record their information for each site in a document or a personal database.
This situation is annoying for personal Web usage, but it is debilitating when planning a complex Web service. One of the promises of Web services is the capability to create workflow-based transactions that span many individual Web services. You might have a transaction that estimates a kitchen remodeling. It could access one Web service to get the cost of materials, another to calculate labor costs, still another to determine the permits required, and a fourth one to calculate the sales tax.
What we need is a single sign-on (SSO) as well as role-based access control (RBAC). Because it is often necessary to span different companies to execute some workflows, these solutions need to span company boundaries—at least in the case of federated companies that work together on projects, but preserve their ownership independence.
Some companies have written one-off systems to accomplish this. What is needed, though, is a standard way of solving the authentication problem so that when your circle of trading partners expands, you will be able to include the new partners quickly and without high costs.
To respond to this need, OASIS approved the 1.0 version of the Security Assertion Markup Language (SAML). A security assertion is a claim to have permission to call a certain method on a Web service. The purpose of SAML is to provide a protocol whereby clients might make assertions and Web services can authenticate these claims. The “ML” in the name indicates that SAML is an XML-based solution.
SSL provides adequate security for simple point-to-point Web service calls. What is lacking is a way to establish a “community of interest” in a certain Web service that can use it securely. What SAML adds over and above SSL is a SOAP-based messaging protocol and XML-based data structures for communicating assertions.
At present, the SAML 1.0 standard places the assertion XML in the body of the SOAP message. The more logical place for this type of information is in the SOAP header. Discussions are now taking place at OASIS between the SAML committee and the WS-Security committee concerning the feasibility of enclosing the SAML assertions inside the <wsse:Security> tag.
SAML provides the capability for the enterprise to vouch for the identity, authentication, and authorization rights of both human and program users.
Another standard on the horizon is the WS-Security standard. It proposes a set of SOAP header extensions that can be used to contain the XML for the standards that we have discussed earlier in this hour, as well as standards that will emerge in the future. The goal of WS-Security is to provide the framework for a complete security solution, but one that is customizable to individual needs.
WS-Security serves as a container for a variety of elements, each of which provides a partial security solution. The elements defined in the specification are as follows:
<Security>—. The enclosing tag.<UsernameToken>—. The username and password.<BinarySecurityToken>—. Contains binary data such as X.509 certificates and Kerberos tickets.<SecurityTokenReference>—. Provides for the external storage of claims (privileges).<ds:Signature>—. Digital signatures specified by the XML Signature specification.<xenc:EncryptedKey>—. Key data specified by the XML Encoding specification.
The primary value of this specification is the organization that it brings to the SOAP header. If this standard is adopted into the SOAP specification, it will be a major step forward in the transformation of Web services security from a series of one-off solutions to a more unified way to transfer information securely over the Web.
In this hour, we covered the topic of securing a Web service transaction against a variety of security problems related to privacy, authentication, nonrepudiation, and nonmodification. We first looked at the problem of securing transactions against attack, and then we looked at the uniqueness of Web services transactions.
We covered several emerging specifications—each of which contributes to an overall solution. SSL allows you to send a single point-to-point transaction securely. WS Signature provides a protocol for verifying the origin of a document. WS Encryption allows you to encode all or part of your transactions during its entire life cycle. SAML allows a complex transaction to use a single authentication and authorization across the entire transaction, and WS-Security provides a framework to contain the other solutions.
The Workshop is designed to help you review what you’ve learned and begin learning how to put your knowledge into practice.
1. | List the threats that could potentially affect the Web services that you have built or are contemplating building. |
2. | Go to www.verisign.com and investigate what it would take to obtain a certificate for your organization. |
3. | If your organization already has a certificate, investigate what is required by your organization to make use of it. |