Trust, Access Control, and Rights for Web Services Part 1

Security Assertion Markup Language (SAML) was the topic of Chapter 6, "Portable Identity, Authentication, and Authorization." WS-Security was presented in Chapter 7, "Building Security into SOAP." Then WS-Policy was the focus of Chapter 8, "Communicating Security Policy." They are the three pillars of WS-Security.

Several other important standards are derived from and complementary to WS-Security; they relate to such fundamental security topics as trust, access control, and rights. In this chapter, we review the family of WS-Security–related technologies. An important additional topic is the XML Key Management Specification (XKMS) for managing keys used in signatures, encryption, and SAML. We also cover two other WS-Security security related specifications not already covered: eXtensible Access Control Markup Language (XACML) and eXtensible Rights Markup Language (XrML). Let's begin with the WS-Security family.

In April 2002, IBM and Microsoft published a joint whitepaper called "Security in a Web Services World: A Proposed Architecture and Roadmap."1 This whitepaper describes a far-reaching, comprehensive vision of a set of security standards and technologies meant to create a unifying approach for dealing with security in a Web services world. The proposed architecture attempts to bring together for Web services what, to date, had been disparate worlds in security. Just as WS-Security allows security mechanisms such as Public Key Infrastructure (PKI) and Security Assertion Markup Language (SAML) to participate in Web Services Security, the Web Services Architecture Roadmap generalizes many of the security functions that previously existed in other domains and proposes a framework for meeting the security requirements of the Web services domain. It provides an evolutionary strategy for putting the different pieces of the security puzzle in place. The proponents of this framework, and the standards bodies they are working through, are accomplishing this by first rolling out foundational specifications such as WS-Security (which, in turn, was built on XML Signature, XML Encryption, SAML, and various other security token standards) and then following with other standards that rely on these foundational standards. Figure 9.1 repeats the diagram shown previously in Chapter 7; in this figure, you can see the related WS-Security standards as well as the dependencies.

Figure 9.1  The WS-Security family of standards built on SOAP.

As a quick review, WS-Security describes SOAP extensions for securing messages. It is a general-purpose mechanism for associating security tokens with SOAP messages. WS-Security builds on and is fully compatible with established, mature security technologies such as SSL, IPsec, XML Signature, and XML Encryption. It is designed to address message integrity, message confidentiality, message authentication, and the encoding of security tokens that must travel with the messages they are securing.

WS-Security provides the foundations for the set of composable security building blocks in Figure 9.1 built on top of WS-Security. By composable, we mean that various building block standards can be combined to provide new and different security standards to solve specific security challenges. For example, WS-Privacy is composed from WS-Security plus WS-Trust and WS-Policy. These composable standards provide a "use only what you need" approach to securing Web services. The composable specifications still under development together with WS-Security are built on a core foundation of technologies such as SOAP, WSDL, XML Signature, XML Encryption, and SSL.