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."
blog comments powered by Disqus