Meeting the Challenges: New Technologies for Web Services Security

At this point, we’ve seen the requirement for new Web Services security specifications. Let’s look at how this requirement is being met by introducing new security specifications, which will be explored in greater detail in subsequent chapters.

Persistent Security

The three security challenges we’ve seen have one thing in common. The principles of security must apply to a security context that includes more than a single request/response SOAP message. The solution to this problem is to persist security data in the SOAP message itself. The security data therefore is not lost after one SOAP communication has ended. Confidential information in a SOAP message should remain confidential over the course of a number of SOAP hops.

A number of industry specifications have been developed for this purpose. These specifications can be organized into two distinct categories:

1. A standardized framework to include XML-formatted security data into SOAP messages.

2. Standards for expressing security data in XML format. This security information should be used for the high-level principles of security: confidentiality, authentication, authorization, integrity, and so forth.

Including XML-Formatted Security Data in SOAP Messages: Introducing WS-Security

WS-Security has emerged as the de facto method of inserting security data into SOAP messages. Work on WS-Security began in 2001, was published by Microsoft, VeriSign, and IBM in April 2002, and was then submitted in June 2002 to the OASIS standards body in order to be made into an industry standard. WS-Security defines placeholders in the SOAP header in order to insert security data. It defines how to add encryption and digital signatures to SOAP messages, and then a general mechanism for inserting arbitrary security tokens. WS-Security is “tight” enough to present the definitive means of including security data into SOAP messages, but is “loose” enough to not place limits on what that security data can be.

Confidentiality for Web Services: Introducing XML Encryption

XML Encryption is a specification from the W3C. It provides not only a way of encrypting portions of XML documents, but also a means of encrypting any data and rendering the encrypted data in XML format. XML Encryption makes encryption functionality easier to deploy.

XML Encryption is not a replacement for SSL. SSL is still the de facto choice for confidentiality between two entities that are communicating using HTTP. However, if the security context extends beyond this individual HTTP connection, XML Encryption is ideal for confidentiality. The capability to encrypt XML is nothing new, because XML is just text after all. However, the ability to selectively encrypt XML data is what makes XML Encryption so useful for Web Services. Encrypting an entire SOAP message is counterproductive, because the SOAP message must include enough information to be useful—routing information, for example. Selectively encrypting data in the SOAP message is useful, however. Certain information may be hidden from SOAP intermediaries as it travels from the originator to the destination Web Service.

XML Encryption does not introduce any new cryptography algorithms or techniques. Triple-DES or RSA encryption may still be used for the actual encryption. XML Encryption provides a way to format the meta-information about which algorithm was used, and when the encryption occurred. This aids the Web Service in decrypting the data, provided the decryption key is available to it. This is important, because prior to XML Encryption the only standardization of encryption data was for e-mail messages (that is, S/MIME). If an organization wished to send encrypted data to another organization, both organizations would have to agree on the format of the encrypted data, how and which algorithms to use, and possibly also how to send an encrypted key. Now that information can be contained in an XML Encryption block. Chapter 5 explores XML Encryption in detail, including code examples in C# and Java.

WS-Security defines how XML Signature data can be included in a SOAP message. This provides persistent confidentiality beyond a single SOAP communication.

Integrity for Web Services: Introducing XML Signature

XML Signature is a specification produced jointly by the W3C and the Internet Engineering Task Force (IETF). Like XML Encryption, it does not only apply to XML. As well as explaining how to digitally sign portions of an XML document, XML Signature also explains how to express the digital signature of any data as XML. As such, it is an “XML-aware digital signature.” PKCS#7 is a means of rendering encrypted data, and signed data, which predates XML Signature and XML Encryption. Rather than using XML, it uses Abstract Syntax Notation number 1 (ASN.1). ASN.1 is a binary format, renowned for its complexity. Producing or verifying a PKCS#7 signature requires not just cryptography software, but also an ASN.1 interpreter. XML Signature also requires cryptography software, of course, but an XML DOM replaces the ASN.1 interpreter.

The power of XML Signature for Web Services is the ability to selectively sign XML data. For example, a single SOAP parameter passed to a method of a Web Service may be signed. If the SOAP request passes through intermediaries en route to the destination Web Service, XML Signature ensures end-to-end integrity.

WS-Security describes how to include XML Signature data in a SOAP message. An important feature of XML Signature is that it can be very selective about what data in an XML instance is signed. This feature is particularly useful for Web Services. For example, if a single SOAP parameter needs to be signed but the SOAP message’s header needs to be changed during routing, an XML Signature can be used that only signs the parameter in question and excludes other parts of the SOAP message. Doing so ensures end-to-end integrity for the SOAP parameter while permitting changes to the SOAP’s header information. Chapter 4 explores XML Signature in detail, including code examples in C# and Java.

Web Services Authentication and Authorization: Introducing SAML, XACML, Passport, and Liberty

Single sign-on (SSO) is one of the “hard” problems in information technology. As seen in Figure 3-5, if a user signs on to a Web site and then a SOAP request is produced on the user’s behalf, the destination Web Service may require information about the end user in order to make an authorization decision. Otherwise, the destination Web Service only has visibility of the machine that is creating the SOAP request. There are two approaches to this requirement. The first approach is to include the information in the SOAP message itself. The second approach is to request this information from a central repository.

Security Assertions Markup Language (SAML) provides a means of expressing information about authentication and authorization, as well as attributes of an end user (for example, a credit limit) in XML format. SAML data may be inserted into a SOAP message using the WS-Security framework. SAML is used to express information about an act of authentication or authorization that has occurred in the past. It does not provide authentication, but can express information about an authentication event that has occurred in the past; for example, "User X authenticated using a password at time Y.” If an entity is authorized based on the fact that they were previously authorized by another system, this is called “portable trust.” SAML is important to address the challenge of multihop SOAP messages also, because separate authentication to each Web Service is often out of the question. By authenticating once, being authorized, and effectively reusing that authorization for subsequent Web Services, single sign-on for Web Services can be achieved.

Note that this information in a SAML assertion may not indicate the end user’s identity. The user may have authenticated using a username and password, and the administrator of the Web site may have no idea of the user’s actual identity. It may simply be an indication that the user presented credentials and was authenticated and authorized. SAML allows information to be placed into a SOAP message to say “this person was authorized according to a certain security policy at a certain time." If the recipient of this SOAP message trusts the issuer of the SAML data, the end user can also be authorized for the Web Service. This SAML data is known as an “assertion” because the issuer is asserting information about the end user. The concept of security assertions has existed before SAML, and is already widely used in existing software.

XML Access Control Markup Language (XACML) is designed to express access control rules in XML format. Although the two technologies are not explicitly linked, XACML may be used in conjunction with SAML. An authorization decision expressed in a SAML assertion may have been based on rules expressed in XACML.

Microsoft’s Passport technology takes a different approach to single sign-on. The user authenticates to the passport infrastructure, either directly through www.passport .com or through an affiliate site that makes use of functionality provided by passport.com. Once the user is authenticated and authorized by Passport, their authentication status is also available to other Web Services that use Passport. Like SAML, this provides single sign-on. However, the model is different, relying on a central point of authentication rather than SAML’s architecture where authentication happens at an individual Web Service. By being implemented at the site of the Web Service itself, SAML authentication and authorization information may be based on role-based security. Role-based security means that access to resources is based on the user’s organizational role; for example, in a medical setting doctors may have access to certain information while nurses have access to different information.

Another industry proposal for the SSO on the Web is the Liberty Alliance Project, championed by Sun. The Liberty Alliance Project aims to enable a non-centralized approach to SSO, termed a “federated network identity.” At the time of this writing, it appears the Passport proposal by Microsoft may be taking a similar tack to the Liberty Alliance Project.

PKI for Web Services: Introducing XKMS

As you may recall from Chapter 2, PKI is a system that allows public key keys to be trusted by providing key signing and key validation services. Although accepted as an important, even vital, technology, PKI has a reputation for being notoriously difficult to implement. The benefits of XML and Web Services apply quite naturally to PKI: addressing interoperability and integration issues. The XML Key Management specification (XKMS) enables PKI services such as trustworthily registering, locating, and validating keys through XML-encoded messages. Because XKMS is service- oriented and uses XML messages, it is only natural that it be implemented as a SOAP-based Web Service giving it the distinction of not only being useful for securing Web Services, but also being available as a Web Service itself. By leveraging the benefits of XML and by learning from past experiences with pre-XML PKI architectures, XKMS makes PKI practical for common use.

Like XML Signature, XKMS eliminates the need for ASN.1 functionality in software that deals with digital certificates. It goes further, however, and can allow XML software to use digital certificates and PKI without the need to implement cryptography algorithms. This is useful for software developers, many of whom may not have the time or inclination to delve into cryptography or employ cryptography toolkits.