Before we can address Web services security, we must first understand the areas where potential threats may occur as well as how they may occur. In this section, we look at the issues surrounding Web services security flow of a Web service invocation starting from the client application through the actual business logic implementation of the service and back to the client again. Throughout this flow, we analyze the possible threats and best practices to address those threats.
Data Protection and Encryption
Data protection refers to the management of transmitted messages so that the contents of each message arrives at its destination intact, unaltered, and not viewed by anyone along the way. The concept of data protection is made up of the sub-concepts of data integrity and data privacy:
Data protection is critical within a Web services environment as personal information, such as credit card numbers, and competitive organizational information, such as customer contacts and employee names, will be exchanged between Web services.
Encryption techniques are used to implement data integrity and data privacy. The most commonly used of such solutions is the Secure Sockets Layer (SSL) protocol. The SSL protocol creates a secure tunnel between the origination and destination computers based on public-key encryption techniques. The protocol also supports authentication of the origination computer to the destination computer, and optionally supports authentication of the destination computer.
However, SSL provides only point-to-point data protection. In many instances the Web service provider may itself forward the request to be ultimately handled by another computer or even a person. A legacy mainframe may actually fulfill requests that are forwarded to it from another computer that simply "wraps" the application running on the mainframe's capabilities as a Web service. As shown in Figure 8-3, after the termination of the SSL connection (at the Web services server) all the data is left insecure.
Figure 8-3. SSL provides point-to-point data protection, leaving forwarded data insecure.
The inability to provide end-to-end security among multiple parties is a major drawback of the SSL protocol within Web services environments where it is routine for multiple entities to be involved. Consider purchasing a book from an online merchant using a credit card. The purchase order for a book is sent from the user to the merchant, who then forwards the credit card information to a bank. Only information about the book, e.g., book title and quantity ordered, must be viewable by the online merchant, not by both the merchant and the bank. Similarly, the credit card information must be viewable only by the bank. The ability to selectively encode various parts of a message using different keys is a critical requirement for Web services.
Moreover, SSL involves a large amount of overhead in encrypting and decrypting an entire message. Oftentimes, a message is comprised of a mixture of both secure and insecure information. Returning to our book purchase order, information about the book can be sent as clear text, while the credit card number must be encrypted. For these types of messages, encrypting the entire message using SSL adds needless overhead.
The SSL protocol provides point-to-point data protection between two parties but has the following weaknesses:
XML Encryption builds on SSL and provides end-to-end security that addresses these two weaknesses. To understand how XML Encryption works, consider the following XML code fragment representing our purchase order for a book:
<?xml version='1.0'?> <PurchaseOrder> <Cart> <Item> <Title>Developing Enterprise Web Services</Title> <Quantity>21</Quantity> </Item> </Cart> <Payment> <PaymentType>VISA</PaymentType> <Number>123456789000</Number> <Expiration>01-23-2024</Expiration> </Payment> </PurchaseOrder>
The purchase order is comprised of XML elements that specify the contents of the shopping cart as well as the payment details. The <Cart> element contains items to be purchased. Each <Item> element contains the title of the book as well as the desired quantity. The <Payment> element contains subelements that specify the type of credit card, the credit card number, and the credit card expiration date.
Using XML Encryption, we can selectively encrypt an entire element or the contents of an element. In the above book purchase order, the only element that must be encrypted is the credit card number denoted by the <Number> element. The resulting document after using XML Encryption to encrypt the credit card number is as follows:
<?xml version='1.0'?> <PurchaseOrder> <Cart> <Item> <Title>Developing Enterprise Web Services</Title> <Quantity>21</Quantity> </Item> </Cart> <Payment> <PaymentType>VISA</PaymentType> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Element'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> <Expiration>01-23-2024</Expiration> </Payment> </PurchaseOrder>
The encrypted data is specified within the <EncryptedData> element. The Type attribute specifies that an element has been encrypted, and the xmlns attribute specifies the namespace used. The actual encrypted data appears as the contents of <CipherValue>.
In some cases, it is advantageous to encrypt only the contents of the element and not the element itself. Using XML Encryption to do thisresults in the following encrypted document:
<?xml version='1.0'?> <PurchaseOrder> <Cart> <Item> <Title>Developing Enterprise Web Services</Title> <Quantity>21</Quantity> </Item> </Cart> <Payment> <PaymentType>VISA</PaymentType> <Number> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </Number> <Expiration>01-23-2024</Expiration> </Payment> </PurchaseOrder>
Again, the encrypted data is specified within the <EncryptedData> element. This time, the Type attribute specifies that the contents of an element have been encrypted and the element tags, <Number> and </Number>, appear as clear text. The actual encrypted data still appears as the contents of <CipherValue>.
Finally, we can also use XML Encryption to encrypt the entire message as follows:
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/ media-types/text/xml'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData>
This time, the entire document, including all the tags and their values, are encrypted and appear as the value of the <CipherValue> element. The value of the attribute Type (of <EncryptedData>) is now set to http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml since the encrypted data prior to encryption was XML the official type definition by the Internet Assigned Numbers Authority (IANA) for XML.
Interestingly enough, XML Encryption can also be used to encrypt non-XML documents. For instance, encrypting a JPEG image file using XML Encryption results in this document:
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/jpeg'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData>
There is little difference between the entire XML document that was encrypted and the encrypted JPEG image. The only difference is the value of the Type attribute of EncryptedData. For the XML document, the value of Type was set to http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml while in this case the value of Type is set to http://www.isi.edu/in-notes/iana/assignments/media-types/jpeg the official IANA type definition for JPEG images. Of course, the actual data will also be different.
Toolkits are available that facilitate the process of encrypting documents using XML Encryption. Implementations of XML Encryption are included within IBM's XML Security Suite and Baltimore Technologies' KeyToolsXML.
More information about XML Encryption can be found in the W3C's technical report XML Encryption Syntax and Processing at http://www.w3.org/TR/xmlenc-core/.
Authentication and Authorization
Authentication refers to verifying that the identity of an entity is in fact that which it claims to be. The entity trying to have its identity authenticated is known as the principal. The evidence used to prove the principal's identity is known as the credentials. If the correct credentials are used, the principal is assumed to be who it claims to be.
Credentials can be misappropriated. Passwords, for example, are easy to steal, while retinal scan data and thumbprints are more difficult.
In a Web services environment, a Web service provider may need to be authenticated by the Web service requester before the service is invoked and personal information is sent. The requester may also need to be authenticated by the provider before the service is rendered and critical information is sent back in the reply.
In many simple service invocations that do not involve the exchange of personal information or where there is no charge for the service invocation, authentication is unnecessary. For example, a client application that queries a free weather report Web service neither needs to authenticate the provider nor does the provider need to authenticate the requester.
After a principal's identity has been authenticated, authorization mechanisms are used to determine what the user (or application) will be allowed to access. Information about the user, such as subscription levels, is used to allow the appropriate level of access. For example, a Web service may have twenty operations, of which only five are available for access by some users while all twenty are available for other users. Or, particular endpoints of a Web service may be made available for premier customers, while standard customers must share just a single endpoint.
Authorization is increasingly important within Web services environments. Web services expose data as well as processes and operations to programmatic access. For the most part, access to this type of information was previously channeled through humans. These human beings acted as checkpoints that safeguarded the information from unauthorized access. With Web services providing programmatic access, authorization schemes must act as the checkpoints.
A variety of technologies and approaches can be used to implement authentication and authorization for Web services. These approaches can generally be classified as system-level approaches, application-level approaches, or third-party approaches.
System-level approaches do not require custom application (or Web service) programming to implement. Nor does it require any changes to the Web service if the authentication approach is changed. Usually, the operating system or the Web server handles authentication and authorization prior to forwarding the SOAP request to the Web service.
Common system-level approaches to authentication include basic passwords, encrypted passwords, and digital certificates. Digital certificates require that each user obtain a certificate verifying his identity. Since today the use of certificates is limited, this approach does not present a viable mass-market authentication scheme. In Microsoft Windows-based systems, both password and certificate credentials are checked against valid user accounts, which necessitate creating accounts before users can access a Web service.
Application-level approaches to authentication require custom development, and usually have to be modified with changes to the authentication mechanism. Sometimes, system-level approaches are insufficient or require too much overhead. For example, the overhead of creating and maintaining individual Windows user accounts may outweigh the benefits of using system-level passwords.
Application-level authentication approaches can pass credentials as part of the SOAP message. In this case, the Web service must parse the credentials as well as implement authentication and authorization mechanisms itself. The credentials can be transmitted as part of the SOAP header or the SOAP body. In the case where credentials are passed as part of the SOAP header, a service other than the called Web service may parse and authorize the invocation. Such a modularized solution allows the development of system-level schemes, and ensures that the Web service consumes computer cycles processing only valid and authorized requests.
SOAP on top of HTTP exposes the credentials as clear text, and facilitates misappropriation of this information. SSL can be used to encrypt the data for all SOAP messages sent to the other operations of the Web service. Unfortunately, SSL imposes significant performance overhead compared with just HTTP alone.
For operations where security can be loosened a bit, alternatives that are less of a performance drain are available. For instance, an authentication operation may be added to the Web service itself. SSL can be used to send SOAP messages to this operation so the credentials are not in the clear. Once a user has been authenticated, the Web service can return a token or a session key that can be used for subsequent SOAP messages. Although the session key can be stolen, the credentials (username and password) are not available and it is not critical to encrypt the session key. Accordingly, HTTP alone can be used. Another method is to use HTTP cookies for the session information instead of the SOAP header or body.
Figure 8-4 depicts a SOAP envelope that uses the optional SOAP header specification to pass username and password credentials. Before the SOAP body, the SOAP header is defined that includes UserName and Password elements. SOAP messages that either lack a header or present incorrect credentials will not be allowed to invoke the GetRealTimeQuote method.
Figure 8-4. Passing username-password credentials as part of the SOAP header.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <AuthHeader xmlns="http://tempuri.org/"> <UserName>MyUserName</UserName> <Password>MyPassword</Password> </AuthHeader> </soap:Header> <soap:Body> <GetRealTimeQuote xmlns="http://tempuri.org/"> <symbol>HPQ</symbol> </GetRealTimeQuote> </soap:Body> </soap:Envelope>
Integrated development environments (IDEs), Web services platforms and tools facilitate generating and parsing SOAP headers and bodies so that developers do not have to write the parsing code themselves.
Third-party authentication services may also be available. Single sign-on capabilities are of particular interest to Web services environments, which are comprised of a large number of heterogeneous services, each of which may use different authentication mechanisms. Requiring the service requester to maintain and manage a large number of credentials for the variety of authentication schemes used by the different Web services within the environment is difficult and impractical.
With a single sign-on scheme, service requesters need only maintain a single credential. The third-party single sign-on service manages and maps the single credential held by service requesters to each of the service providers. The complexities of maintaining, managing, and revoking authentication credentials and authorization access list are handle by the third-party service provider. Two examples of single sign-on services are Microsoft Passport and the Liberty Alliance.
Non-Repudiation and Signatures
Protecting the confidentiality of messages is important within any secure environment. But, data privacy is just one piece of the security puzzle. Alongside privacy are the following related and equally important issues:
The means to support the important issues of authenticity, integrity, and non-repudiation are not provided by standard security mechanisms, such as SSL and passwords that we have already discussed.
These issues are addressed by the concept of digital signatures. Digital signatures are similar to standard handwritten signatures, and allow the receiver of a document to verify that the source from which it came has created (or viewed) and validated the contents of the document. It also supports the ethic of accountability in that the identity of the person who validated the document can be proved and the person can be held accountable for their validation.
Consider the creation of purchase orders within organizations. Purchase orders (POs) are documents that allow an organization to purchase components or services from a vendor. Usually, companies buy components in large volumes and errors in the components purchased, delivery dates, or payment terms may result in potentially large losses either from lost revenue or from increased costs.
The steps necessary to create a PO are usually complex and involve critical decisions made by a number of different people. The process may proceed as follows:
In each step, different people's areas of expertise are brought to bear. Each of these people must be accountable for their actions only and not for those of others. If the engineer makes a mistake in identifying the appropriate component, only she should be held accountable; the purchasing officer who made the actual purchase should not be liable. Similarly, the purchasing officer must be confident that the component part number specified on the PO is as the engineer specified and has not been modified (either intentionally or accidentally) by someone else.
The XML Signatures specification specifies a technology that meets these needs, and is well suited for use within Web services environments. The key characteristics of the XML Signature technology are:
Now that we have seen the benefits of digital signatures as well as the unique features of the XML Signature technology, we next turn to the process of signing documents.
The basic technology behind signatures is simple and is based on Public Key Infrastructure (PKI) technologies. The basic process is as follows:
For this digital signature to have any validity, the receiver must have confidence in the authenticity of the public key and that it actually belongs to the entity the receiver thinks it belongs to. Otherwise, an imposter can claim to be a different entity, transform the document using his private key, and provide his public key to the receiver. To safeguard against this situation, a certificate issued by a trusted Certificate Authority is used to match a public key with the actual entity.
Now that we have discussed the fundamental concepts underlying digital signatures, the steps in generating a signature using the XML Signature technology are as follows:
The digital certificate for the sender may also be provided within the signature. The X.509 digital certificate for the sender including the sender's public key would provide all the information necessary to confidently verify the signature. The certificate information would be placed within a <KeyInfo> element as follows:
<KeyInfo> <X509Data> . . . </X509Data> </KeyInfo>
We have now created a digital signature and have successfully signed the resources to be transmitted from the sender to the receiver.
On receiving the signed document, the receiver must simply follow these steps to verify the signature as well as the integrity of the received data:
These simple steps are used to create and later verify digital signatures using the XML Signatures specification. Digitally signed documents provide a means to verify the authenticity and integrity of a document as well as a means to implement non-repudiation.