Web Services Security Initiatives and Organizations

The following organizations work on web services security specifications, guidelines, and tools:

The World Wide Web Consortium (W3C)

Organization for Advancement of Structured Information Standards (OASIS)

Web Services Interoperability Organization (WS-I)

Java Community Process (JCP)

Basically, the JCP, W3C, and OASIS are developing specifications related to web services security. WS-I creates profiles that recommend what to implement from various specifications and provides direction on how to implement the specifications. The following sections briefly discuss the specifications and profiles being developed by each organization at the time of this writing.

W3C Specifications

The mission of the World Wide Web Consortium (W3C), according to its Web site at http://www.w3.org/, is to lead the World Wide Web to its full potential by developing protocols and guidelines that ensure long-term growth for the web. W3C primarily pursues its mission through the creation of Web standards and guidelines. The W3C is working on the following specifications related to web services security:

XML Encryption (XML-Enc)

This specification provides requirements for XML syntax and processing for encrypting digital content, including portions of XML documents and protocol messages. The version of the specification current at the time of this writing may be viewed at http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.

XML Digital Signature (XML-Sig)

This specification specifies an XML compliant syntax used for representing the signature of web resources and portions of protocol messages (anything referenceable by a URI) and procedures for computing and verifying such signatures. The version of the specification current at the time of this writing may be viewed at http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.

XML Key Management Specification (XKMS)

The specification specifies protocols for distributing and registering public keys, suitable for use in conjunction with the W3C recommendations for XML Signature and XML Encryption. The version of the specification current at the time of this writing may be viewed at http://www.w3.org/TR/2005/REC-xkms2-20050628/.

OASIS Specifications

According to its web site at http://www.oasis-open.org/, the Organization for the Advancement of Structured Information Standards (OASIS) drives the development, convergence, and adoption of e-business standards. OASIS is working on the following specifications related to web services security. At the time this document was written, OASIS standards documents are available from http://www.oasis-open.org/specs/index.php.

Web Services Security (WSS): SOAP Message Security

This specification describes enhancements to SOAP messaging to provide message integrity, message confidentiality, and message authentication while accommodating a wide variety of security models and encryption technologies. This specification also defines an extensible, general-purpose mechanism for associating security tokens with message content, as well as how to encode binary security tokens, a framework for XML-based tokens, and how to include opaque encrypted keys.

Security Assertion Markup Language (SAML)

The SAML specification defines an XML-based mechanism for securing Business-to-Business (B2B) and Business-to-Consumer (B2C) e-commerce transactions. SAML defines an XML framework for exchanging authentication and authorization information. SAML uses XML-encoded security assertions and XML-encoded request/response protocol and specifies rules for using assertions with standard transport and messaging frameworks. SAML provides interoperability between disparate security systems. SAML can be applied to facilitate three use cases: single sign-on, distributed transactions, and authorization services.

eXtensible Access Control Markup Language (XACML)

The XACML specification defines a common language for expressing security policy. XACML defines an extensible structure for the core schema and namespace for expressing authorization policies in XML. A common policy language, when implemented across an enterprise, allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems.

JCP Specifications

According to the Java Community Process (JCP) web site, the JCP holds the responsibility for the development of Java technology. The JCP primarily guides the development and approval of Java technical specifications. The JCP is working on the following specifications related to web services security. The specifications can be viewed from the JCP web site at http://www.jcp.org/en/jsr/all.

JSR 104: XML Trust Service APIs

JSR-104 defines a standard set of APIs and a protocol for a trust service. A key objective of the protocol design is to minimize the complexity of applications using XML Signature. By becoming a client of the trust service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships, which may be based upon a different specification such as X.509/PKIX, SPKI or PGP.

JSR 105: XML Digital Signature APIs

JSR-105 defines a standard set of APIs for XML digital signature services. The XML Digital Signature specification is defined by the W3C. This proposal is to define and incorporate the high-level implementation-independent Java APIs.

JSR 106: XML Encryption APIs

JSR-106 defines a standard set of APIs for XML digital encryption services. XML Encryption can be used to perform fine-grained, element-based encryption of fragments within an XML Document as well as encrypt arbitrary binary data and include this within an XML document.

JSR 155: Web Services Security Assertions

JSR-155 provides a set of APIs, exchange patterns, and implementation to securely (integrity and confidentiality) exchange assertions between web services based on OASIS SAML.

JSR 183: Web Services Message Security APIs

JSR-183 defines a standard set of APIs for Web services message security. The goal of this JSR is to enable applications to construct secure SOAP message exchanges.

JSR 196: Java Authentication Service Provider Interface for Containers

The proposed specification will define a standard service provider interface by which authentication mechanism providers may be integrated with containers. Providers integrated through this interface will be used to establish the authentication identities used in container access decisions, including those used by the container in invocations of components in other containers.

WS-I Specifications

According to the Web Services Interoperability Organization (WS-I) web site, WS-I is an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages. Specifically, WS-I creates, promotes and supports generic protocols for the interoperable exchange of messages between Web services. WS-I creates profiles, which recommend what to use and how to use it from the various web services specifications created by W3C, OASIS, and the JCP. WS-I is working on the following profiles related to web services security. The profiles can be viewed from the WS-I web site at http://www.ws-i.org/deliverables/Default.aspx.

Basic Security Profile (BSP)

The Basic Security Profile provides guidance on the use of WS-Security and the User Name and X.509 security token formats.

REL Token Profile

The REL Token Profile is the interoperability profile for the Rights Expression Language (REL) security token that is used with WS-Security.

SAML Token Profile

This is the interoperability profile for the Security Assertion Markup Language (SAML) security token that is used with WS-Security.

Security Challenges, Threats, and Countermeasures

This document identifies potential security challenges and threats in a web service application, and identifies appropriate candidate technologies to address these challenges. The section Security Challenges, Threats, and Countermeasures discusses the challenges, threats, and countermeasures in a bit more detail.

Security Challenges, Threats, and Countermeasures

The WS-I document titled Security Challenges, Threats, and Countermeasures can be read in its entirety at http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf. Table 31-1 attempts to summarize many of the threats and countermeasures as an introduction to this document.

Table 31-1 Security Challenges, Threats, and Countermeasures
Challenge	Threats	Countermeasures
Peer Identification and Authentication	falsified messages, man in the middle, principal spoofing, forged claims, replay of message parts	-HTTPS with X.509 server authentication -HTTP client authentication (Basic or Digest) -HTTPS with X.509 mutual authentication of server and user agent -OASIS SOAP Message Security
Data Origin Identification and Authentication	falsified messages, man in the middle, principal spoofing, forged claims, replay of message parts	-OASIS SOAP Message Security -MIME with XML Signature/XML Encryption -XML Signature
Data Integrity (including Transport Data Integrity and SOAP Message Integrity)	message alteration, replay	-SSL/TLS with encryption enabled -XML Signatures (as profiled in OASIS SOAP Message Security)
Data Confidentiality (including Transport Data Confidentiality and SOAP Message Confidentiality)	confidentiality	-SSL/TSL with encryption enabled -XML Signatures (as profiled in OASIS SOAP Message Security)
Message Uniqueness	replay of message parts, replay, denial of service	-SSL/TLS between the node that generated the request and the node that is guaranteeing -Signing of nonce, time stamp

As you can see from the countermeasures that are recommended in the table and in the document, the use of XML Encryption and XML Digital Signature to secure SOAP messages and attachments is strongly recommended by this organization. Using Message Security with Java EE discusses some options for securing messages with Java EE.