Basic Concepts of Web Services Security

Today we cover the basics of Web services and information security and the way Web services security builds on existing security technology. This is chapter 1 from Securing Web Services with WS-Security, by Rosenberg and Remy (ISBN 0672326515, Sams, 2004).

Securing Web Services with WS-SecurityWeb services are a transformational technology for integrating information sources from both inside and outside an enterprise. Web services are the newest incarnation of middleware for distributed computing. Unlike all previous forms of middleware, however, this is a simpler, standards-based, and more loosely coupled technology for connecting data, systems, and organizations. That is good news for architects and developers wanting to quickly become proficient in this technology and deploy real systems. It is also somewhat bad news for architects and developers because all middleware needs strong security practices, and Web services need it more than any middleware of the past. Why more? Because Web services create loosely coupled integrations. Because Web services are not just being used to integrate internal systems, but they are also integrating data sources from outside the organization. Because Web services are based on the passing of readable and self-describing business messages represented in XML. Because Web services are based on underlying Web technologies that already had their own set of security challenges.

It is true that Web services—like most new transformational information technologies introduced—have been overhyped, and it is true that fears of security problems have also been overblown, which has impeded the development and deployment of Web services. It is also true that the standards for Web services are either quite new or in some cases not even fully baked yet. This book is designed to take the mystery and fear out of how to build secure Web services and to shed light on these new standards and how to best use them. It is also designed to show you the richness and complexity of the security issues around Web services so that you, the designers, builders, and operators of Web services, can fully exploit all the capabilities of Web services to your best advantage but do so knowing full well what all the security challenges are and how to face them.

This chapter covers the basics of Web services and information security and the way Web services security builds on existing security technology. This sets the stage for a deeper understanding of the major standards for information security associated with Web services.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XML, SOAP, and WSDL}

Four technologies form the basis of Web services: eXtensible Markup Language (XML); SOAP (See Footnote 1 at end of article); Web Services Description Language (WSDL); and Universal Description, Discovery, and Integration (UDDI) (Footnote 2).

XML and XML Schema

XML was created as a structured self-describing way to represent data that is totally independent of application, protocol, vocabulary, operating system, or even programming language. Many call XML the lingua franca of business because it is being used so broadly across all industries to portably transmit business data. The use of XML presents a broad set of security challenges.

XML Schema is a way of describing the rules for a particular XML instance (also known as a document). XML can be used independently of XML Schema; however, in Web services and most business situations, the XML that you work with will be governed by an XML Schema (perhaps created by a development tool and put into your Web services WSDL file for you).

XML is the foundation of the Web services standards. All standards for describing, discovering, and invoking Web services are based on XML. SOAP and WSDL are described using XML Schema. The core security standards of XML Encryption, XML Signature, Security Assertion Markup Language (SAML), and WS-Security are XML-based and are also described by an XML Schema.

XML and HTML are both text-based formats that came from the same roots. XML was initially developed to overcome the limitations of HTML, which is good at describing how things should be displayed but is poor at describing what the data is that is being displayed. XML being text-based is very important to Web services; because it is human-readable, no tools are needed to parse and render the data, and simple text tools and editors are sufficient for its manipulation. XML documents are very wordy, and although you can easily become lost in the depth and richness of the tags, its markup format of tagged elements arranged in a hierarchical structure makes XML documents easy to comprehend. But there is a security price to pay for the open, text-based structure of XML. As you will see later, to provide data integrity—a guarantee that not one bit in the original document has been changed—with XML, you have to guarantee that not one character—even whitespace—of an XML message has been changed. Verifying data integrity is particularly challenging when using XML since differences in platforms and XML parsers can result in logically equivalent documents being physically different; consequently, a process of canonicalization is necessary to make a valid comparison with the originally signed document. This is just one example of the special considerations needed when considering Web Service Security.

SOAP

SOAP was created as a way to transport XML from one computer to another via a number of standard transport protocols. HTTP is the most common of those transports and is, of course, the most prevalent transport used by the Web itself.

SOAP itself is defined using XML, and it provides a simple, consistent, yet extensible mechanism that allows one application to send an XML message to another. SOAP is what makes application integration possible, because after XML defines the contents of a message, it is SOAP that moves the data from one place to another over the network. SOAP allows the sender and receiver of XML documents to support a common data transfer protocol. SOAP allows you to treat XML messages as requests for remote services. The SOAP model allows a clean separation between infrastructure processing and application processing of messages. Figure 1.1 shows the basic structure of a SOAP message.

Basic Concepts of Web Services Security

Figure 1.1 The basic structure of SOAP.

SOAP provides an envelope into which an XML message is placed. This envelope is just a container to hold XML data. The idea is for SOAP to create a uniform container that can then be carried by a variety of transports. SOAP prevents applications from caring about the transport; the applications see consistency in the SOAP envelope and its contents.

Inside the SOAP envelope are two parts: the header and the body.

  • SOAP header—Contains information about the SOAP message (as opposed to the XML message contained in the SOAP body). This information is used to manage or secure the package. SOAP is designed to be extensible, and a major area for extension is the SOAP header. Chapter 7, “Building Security into SOAP,” which describes WS-Security, provides more detail on SOAP header security extensions.

  • SOAP body—Contains the message payload. This information is being sent from one application to another. It might be a full document such as a purchase order or contract, or it might be a description of remote-procedure call information, including the methods to call and parameters to those method calls.

The simple SOAP message in Listing 1.1 shows an envelope that contains both a SOAP header and a SOAP body.

Listing 1.1 SOAP Envelope

<?xml version=”1.0″ ?>
<env:Envelope xmlns:env=”http://www.w3.org/2001/12/soap-envelope”>
<env:Header>
<n:alertcontrol xmlns:n=”http://example.org/alertcontrol”>
<n:priority>1</n:priority>
<n:expires>2004-06-22T14:00:00-5:00</n:expires>
</n:alertcontrol>
</env:Header>
<env:Body>
<m:alert xmlns:m=”http://example.org/alert”>
<m:msg>Pick up Bobby at school at 2PM</m:msg>
</m:alert>
</env:Body>
</env:Envelope>

To understand SOAP, you need to understand the different “styles” of SOAP bodies. RPC-style SOAP bodies tend to be simple parameters to facilitate calling a remote method. Document-style SOAP bodies tend to be rich XML documents. Document style, in our view, is more appropriate for B2B Web services because it is usually more optimal to have “chunky,” coarse-grained calls across a slow network rather than the fine-grained type of RPC call that you might use locally or on a fast network. This is not just due to the network but also due to the cost of marshalling and unmarshalling the XML and performing security-related operations.

SOAP needs to be secured. The messages it carries must be kept secret from unintended recipients. The remote service being called must know who is calling it and know the caller is authorized to do so. SOAP is a packaging mechanism for XML messages and documents. Like any package, it needs to describe important information about its contents, such as who it is from, how a recipient can trust that it really is the sender, what the sender is allowed to do, and much more. These are identity- and trust-related issues; they are the core of SOAP security discussed in detail later in this book.

WSDL

WSDL is an XML language that defines the set of operations that a Web service provides and the structure of their related SOAP messages. That is, the WSDL defines what the input and output structure will be for a Web service, and that will define what you expect to see in the payload XML message. WSDL is how one service tells another which way to interact with it, where the service resides, what the service can do, and how to invoke it. WSDL directly supports developers and is absorbed at application development time into developer tools. WSDL’s definitions of remote services are presented to programmer-like local objects that can be acted upon as if they were methods in classes, just like any of their other local objects.

When you publish a WSDL for one of your services, you are creating a contract for how other services may interact with you to utilize your service. WSDL is what you publish to describe your Web service and the rules for how to work with it. You might think that security would also be described in WSDL because this is part of the rules for working with a particular Web service; however, the security options (security policy) available are richer than what you typically see in WSDL, so the standards are evolving toward using WS-Policy to describe a Web services security policy and then referring to this policy from the WSDL. Chapter 8, “Communicating Security Policy,” goes into more depth on WS-Policy.

A WSDL file has a what section, a how section, and a where section. The what section specifies the input and output messages. The how section defines how the messages should be packaged in the SOAP envelope and how to transfer it. It also defines what information should be included in the SOAP header. The where section describes a specific Web service implementation and ways to find its endpoint.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=UDDI}

UDDI is typically the fourth leg of the stool used to define Web services. Although we view UDDI as a useful standard, we do not see its usefulness beyond internal promotion of reuse inside large organizations. Given that, we do not put it front and center as a part of our discussions of Web services security and will not treat it further in this book.

Before you dive into the security implications of each of these Web services standards, you need some context: What are Web services really for? The answer is, among other uses that undoubtedly will develop as this new paradigm matures, application integration, B2B business process integration, portals, and service-oriented architectures.

Application Integration

Application integration is critical to organizations large and small because information integration is so fundamentally important. When organizations integrate all their applications that deal with customers (CRM, ERP, accounting, billing), they are trying to create a single view of all the information about those customers. When they integrate all their trading partners into a single supply chain, they are attempting to create a holistic view of their entire supply chain and all the information that describes their trading processes. This kind of information integration is fundamental to the business process. Rarely does a business process (product development, product marketing, product manufacturing, product ordering, product fulfillment, customer relationships, partner relationships, financials, and so on) utilize one and only one source of information (an application). It is because business processes cross application boundaries and even enterprise boundaries that Web services are needed to create those bridges.

Application integration is hard because systems were not designed with the same data structures, protocols, or even the same vocabulary for describing the items they manipulate. Applications were built at different times by different vendors using different technologies. However, many of these different applications need to communicate to perform certain functions. This is where XML comes in. It makes information easy to interchange and therefore easier to integrate.

The glue used to communicate from one application to another has traditionally been called middleware. Middleware has never been pervasive and was always very expensive. Rarely has anyone ever tried to use middleware between enterprises because simply using it within a single enterprise’s boundaries is hard enough. SOAP is a critical step in taking XML messages toward being Web services middleware. In one of its modes, SOAP makes XML into a request/response paradigm that is published via WSDL. Web services are becoming pervasive because they are middleware based on the Web, and the Web is pervasive.

B2B Business Process Integration

Business processes don’t stop at your company’s firewall. Just as internal application integration is partly motivated by the need to break down application barriers, inter-organization business processes motivate B2B application integration. A driving need to integrate across organizations comes from management of supply chains and demand chains with trading partners. Traditional middleware could never be employed to solve this need because it never worked across the Internet.

The good news is that the Internet is pervasive. Most Internet communication occurs via text (for example, HTML is text, email is text), and virtually all applications have some form of text interface. XML is text-based and is designed to make business information transportable and self-describing. XML, plus the fact that all vendors support Web services, has moved us closer to solving the heterogeneous communication problems of different languages, different platforms, and different applications than any middleware technology of the past.

For these reasons, Web services technology is built on XML and Web technologies, which makes it the first middleware that can address the B2B business process integration challenge.

Portals

On the Internet and within intranets, portals are the entry point for customers into a site. Portals have been growing in utility and importance for some time as a way to aggregate information and applications into a single site that is accessible by browsers. Portals as major business models have been common for years. Amazon.com, Yahoo!, and Orbitz are all fundamentally portals. They pull information from their partners’ repositories into a single site that consumers with browsers visit to buy books, music, and consumer goods; plan trips; and the like. Most of these major Web e-commerce companies built their portals long before Web services standards existed. They effectively built Web services to integrate all their information content using home-grown approaches. Companies trying to do what they have done now can do it much more cheaply and easily and remain much more interoperable by using the new Web services standards.

Companies are rapidly turning their corporate intranets into portals to provide a wide range of company-related information and services to employees, shareholders, and partners. One type of service they are providing employees is a unified benefits information resource. To make that a complete service, the 401k information from third-party providers must be integrated into the corporate portal. That is a perfect use for secured Web services that bring the employees’ 401k account information into the corporate benefits portal by accessing the external services of the 401k provider.

Integrated customer information is so much the lifeblood of all companies that both customer relationship management (CRM) and customer information portals have represented large corporate investments for many years. Naturally, because Web services are less expensive and less complex than any previous form of middleware, they have been brought to bear on this common need.

Service-Oriented Architectures

In a service-oriented architecture (SOA), the interface is completely separated from the implementation. The software is provided strictly as a service that does not have to be downloaded and installed. SOA promotes reuse and sharing of services by numerous applications and even by different organizations. People describe an “SOA nirvana” when all systems are built as SOA and all applications are composite—built by stitching together several useful shared service components into powerful applications. Many people look to Web services to bring us to this SOA nirvana (Footnote 3).

The idea of services as being a powerful computing paradigm is not new. A service is an application that can be consumed by software as opposed to a human at a browser. It is software that does work for other software. It is how RPC mechanisms work. This was the premise of the client/server computing revolution of the early ’90s. In this model, the server provided the service.

The benefits of a service-oriented architecture are legion. The complexities of a software system are hidden behind its interface. A complex software system becomes a simpler black box defined only by its external interface. The service so constructed becomes a shared resource that can support many applications.

Web services combine the concept of software-as-a-service with the ubiquity and connectedness of the Web. This is what makes Web services so compelling and so exciting: They create a Web API. We are talking about building applications with a broadly accepted standard API based on Web technologies. Web services enable you to wrap legacy applications with this Web API and turn them into shared services. Now these applications can be integrated with other applications and with trading partners. Previously inaccessible information resident in these legacy applications can be brought out to portals and combined with other application information and all made accessible to any user with a browser. Any application can be modified to provide this type of Web API and therefore can be integrated with any other application, allowing you to use the entire Web for application-to-application integration. This, then, is the power of Web services.

Definition of Web Services

A good working definition of a Web service, then, is an application that provides a Web API. The API enables the software resource to act as a service. Being a Web API means that this service is accessible at an Internet URI. Further, an API supports application integration, so a Web API allows application-to-application integration using XML over Web protocols and infrastructure. All the security and trust issues of being part of the open Web infrastructure will concern us. All the information security and message security issues inherent in sending messages from one network point to another will concern us. All the authorization and authority security issues inherent in middleware that performs RPCs will concern us. Now, let’s cover some security basics to build a foundation for our deeper discussions in later chapters.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Security Basics}

The Web is an interconnected global information system that provides resources suitable for consumption directly by humans. In this model, security is critical for many of these resources (login-password authentication at restricted sites, SSL encryption of credit cards and other personally identifiable confidential information). It only makes sense, then, that application-to-application Web services need at least this much security as well.

In fact, because Web services expose critical and valuable XML-encoded business information, Web services security is a critically important concept to fully understand. For one thing, trade secret pilfering is already a large problem, and without security, Web services might even make this situation worse. The reason is that Web services can be thought of as allowing in strange, new users who might take your company’s valuable business secrets out.

This section covers basic security concepts to establish the vocabulary that will be used throughout this book. Keeping communications secret is the heart of security. The science of keeping messages secret is called cryptography. Cryptography is also used to guarantee trust in a known identity across a network by “binding” that identity to a message that you can see, interpret, and trust. An identity asserting itself must be authenticated by a trust authority to a previously established identity known to the authority for the binding to be valid. After you know the identity, authorization allows you to specify what the individual with that identity is allowed to do. When you receive a secret message, you need to know that nothing in the message has been changed in any way since it was published, an attribute called integrity. When cryptography successfully keeps a message secret, it has satisfied the requirement for confidentiality. At times, you might want to know that someone who received confidential information cannot deny that she received it, an important security concept called non-repudiation.

Most of these core security concepts depend on encryption technologies, so before you look at any of them more closely, take a look at the fundamentals of encryption.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Shared Key and Public Key Technologies}

We won’t get very far in our security discussions without bumping into shared key and public key technologies. They, in turn, stem from cryptography. We will briefly introduce these concepts here so that we can apply them where needed throughout the rest of the book.

Cryptography

Cryptology is the branch of mathematics focused on designing algorithms to keep information (data) secret. Cryptography is the work of applying these algorithms to secure systems, protocols, applications, and messages (Footnote 4).

The first and most important area of cryptography to discuss is encryption. Encryption is the basis for XML Encryption and also for XML Signature, which encrypts a digested form of a message. The message digest encrypted in a digital signature is created using another important cryptographic algorithm called a hash function, which is a special class of one-way function that creates a fixed-size (small) output that is unique for all input messages and that is not, in practice, reversible. In the Web services arena, you will find common uses for both shared key (Footnote 5) and public key encryption.

A message that is completely readable and is in no way scrambled or disguised is called plaintext. Plaintext is unencrypted data. Encryption is the process of scrambling or disguising plaintext by applying a cryptographic algorithm to produce ciphertext. Ciphertext is encrypted data. Decryption reverses the encryption process and turns ciphertext back into its original plaintext form. These concepts are shown in Figure 1.2.

Basic Concepts of Web Services Security

Figure 1.2 The relationships between plaintext and ciphertext, and the encryption and decryption processes that transform them.

The goal of encryption—and therein the way to achieve confidentiality—is to create ciphertext from plaintext that is undecipherable to anyone except the intended recipient. A special cryptographic algorithm that creates seemingly random permutations on the message, but which in fact are reversible under the right circumstances, performs the encryption process.

The algorithms for encryption and decryption require a key, which is a special numeric value that is required as a parameter for the algorithm to perform its task. The wrong key will get garbage out, not the correct output.

Shared key algorithms use the same key performing encryption and decryption symmetrically and are relatively fast. Public key encryption uses different but mathematically related (a public and private pair) keys performing encryption and decryption asymmetrically and is primarily used for secure shared key distribution and digital signatures.

Throughout this book, we will use the term shared key when we refer to symmetric encryption and public key when we refer to asymmetric encryption. We will use the term subject to refer to the holder of a key. A subject may be an individual or an entity (computer).

The magic is in the keys. But what is a key, and what does it have to do with encryption?

Keys

A key is a set of bits that acts as an input parameter to a crypto-algorithm. Think of the crypto-algorithm like the lock on your house door. That lock is standard, and so is your door. Lots of other people have doors and locks that are outwardly exactly the same as yours. But inside the lock on your door are some unique (or almost (Footnote 6)) settings of tumblers that exactly match your and only your key.

Algorithms for encryption and decryption do not need to be and normally are not kept secret. It is the key that is kept secret. It is an important fundamental principle of cryptography that the algorithms be public, standard, and widely distributed and carefully scrutinized. This principle ensures that all the world’s cryptographers fully shake out the algorithms for any security flaws.

The key is the variable that makes the algorithm result unique and secret. For some crypto-algorithms, the key may be a random number. For others, such as public key algorithms, it must be carefully chosen—a complex, time-consuming mathematical operation by itself. The key space needs to be large, so a large number of possible keys is available to prevent guessing attacks. Different algorithms require different key lengths for good security. Most keys today are typically 200 bits or larger.

Shared Key Cryptography

Shared key cryptography uses the same key to encrypt and decrypt the data. This requires that both communicating parties share the same key and, vitally important, keep it secret from the rest of the world. As shown in Figure 1.3, plaintext is encrypted into ciphertext by the sender using the shared secret key. The ciphertext is then decrypted by the receiver using the same shared secret key.

Basic Concepts of Web Services Security

Figure 1.3  The shared key (symmetric) encryption process.

The advantage of shared key encryption/decryption is that the algorithms are fast and can operate on arbitrarily sized messages. The disadvantage is that this approach creates great difficulties managing a shared key that must be kept secret across a network between message sender and recipient. Within Web services security, you will run into shared key cryptography as the basis of Secure Socket Layer (SSL) security and as the foundation for XML Encryption. Much effort has been put into XML Encryption to take care of most of its details for you. But you will be exposed at the minimum to choices you will have to make about algorithms, key information, and the like, so it is important you gain a foundation in these concepts.

Public Key Cryptography

Public key cryptography uses a key pair called a private and public key. Whichever one is used to encrypt the data is not the one used to decrypt the data; only the other half of the pair can decrypt the data. Of vital importance is that the private keys are never shared. Only the public key can be, and it is widely distributed to others. We repeat that it is an absolute tenet of public key cryptography that each subject keeps his private key confidential, never sharing it with anyone.

Either key can be used to encrypt, but only the matching key from the pair can then be used to decrypt. In Figure 1.4, the sender uses the public key of the recipient to encrypt her plaintext message into ciphertext. The resulting ciphertext is sent to the recipient who uses her private key to decrypt the ciphertext back into the original plaintext message.

Basic Concepts of Web Services Security

Figure 1.4  The public key (asymmetric) encryption process.

If you want to make sure only the recipient can read your message, use that person’s public key to encrypt, and then he and only he using his private key can decrypt. If you want everyone who gets your message to know it came from you and only you, use your private key to encrypt and then the recipients can use your public key to decrypt. Because you keep your private key highly secure, the message could have been encrypted only by you.

Now that you have a basic understanding of encryption and digital signature, we can establish working definitions for critical security concepts that will be used throughout this book.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Security Concepts and Definitions}

Authentication, authorization, integrity, confidentiality, and non-repudiation are critical concepts for your understanding of Web services security, so the following sections provide a bit more detail on each one.

Authentication

Authentication involves comparing provided identity information (a “challenge”) to something already stored about this individual. Authentication is classically divided into three types: something you know, something you have, or something you are:

  • Something you know—Pin, password, pass phrase, shared secret

  • Something you have—Key, card, token

  • Something you are—Biometrics such as fingerprint, retinal scan, voice print, palm print

Single-factor authentication (using just one of the preceding types) is the simplest but is not very strong. Stealing or guessing a password is easy, and the rightful individual has no way to refute this is the case. Furthermore, because a password is something you know, you can tell it to someone or she can guess it, and with no other factor checked, that person is into the system with nothing stopping her.

Two-factor authentication, also known as strong authentication, is much stronger and is considered the standard when authentication is for anything of high value. Either something you have or something you are is added to the something you know category of shared secret. Something you have is typically a card, token, or device of some sort. Something you are is a biometric such as a fingerprint, retinal scan, or voice print. Outside military applications, authentication stronger than two-factor is rarely found. To strengthen two-factor authentication, you must strengthen the process used to create the individual factors.

How rigorous the authentication needs to be and what types of factors should be used in the one-, two-, or more factors of authentication require that you think about the level of trust needed. What is it that you are trying to protect? If the Web service is one that integrates vendors into your supply chain, and they have no access to critical corporate or customer data, the level of authentication may be lower than for a Web service that integrates an employer to its 401k provider and represents an employee requesting fund reallocation.

Authorization

Authorization is the process of establishing what someone who has been authenticated is allowed to do. The entity receiving the request for service will be granting permissions for each identity to access certain items.

Most Web services coming in over the public network to an enterprise require authentication; it is not usually acceptable to provide services that you expect to be paid for without knowing who is using them. So fundamentally, authorization requires authentication. Additionally, Web services frequently expose vital business data to the requestor, who must be identified and not remain anonymous. Exceptions to this rule are free services that do not care who use them. If a service provides different levels of access depending on who is using it, that service also requires authorization to determine, based on identity, what services are accessible to whom.

One way that authorization is implemented is through a set of credentials that a subject identity carries and presents; those credentials are then mapped into access to certain restricted items. Alternatively, rights can be attached to restricted content, and these rights are mapped to identities and the permissions they will be granted to this content.

On the HTML-based Web, authorization has typically been very coarse grained and either gives access to entire sections of a Web site or denies access completely. With Web services, on the other hand, very fine-grained control specifying access to messages, parts of messages, or content carried by a message is possible. Unlike many security concepts, authorization is actually very easy to understand, but it turns out to be exceedingly complex technologically as well as socially. You will see why in Chapter 6, “Portable Identify, Authentication, and Authorization,” which discusses standards such as SAML that are involved with this aspect of identity.

Integrity

Integrity is an assertion that no one has tampered with a message since it was initially created. This assures the sender and the receiver that every bit produced by the sender is received by the recipient in precisely unaltered form. In cryptographic terms, data integrity is accomplished by using digital signatures. Messages in which data integrity is required (Footnote 7) must explicitly or implicitly include the identity and credentials of the sender to enable this kind of message-level security. Why? Because proving integrity means proving no bits have been changed in the message, which involves sending something with the message that no one in the middle could fraudulently create. That, in turn, requires signing that data with a key that only the sender could have had (more on this in Chapter 4, “Safeguarding the Identity and Integrity of XML Messages”). Message integrity- and identity-related issues (authentication and authorization) are often inter-related. Ironically, no matter how sophisticated your security technology becomes, the core security issue comes down to this: Do you know whom you are dealing with and do you trust those people?

Confidentiality

Confidentiality is keeping the message secret. This process requires encryption, which scrambles the message in such a way that only authorized identities can decrypt and see the data. To do this, you exchange a shared secret and an algorithm for encrypting and decrypting the message. You could imagine Bob and Alice agreeing that they were going to encrypt their messages to each other by adding some number to each letter in the alphabet (the algorithm) and that number would be 2 for the next five days (the key). Thus, the message from Bob to Alice would look scrambled to a reader, and even if you knew the algorithm, you would have to do some analysis (not much in this case) to figure out how to decode the message. In the real world, these algorithms are very challenging mathematical functions with keys that are very large numbers, and the time to do the analysis is technically infeasible even with modern computers.

With typical contemporary encryption strategies, you provide the algorithm openly and rely on the strength of the key to keep the encryption secure. The trick is keeping the key secret. You could keep the key secret by giving it to the recipients in some way outside the message exchange, such as mailing it to them or phoning them. However, this approach doesn’t scale up very well to large numbers of participants, so exchanging this key usually requires Public Key Infrastructure (PKI) technology, which is designed to manage and exchange keys. Chapter 3, “The Foundations of Distributed Message-Level Security,” describes PKI in more detail, and Chapter 5, “Ensuring Confidentiality of XML Messages,” goes into a lot of detail about encryption, specifically XML Encryption.

Non-repudiation

As digital transactions are used in more and more legal contracts and as the acceptability of digital signatures becomes commonplace, the legal aspects of identity will become critical for Web services. First and foremost among those legal aspects of identity is non-repudiation.

Non-repudiation proves that one identity sent the data only to another identity. This then proves that this specific transaction was entered into by the recipient, and neither party can refute or deny that it occurred later. If the transaction is challenged legally, a contract that was supposedly executed must be shown to have been entered into by both parties. Each party must have seen the contract as signed, and their identities—confirmed traditionally by validating “wet” signatures on paper and notary witnesses—must have been confirmed at the time of signing. These are difficult, and as yet legally unchallenged, tenants to uphold in a digital and anonymous world, but that day is coming.

Non-repudiation depends on public key cryptography technology. You prove that one identity sent the data only to another identity because the sender used the recipient’s public key, and it is only the recipient with his secret private key who can decrypt the data. To achieve legal non-repudiation, more is needed, such as a separate time-and-date-stamp notary to prove when the transaction occurred as well as independent verification of the participants’ identities.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Web Services Security Basics}

Building on the brief introduction to Web services and information security, you can now delve into Web services security basics. A basic tenet of Web services security is that no new security technologies were invented. Instead, you will build on established security technologies and purpose them to your message-level security needs.

XML Signature

XML Signature is foundational technology for the standard called WS-Security, covered in detail in Chapter 7, and for Web services security in general. XML Signature is built on top of mature digital signature technology. The purpose of digital signatures is to provide a mechanism for message integrity (no one has changed the message since it was created) and non-repudiation (you cannot refute that this message exchange occurred). XML Signature enables you to encode digital signatures into XML.

Electronic signatures were approved by Congress in June 2000. This approval gives legitimacy to electronic signatures and prevents the contesting of a signed contract solely because it is signed electronically. This event set the stage for digital signature standards. The genesis of XML Signature was a joint IETF/W3C working group called XML-DSig that was established to create a highly extensible signature syntax tightly integrated with existing XML technologies, but one that could also handle composite documents from diverse application domains as well. The XML-Signature Syntax and Processing W3C Recommendation defines the XML Signature syntax and associated processing rules. Its ancestors include PKCS#7 Signature and S/MIME. PKCS#7 is part of Public Key Cryptography Standards (PKCS) created by RSA Data Security. With this standard, someone could sign XML, but not in a way consistent with standardized XML format. And it was not possible to sign just part of an XML document as it is with XML Signature. Secure Multipurpose Internet Mail Extensions (S/MIME) already provided a way to bind a digital signature to an email message in a way that allowed the recipient to verify both integrity and non-repudiation of the signer.

XML Signature is a core foundation for Web services security. It was the first XML security standard to reach recommendation status. It is core to WS-Security, XKMS, and other Web services security standards you will be learning much more about. It will be core to your being able to provide integrity and non-repudiation, and you will also find it to be invaluable in the process of transporting shared secret keys that are needed by XML Encryption.

XML Signature is the topic of Chapter 4.

XML Encryption

Like XML Signature, XML Encryption is built on top of mature cryptographic technology—in this case, shared key encryption technology. Core requirements for XML Encryption are that it must be able to encrypt an arbitrarily sized XML message, and it must do so efficiently. Those two factors led its creators to choose shared key (symmetric) encryption as the foundation for XML Encryption. Encryption provides for message confidentiality (the message will be secret from all but the intended recipient). The reason XML Encryption is needed over and above transport-level encryption such as SSL is that you need to maintain confidentiality of messages in the face of the message taking multiple hops on its way to its destination. This will be common when shared services are utilized. You also need confidentiality when the XML message is stored even after it reaches its final destination. This requirement is called persistent confidentiality.

Like XML Signature, XML Encryption applies standard algorithms to data and then stores that encrypted result in XML. And as with XML Signature, you can apply encryption selectively only to portions of a document.

XML Encryption builds on and shares several concepts with XML Signature. Like XML Signature, it is a W3C Recommendation. It is a vitally important second foundation to Web services security because it is the way you will achieve confidentiality in your XML messages. Remember, the key benefit XML Encryption brings over any other encryption strategy is that it allows confidentiality to be satisfied across more than just the context of a single SOAP request.

XML Encryption is the topic of Chapter 5.

SAML

The purpose of SAML is to allow trust assertions to be specified in XML. Assertions apply to an individual or an entity and are “attached” to a message and go where it goes, leading to the simple description of SAML as enabling “portable trust.” SAML assertions take the form of authentications, authorizations, or attributes of entities. Assertions can be claims, statements, or declarations. Assertions are accepted as true only in the context of the integrity and authenticity of the entity making the assertions. At this point, the situation becomes really complicated: Everything you are counting on depends on third parties; you have to trust them to trust the individual on whose behalf claims and assertions are being made.

SAML defines a set of Web APIs (that is, Web services) to be used to obtain these assertions from trust services that make authorization and authentication decisions about individuals and entities. After the SAML authority has made its assertions, SAML also provides a way to exchange this information with other systems. As you will see, WS-Security is enabled to use SAML as one of its security tokens applied to a SOAP message. You will also look at a large project called Project Liberty that is setting out to use SAML (and actually extend it) assertions across multiple security domains, allowing single sign-on to a circle of trust established between business partners.

SAML came from a blending of the two early standards efforts around portable trust called S2ML and AuthML. SAML is developed through the Organization for the Advancement of Structured Information Standards (OASIS) XML-based Security Services Technical Committee (SSTC). SAML 1.0 was approved as a standard in November 2002, version 1.1 was approved as an OASIS standard in August 2003, and a working group is already discussing v2.0.

SAML is the topic of Chapter 6.

WS-Security

XML Signature and XML Encryption are about XML security. So what is WS-Security about? It is about SOAP security.

WS-Security is an overarching conceptual model that abstracts different security technologies into “claims” and “tokens.” Ways to package security tokens into SOAP messages are the nuts and bolts of WS-Security. The broader context of WS-Security is a set of additional road-map specifications built on these concepts and solidified into XML specifications. They involve how to apply for a security token, how tokens are linked to identity, how they are linked to a Web service, and more.

Microsoft initially released WS-Security in October 2001. In April 2002, IBM and VeriSign joined Microsoft in releasing their joint document called “Security in a Web Services World.” This initial security framework was submitted to OASIS in June 2002. OASIS formed the Web Services Security (WSS) technical committee in September 2002 to standardize this specification. Most platform and tools vendors will have shipped support for the initial WS-Security draft specification by early 2004. The WS-Security specification reached “committee draft” status in January 2004.

WS-Security provides a mechanism that allows you to digitally sign (using XML Signature) all or part of a SOAP message and pass the signature in the SOAP header. It provides a mechanism that allows you to encrypt (using XML Encryption) all or part of a SOAP message. It also provides a way to pass information in a SOAP header about the encryption keys needed to decrypt the message or verify the digital signature. And it allows trust assertions about the SOAP message to be passed in the SOAP header as well. A variety of bindings for security tokens have been defined. All these tokens will be explained in detail later.

WS-Security is the topic of Chapter 7.

Trust Issues

WS-Policy allows organizations exposing Web services to specify the specific requirements of their Web services for such issues as privacy or security. WS-Policy is a high-level specification providing the basic constructs needed to compose a particular policy language (such as WS-SecurityPolicy). Closely related to WS-Policy is WS-PolicyAssertions, which provides some basic policy assertions that would apply to any type of policy (for example, the Language assertion), and WS-PolicyAttachment, which gives guidance on how to attach a policy to a resource (for example, a WSDL). WS-SecurityPolicy is a specific type of policy using the WS-Policy framework that answers certain security requirement and configuration questions for a Web service, such as What encryption algorithms are supported? What parameters must be encrypted? What types of security tokens are understood?

The WS-Policy family is the topic of Chapter 8.

Other WS-Security–Related Specs

WS-Security is a broad description of a framework indicating how to secure Web services. To complete the picture begun with the discussions of WS-Security and how it can be used to secure SOAP messages and continued with the policy framework described by WS-Policy and its constituents, we need to fill in the other technologies related to and used by WS-Security. They include more policy-related specifications such as WS-Privacy; the WS-Trust API to trust services; topics related to federation such as WS-Federation, WS-Authorization, and WS-SecureConversation; and a suite of supporting standards not directly in the WS-* family. Those other important standards include The XML Key Management Specification (XKMS), eXtensible Access Control Markup Language (XACML), and eXtensible Rights Markup Language (XrML).

Coverage of other WS-Security–related specifications and technologies appears in Chapter 9, “Trust, Access Control, and Rights for Web Services.”

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Summary}

This chapter asked the question “What are Web services, and why do they need security?” The answer is that Web services are the latest evolution of middleware that creates a loosely coupled RPC mechanism for application and information integration.

This chapter provided a brief introduction to XML, SOAP, and WSDL. The XML language is not only the way Web services messages are formatted, but it is also the language in which all other Web services standards are defined. XML is not new, and there are mature standards for securing XML messages. SOAP is the packaging mechanism for transporting XML messages over networking protocols and for treating XML as an RPC mechanism. WSDL separates the interface for a Web service from its implementation.

There are many types of application integration, and this chapter briefly covered the most common types and described why they need security. Internal application integration is most commonly used to integrate information from different sources within an organization to create more useful and more powerful composite applications. These types of integration need security from prying internal eyes and to comply with internal as well as external business practice policy regulations. B2B business process integration allows organizations to integrate with their supply chain or demand chain. Knowing for sure who is using what information is critical because these types of integration involve business-critical information exchange. Portals are used internally and externally as a way to aggregate information and applications into a single browser-accessible Web site. Users of portals must be authenticated to prove they are part of the group allowed access to the information. Service-oriented architecture is an approach more and more in favor as organizations try to leverage their information-processing assets maximally. SOA allows reuse of useful components and rapid construction of new applications. In SOA, messages move from point to point to point and need to maintain integrity and confidentiality all throughout their journey.

To fulfill all the security requirements Web services will place on you, this chapter asked the question “What are the core concepts of security that you need to know?” The answer starts with cryptography, a branch of mathematics focused on keeping secrets. The crypto-algorithms used to make messages secret are called encryption. The key to keeping secrets is in the keys to these algorithms. In shared key encryption, both sender and receiver share the same key for encryption and decryption of the message. In public key encryption, a matched pair of keys is used, one for encryption and its mate, and only its mate, for decryption. When you know what basic encryption is, the other critical concepts to understand and embrace are authentication (who is it?), authorization (what are they allowed to do?), integrity (is their message unaltered since they sent it?), confidentiality (was the message indecipherable by anyone intercepting it?), and non-repudiation (can you prove the message was indeed sent?).

Finally, this chapter introduced the Web services security basics that build on the security concepts just described. XML Signature provides integrity and non-repudiation for XML messages. XML Encryption provides confidentiality for XML messages. SAML assures the identity of a subject is made trustable and portable so that it can be attached to XML messages. WS-Security makes the entire SOAP system secure. And associated with WS-Security are also a host of other standards that help address a variety of trust issues brought on by Web services.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Footnotes}
  1. SOAP used to stand for Simple Object Access Protocol, but in the W3C SOAP 1.2 specification, SOAP is now just a name and is no longer an acronym. The reason for the change is that the W3C realized that SOAP is neither especially simple, nor is it related to objects in any way.

  2. Most authors consider the base set of Web services standards to include UDDI as well as SOAP and WSDL. UDDI stands for Universal Description, Discovery, and Integration. Advertising Web services so that systems can automatically discover them sounds like a good idea, but we don’t believe it is practical for the public Internet. Instead, we view UDDI as a powerful mechanism to be used inside larger organizations to promote reuse of shared services. So, although we do view it as a useful standard, we don’t view it as part of the core set of things that define Web services.

  3. In an SOA, UDDI will have a strong, meaningful role.

  4. Recommended text on cryptography: Applied Cryptography by Bruce Schneier (John Wiley & Sons, 1996).

  5. 5. The terms shared key, secret key, and symmetric key are used interchangeably in various texts. To be consistent in this book, we choose to use the term shared key throughout, but occasionally context requires we also use the term symmetric key.

  6. “Almost unique” because, like door locks, there is not an absolute certainty that two keys are unique. But the chances of two keys being the same is infinitesimally small, just as is the chance that your key will happen to open a neighbor’s door lock.

  7. On the Web, for example, message integrity is not required and not possible. You request HTML documents from Web sites and assume you are getting what was sent; because the risks of a bit or a word or even the entire document having been modified is low, you don’t worry about message integrity. When the message is a patient record, a purchase order, or a contract, as you expect Web services to carry, you care a lot about integrity.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

[gp-comments width="770" linklove="off" ]

chat