14.5 Security Technologies

< Day Day Up >

14.5 Security Technologies When existing applications evolve into Web services, some of the security constraints and trust models of those applications will need to be carried forward and expressed within current implementations of Web services. To accomplish this result, it is necessary to integrate the work begun in the various Web Services security toolkits, which offer a range of security technologies from basic authentication to XML Signature support. As these security technologies themselves become services, and as workflow becomes the primary application paradigm for dynamic application integration, security services will evolve into core elements of a secure application workflow. A variety of security technologies are being adopted as standards. Following is a brief overview of these standards and how they can be used. XML Signature is a standard for securely binding a claim to a set of bits. The XML Signature specification[10] allows for XML documents to be signed in a standard way, with a variety of digital-signature algorithms. Digital signatures can be used for validation of messages and for nonrepudiation. [10] See RFC 3275 at http://www.ietf.org/rfc/rfc3275.txt. SAML, a blending of the formerly competing Authentication Markup Language (AuthML) and Security Services Markup Language (S2ML), is an industry standard that, together with other standards, forms the basis for secure e-commerce transactions through XML. SAML is being developed to provide a common language for the sharing of security services between companies engaged in B2B and business-to-consumer (B2C) transactions. SAML allows companies to exchange authentication, authorization, and profile information with their customers, partners, or suppliers, regardless of the security systems or e-commerce platforms they have in place. The goal of XML Encryption[11] is to enable encrypting XML fragments. XML Encryption allows for encrypting the parts of an XML document while leaving other parts unencrypted, encrypting a whole XML document, and superencrypting XML data�encrypting an XML document when some of its elements have already been encrypted. [11] See http://www.w3.org/TR/xmlenc-core/. WS-Security is a standard set of SOAP extensions that can be used when building secure Web services to implement integrity and confidentiality. This set of extensions, which is depicted in Table 14.1 on page 509, is also referred to as the Web Services Security Language. As part of the Java Community Process (JCP), four Java Specification Requests (JSRs)[12] are in progress: [12] JSR details can be found at http://www.jcp.org. JSR 105, "XML Digital Signature APIs" JSR 106, "XML Digital Encryption APIs" JSR 155, "Web Services Security Assertions" JSR 183, "Web Services Message Security APIs" These four JSRs leverage the standards body work and define the Java API standards for each respective technology. This standardizes the interfaces in each vendor's Web Services toolkit. 14.5.1 XML and Cryptography XML has become the standard for data exchange. SOAP has become the de facto standard as a means of sending XML messages. An area of rapid growth is security. The Web Services security challenge is to understand and assess the risk involved in securing a Web-based service today, building on existing security technologies, and at the same time tracking emerging standards and understanding how they will be used to offset the risk in new Web services. Any security model must illustrate how data can flow through an application and network topology to meet the requirements defined by the business without exposing the data to undue risk. A Web service security model must support protocol-independent declarative security policies that Web service providers can enforce, as well as descriptive security policies attached to the service definitions that clients can use in order to securely access the Web service. Several standards bodies are actively involved in examining the issues and in developing standards. The main relevant developments here are XML Encryption, XML Signature, and XML Key Management Specification (XKMS), all driven by the World Wide Web Consortium (W3C) WS-Security, XACML, and SAML, driven by OASIS We will concentrate on XML Signature and XML Encryption. Several standard digital signature formats are available today (see Section 10.3.3 on page 370). The most widely used one is Public-Key Cryptography Standards (PKCS) #7 (PKCS#7) (see Section 12.1.3 on page 436), which is used in such standards as S/MIME (see Section 12.2 on page 439) and RosettaNet.[13] [13] Named after the ancient Rosetta stone, which helped decipher hieroglyphics, RosettaNet is a consortium whose goal is to design and implement industrywide, open e-business process standards on the Internet. The consortium includes IBM, Microsoft, Intel, and Oracle. For more information, see http://www.rosettanet.org. The PKCS#7 syntax is based on Abstract Syntax Notation 1 (ASN.1), which takes a binary bit string as the data to be signed. The type of the data being signed is irrelevant as far as the signature's validity is concerned. As any signature algorithm is expensive to apply directly to a large amount of data, a hash value is first calculated for the entire data, and then the hash value is signed (see Section 10.3.3.1 on page 371 and Section 10.3.3.2 on page 372). Typically, even a single bit change in the bit string results in a completely different hash value, as we observed in Section 10.2.2.4 on page 356. Therefore, any modification of the data invalidates the signature. For signing XML documents, a joint working group between the IETF[14] and the W3C has defined the XML Digital Signature standard. XML Digital Signature is an XML grammar for signing data regardless of whether the data object is included within an XML document. Likewise, the XML Encryption specification defines a means of representing encrypted data as XML content. XML Encryption supports elementwise encryption. This way, it is possible to encrypt an entire XML document or only parts of it. [14] See http://www.ietf.org. As with general encryption scenarios, an XML document as a whole can be digitally signed without problem. However, difficulty arises when parts of a document need to be signed, perhaps by different people, and when this needs to be done in conjunction with selective encryption. To digitally sign an XML document, you first must calculate the hash value of the document. It is possible to take an XML document as a character string, and thus a bit string, and compute its hash value. The problem with this approach is that logically, the same XML document can be represented in many different ways because of XML's flexibility regarding character encoding, white-space handling, and so on. To address the problem of surface string deviation, the joint working group of XML Digital Signature defined XML C14N, which introduces a set of rules about how an XML document can be represented as a character string in a standard way, so that equivalent XML documents have exactly the same C14N representation, and nonequivalent XML documents have different C14N representations. There are additional problems as well. One of the strengths of XML languages is that searching is clear and unambiguous: The document type declaration (DTD),[15] or schema, provides information as to the relevant syntax. If a document subsection, including tags, is encrypted as a whole, the ability to search for data relevant to those tags is lost. Further, if the tags are themselves encrypted, they may, being known, be useful as material for mounting plaintext attacks against the cryptography used. [15] The XML document type declaration contains or points to markup declarations that provide a grammar for a class of documents. This grammar is known as a DTD. In Listing 14.1, an XML Digital Signature example, the SignedInfo element points to the data that is signed, and the SignatureValue element contains the actual signature. Note that the canonicalization method is also specified. This way, the receiver knows exactly what algorithm was used to generate the signature. The same algorithm must be used to validate the signature. Listing 14.1. Example of XML Digital Signature <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI= "#wssecurity_body_id_2601212934311668096_1040651106378"> <Transforms> <Transform Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>AWQKpmksMpzzT4PxcizO980gVHw=</DigestValue> </Reference> </SignedInfo> <SignatureValue> bNhT+DsNN9PR [binary data has been truncated] </SignatureValue> </Signature> 14.5.2 WS-Security WS-Security provides a set of mechanisms to help developers of Web services secure SOAP message exchanges. Specifically, WS-Security describes enhancements to the existing SOAP messaging to provide quality of protection through the application of message integrity, message confidentiality, and single-message authentication to SOAP messages. These basic mechanisms can be combined to accommodate building a wide variety of security models using cryptographic technologies. A claim is a declaration made by an entity�for example, about an entity's name, identity, key, group, privilege, capability, and so on. A security token is a collection of claims. Examples of security tokens include an X.509 certificate, a Kerberos ticket, and a user ID. WS-Security provides a general-purpose mechanism for associating security tokens with messages. However, WS-security does not require a specific type of security token. WS-Security is designed to be extensible�for example, by supporting multiple security-token formats�to accommodate a variety of authentication and authorization mechanisms. Let us consider the following security scenario. A requester provides proof of identity and a signed claim of having a particular business certification. A Web service, on receiving such a message, could then determine what kind of trust to place in the claim, based on the signature. Additionally, WS-Security describes how to encode binary security tokens and attach them to SOAP messages. In particular, the WS-Security specification esplains how to encode X.509 digital certificates (see Section 10.3.4 on page 372), Kerberos tickets, and opaque encrypted keys (see Section 11.1.4 on page 389) as samples of various binary token types. Kerberos tickets and X.509 certificates are used by developers to add authentication mechanisms to many Web applications. With WS-Security, the domain of these mechanisms can be extended by carrying authentication information in Web Services requests. WS-Security also includes extensibility mechanisms that can be used to further describe the security tokens included with a message. In this sense, WS-Security is a building block that can be used in conjunction with other Web Services protocols to address a wide variety of application security requirements. Message integrity is provided by leveraging XML Signature and security tokens to ensure that messages have originated from the appropriate sender and were not modified in transit. WS-Security also extends XML Signature by introducing a mechanism to reference attached tokens to bind signatures to claims. Similarly, message confidentiality leverages XML Encryption and security tokens to keep portions of SOAP messages confidential. The SOAP messaging model is based on an extensible framework. SOAP-based specifications are designed to be composed with one another to provide a rich messaging environment. As such, WS-Security by itself does not provide a complete security solution but can be used in conjunction with other Web service and application-specific mechanisms to accommodate a wide variety of existing and future security models and encryption technologies.

< Day Day Up >