The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: September 13, 2006
Web Services Security Specification (WS-Security, WS-Security 2004)

Overview: In October 2001, Microsoft announced the release of a WS-Security specification defining enhancements to SOAP messaging to provide three capabilities: credential exchange, message integrity, and message confidentiality. In April 2002, Microsoft, IBM, VeriSign announced the publication of a Web Services Security (WS-Security) specification and a roadmap document describing a proposed strategy for addressing security within a Web service environment.

In July 2002 the Web Services Security (WS-Security) specification was submitted to OASIS by IBM, Microsoft, and VeriSign for further development. Also in July 2002, an OASIS Web Services Security Technical Committee (WSS) was formed to continue work on the Web services security foundations published in the WS-Security specification within the context of the Web Services Security roadmap published in April, 2002: "Security in a Web Services World: A Proposed Architecture and Roadmap."

In April 2004 the OASIS WSS TC Chairs announced that five specifications produced by the technical committee had been approved as OASIS standards. This initial specification set included a core document Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), the Web Services Security UsernameToken Profile 1.0, the Web Services Security X.509 Certificate Token Profile, and two relevant XML Schemas.

In February 2006, OASIS announced that its members had "approved WS-Security version 1.1 as an OASIS Standard. Developed through an open process by the OASIS Web Services Security (WSS) Technical Committee, WS-Security delivers a technical foundation for implementing security functions such as integrity and confidentiality in messages implementing higher-level Web services applications... The WSS specifications describe a mechanism for securing web services message exchanges using a variety of existing security technologies and methodolgies. The 2006-02 document set is the 1.1 revision of the original WS-Security 2004 OASIS standard. Several token profiles have been added. The 1.0 Errata has been factored in. Feedback from the public has been included and steps have been taken to enhance the readability and usability of the specification. An additional 1.1 Schema has been produced and a few XML Elements have been added to the language."

Contents


Web Services Security: Publication Milestones

[February 15, 2006] "Members Approve WS-Security v1.1 as OASIS Standard."

[April 08, 2004]   OASIS Web Services Security Specification Approved as an OASIS Standard.    On April 6, 2004 the co-chairs of the OASIS Web Services Security (WSS) Technical Committee announced the TC's unanimous decision to request that the WSS TC's Web Services Security specification, as successfully balloted to the OASIS membership, be advanced to OASIS Standard status. The Web Services Security specification set includes: Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), Web Services Security UsernameToken Profile 1.0, Web Services Security X.509 Certificate Token Profile, and two relevant XML Schemas. The WSS TC is also creating additional token profiles for use with the core SOAP Message Security 1.0 specification, including the Web Services Security: SAML Token Profile, now in an advanced state of preparation. The SOAP Message Security 1.0 core specification "describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies. The specification also provides a general-purpose mechanism for associating security tokens with message content. No specific type of security token is required, the specification is designed to be extensible, so as to support multiple security token formats. For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification. Additionally, the specification describes how to encode binary security tokens, a framework for XML-based tokens, and how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics 26 of the tokens that are included with a message." The UsernameToken Profile describes how to use the UsernameToken with the core WSS specification. It "describes how a web service consumer can supply a UsernameToken as a means of identifying the requestor by 'username', and optionally using a password (or shared secret, or password equivalent) [how] to authenticate that identity to the web service producer." The X.509 Certificate Token Profile document describes "how to use X.509 Certificates with the SOAP Message Security 1.0 specification. An X.509 certificate specifies a binding between a public key and a set of attributes that includes (at least) a subject name, issuer name, serial number and validity interval. This binding may be subject to subsequent revocation advertised by mechanisms that include issuance of CRLs, OCSP tokens or mechanisms that are outside the X.509 framework, such as XKMS. An X.509 certificate may be used to validate a public key that may be used to authenticate a WS-Security-enhanced message or to identify the public key with which a WS-Security-enhanced message has been encrypted."

[January 26, 2004]   OASIS Web Services Security TC (WSS) Approves Committee Draft Specifications.    A set of five documents has been approved as Committee Draft specifications by the OASIS Web Services Security (WSS) Technical Committee. The WSS Committee Draft documents have also been approved for submission to OASIS for consideration as OASIS standards. The CDs include Web Services Security: SOAP Message Security 1.0, Web Services Security UsernameToken Profile, and Web Services Security X.509 Certificate Token Profile. They are accompanied by two XML Schemas, documented in the main WSS specification as Appendix A "Utility Elements and Attributes" and Appendix B "SecurityTokenReference Model." The WSS 1.0 specification "describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies. The document also provides a general-purpose mechanism for associating security tokens with message content. No specific type of security token is required, the specification is designed to be extensible (i.e., support multiple security token formats). For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification. Additionally, the WSS specification describes how to encode binary security tokens, a framework for XML-based tokens, and how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the tokens that are included with a message." The OASIS WSS TC was chartered to continue work on the Web Services security foundations as described in an earlier WS-Security specification authored by IBM, Microsoft, and VeriSign, written within the context of the Web Services Security Roadmap as published in April 2002. WSS TC members also envision that the approved deliverables will form "the necessary technical foundation for higher-level security services which are to be defined in other specifications."

[September 09, 2003]   OASIS WSS TC Approves Three Web Services Security Specifications for Public Review.    The OASIS Web Services Security Technical Committee has announced a unanimous vote to begin the public review of three Web Services Security specifications and associated XML Schemas. The documents were approved as TC Committee Drafts, moving the WSS TC's work one step closer to making WS-Security an OASIS Standard. The 30-day public review period for the WSS TC specifications starts 19-September-2003 and ends 19-October-2003. The Core Web Services Security: SOAP Message Security document "proposes a standard set of SOAP extensions that can be used when building secure Web services to implement message content integrity and confidentiality. It is flexible and is designed to be used as the basis for securing Web services within a wide variety of security models including PKI, Kerberos, and SSL. Specifically, this specification provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies." Two XML Schemas are considered part of the WSS Core. The Web Services Security: Username Token Profile document "describes how to use the UsernameToken with the Web Services Security (WSS) specification; more specifically, it describes how a web service consumer can supply a UsernameToken as a means of identifying the requestor by 'username', and optionally using a password, to authenticate that identity to the web service producer." The Web Services Security: X.509 Certificate Token Profile document describes the use of the X.509 authentication framework with the Core WSS specification. An X.509 certificate may be used to validate a public key that may be used to authenticate a WS-Security-enhanced message, or to identify the public key with which a WS-Security-enhanced message has been encrypted."

[July 23, 2002]   OASIS Announces Technical Committee for Web Services Security.    OASIS has announced the formation of new Technical Committee for Web Services Security (WSS). The TC is designed to continue work on the Web services security foundations published in the WS-Security specification from IBM, Microsoft, and Verisign. Development will also follow the vision of the Web Services Security Roadmap published in April, 2002. The WS-Security specification "defines a standard set of Simple Object Access Protocol (SOAP) extensions, or message headers, that can be used to implement integrity and confidentiality in Web services applications." The new Web Services Security specification will support security mechanisms of several types, each using implementation and language-neutral XML formats defined by XML Schema: use of XML signature to provide SOAP message integrity for Web services; use of XML encryption to provide SOAP message confidentiality for Web services; attaching and/or referencing security tokens in headers of SOAP messages; carrying security information for potentially multiple, designated actors; associating signatures with security tokens; representing specific forms of binary security tokens as defined in WS-Security specification. Participation in the OASIS Web Services Security Technical Committee is open to all organizations and individuals. [Full context]

[June 27, 2002] Announcement: "IBM, Microsoft and VeriSign Submit WS-Security Specification to OASIS for Standardization. Advanced Web Services Security Specification Broadly Supported by Industry." - "IBM, Microsoft Corp., and VeriSign, Inc., today announced they will submit the latest version of the Web Services Security (WS-Security) specification to the Organization for the Advancement of Structured Information Standards (OASIS) for ongoing development. The WS-Security specification is one of the first Web services standards to support, integrate and unify multiple security models, mechanisms and technologies, allowing a variety of systems to interoperate in a platform- and language-neutral manner. Baltimore Technologies, BEA Systems, Cisco Systems, Documentum, Entrust, Inc., Intel Corporation, IONA, Netegrity, Novell, Oblix, OpenNetwork, RSA Security, SAP, Sun Microsystems, and Systinet have all expressed plans to participate in the OASIS development effort. With this announcement, IBM, Microsoft and VeriSign are furthering their commitment to build and deliver standards-based security solutions that meet customer requirements. The three companies will continue to work together to advance standards-based specifications that will allow for comprehensive Web services security solutions as outlined in the "Security in a Web Services World" road map, which was drafted by IBM and Microsoft in April 2002. The WS-Security specification, which provides the foundation for that road map, defines a standard set of Simple Object Access Protocol (SOAP) extensions, or message headers, that can be used to implement integrity and confidentiality in Web services applications. Web services are applications that can be accessed through XML and SOAP-based protocols, making them platform- and language-independent. WS-Security provides a foundation layer for secure Web services, laying the groundwork for higher-level facilities such as federation, policy and trust..."

[April 11, 2002] A joint announcement from Microsoft, IBM, and VeriSign on 2002-04-11 presented the (re-) publication of a Web services security specification "to help organizations build secure, broadly interoperable Web services applications. The three companies jointly developed the new specification, known as WS-Security, and plan to submit it to a standards body. WS-Security defines a standard set of Simple Object Access Protocol (SOAP) extensions, or message headers, that can be used to implement integrity and confidentiality in Web services applications." The WS-Security specification is positioned as "the foundation for a broader road map and additional set of proposed Web services security capabilities outlined by IBM and Microsoft to tackle the growing need for consistent support of more secure Web services. The proposed road map is documented in Security in a Web Services World, which outlines additional Web services security specifications the companies plan to develop along with key customers, industry partners, and standards organizations." The other specifications include WS-Policy, WS-Trust, WS-Privacy, WS-Secure Conversation, WS-Federation, and WS-Authorization. The modular approach outlined in the proposal is said to be "necessary for Web services security because of the variety of systems that make up today's IT environments; as the use of Web services increases among collaborating organizations using different security approaches, the proposed security and trust model provides a flexible framework in which organizations can interconnect in a trusted way."

[October 23, 2001] An announcement was made in October, 2001, as presented in the news item "Microsoft Releases New XML Web Services Specifications for a Global XML Web Services Architecture." Specifications referenced then included: (1) WS-Security; (2) WS-Routing; (3) WS-Referral; (4) WS-License. From the description: "This Global XML Web Services Architecture "provides a set of principles and guidelines for advancing the protocols and file formats of today's XML Web services to more complex and sophisticated tasks. The four specifications build on XML Web services technologies such as XML, SOAP, WSDL, and UDDI specifications, extending them for global-class computing. The new specifications adhere to the road map outlined by Microsoft and IBM Corp. at the W3C Web Services Workshop in April 2001 and represent a first step toward a comprehensive Global XML Web Services Architecture. (1) WS-Security outlines how to use the W3C specifications XML Signature and XML Encryption; (2) WS-License, along with WS-Security, outlines how existing digital credentials and their associated trust semantics can be securely associated with SOAP messages; (3) WS-Routing describes how to place message addresses in the SOAP message header and enables SOAP messages to travel serially to multiple destinations along a message path [formerly SOAP-RP]; (4) WS-Referral enables the routing between SOAP nodes on a message path to be dynamically configured. As with previous XML Web services specifications, these four will be available for a review period and then submitted to appropriate standards bodies."


OASIS Web Services Security TC (WSS) Deliverables

  • OASIS WSS TC:

  • Web Services Security: SOAP Message Security 1.0 (WS-Security 2004). Monday, 15-March-2004. Edited by Anthony Nadalin (IBM), Chris Kaler (Microsoft), Phillip Hallam-Baker (VeriSign), and Ronald Monzillo (Sun). Produced by members of the OASIS Web Services Security (WSS) Technical Committee. Document identifier: {WSS: SOAP Message Security }-{1.0} (Word) (PDF). Location: 'http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0'. 56 pages. This slightly revised version of the 'core' document was released on March 15, 2004 in connection with the ballot for approving the document as an OASIS Standard. The WSS TC changed the name on the title page of the specification to avoid confusion with the original contribution. The following clarification was added in the document Introduction: "This OASIS specification is the result of significant new work by the WSS Technical Committee and supersedes the input submissions, Web Service Security (WS-Security) Version 1.0 April 5, 2002 and Web Services Security Addendum Version 1.0 August 18, 2002." Summary: The SOAP Message Security 1.0 core specification "describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies. The specification also provides a general-purpose mechanism for associating security tokens with message content. No specific type of security token is required, the specification is designed to be extensible, so as to support multiple security token formats. For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification. Additionally, the specification describes how to encode binary security tokens, a framework for XML-based tokens, and how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics 26 of the tokens that are included with a message." [source PDF]

  • Web Services Security UsernameToken Profile 1.0. Edited by Anthony Nadalin (IBM), Phil Griffin (Individual Member), Chris Kaler (Microsoft), Phillip Hallam-Baker (VeriSign), and Ronald Monzillo (Sun). Produced by members of the OASIS Web Services Security (WSS) Technical Committee. Monday, 15-March-2004. Document identifier: '{WSS: SOAP Message Security }-{UsernameToken Profile }-{1.0}'. 14 pages. Summary: The UsernameToken Profile describes how to use the UsernameToken with the core WSS specification. It "describes how a web service consumer can supply a UsernameToken as a means of identifying the requestor by 'username', and optionally using a password (or shared secret, or password equivalent) [how] to authenticate that identity to the web service producer." [source PDF]

  • Web Services Security X.509 Certificate Token Profile. Edited by Phillip Hallam-Baker (VeriSign), Chris Kaler (Microsoft), Ronald Monzillo (Sun), and Anthony Nadalin (IBM). Produced by members of the OASIS Web Services Security (WSS) technical committee. Monday, 15-March-2004. Document identifier: '{WSS: SOAP Message Security }-{X509 Profile }-{1.0}'. 17 pages. Summary: The X.509 Certificate Token Profile document describes "how to use X.509 Certificates with the SOAP Message Security 1.0 specification. An X.509 certificate specifies a binding between a public key and a set of attributes that includes (at least) a subject name, issuer name, serial number and validity interval. This binding may be subject to subsequent revocation advertised by mechanisms that include issuance of CRLs, OCSP tokens or mechanisms that are outside the X.509 framework, such as XKMS. An X.509 certificate may be used to validate a public key that may be used to authenticate a WS-Security-enhanced message or to identify the public key with which a WS-Security-enhanced message has been encrypted." [source PDF]

  • WSS XML Schema: wss-wssecurity-secext-1.0.xsd. Namespace: http://www.docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd, and namespace prefix: wsse. Appendix B "SecurityTokenReference Model" of Web Services Security: SOAP Message Security 1.0 "provides a non-normative overview of the usage and processing models for the <wsse:SecurityTokenReference> element. There are several motivations for introducing the <wsse:SecurityTokenReference> element: The XML Signature reference mechanisms are focused on 'key' references rather than general token references. The XML Signature reference mechanisms utilize a fairly closed schema which limits the extensibility that can be applied. There are additional types of general reference mechanisms that are needed, but are not covered by XML Signature. There are scenarios where a reference may occur outside of an XML Signature and the XML Signature schema is not appropriate or desired. The XML Signature references may include aspects (e.g., transforms) that may not apply to all references..." [source .XSD]

  • WSS XML Schema: wss-wssecurity-utility-1.0.xsd. Namespace: http://www.docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd, and namespace prefix: wsu. Appendix A "Utility Elements and Attributes" of Web Services Security: SOAP Message Security 1.0 "defines several elements, attributes, and attribute groups which can be re-used by other specifications. This appendix provides an overview of these utility components. It should be noted that the detailed descriptions are provided in the specification and this appendix will reference these sections as well as calling out other aspects not documented in the specification. Identification Attribute: There are many situations where elements within SOAP messages need to be referenced. For example, when signing a SOAP message, selected elements are included in the signature. XML Schema Part 2 provides several built-in data types that may be used for identifying and referencing elements, but their use requires that consumers of the SOAP message either have or are able to obtain the schemas where the identity or reference mechanisms are defined. In some circumstances, for example, intermediaries, this can be problematic and not desirable. Consequently a mechanism is required for identifying and referencing elements, based on the SOAP foundation, which does not rely upon complete schema knowledge of the context in which an element is used. This functionality can be integrated into SOAP processors so that elements can be identified and referred to without dynamic schema discovery and processing. This specification specifies a namespace-qualified global attribute for identifying an element which can be applied to any element that either allows arbitrary attributes or specifically allows this attribute... The specification [also] defines XML elements which may be used to express timestamp information such as creation and expiration. While defined in the context of message security, these elements can be re-used wherever these sorts of time statements need to be made. The elements in this specification are defined and illustrated using time references in terms of the dateTime type defined in XML Schema... The schema for the utility aspects of this specification also defines some general purpose schema elements..." [source .XSD]

  • Web Services Security: SAML Token Profile. WSS TC Working Draft. Version 10. April 06, 2004. Produced by members of the OASIS Web Services Security (WSS) Technical Committee. 35 pages. This document describes how to use Security Assertion Markup Language (SAML) Version 1.1 assertions with the core Web Services Security: SOAP Message Security 1.0 specification. The profile describes: (1) how SAML assertions are carried in and referenced from <wsse:security> headers; (2) how SAML assertions are used with XML Signature to bind the statements of the assertions (i.e., the claims) to a SOAP message. See also the following reference.

  • Web Services Security: SAML Interop 1 Scenarios. WSS Technical Committee Working Draft. Version 04. January 29, 2004. 41 pages. Document identifier: 'wss-saml-interop1-draft-04.doc'. OASIS WSS TC. Edited by Rich Levinson (Netegrity) and Hal Lockhart (BEA Systems). With contributions from Prateek Mishra (Netegrity) and Ron Monzillo (Sun Microsystems). ['This document documents the four scenarios to be used for the WSS-SAML Interoperability Event.'] "This document describes message exchanges to be tested during the SAML interoperability event of the WSS TC. All use the Request/Response Message Exchange Pattern (MEP) with no intermediaries. All invoke the same simple application. These scenarios are intended to test the interoperability of different implementations performing common operations and to test the soundness of the various specifications and clarity and mutual understanding of their meaning and proper application." See preceding reference: a WSS SAML Profile is being prepared and a SAML "virtual interop" event is to be held on May 17, 2004. Contact: Ronald Monzillo; SAML general references. [source .DOC]

  • [December 16, 2002] "Web Services Security Core Specification." Produced by the OASIS Web Services Security TC (WSS). Working Draft version 08. 12-December-2002. Document identifier: WSS-Core-08. 56 pages. Edited by Phillip Hallam-Baker (VeriSign), Chris Kaler (Microsoft), Ronald Monzillo (Sun), and Anthony Nadalin ( IBM). 'An updated draft of WSS-Core to address action items that occurred in the F2F as of 12/12/2002, posted to the TC mailing list by Anthony Nadalin 2002-12-16. " This specification proposes a standard set of SOAP extensions that can be used when building secure Web services to implement message level integrity and confidentiality. This specification refers to this set of extensions as the 'Web Services Security Core Language' or 'WSS-Core'. This specification is flexible and is designed to be used as the basis for securing Web services within a wide variety of security models including PKI, Kerberos, and SSL. Specifically, this specification provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. The token formats and semantics for using these are defined in the associated binding documents. This specification provides three main mechanisms: ability to send security token as part of a message, message integrity, and message confidentiality. These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies. These mechanisms can be used independently (e.g., to pass a security token) or in a tightly coupled manner (e.g., signing and encrypting a message and providing a security token path associated with the keys used for signing and encryption)..."

  • [November 17, 2002] Web Services Security Core Specification. Working Draft 04. 17-November-2002. Edited by Phillip Hallam-Baker (VeriSign), Chris Kaler (Microsoft), Ronald Monzillo (Sun), and Anthony Nadalin (IBM). 49 pages. "This specification describes enhancements to the SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. This specification also provides a general-purpose mechanism for associating security tokens with messages. No specific type of security token is required; it is designed to be extensible (e.g., support multiple security token formats). For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification. Additionally, this specification describes how to encode binary security tokens, a framework for XML-based tokens, and describes how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the tokens that are included with a message." [cache]

  • [November 25, 2002] "Web Services Security XCBF Token Profile." Edited by Phillip H. Griffin (Griffin Consulting) and Monica J. Martin (Drake Certivo Inc). Submitted to the OASIS Web Services Security TC (WSS). OASIS TC Working Draft. Version 1.0. Monday, 25 November 2002. 15 pages. From the Introduction: "This document describes the use of XML Common Biometric Format (XCBF) cryptographic messages within the WS-Security specification. XCBF messages are validated against an ASN.1 schema. This schema definition language is used to define X.509 certificates and CRLs, and the cryptographic messages used to secure electronic mail in RFC3369 and X9.96 XML Cryptographic Message Syntax. In an instance of communication, XCBF messages may be represented in a compact binary format or as well-formed XML markup. A common XCBF security token is defined to convey and manage biometric information used for authentication and identification. Each binary representation of an XCBF message has an XML markup representation. Both representations share the same schema. This characteristic allows XML markup to be used in resource rich environments, but transferred or stored in a compressed binary format in resource poor environments, e.g., smart cards, wireless and remote devices, and high volume transaction systems. XCBF messages may include digitally signed or encrypted information. The binary format used to represent XCBF messages relies on the canonical Distinguished Encoding Rules (DER) used to encode X.509 certificates. The XML markup format used in this Standard is the canonical variant of the XML Encoding Rules (XER)."

  • [September 20, 2002] "Web Services Security Core Specification." Edited by Phillip Hallam-Baker (VeriSign), Chris Kaler (Microsoft), Ronald Monzillo (Sun), and Anthony Nadalin (IBM). Working Draft 01. 20-September-2002. 46 pages. Document identifier: WSS-Core-01. Posted 2002-09-21 by Anthony Nadalin to the WSS TC as "WSS-Core Draft." Comments from external reviewers may be sent to the 'wss-comment' mailing list. From the document abstract: "This specification describes enhancements to the SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. This specification also provides a general-purpose mechanism for associating security tokens with messages. No specific type of security token is required; it is designed to be extensible (e.g., support multiple security token formats). For example, a client might provide proof of identity and proof that they have a particular business certification. Additionally, this specification describes how to encode binary security tokens, a framework for XML-based tokens, and describes how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the tokens that are included with a message." From the section 1 Introduction: "...the focus of this specification is to describe a single-message security language that provides for message security that may assume an established session, security context and/or policy agreement... The Web services security language must support a wide variety of security models. The following list identifies the key driving requirements for this specification: Multiple security token formats; Multiple trust domains; Multiple signature formats; Multiple encryption technologies; End-to-end message-level security and not just transport-level security." Note in the posting: "Here is the initial draft of WSS-Core for review. Below is a high level overview of items that were done to achieve the initial draft: (1) merged WS-Security and WS-Security Addendum; (2) merged the framework from WS-Security XML Token into WSS-Core; (3) removed specifics on Kerberos and X509 tokens from the Binary Security Token section in WS-Security."

  • Web Services Security SAML Token Binding. Working Draft 04. WSS-SAML-04. 9-December-2002. 23 pages. "describes how to use Security Assertion Markup Language (SAML) assertions with the WS-Security specification." [source]

  • Announcement 2002-07-23: "OASIS Members Form Web Services Security Technical Committee. WS-Security Specification To Be Advanced by BEA Systems, Blockade Systems, Commerce One, divine, Documentum, Fujitsu, Intel, IBM, IONA, Microsoft, Novell, Oblix, OpenNetwork, Perficient, SAP, SeeBeyond, Sonic Software, Sun Microsystems, TIBCO, VeriSign, webMethods, XML Global, and Other OASIS Members."

  • Web Services Security TC Proposal

  • "IBM, Microsoft and VeriSign Submit WS-Security Specification to OASIS for Standardization. Advanced Web Services Security Specification Broadly Supported by Industry." June 27, 2002.


WS-Security 2001-2002 and Related Specifications: Principal References

  • "XML and Security": General references.
  • Relevant WS-Security (Original-Author) Websites:

  • "Web Services Security (WS-Security)." Specification Version 1.0. Edited by Chris Kaler (Microsoft). April 5, 2002. 29 pages. The previous published version was solely from Microsoft. This version of WS-Security was published as a public specification on 11-April-2002; "this is the first joint IBM/Microsoft publication of the specification." Also from Microsoft and IBM. Authors: Bob Atkinson (Microsoft), Giovanni Della-Libera (Microsoft), Satoshi Hada (IBM), Maryann Hondo (IBM), Phillip Hallam-Baker (VeriSign), Chris Kaler (Editor) (Microsoft), Johannes Klein (Microsoft), Brian LaMacchia (Microsoft), Paul Leach (Microsoft), John Manferdelli (Microsoft), Hiroshi Maruyama (IBM), Anthony Nadalin (IBM), Nataraj Nagaratnam (IBM), Hemma Prafullchandra (VeriSign), John Shewchuk (Microsoft), Dan Simon (Microsoft). [cache]

  • WS-Security XML Schema. Namespace: xmlns="http://schemas.xmlsoap.org/ws/2002/04/secext" [cache, 2002-04-11]

  • WS-Security Profile for XML-based Tokens. See the news item of 2002-08-30.

  • Web Services Security Addendum Version 1.0. August 18, 2002. See summary.

  • "WS-Security AppNotes." A Joint WS-Security Application Note from IBM Corporation and Microsoft Corporation. August 15, 2002. Version 1.0.

  • [April 2002] From the WS-Security Brief: "WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. WS-Security also provides a general-purpose mechanism for associating security tokens with messages. However, no specific type of security token is required by WS-Security. It is designed to be extensible (that is, support multiple security token formats). For example, a client might provide proof of identity and proof that they have a particular business certification. Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message."

  • WS Specifications 2002-04:

    Initial Specifications

    • WS-Security: describes how to attach signature and encryption headers to SOAP messages. In addition, it describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages.
    • WS-Policy: will describe the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g., required security tokens, supported encryption algorithms, privacy rules).
    • WS-Trust: will describe a framework for trust models that enables Web services to securely interoperate.
    • WS-Privacy: will describe a model for how Web services and requesters state privacy preferences and organizational privacy practice statements.

    Follow-On Specifications

    • WS-SecureConversation: will describe how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys.
    • WS-Federation: will describe how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities.
    • WS-Authorization: will describe how to manage authorization data and authorization policies.

  • From the Roadmap: The document "defines a comprehensive Web service security model that supports, integrates and unifies several popular security models, mechanisms, and technologies (including both symmetric and public key technologies) in a way that enables a variety of systems to securely interoperate in a platform- and language-neutral manner... In this document we present a broad set of specifications that cover security technologies including authentication, authorization, privacy, trust, integrity, confidentiality, secure communications channels, federation, delegation and auditing across a wide spectrum of application and business topologies. These specifications provide a framework that is extensible, flexible, and maximizes existing investments in security infrastructure. These specifications subsume and expand upon the ideas expressed in similar specifications previously proposed by IBM and Microsoft (namely the SOAP-Security, WS-Security and WS-License specifications)... By leveraging the natural extensibility that is at the core of the Web services model, the specifications build upon foundational technologies such as SOAP, WSDL, XML Digital Signatures, XML Encryption and SSL/TLS. This allows Web service providers and requesters to develop solutions that meet the individual security requirements of their applications... document outlines a comprehensive, modular solution that, when implemented, will allow customers to build interoperable and secure Web services that leverage and expand upon existing investments in security infrastructure while allowing them to take full advantage of the integration and interoperability benefits Web service technologies have to offer... We anticipate concerns about what can be done to ensure interoperability and consistent implementation of the various proposed specifications. To address this, IBM and Microsoft will work closely with standards organizations, the developer community, and with industry organizations such as WS-I.org to develop interoperability profiles and tests that will provide guidance to tool vendors..."

  • [August 21, 2002] "Web Services Security Addendum." Edited by Chris Kaler (Microsoft). 18-August-2002. From International Business Machines Corporation, Microsoft Corporation, and VeriSign, Inc. Authors: Giovanni Della-Libera (Microsoft), Phillip Hallam-Baker (VeriSign), Maryann Hondo (IBM), Hiroshi Maruyama (IBM), Anthony Nadalin (IBM), Nataraj Nagaratnam (IBM), Hemma Prafullchandra (VeriSign), John Shewchuk (Microsoft), Kent Tamura (IBM), and Hervey Wilson (Microsoft). The Addendum document "describes clarifications, enhancements, best practices, and errata of the WS-Security specification... Since the publication of the WS-Security specification, additional reviews and implementation experiences suggest some additions, clarifications, and corrections to the original specification." Topics include: Errata, ID References, Placement of X.509 Certificates, Message Timestamps, Passing Passwords, Key Identifiers, Key Names, Token Reference Lookup Processing Order, Encrypted Keys, Decrypted Transformation, Certificate Collections, Security Considerations. [A 2002-08-23 note from Anthony Nadalin (IBM), Chris Kaler (Microsoft), and Hemma Prafullchandra (Verisign) reads: "WSS TC Co-Chairs: We are submitting the specification entitled WS-Security Addendum 1.0, August 18, 2002 for consideration within the WSS-TC as a supplement to the existing WS-Security input specification. The attached specification is a result of building our respective WS-Security implementations. The WS-Security Addendum 1.0, August 18, 2002 can be found at the following sites: (1) IBM, (2) Microsoft; (3) Verisign..."]

  • [August 30, 2002] WS-Security Profile for XML-based Tokens "Web Services Security TC Receives WS-Security Profile for XML-based Tokens."     A communiqué from IBM, Microsoft, and Verisign to the OASIS WSS TC describes the submission of a WS-Security Profile for XML-based Tokens specification designed to supplement the existing WS-Security input specification. The authors request consideration of the specification by the WSS-TC, as the document "further clarifies how XML Tokens are used with WS-Security." The document "describes a general framework to enable XML-based security tokens to be used with WS-Security. Two profiles that use this general framework are provided: one for the Security Assertion Markup Language (SAML) and another for the Extensible rights Markup Language (XrML). Since these formats are described in standalone specifications, not unlike X.509 and Kerberos, the document describes their usage with respect to the WS-Security specification. The specification does not endorse any particular XML security token standard; the description of SAML and XrML are provided to show the mechanisms by which the bindings should be performed. Additional XML token formats may be added to the specification in future revisions as needed." A Web Services Security Addendum was submitted to the WSS-TC previously. [Full context]

  • "WS-Security AppNotes." A Joint WS-Security Application Note from IBM Corporation and Microsoft Corporation. August 15, 2002. Version 1.0. ['This is a preliminary document and may be changed substantially over time.'] "This paper is provided as guidance to implementers of the WS-Security specification. This application note applies to both WS-Security and the associated addendum. Consequently, the discussions here apply to the schemas identified in both specifications... The Web Services Security specification (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 in various ways to accommodate building a wide variety of security models using a variety of cryptographic technologies. WS-Security also provides a general-purpose mechanism for associating security tokens with messages. However, no specific type of security token is required by WS-Security. It is designed to be extensible (e.g., support multiple security token formats) to accommodate a variety of authentication and authorization mechanisms. For example, a requestor might provide proof of identity and a signed claim that they have a particular business certification. A Web service, receiving such a message could then determine what kind of trust they place in the claim. Additionally, WS-Security describes how to encode binary security tokens and attach them to SOAP messages. Specifically, the WS-Security specification describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque encrypted keys as a sample of different binary token types. Kerberos tickets and X509 certificates are used today 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 credentials that are included with a message. WS-Security is a building block that can be used in conjunction with other Web service 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. Similarly, message confidentiality leverages XML Encryption and security tokens to keep portions of a SOAP message confidential..."

  • [Microsoft] Royalty Free Web Services Security Specification License Agreement. 2002-12-16 or later. "... If Company wants a license from Microsoft to implement the Web Service Security Specification ('WS-Security') (as defined below), Company must sign and return this Agreement to Microsoft... 'WS-Security' means collectively the following specifications that were submitted by Microsoft, IBM and Verisign to OASIS in June and August, 2002..." == (1) "Web Services Security (WS-Security)" Version 1.0, dated April 5, 2002; (2) "Web Services Security Addendum" Version 1.0, dated August 18, 2002; and (3) "WS-Security Profile for XML-based Tokens" Versions 1.0, dated August 28, 2002. [cache/snapshot 2002-12-16]

  • "Security in a Web Services World: A Proposed Architecture and Roadmap." Joint White Paper from IBM Corporation and Microsoft Corporation. Version 1.0. April 7, 2002. Also available from IBM and VeriSign.

  • Announcement 2002-04-11: "IBM, Microsoft and VeriSign Announce New Security Specification to Advance Web Services. WS-Security Specification is the Cornerstone to Building Secure Web Services. Companies Will Jointly Submit Specification for Standardization." [source, MS]

  • "Microsoft, IBM, and VeriSign Promote WS-Security Specifications for Web Services." News item 2002-04-11.

  • "Microsoft Releases New XML Web Services Specifications for a Global XML Web Services Architecture." Announcement 2001-10-23.


Web Services Security Specification: Articles, Papers, News

  • [September 13, 2006] Guide to Secure Web Services. Draft Recommendation of the National Institute of Standards and Technology (NIST). By Anoop Singhal (NIST) and Theodore Winograd (Booz Allen Hamilton) Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology (NIST), U.S. Department of Commerce. Developed under the U.S. Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347. NIST Special Publication 800-95 (Draft). September 2006. 140 pages. Appendix C provides an overview of ebXML, a Web services protocol suite developed by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT). Document sections: 1. Introduction; 2. Background to Web Services and Their Relationship to Security; 3. Web Service Security Functions and Related Technologies; 4. Human User's Entry Point into the SOA: Web Portals; 5. Secure Web Service-Enabling of Legacy Applications; 6. Secure Implementation Tools and Technologies. "The security challenges presented by the Web services approach are formidable and unavoidable. Many of the features that make Web services attractive, including greater accessibility of data, dynamic application-to-application connections, and relative autonomy (lack of human intervention) are at odds with traditional security models and controls... While many of the Web services challenges have been met with existing standards, there are a number of challenges that standards organizations are currently addressing -- particularly in the area of Web services discovery and reliability. The Web Services Interoperability (WS-I) organization acknowledges that there are many challenges that have yet to be addressed. Some examples of these challenges are: Repudiation of transactions; Secure issuance of credentials; Exploitation of covert channels; Compromised services; Spread of viruses and Trojan horses via SOAP messages; Denial of service attacks; Incorrect service implementations; Poor service designs. This [Guide to Secure Web Services] publication seeks to assist organizations in understanding the challenges in integrating information security practices into Service Oriented Architecture (SOA) design and development based on Web services. This publication also provides practical, real-world guidance on current and emerging standards applicable to Web services, as well as background information on the most common security threats to SOAs based on Web services. This document presents information that is largely independent of particular hardware platforms, operating systems, and applications. Supplementary security devices (i.e., perimeter security appliances) are considered outside the scope of this publication. Interfaces between Web services components and supplementary controls are noted as such throughout this document on a case-by-case basis..." [PDF source]

  • [February 15, 2006] "Members Approve WS-Security v1.1 as OASIS Standard." OASIS Announcement February 15, 2006. "OASIS, the international e-business standards consortium, today announced that its members have approved WS-Security version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification. Developed through an open process by the OASIS Web Services Security (WSS) Technical Committee, WS-Security delivers a technical foundation for implementing security functions such as integrity and confidentiality in messages implementing higher-level Web services applications... The specifications describe a mechanism for securing web services message exchanges using a variety of existing security technologies and methodolgies. The document set is the 1.1 revision of the original WS-Security 2004 OASIS standard. Several token profiles have been added. The 1.0 Errata has been factored in. Feedback from the public has been included and steps have been taken to enhance the readability and usability of the specification. An additional 1.1 Schema has been produced and a few XML Elements have been added to the language."

  • [April 20, 2005] "Companies Demonstrate Interoperability of WS-Security OASIS Standard. BEA Systems, DataPower, IBM, Microsoft, Oracle, Reactivity, Panacea Software, RSA Security, Sarvega, Sun Microsystems, Systinet, TIBCO, and VeriSign Collaborate on WS-Security OASIS InterOp at Gartner Summit." - "Fourteen organizations joined together for the first time to demonstrate interoperability of the WS-Security OASIS Standard at the Gartner Application Integration and Web Services Summit in Los Angeles today. WS-Security, developed by the OASIS Web Services Security (WSS) TC, delivers a technical foundation for implementing security functions such as integrity and confidentiality in messages implementing higher-level Web services applications. Gartner analyst, Ray Wagner, describes WS-Security as 'the standard for the majority of Web services...committing to it now will allow enterprises to easily modify the security profile of deployed Web services in the future.' WS-Security allows a wide range of key security methods such as authentication and access control to be reliably, readily associated with SOAP messages. The OASIS InterOp at the Gartner Summit demonstrated the exchange of messages protected by WS-Security using the X.509 Token Profile. 'It is gratifying to see so many vendors supporting the WS-Security OASIS Standard with their interoperable implementations,' observed Hal Lockhart of BEA Systems, lead of the OASIS InterOp team. 'We came together with a common goal: to make it clear to all implementers-not just the larger enterprises that have already embraced the standard-that the time is right to adopt WS-Security.' Patrick Gannon, president and CEO of OASIS, agreed. 'WS-Security provides a key component for the broader security frameworks that users need. Many of the participants in today's InterOp are also deeply involved in advancing other OASIS Standards for security, such as the Security Assertion Markup Language (SAML) and the eXtensible Access Control Markup Language (XACML). The synergy between these efforts goes a long way towards meeting the marketplace's need for a cohesive fit between standards,' said Gannon, who also participated in Gartner's 'Power Panel: A Conversation on Standards' at the event..."

  • [September 2004] "WS-Security Interoperability Using WSE 2.0 and Sun JWSDP 1.4." By Simon Guest (Program Manager, Architecture Strategy Team, Microsoft Corporation). "This article shows WS-Security Interoperability between Microsoft WSE 2.0 and Sun JWSDP 1.4. It covers techniques to send secure messages between the .NET Framework and J2SE using Microsoft WSE 2.0 and Sun JWSDP 1.4, both of which support the OASIS WSS 1.0 standard. The walkthroughs in this article will take you through all you need to know to configure the two environments for securely signing and encrypting SOAP requests and responses using X509 certificates. WS-Security is a specification to enable security for Web services; specifically through message integrity, message confidentiality, and single message authentication. The WS-Security specification was co-authored by Microsoft, IBM, and Verisign. On April 6 2004, OASIS released OASIS Web services Security 1.0 based on this specification. This standard includes recommendations for SOAP message security with profiles for using username and X509 tokens to enable security. Many vendors are providing implementations of WS-Security. Microsoft offer WS-Security support in WSE (Web Services Enhancements) 2.0, a download from MSDN that compliments the Web services support in the .NET Framework. Sun offer support for WS-Security in JWSDP (Java Web services Developer Pack) 1.4, which can be downloaded from their site. As a standard, WS-Security is still new. The capability to use WS-Security to perform vendor neutral, transport independent security for Web services is however powerful. The commitment of all vendors, with the OASIS specification proves that security for Web services is achievable today..."

  • "Web Services Security (WSS) Ratified as OASIS Standard. AmberPoint, BEA Systems, Betrusted, Commerce One, Computer Associates, Documentum, Entrust, Fujitsu, HP, Hitachi, IBM, Microsoft, Netegrity, Nokia, Novell, Oblix, OpenNetwork, Oracle, Reactivity, RSA Security, SAP, Sarvega, SeeBeyond Technology, Sun Microsystems, Verisign, and Others Develop Foundational Standard for Security." - "The OASIS international standards consortium today announced that its members have approved the Web Services Security (WSS) version 1.0 (WS-Security 2004) as an OASIS Standard, a status that signifies the highest level of ratification. WSS offers a trusted means for applying security to Web services by providing the necessary technical foundation for higher-level services. Gartner analyst, Ray Wagner, advised, 'Enterprises should adopt WSS formatting for all across-the-firewall Web service deployments, even in cases where no security needs have been identified. Gartner believes that WSS will be the standard for the majority of Web services, and committing to it now will allow enterprises to easily modify the security profile of deployed Web services in the future.' WSS builds upon existing security technologies such as XML Digital Signature, XML Encryption and X.509 Certificates to deliver an industry standard way of securing Web services message exchanges. Providing a framework within which authentication and authorization take place, WSS lets user apply existing security technology and infrastructure in a Web services environment. 'By enabling applications to share information regarding network access regardless of the underlying platform, Web Services Security paves the way for broader adoption of Web services,' said Chris Kaler of Microsoft, co-chair of the OASIS WSS Technical Committee. 'The OASIS WSS TC is pleased by the support and commitment of the Web services community leading to the ratification of Web Services Security as an industry standard.' WSS handles complex confidentiality and integrity for SOAP (Simple Object Access Protocol) messages, providing a general-purpose mechanism for associating security tokens with message content. Designed to be extensible, WSS supports multiple security token formats. 'A client might provide one format for proof of identity and another format to verify their business certification,' explained Kelvin Lawrence of IBM, co-chair of the OASIS WSS Technical Committee. 'Using WSS, a system can authenticate the identity of a person connecting to several networks at once or pass data between two applications securely.' 'The Web Services Security OASIS Standard represents a truly impressive collaboration from across the industry,' noted Patrick Gannon, president and CEO of OASIS. 'It is testament to the value of the open standards process where users and vendors, large and small, come together to advance a common good. WSS delivers a much-needed foundational technology that will enable Web services to be deployed with confidence'..." See details in the news story "OASIS Web Services Security Specification Approved as an OASIS Standard."

  • [April 13, 2004] "Web Services Security Advances With Approval of Key Standard." By Ray Wagner (Gartner Research). Gartner Note, Number FT-22-6913. April 13, 2004. ['The formal approval of a widely accepted standard is a significant step forward for Web services security. Enterprises should adopt Web Services Security (WS-Security) now.'] "The OASIS decision is a critical, if unsurprising, event in the development of secure Web services implementations. The need for WS-Security is widely recognized, and no serious competition for the standard exists. WS-Security is one of the essential cornerstones — along with Secure Sockets Layer/Transport Layer Security (SSL/TLS), Security Assertion Markup Language (SAML) and perhaps XKMS (XML Key Management Specification) — of mutual authentication and data confidentiality for Web services. Further industry acceptance and development of SAML- and SSL-based Web services in the WS-Security format is likely, because the basic infrastructure is already in place. Most vendors of Web services, Web services security and identity management products now support, or plan to support, WS-Security and SAML. This level of industrywide agreement does not, however, exist for the many other, more ambitious standards (WS-*) that will be required for true Web services interoperability... Gartner believes that WS-Security will be the standard for the majority of Web services, and committing to it now will allow enterprises to easily modify the security profile of deployed Web services in the future. Security administrators should not, however, assume that WS-Security and SAML alone will ensure adequate Web services security. Web services deployments will still be at risk if old code bases are connected to Web services interface or new ones are written with security flaws or bad WSDL (Web Services Description Language) descriptions. Through 2007, the greatest threat to Web services security will likely be the use of commercial off-the-shelf Web services application interfaces without adequate security..." Article also in PDF format.

  • [April 09, 2004] "A Developer's Roadmap to Using WS-Security." By Vance McCarthy. In Integration Developer News (April 09, 2004). "WS-Security, one of the core building blocks for interoperable web services security, was adopted this week by OASIS. The action means that devs and IT managers could start seeing XML-based security solutions start cropping up in all sorts of enterprise products, from IDEs, to firewalls and even front-end UI designs and back-end servers. It also means that Microsoft, Sun and IBM continue to find more reasons to cooperate, rather than bicker. To help devs and senior technicians understand what the adoption of WS-Security might mean to their business -- and career -- IDN takes as a look at how developers can best begin to leverage WS-Security technologies, as we conduct an in-depth conversation with Steven Van Roekel, Microsoft's Director of Web Services Technical Marketing, and a leading member of the WS-I's (Web Services Interoperability Organization's) push to implement tools and testing assistance for developer and ISV use of WS-Security. In our conversation, Van Roekel also shared details on how developers can implement WS-Security across multi-vendor (Java and .NET) platforms, the vision for 'next steps' for securing web services, and even how the WS-I's BSWG plans to produce a basic Security Profile, to help guide developers in building an interoperable security framework from various products and standards..."

  • [April 08, 2004] "Security Specification for Web Services Finalized." By Gavin Clarke. In CBR Online (April 08, 2004). "A key security element of IBM Corp and Microsoft Corp's web services roadmap has received official standards blessing, paving the way for widespread industry adoption. Key documents in the WS-Security 1.0 core specification have been ratified along with two important token profiles, for usernames and X.509, by the Organization for the Advancement of Structured Information Standards (OASIS). Companies developing WS-Security through an OASIS technical committee included BEA Systems, Hewlett Packard, IBM, Microsoft, Oracle, SAP and Verisign. Vendors are now expected to implement WS-Security into their products, providing a common level of interoperability. WS-Security is fundamental to the WS-* specification roadmap that was co-authored by IBM and Microsoft. WS-Security serves as foundation specification for other elements in the companies' roadmap including WS-Secure Conversation, WS-Trust and WS-Security Policy that manage the transaction secured by WS-Security. WS-Security is also important in helping end-users come a step closer to realizing the full potential of web services, by providing a secure mechanism to take web services transactions beyond the firewall for secure day-to-day transactions with partners. Security has been lacking in web services to-date, hence projects have remained internal. WS-Security provides security infrastructure for applications such ordering, invoicing and payment. VeriSign principle scientist Phillip Hallam-Baker, who worked helped work on WS-Security, said. 'People have the ability to start taking their existing applications beyond the firewall and moving to the next stage of web services, using them in extranets for business with close partners.' WS-Security provides confidentially and integrity for web services transactions through the federated use of encryption and digital signatures. WS-Security differs from traditional approaches to encrypting and signing messages, because it accepts a message may be routed between multiple trading partners instead of communication being limited to point-to-point transaction between just two parties..."

  • [December 26, 2003] "Web Services Security Kerberos Binding." By Giovanni Della-Libera (Microsoft), Brendan Dixon (Microsoft), Praerit Garg (Microsoft), Maryann Hondo (IBM), Chris Kaler (Microsoft), Hiroshi Maruyama (IBM), Anthony Nadalin (IBM), and Nataraj Nagaratnam (IBM). December 18, 2003. Copyright (c) 2003 IBM Corporation, Microsoft Corporation. 25 pages. ['This Web Services Security Kerberos Binding Specification is an initial public draft release and is provided for review and evaluation only.'] "This document describes how to use Web Services security specifications with Kerberos... Kerberos is an established authentication and security infrastructure in use in many environments today. Consequently, as applications integrate with and are developed for Web services, there is a need to leverage existing security infrastructure. This specification describes how to integrate Kerberos security environments with the Web service security architecture. Integration with Web services security requires the following aspects: (1) Requesting and issuing security tokens; (2) Attaching security token to messages; (3) Establishing a secure context; (4) Signing and encrypting the message using the security context. This specification describes two models of Web service usage and interoperability: GSS-API and Raw Kerberos... This specification builds on the WS-Security, WS-Trust, and WS-SecureConversation specifications to integrate Kerberos functionality... The security tokens used by both [GSS-API and Raw Kerberos] models are binary and not based on XML. Consequently, the <wsse:BinarySecurityToken> element from WS-Security is used to pass security tokens inside SOAP messages. The wsse:ValueType and wsse:EncodingType attributes describe the security token's type and encoding. Applications integrating Kerberos with WS-Security must include their tokens as instances of <wsse:BinarySecurityToken>. They should encode these in base64... GSS-API presents a common approach and feature set over a number of different and popular security protocols. It is frequently used when two Web services, both existing within Kerberos environments leveraging GSS-API, want to securely interoperate across the Internet... Alternatively instead of using GSS-API, interoperability can be achieved at the Kerberos level. That is, using raw Kerberos security tokens and cryptographic functions. The model is straightforward: tickets are obtained and the keys are extracted for use in signing and encrypting messages. Kerberos is an IETF standard third-party mediated protocol as described in RFC 1510... Conceptually, a Kerberos KDC implements what WS-Trust calls a Security Token Service: It generates security tokens (e.g., Kerberos TGT) in exchange for other tokens..." [cache]

  • [July 12, 2003] "Burton Group Speakers Debate Web Services. Security Remains a Concern." By Paul Krill. In InfoWorld (July 11, 2003). "Speakers at the Burton Group Catalyst Conference 2003 debated the pros and cons of Web services-based application integration, illustrating the diversity of opinions still surrounding the technology... 'The reason that Web services will succeed is because we have total industry buy-in,' [Ann] Manes said. She also touted the Web Services Interoperability Organization's Basic Profile, saying it will provide for basic interoperability across any language or platform. Issues remain, however, such as scalability and performance, said Manes. She also stressed that users of Web services need to fit their systems with Web services management tools. But Web services will become part of the IT fabric, Manes said. 'Five years from now, you won't even think about Web services because it will become just part of your fabric,' in the same manner that enterprises use sockets, Manes said. The issue of security, long a concern with Web services, is being addressed via the WS-Security specification, she said. 'WS-Security is very close to being finished and it's a very strong specification,' Manes said. WS-Security is under the jurisdiction of the Organization for the Advancement of Structured Information Standards (OASIS). A Web services user speaking at the conference, however, expressed concerns with the current level of security in Web services. 'It's a miserable story and I think it's a reason why we don't do a whole lot outside our firewalls,' said David Cohen, a vice president of the technology architecture group at Merrill Lynch. 'To me, Web services is just a communications system,' Cohen said. 'It's just at a higher level of the network stack.' Merrill Lynch, however, is a 'huge champion of XML,' said Cohen. BEA Systems' Scott Dietzen, also CTO, stressed that Web technology providers need to get on the WS-Security bandwagon..."

  • [June 25, 2003] "Systinet Announces WASP Server for Java, 4.6 With Full Support For WS-Security. WASP Provides Industry's Best Web Services Security, Performance and Interoperability." - "Systinet, "leading independent provider of Web services infrastructure software, today announced the general release of WASP Server for Java, 4.6, the award-winning Web services infrastructure platform that fully supports the latest standards, including OASIS Web Services Security (WS-S) and offers the industry's best performance and interoperability. The 4.6 release has new and unique functionality that makes it much easier to create and run Web services applications, including enhanced support for asynchronous Web services, full support for SOAP 1.2, and the industry's most comprehensive support for Java Web services APIs, including JAX-RPC, JAXM and SAAJ. WASP Server for Java is a complete solution for creating, running and managing sophisticated Web services applications and is available for free download from Systinet's Website... In addition to the many security capabilities already in WASP Server for Java, version 4.6 now includes WS-S message-level security. WASP supports both the OASIS WS-S standard currently in final draft, and the earlier Microsoft-IBM WS-Security specifications. This support ensures that WASP is compatible with all WS-Security implementations. WASP Server for Java, 4.6 also offers unique security and alerting features. For example, users will be alerted if a message cannot be decrypted or if an authentication event failed... WASP Server for Java offers unique asynchronous web services support: Simple Web services are invoked synchronously -- when a client sends a message to a server, it halts until a response is received. This method becomes unworkable, especially for complex computations or for multi-part tasks. Since it is much more efficient to asynchronously invoke services, WASP 4.6 supports an easy-to-use, event-based way of calling Web services asynchronously. The mechanism eliminates the need for developers to write client code for polling the service. Also, WASP Server for Java features transport-level asynchronous messaging, which relies on using different transport channels for the request and response messages, such as an HTTP request, an e-mail response, or even an email request and an e-mail response... WASP makes is easy to build Web services using popular IDEs and has expanded support to include IntelliJ IDEA, a popular Java development environment. WASP already supports Borland JBuilder, Eclipse, IBM WebSphere Studio Application Developer, Sun ONE Studio and NetBeans. Systinet's WASP suite of products is a complete solution for building, deploying, securing and managing Web services. Systinet WASP Server for Java and WASP Server for C++ are industrial-strength Web services runtime environments that fully support industry standards, including SOAP 1.1, SOAP 1.2 and WSDL 1.1. WASP UDDI is a V2 complaint registry with advanced V3 functionality. WASP UDDI is a full-featured UDDI registry that allows businesses to standardize the way businesses organize, catalog, discover and reuse Web services across the company..."

  • [April 11, 2003] "Web Services Security: Non-Repudiation." Edited by Eric L. Gravengaard (Reactivity, Inc). Contributors: Grant Goodale, Michael Hanson, Brian Roddy, and Dan Walkowski (Reactivity). Submitted to the OASIS Web Services Security TC. Document identifier: 'web-services-non-repudiation-05'. 11-April-2003. 19 pages. Posted to the WSS Mailing List 11-April-2003 by Eric Gravengaard (Reactivity, Inc). The Web Services Security: SOAP Message Security specification defines the usage of XML Digital Signatures within a SOAP header element to prove the integrity of a SOAP message. While this is useful in the context of non-repudiation to the receiver, it does nothing to guarantee to the sender that the message was delivered properly and without modification. Similarly, when the SOAP requestor receives the SOAP response message there is no way of proving that the SOAP response was generated after receiving and processing the SOAP request. This specification extends the use of XML Digital Signature in the context of WSS: SOAP Message Security to allow senders of SOAP messages to request message disposition notifications that may optionally be signed to prove that the receiver received the SOAP message without modification. The specification also defines a method for embedding SOAP message dispositions in a SOAP message header. This specification constitutes a protocol for voluntary non-repudiation of receipt that when used systematically provides cryptographic proof of both parties participation in a transaction. This specification does not define any mechanism to prove receipt of a message by a non-conformant implementation. Editor's comment: "Reactivity would like to submit this document to the TC for consideration and inclusion in the Web Services Security: SOAP Message Security specification. The Web Services Security: Non-Repudiation proposal (WSNR) defines a standard mechanism for voluntary non-repudiation of receipt. The goal of this proposal is to enable the exchange of SOAP messages in an environment where the SOAP Message sender has cryptographic proof that the SOAP Message responder received the request unaltered. This proposal makes use of the XML Signature specification to provide cryptographic proof of integrity and the WSS:SOAP Message Security Core to allow the transport of both receipt requests and receipts within a <Security> header. This submission is made under the OASIS rules regarding intellectual property rights. Reactivity intends the contents of this document to be available for license royalty free..." [source]

  • [February 21, 2003] "WS-Security: New Technologies Help You Make Your Web Services More Secure." By David Chappell. In Microsoft MSDN Magazine (April 2003). ['Without good security, Web Services will never reach their potential. WS-Security and its associated technologies, the focus of this article, represent the future of security for Web Services. Provided here is an overview of these emerging security standards that explains what they do, how they work, and how they get along together. Topics discussed include integrity and confidentiality and how these are provided by public key cryptography, WS-Security, and more. Some of the key components of WS-Security, such as the wsu namespace, are also covered.'] "Web Services without effective security aren't very useful. Yet the original creators of SOAP chose to put off defining how this problem should be solved. This was a defensible decision, since getting Web Services off the ground meant keeping them simple -- and providing security is seldom simple. The problem, however, can't be put off forever so Microsoft and IBM, among others, are working together to address this issue. Their efforts have resulted in a group of specs for providing Web Services security, the most important of which is WS-Security. With this article I'll provide a big-picture view of how these technologies work. From one perspective, the task facing the creators of Web Services security looks simple. After all, effective mechanisms already exist for distributed security, including Kerberos, public key technologies, and others, so the task these creators faced wasn't inventing new security mechanisms. Instead, their goal was to define ways to use what already existed in a Web Services world, a world built on XML and SOAP... The fundamental technology for adding security to SOAP is defined by WS-Security. Its ambitious goal is to provide end-to-end message-level security for SOAP messages, and yet the WS-Security spec isn't especially hefty, weighing in at just over 20 pages. This is because WS-Security defines very little new technology but instead defines a way to use existing security technology with SOAP... Effective security for Web Services is essential. Given that most of what's needed is already in place (and the problem is simply a matter of mapping this existing security technology to XML and SOAP), you might think that WS-Security and its associated specs would be very simple (and this article would be very short). Yet accommodating the diverse security mechanisms in use today, along with allowing for those that will appear tomorrow, requires a nontrivial set of technology. Once this technology is in place, the world of secure and interoperable Web Services that we'd all like to see can become a reality. I don't know about you, but I can't wait for this day to arrive..."

  • [January 14, 2003] Royalty-Free License Terms in Microsoft's Web Services Security IPR Disclosure. In part: "... If an OASIS Standard incorporating this Contribution is adopted by OASIS pursuant to the WS-Security Technical Committee Charter at the time the Contribution was submitted, Microsoft will grant, for the limited purposes of implementing and complying with the required portions of the resulting OASIS Standard, a ROYALTY-FREE, worldwide, non-sublicenseable, non-transferable, license to any such Necessary Claims to implement the Contribution under reasonable and non-discriminatory terms and conditions, provided a reciprocal patent license is granted to Microsoft and other implementers of the OASIS Standard..."

  • [December 16, 2002] "Microsoft Delivers Latest Developer Tools for Building Advanced, More Secure Web Services. Web Services Enhancements 1.0 Available for Visual Studio .NET. Developers, With Support From Companies Such as F5 Networks, WestGlobal and WRQ." - "Highlighting industry demand for the latest Web services capabilities, Microsoft Corp. today announced key companies, including F5 Networks, WestGlobal and WRQ Inc., that are taking advantage of Web Services Enhancements 1.0 (WSE) for Microsoft .NET, which gives Visual Studio .NET developers support for the latest Web services specifications, such as WS-Security, WS-Routing and WS-Attachments. The news coincides with Microsoft's announcement of the release to Web (RTW) of WSE 1.0, following the technical preview delivered in August 2002. Available via download, WSE works with Visual Studio .NET and the .NET Framework so developers can quickly add a few lines of code to their Web services applications to keep pace with the latest industry advancements. In addition to its ability to quickly build new Web services solutions, WSE has been embraced by customers and industry partners as an important tool for connecting to existing systems... Since the introduction of the technical preview in August 2002, WSE has gone through rigorous testing and customer review to reach the milestone of RTW of WSE 1.0. WSE is built on existing XML Web Services standards such as XML and SOAP, while providing the following advanced capabilities: Security. It can help secure XML Web services across platforms and trust domains, including digital signing and encryption of SOAP messages that are compliant with the WS-Security specification, jointly introduced by Microsoft, IBM Corp. and VeriSign Inc. in April 2002 and submitted to OASIS in June 2002. Routing. It can route an XML Web service through intermediaries using the WS-Routing specification, which describes how to place message addresses in the SOAP message header and enables SOAP messages to travel serially to multiple destinations along a message path. The route a SOAP message takes to an XML Web service can be transparently delegated among Web servers. Attachments. Communication between XML Web services can contain attachments that are not serialized into XML. The WSDK provides the ability to add attachments to SOAP messages following the WS-Attachments specification. WS-Attachments was jointly submitted to the IETF by Microsoft and IBM. Extensible framework. WSE is an extensible pipeline for SOAP message processing. Developers can extend the built-in functionality of the system to customize its encryption and signing capabilities to support proprietary security infrastructures. Custom logic also can be incorporated into the pipeline to provide additional functionality such as auditing, logging, or store and forward..." See: (1) the main page Web Services Enhancements for Microsoft .NET; (2) Programming with Web Services Enhancements 1.0 for Microsoft .NET"; (3) "WS-Security Authentication and Digital Signatures with Web Services Enhancements," by Matt Powell; (4) Inside the Web Services Enhancements Pipeline.

  • [December 16, 2002] "Microsoft Highlights Security in Web Services Development Pack." By Paul Krill. In InfoWorld (December 16, 2002). "Microsoft on Monday [2002-12-16] is officially unveiling the general release of Web Services Enhancements 1.0 (WSE) for Microsoft .Net, focusing on security and support of proposed standards. The free product, which had been available in an unsupported technical preview format since August, is a plug-in to Microsoft's Visual Studio .Net. It is built on existing Web services standards such as XML, SOAP (simple Object Access Protocol) and WSDL (Web Services Description Language). New in the general release is an API for log-in, session handling and audit trails, but Microsoft officials are focusing particularly on support for the proposed WS-Security standard now under consideration by OASIS (Organization for the Advancement of Structured Information Standards). WS-Security was first published by Microsoft, IBM and Verisign in April. Through use of WS-Security, developers can build more secure Web services, Microsoft officials stressed. "It secures the actual message and payload," said Rebecca Dias, product manager for Web services marketing at Microsoft, in Redmond, Wash. Security is maintained when messages are passed to multiple points, she said. "What we're doing is allowing you to sign that part of data that's flowing over the Internet," Dias said. Other features included as part of WS-Security support include backing for x.509 digital certificates and Kerberos, to encrypt messages... Microsoft also is featuring support for the Microsoft-proposed WS-Routing specification. This enables messages to be sent through intermediaries and across different transports, to leverage load balancing as well as geographic balancing, to enable a local server to process Web services. Also featured is support for the WS-Attachments proposal now sitting before the IETF (Internet Engineering Task Force). This support together with backing of DIME (Direct Internet Message Encapsulation) enables binary files to be sent via SOAP-based transports..." See also the announcement "Microsoft Delivers Latest Developer Tools for Building Advanced, More Secure Web Services. Web Services Enhancements 1.0 Available for Visual Studio .NET. Developers, With Support From Companies Such as F5 Networks, WestGlobal and WRQ."

  • [December 11, 2002] "WS-Security Authentication and Digital Signatures with Web Services Enhancements." By Matt Powell (Microsoft Corporation). Microsoft MSDN Library. December 2002. ['Part of the documentation for Web Services Enhancements 1.0 for Microsoft .NET. Web Services Enhancements 1.0 for Microsoft .NET (WSE) provides advanced Web services functionality for Microsoft Visual Studio .NET and Microsoft .NET Framework developers to support the latest Web services capabilities. Enterprise ready applications can be developed quickly with the support of security features such as digital signature and encryption, message routing capabilities, and the ability to include message attachments that are not serialized into XML.'] "With the advent of the Web Services Enhancements 1.0 for Microsoft .NET (WSE), Microsoft has provided its first toolset for implementing security within a SOAP message. No longer are Web services tied strictly to using the security capabilities of the underlying transport. Now a SOAP message on its own can be authenticated, its integrity verified, and can even be encrypted all within the SOAP envelope using the mechanisms defined by the WS-Security specification. In this article, we will be looking at how you can use WSE to take advantage of WS-Security for authenticating and signing data for your Web services. Simply sending X.509 certificates with a request is actually not much of a way to authenticate anything. The certificates are considered public knowledge so anyone could include anyone else's certificate with their request. The mechanism for using certificates for authentication is based off the idea we mentioned earlier in regards to signing some entity with the private key that corresponds to the public key in the certificate... WSE supports creating digital signatures in a very straightforward manner... The WSE SOAP extension will validate the syntax of a digital signature, but simply knowing that a valid signature exists in a message is not enough to know that the message came from a particular individual. WS-Security and the XML Digital Signature specification, (Extensible Markup Language) XML-Signature Syntax and Processing, are very flexible in the way that they allow signatures to be included within XML... This article illustrates how Web Services Enhancements for Microsoft .NET offers you a glimpse into the capabilities of the WS-Security specification by looking at how you can use WSE to do UsernameToken authentication and by using X.509 authentication to digitally sign portions of the SOAP message. WSE lets you inspect and verify the kind of WS-Security support that is included with a SOAP message. There are a number of other WS-Security capabilities WSE provides that are not discussed here, such as using various forms of encryption..."

  • [December 10, 2002] "VeriSign Offers Open Source WS-Security Implementation and Integration Toolkit to Help Developers Integrate Security Into Web Services. Effort Continues VeriSign's Commitment to Driving Trusted Web Services With Royalty-Free Implementation." - "Furthering its commitment to trusted Web services, VeriSign, Inc., the leading provider of digital trust services, announced today the royalty free availability of technology that will allow companies to integrate digital signatures and encryption into Web services. Based on the recently announced WS-Security specification and Addendum, which was co-written by IBM, Microsoft and VeriSign, this implementation provides enterprises, software developers and systems integrators with code they can use to achieve higher levels of trust and security when designing Web services applications and services. Offering this code as open source is intended to accelerate widespread adoption of Web services by making them even easier to secure. In addition, VeriSign announced that it has made available a version of its VeriSign Trust Service Integration Kit (TSIK) with security features for Web services, such as XML Signature, XML Encryption, and XML Key Management Services (XKMS). VeriSign TSIK is a Java-based developer toolkit for integrating security capabilities into Web services. 'Companies simply will not implement Web services until the industry adequately addresses the issues of trust and security,' said Dr. Phillip Hallam-Baker, VeriSign's Principal Scientist and Web Services Security Architect. 'We are helping to address those critical issues by taking a leadership role in providing customers and developers with some extremely useful code that they can implement in their Web services applications today to alleviate those concerns'... VeriSign will provide an open source implementation of WS-Security through its open source libraries, providing resources for building interoperable, trusted Web services using the proposed WS-Security standard. The VeriSign libraries can be deployed to provide protocol support for both client and server applications. In a typical situation, a Web service will rely on these libraries to add secure messaging to whatever business logic the Web service supports. The Trust Service Integration Kit includes three basic components: the messaging framework, the trust layer and XML resources. (1) The messaging framework brings together various VeriSign Application Programming Interfaces (APIs) to provide a robust environment for developing secure, trusted, interoperable Web services. The Java libraries enable developers to create Java objects for sending and receiving XML messages in conjunction with a customer Web service API. (2) The trust layer provides APIs for security XML messages using public key infrastructure (PKI), and includes implementations of two key specifications, W3C XML Digital Signature and XML Encryption. These implementations emphasize ease-of-use over feature coverage... The Trust Verifier provides several mechanisms, including real-time XML Key Management Specification (XKMS) lookups, for establishing whether a public key or certificate chain is trusted. (3) The API also includes low-level resources for directly manipulating XML, building data types, navigating through document structures, validating the format of schemas and interfacing with parsers..."

  • [November 22, 2002] "The 19th Annual Awards for Technical Excellence. 'Protocols' Winners: SAML and WS-Security." By the Editors of PC Magazine. In PC Magazine (November 19, 2002). "Securing Web services is no easy task. The same virtues that make Web services so promising for e-business -- they're platform-independent, text-based, and self-describing -- create major security concerns, giving pause to businesses considering a move to the hot new interoperability technology. Two standards are emerging to secure Web services: Security Assertion Markup Language (SAML) and WS-Security, both proposals submitted to the Organization for the Advancement of Structured Information Standards (OASIS). To protect confidentiality, WS-Security relies on XML Encryption, while SAML uses the slower HTTPS. WS-Security protects individual transactions, and the substantial infrastructure required by SAML pays off with single sign-on capability. The Liberty Alliance's authentication solution -- Liberty 1.0 -- builds on SAML, while Microsoft's competing technology, .NET Passport, uses WS-Security. No matter whether these two standards converge or remain separate, the success of Web services in e-business could depend on them..."

  • [October 26, 2002] "Liberty, WS-Security Uniting Over SAML Standards." By Vance McCarthy. From Integration Developer News. October 21, 2002. Case Study. "Last month, the Liberty Alliance Project elected a new president Michael Barrett, vice president for Internet strategy at American Express. Since coming to office, Barrett has left little doubt that he will push those vendors sparring over identity and security standards -- notably Sun, IBM and Microsoft -- to reach an agreement on interoperability. So far, the 'peace talks' between Liberty and Microsoft Passport seem to be going well, thanks in large part to all-party discussions on security taking place under the OASIS (Organization for the Advancement of Structured Information Standards) umbrella, and some XML-based security brokering technology being specified inside OASIS called SAML (Security Assertion Markup Language). 'It's pretty obvious that we'll use SAML as a glue between different identity approaches [such as Liberty and Passport], the SAML technical committee co-chair for OASIS Jeff Hodges told Integration Developer News. 'And while SAML is not an authentication technology in and of itself, SAML can be used as a tool to glue together disparate authentication domains.' For its part, Liberty is built on SAML, but does not define any authentication mechanisms. SAML is a framework and one needs to profile it to put into context to make use of it. Further, the Java Community Process (JCP) has a proposal to natively support SAML (JSR 155) for use in J2EE... Of good news to developers worried about interoperability issues, SAML is also being endorsed by Microsoft execs. 'Members of the OASIS security committee wants to see all our work reconciled, and we want to see SAML token support in WS-Security.' Adam Sohn, a product manager for Microsoft .NET platform strategy group told IDN in an interview this summer. Sohn added that WS-Security's decision to support SAML (and Liberty) will not prompt WS-Security to 'downplay' plan to support a variety of security mechanisms already at work within the enterprise, including PKI, Kerberos and even SSL. WS-Security will look at Liberty and SAML as just another credential type, and we expect to have support in WS-Security this year' Sohn added... 'There are a lot of touching points across Liberty, SAML and WS-Security, and it's hard to look at a crystal ball to see exactly what will happen. But we are starting to see some convergences and rapprochement between all these groups, ' Slava Kavsan, Chief Technologist at RSA Security, and chairman of the Liberty Alliance's Trust and Security Group told IDN. Notably, RSA has been a key figure in pushing compatibility among Sun, Microsoft and IBM approaches. 'There is good news. First, WS-Security will mention SAML is its next draft.' Kavsan looks at the interoperability issues on identity as similar to other compatibility questions that exist on a number of web services fronts between IBM, Microsoft and Sun. 'We're still in a basic architectural world of the Microsoft client needing to talk to a Java or Sun server,' he said. 'Even though Liberty is working on its own browser-based client spec, Liberty needs to and intends to support Microsoft's client base'..."

  • [October 22, 2002] "Understanding WS-Security." By Scott Seely (Microsoft Corporation). From MSDN Library. October 2002. ['This article looks at how to use WS-Security to embed security within the SOAP message itself, exploring the concerns WS-Security addresses: authentication, signatures, and encryption. This article assumes that you are already familiar with XML Canonicalization, XML Signature, and XML Encryption.'] "... the bigger problems involve sending the message along a path more complicated than request/response or over a transport that does not involve HTTP. The identity, integrity, and security of the message and the caller need to be preserved over multiple hops. More than one encryption key may be used along the route. Trust domains will be crossed. HTTP and its security mechanisms only address point-to-point security. More complex solutions need end-to-end security baked in. WS-Security addresses how to maintain a secure context over a multi-point message path. WS-Security addresses security by leveraging existing standards and specifications. This avoids the necessity to define a complete security solution within WS-Security. The industry has solved many of these problems. Kerberos and X.509 address authentication. X.509 also uses existing PKI for key management. XML Encryption and XML Signature describe ways of encrypting and signing the contents of XML messages. XML Canonicalization describes ways of making the XML ready to be signed and encrypted. What WS-Security adds to existing specifications is a framework to embed these mechanisms into a SOAP message. This is done in a transport-neutral fashion. WS-Security defines a SOAP Header element to carry security-related data. If XML Signature is used, this header can contain the information defined by XML Signature that conveys how the message was signed, the key that was used, and the resulting signature value. Likewise, if an element within the message is encrypted, the encryption information such as that conveyed by XML Encryption can be contained within the WS-Security header. WS-Security does not specify the format of the signature or encryption. Instead, it specifies how one would embed the security information laid out by other specifications within a SOAP message. WS-Security is primarily a specification for an XML-based security metadata container... WS-Security allows for a SOAP message to identify the caller, sign the message, and encrypt message contents. Whenever possible, existing specifications are reused to reduce the amount of invention required to securely deliver a SOAP message. Because all of the information is delivered within the message itself, the message becomes transport neutral. The message would be secure if it was delivered by HTTP, e-mail, or on CD-ROM..."

  • [September 21, 2002]   Discussion Forum for Web Services Security Quality of Protection.    An OASIS discussion list has been created on the topic Web Services Security Quality of Protection. Subscribers to the 'WSSQoP-Discuss' list will discuss the possible creation of an OASIS Technical Committee. Sponsors of the proposal include representatives from CommerceOne, Cisco, Entrust, IBM, RSA Security, SAP, Sun Microsystems, and VeriSign; the discussion leader is Tim Moses (Entrust). The stated purpose of the TC under discussion would be "to identify candidate solutions for communicating the required security tokens and quality of protection for a Web service, taking advantage of the common service definition tools, such as WSDL. The solutions are intended to allow a service consumer to determine (1) how to produce a SOAP message including security tokens and protection mechanisms, in accordance with WSS, that is acceptable to both the provider and consumer, and (2) whether the consumer is capable of performing the required security processing on the response from a Web service. Components of security policy include at least the set of acceptable types of security token, the set of acceptable cryptographic algorithms, (optionally) what key to use for encryption, and the payload nodes to be protected. The topic is potentially open-ended, leading to solutions for trust policy, authorization policy, personal privacy policy, etc. While recognizing this, it is the intention to limit the identified solutions to those that address the QoP of the initial mechanisms of WSS. This is analogous to the 'cipher suites' and "supported algorithms" mechanisms of TLS and S/MIME, respectively. In addition, the group will identify candidate process models for producing a WSDL instance from a security policy definition, and producing a language-specific API from a WSDL instance..." [Full context]

  • [September 19, 2002] "Federated Identity Face-Off." Interview by Stuart J. Johnston and Dan Ruby. In XML Magazine (October/November 2002). ['In a virtual debate, IBM's Bob Sutor and Sun's Simon Phipps pull no punches on competing federated identity management strategies.' See also the reference list for Federated Identity Resources] Excerpts: Now that WS-Security is in OASIS and has gained Sun's support, how do you see it evolving? [Phipps:] "We're very happy to have WS-Security brought into OASIS so that it can make a contribution to the ongoing security discussion. Microsoft and IBM have done an about-face and have introduced it as a royalty-free specification into OASIS, and we felt that that needed to be encouraged and embraced. So what we've been embracing, fundamentally, is the contribution more than the proposal. There are a couple of principles that we are committed to. One of them is working with open communities to evolve new marketplaces that are level playing fields. Sun is committed to doing that through OASIS, and the fact that the SAML work was already going on at OASIS means that we're deeply committed to SAML." [Sutor]: Now that it is in a standards body, we would expect WS-Security to morph -- you never know how much. We would certainly expect inputs from other people. Look at how we brought SOAP 1.1 to the W3C two years ago, and fairly soon now we expect a SOAP 1.2 to come out, and it's not exactly the same. A lot of what they're doing with SOAP 1.2 has to do with how you bind it to underlying transports. That wasn't fully expressed in SOAP 1.1. But this was an open effort and whatever the industry decided SOAP 1.2 needed, that was done..." Where are there points of overlap or competition between WS-Security and Liberty Alliance? [Sutor]: "Liberty is not a Web services spec. WS-Security defines a set of SOAP extensions, using SOAP just as it is designed. For example, it provides a convention for how to put a SAML assertion in a SOAP header, which will support Liberty as it defines its protocols, conventions, and workflow. From a Web-services perspective, WS-Security is the more fundamental spec..." [Phipps:] "Liberty is a movement by the users of network identity to specify what they need for vendors to provide for them. On the other hand, the ideas in WS-Security up until now were those developed in-house by a monopolist, and only then crossed the border into being a contribution to an open discussion. Liberty's proposed mechanism is comparable with the whole WS-Security road map that has been articulated. WS-Security is just a small piece of an architecture. It says nothing about how to federate..."

  • [September 18, 2002] "IBM Supports WS-Security Spec in Products." By Richard Karpinski. In InternetWeek (September 18, 2002). "IBM on Wednesday detailed plans to begin supporting the recently announced WS-Security specification -- which it helped co-author -- in products including its WebSphere application server and Tivoli management platform. WS-Security provides a framework for securing Web services, from how to apply encryption and authentication technologies to how to ensure the integrity of Web services messages. The spec defines a series of SOAP extensions that add security features to the Web services protocol stack. IBM's move represents one of the first implementations of this important new spec, which just recently was placed on a standards track at the OASIS group... Security concerns are often cited as one of the biggest barriers to Web services adoption. The core Web services protocols, such as SOAP, do not have built-in security mechanisms, so enterprises need a way to secure SOAP messages they'll be sending over open networks like the Internet. Only until security issues are settled will Web services move beyond corporate firewalls. IBM said version 5 of its WebSphere application server will support WS-Security in the fourth quarter; Tivoli Access Manager will add support early next year. In addition to basic Web services security, IBM will add features to enable federated identity management capabilities to its software products, which will make it possible for users to more flexibly consume Web services..."

  • [August 26, 2002]   Microsoft Announces Web Services Development Kit Technology Preview.    Microsoft has announced a technical preview for the Microsoft Web Services Development Kit (WSDK), which "provides the tools developers need to build advanced Web services applications using the latest Web services specifications, such as WS-Security, WS-Routing and WS-Attachments. The WSDK is a new Microsoft .NET class library for building Web services using the latest Web services protocols, including WS-Security, WS-Routing, DIME and WS-Attachments. The WSDK offers a low-level API that allows you to apply these protocols directly to individual SOAP messages being sent using HTTP. The library also integrates with the higher-level Microsoft ASP.NET Web service APIs (ASMX) included in the Microsoft .NET Framework. The design of the WSDK reflects the principles of the basic message-level protocols themselves, as outlined in the document 'Understanding GXA': Decentralization and federation; Modularity; XML-based data model; Transport neutrality; Application-domain neutrality... The WSDK incorporates Microsoft's recent work with industry customers and partners to develop Web services specifications beyond XML and SOAP, such as WS-Security, that address the core challenges of Web services in a way that is broadly interoperable across heterogeneous systems. The core features included in the technology preview of the Microsoft WSDK include (1) the ability to help secure XML Web services across platforms and trust domains, including digital signing and encryption of SOAP messages that are compliant with the WS-Security specification; (2) the ability to route an XML Web service through intermediaries using the WS-Routing specification; (3) communication between XML Web services can contain attachments that are not serialized into XML." [Full context]

  • [July 23, 2002] "OASIS Forms WS-Security Committee." By Brian Fonseca. In InfoWorld (July 23, 2002). "Microsoft and IBM moved one step closer to turning their security specification into a standard on Tuesday. Clearing a significant hurdle for the WS-Security standard to gain recognition as a trusted means for applying security to Web services, standards body OASIS (Organization for the Advancement of Structure Information Standards) formed a technical committee to give vendors a crack at the immature specification. First published in April as part of a working partnership between Microsoft, IBM, and VeriSign, the WS-Security specification defines a standard set of SOAP extensions, or message headers, which can be used to set and unify multiple security models, mechanisms, and technology -- such as encryption and digital signatures for instance -- onto Web services applications which traverse the Internet. Aside from an initial WS-Security road map, the trio also proposed specifications yet to come that address a variety of other security, policy, messaging, and trust issues associated with Web services security. They include WS-Policy, WS-Trust, WS-Privacy, WS-Secure Conversation, WS-Federation, and WS-Authorization..."

  • [July 10, 2002] "WS-Next: Plotting A Web Services Security Road Map." By Richard Karpinski. In InternetWeek (July 08, 2002). "When IBM, Microsoft, and VeriSign announced last week they planned to move their would-be WS-Security standard to the OASIS group, most of the attention went to the political gamesmanship. The trio had managed to convince Sun Microsystems to join the effort, avoiding a prolonged battle over how to add baseline security -- things like encryption and digital signature support -- to Web services... Most simply, WS-Security defines a set of Simple Object Access Protocol (SOAP) headers that can be used to implement security measures for Web services. The base WS-Security specification describes how to add encryption and digital signatures to Web services (in each case supporting a W3C working group effort, XML-Encryption and XML-Signatures, respectively.) WS-Security also defines a general mechanism for passing around arbitrary security tokens, though it doesn't define how those tokens work... The overall idea with WS-Security is to build a security stack in much the same way the industry built a basic Web services protocol stack with XML Schemas, SOAP, WSDL, and so forth. The concept of simplifying and consolidating Web services security efforts is also a key driver behind WS-Security... WS-Security and SAML: SAML defines a standard, XML-based approach for passing security tokens defining authentication and authorization rights. SAML is almost two years old now, which means it pre-dates the recent wave of interest in Web services. Originally, SAML was more about distributed authentication and single sign-on. But those concepts are also integral to Web services, and with both SAML and WS-Security now housed at OASIS, backers of the two specs are eyeing each other warily. According to Netegrity's Chanliau, the two security approaches will work together and ultimately give enterprises some important choices about how to secure Web services. For starters, SAML has quickly adopted WS-Security as the appropriate method for "binding" SAML assertions into SOAP messages. Version 1.0 of SAML is coming up to a vote this month; it is expected to be approved as standard by fall. SAML 1.0 won't include a SAML-over-SOAP definition today -- concentrating on http instead -- but Chanliau expects future versions of the SAML spec to adopt WS-Security..."

  • [July 02, 2002] "WS-Security Takes Good Step Toward Being Web Service Standard." By Ray Wagner. Gartner Note Note Number: FT-17-3085. 02-July-2002. ['The Organization for the Advancement of Structured Information Standards (OASIS) will oversee the Web Services Security (WS-Security) specification and won't charge royalties. A good step toward standards, but challenges remain.'] "On 27-June-2002, IBM, Microsoft and VeriSign announced they will submit the latest version of the WS-Security specification to OASIS for development. WS-Security allows systems to interoperate in a platform- and language-neutral manner. Baltimore Technologies, BEA Systems, Cisco Systems, Documentum, Entrust, Intel, IONA Technologies, Netegrity, Novell, Oblix, OpenNetwork, RSA Security, SAP, Sun Microsystems and Systinet have all said they will participate in the OASIS development effort. Gartner believes this is a strong step toward making WS-Security an industry standard. The IBM/Microsoft/VeriSign alliance will make WS-Security royalty-free, a step that boosts its chances of becoming a standard. The participation of competitors and industry heavyweights such as BEA, Cisco and Sun also indicates an understanding of, and support for, standardized security mechanisms within Web services. Gartner urges all participants to continue cooperation on such standards. Gartner cautions enterprises, however, that Web services have important security issues that remain unresolved. Proposed Web service security mechanisms highly depend on the distribution of digital certificates and on the underlying trust that supports their use. Credentials will be available from many different sources, including enterprises' own products, and "meta-trust" issues remain. The lack of any guaranteed level of trust between enterprise Web service deployments will represent a major stumbling block to widespread deployment beyond the enterprise. This issue has slowed the acceptance of public key infrastructure for years and must be resolved for Web services to become ubiquitous beyond enterprise boundaries..."

  • [June 27, 2002] "Sun Switches Gears On Encryption." By Wylie Wong. In CNET News.com (June 27, 2002). "Microsoft, IBM and VeriSign have submitted a security specification for Web services to an industry standards body, a move that has won the backing of an unlikely supporter: Sun Microsystems. WS-Security is a 2-month-old technology that encrypts information and ensures that data passed between companies remains confidential. Its three creators -- Microsoft, IBM and VeriSign -- said Thursday they have submitted the specification to a standards body called the Organization for the Advancement of Structured Information Standards (OASIS). Sun had been devising its own rival Web services security specification, but the royalty-free licensing of WS-Security specifications allayed Sun's concerns, a source familiar with the negotiations said. Sun will now focus all its development work on WS-Security and work with its rivals to improve the specification through the OASIS group, said Bill Smith, Sun's director of Liberty Alliance technology. 'They're taking WS-Security into a recognized, open industry organization, and Web infrastructure on a royalty-free basis is an important thing as well,' Smith said. 'You should expect Sun to actively participate in this forum. We will bring whatever we have that can help fill out WS-Security. This is where (the security work) is being done.' Sun's support of WS-Security alleviates concerns about a possible standards war over Web services security. Proponents of Web services have feared that industry squabbling could derail the much-hyped movement. Every software maker has touted Web services as the future of software because such services allow companies to interact and conduct business via the Internet. But Web services won't work unless the entire tech industry coalesces around a single set of standards. Analysts have said lack of security is the biggest obstacle to the adoption of Web services--and that WS-Security took a big step in addressing the issue. Besides WS-Security, IBM, Microsoft and VeriSign plan to build five more security specifications in the next year and a half to provide additional security measures that businesses may need for Web services. Although Smith declined comment on it, sources said Sun had been quietly working on its own security specification that was royalty free. Over the past several months, Sun executives had expressed concern that IBM and Microsoft might charge 'tolls' to developers -- in the form of royalties on patents -- for using two existing Web services specifications: the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL). Neither Microsoft nor IBM has formally stated a desire to charge royalties on the standards, which are in part based on patents held by them..."

  • [June 27, 2002] "WS-Security Specification Sent to OASIS." By Darryl K. Taft. In eWEEK (June 27, 2002). ['IBM, Microsoft and VeriSign announce they will push their Web services security standard through OASIS.'] "Moving ahead on promises made when they formed the initiative in April, IBM, Microsoft Corp. and VeriSign Inc. Thursday announced that they will submit the latest version of the Web Services Security (WS-Security) specification to the Organization for the Advancement of Structured Information Standards for ongoing development. The WS-Security specification is a leading Web services standards effort to support, integrate and unify multiple security models, mechanisms and technologies, allowing a variety of systems to interoperate in a platform- and language-neutral manner, the companies said. Eric Newcomer, chief technology officer of Iona Technologies Inc., in Waltham, Mass., and a founding member of the working group that will handle the WS-Security standards effort within OASIS, said from his perspective IBM and Microsoft grew 'impatient' with the efforts of the Worldwide Web Consortium (W3C) to deliver a standard around security and Web services... In addition to Iona, many OASIS member companies pledged support for WS-Security, including Baltimore Technologies plc., BEA Systems Inc., Documentum Inc., Entrust Inc., Netegrity Inc., Novell Inc., Oblix Inc., RSA Security Inc., SAP AG, Sun Microsystems Inc., Systinet Corp., Vodafone Group plc. and webMethods Inc... The WS-Security specification, which provides the foundation for that road map, defines a standard set of Simple Object Access Protocol (SOAP) extensions, or message headers, which can be used to implement integrity and confidentiality in Web services applications. Web services are applications that can be accessed through XML and SOAP-based protocols, making them platform- and language-independent. WS-Security provides a foundation layer for secure Web services, laying the groundwork for higher-level facilities such as federation, policy and trust."

  • [April 12, 2002] IBM Web Services Toolkit Supports the WS-Security Specification. IBM alphaWorks Labs has released a new version of its Web Services Toolkit with support for the Web Services Security Specification (WS-Security) announced on 2002-04-11. Specifically, the v3.1 IBM WSTK additions "provide an implementation of SOAP Security Token and Digital Signature components of the WS-Security specification. The SOAP Security Token which indicates the message sender's properties (name, identity, credentials, and capabilities ) is passed with SOAP messages; this helps identify the message sender to the Web service provider. This modular technology is useful to Web service providers when they need to support users with different authentication mechanisms. It also enables Web services providers to incorporate additional security features to their Web services applications over time. Version 3.1 also features a Buyer-Seller demo, Business Explorer for Web Services, Web Services Management, WSDL Explorer, new utility services, WSIL4J, and support for the use of UDDI v2 registries. The Buyer-Seller demo uses various aspects of Web Services components such as WSDL, WS-Inspection, UDDI, AXIS, etc. in a standards-based J2EE runtime environment."

  • [April 11, 2002] "Spec Secures Web Services Applications." By Peter Galli and Darryl Taft. In eWEEK (April 11, 2002). "Microsoft Corp., IBM and VeriSign Inc. have joined forces to develop and publish a new security specification for Web services that will form the foundation of their proposed Web services security architecture. The specification, which the parties say is the first such spec to be launched, will be known as WS-Security and is designed to help organizations build secure and broadly interoperable Web services applications. 'The spec is designed to enable message-level, SOAP-level security, specifically encryption, authentication and identity around those messages. What this will really enable is for Web services to communicate in a trusted manner, especially in a scenario where you have multiple actors in a Web service, where it will provide end-to-end security between all of those parties,' [said] Marcie Verdin, director of enterprise services at VeriSign... Bob Sutor, the director for eBusiness strategy at IBM, said the plan is to submit the specification to standards groups, but he declined to say which these would be. 'This is very broad, and no one standards organization is going to be able to do it. The W3C [World Wide Web Consortium] may be involved; we'll just have to wait and see'... 'This is the foundational specification for Web services security, in the same way that two years ago SOAP was a foundational specification', he added. Steven VanRoekel, the director of Web services marketing at Microsoft, said the specification is based on work that had already been done in the W3C around XML encryption and digital signatures. When asked about not including other industry players in the development of the specification, Sutor said, 'We have published several specifications together in the past like SOAP and WSDL [Web Services Description Language]. We put them out there and let the industry and partners comment on them. We plan to do the same with this and will only submit the spec to the standards bodies in a few months after we have received industry input.'... customers have been saying that while the technology is new and innovative, they are not going to use it for anything mission-critical across the Internet until they can be comfortable that their information is secure and stays confidential... IBM and Microsoft have also developed and are publishing a Web services security road map, titled 'Security in a Web Services World.' The document defines additional and related Web services security capabilities within the framework established by the WS-Security specification that Microsoft and IBM plan to develop ... The additional proposed specifications deal with security policies, trust relationships, privacy practices, the management and authentication of message exchanges between parties, trust in heterogeneous federated environments, and the management of authorization data and policies..."

  • [April 11, 2002] "Microsoft, IBM, Verisign Team on Web Services." By Joris Evers. In InfoWorld (April 11, 2002). " Microsoft, IBM, and Verisign have devised a way to add integrity- and confidentiality-checking capabilities to upcoming Web services applications, a first step in a broader joint effort to secure Web services, the companies said Thursday. The jointly developed specification, dubbed WS-Security, defines a set of SOAP (Simple Object Access Protocol) extensions and describes how to exchange secure and signed messages in a Web services environment, providing a foundation for Web services security... In addition to the WS-Security specification, Microsoft and IBM said they plan to develop a range of security specifications for Web services together with key customers, partners, and standards organizations such as the W3C (World Wide Web Consortium) and the IETF (Internet Engineering Task Force). Six of the other proposed specifications are WS-Policy, WS-Trust, WS-Privacy, WS-Secure Conversation, WS-Federation, and WS-Authorization. These proposed specifications can be grouped in two categories, with the first three dealing with defining security policies, establishing trust relationships, and implementing privacy policies, and the last three handling the sending and receiving of messages sent between Web services..."

  • [April 11, 2002] "Tech Giants Partner On Security Specs." By Wylie Wong. In CNET News.com (April 10, 2002). "Microsoft, IBM and VeriSign have teamed to create security specifications for Web services, a move analysts say will help drive adoption of the hyped but still emerging technology... they will release a new specification, called WS-Security, which will encrypt information and ensure that the data being passed between companies remain confidential. The companies, which are announcing the new security initiative at Microsoft's Tech Ed developer conference, also plan to build five more security specifications in the next 12 to 18 months that will provide additional security measures that businesses may need for Web services... WS-Security merges two different security specifications that Microsoft and IBM had worked on separately with help from VeriSign, said executives from the three companies. Microsoft released a security specification, also called WS-Security, in October, but the software giant built the original without collaborating with the other companies. The new version of WS-Security, which combines the work of IBM, Microsoft and VeriSign, is used as part of a SOAP message. It outlines how to use existing World Wide Web Consortium specifications called XML Signature and XML Encryption. "It ensures the message you received is the one that was sent and was not tampered with along the way," said Bob Sutor, IBM's director of e-business standards strategy. "You want to know that the message is from me and not someone spoofing my identity and counterfeiting messages to you." The three companies plan to eventually submit WS-Security to an industry standards body, but have not yet decided on the timing or the body that they will work with..."


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/ws-security.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org