Articles - XWSS: XML Web Services Security Forum

Articles & Technical Resources

Member-contributed articles, whitepapers, and technical guides on XML web services security. Sorted by date, most recent first.

p_richardson - Member since 2002-01-08 - Posts: 487

Posted: 2003-05-14 10:22 UTC

Securing SOAP with WS-Security: A Practical Guide

The OASIS Web Services Security (WS-Security) 1.0 specification, published in April 2002, defines a framework for attaching security credentials to SOAP messages. While the specification itself is thorough, practical guidance on implementing WS-Security across different application servers remains scarce. This article attempts to fill that gap with working examples for the three most common enterprise SOAP stacks.

The core mechanism of WS-Security is the <wsse:Security> SOAP header block, which carries security tokens (UsernameToken, X.509 certificates, Kerberos tickets), XML Signatures over message elements, and XML Encryption of sensitive data. The key insight that WS-Security provides over transport-level SSL is that security properties travel with the message through intermediaries. In a multi-hop SOAP processing chain where a message passes through routing nodes or transformation engines, SSL protects only the immediate link, while WS-Security protects the message end-to-end.

This article covers: constructing UsernameToken with password digest, signing SOAP body elements with X.509 certificates, encrypting sensitive elements with symmetric keys wrapped in the recipient's public key, and handling timestamp validation to prevent replay attacks. Code samples are provided for BEA WebLogic 8.1, IBM WebSphere 5.0, and Apache Axis 1.1 with the WSS4J library.

d_kumar - Member since 2002-08-11 - Posts: 193

Posted: 2003-09-02 14:08 UTC

XML Firewall Product Comparison 2003

As organizations deploy more SOAP-based web services, the need for specialized XML-aware security appliances has grown considerably. Traditional network firewalls operate at layers 3 and 4 and cannot inspect the content of XML messages carried over HTTP. XML firewalls fill this gap by parsing, validating, and filtering SOAP traffic at the application layer.

We evaluated four XML firewall products over a three-month period in a lab environment that replicated a typical enterprise web services deployment with both internal and external-facing SOAP endpoints. The products tested were: DataPower XS40 XML Security Gateway, Reactivity XML Firewall, Sarvega XMG XML Management Gateway, and Forum Systems XWall XML Firewall. Each product was assessed on schema enforcement, WS-Security header processing, XML threat prevention (entity expansion, oversized payloads, recursive structures), performance under load, and integration with existing identity infrastructure (LDAP, X.509 PKI).

The DataPower XS40 provided the strongest performance numbers and the most comprehensive XML threat protection, but at a significantly higher price point. Reactivity offered the best policy management interface and the most flexible integration with third-party SAML identity providers. Sarvega excelled in high-throughput scenarios where schema validation was the primary requirement. Forum Systems XWall provided adequate protection at the lowest cost, making it suitable for smaller deployments. Full benchmark results and configuration details are included in the attached PDF.

r_foster - Member since 2002-05-19 - Posts: 312

Posted: 2003-06-28 09:45 UTC

WS-Security vs SSL: When Message-Level Security Matters

A question that arises frequently on this forum and in enterprise architecture reviews is whether WS-Security is necessary when SSL/TLS is already protecting the transport layer. The short answer is that they solve different problems, and many deployments will require both. This article examines the specific scenarios where message-level security provides protections that transport security cannot.

The fundamental distinction is that SSL provides point-to-point confidentiality and integrity between two TCP endpoints, while WS-Security provides end-to-end security properties that persist regardless of how many intermediaries process the SOAP message. In an architecture where messages pass through a load balancer that terminates SSL, then through a routing intermediary, and finally to the backend service, the message content is exposed in plaintext at each hop. WS-Security encryption protects the sensitive elements of the message throughout this entire chain.

Additionally, WS-Security supports selective encryption and signing of individual XML elements within a SOAP message. This enables patterns where different parts of the message are accessible to different intermediaries. For example, a routing header may be readable by all nodes, while the business payload is encrypted for only the final recipient. SSL provides no such granularity. We also discuss non-repudiation requirements, where XML Signatures provide proof of origin that SSL session keys (which are ephemeral and shared) cannot provide. The article concludes with a decision matrix to help architects determine which security mechanisms are appropriate for their deployment topology.

mhendricks - Member since 2002-03-15 - Posts: 342

Posted: 2003-11-20 16:30 UTC

The SOAP Security Problem No One Talks About

Much of the discussion around web services security focuses on the WS-Security specification and its associated token profiles. While these are important, there is a more fundamental problem that receives far too little attention: the XML parser itself is an attack surface. Every SOAP endpoint must parse untrusted XML before any security processing can occur, and the default configuration of nearly every XML parser in use today is unsafe.

The problem is structural. The WS-Security processing model assumes that the SOAP message has already been parsed into a DOM or SAX event stream before the security header is examined. This means that parser-level attacks (entity expansion, external entity resolution, schema poisoning) execute before any WS-Security policy can reject the message. An attacker does not need to forge a valid security token or break encryption. They simply need to craft an XML document that exploits the parser, and the WS-Security layer never gets a chance to intervene.

This article catalogs the known XML parser attacks relevant to SOAP endpoints, provides configuration guidance for Xerces-J, MSXML, and the .NET System.Xml parsers, and argues for the adoption of an "XML hardening" checklist as a prerequisite to any WS-Security deployment. We also examine how the emerging generation of XML firewall appliances addresses these parser-level threats by performing pre-validation before the message reaches the application server's XML parser. Until the OASIS WS-Security TC incorporates parser security guidance into the standard, the responsibility falls on individual deployers to close this gap.

s_yamamoto - Member since 2002-06-22 - Posts: 218

Posted: 2003-08-15 11:12 UTC

SAML Assertions in Enterprise Web Services

The Security Assertion Markup Language (SAML) 1.1 specification, published by OASIS in September 2003, provides a standard XML vocabulary for expressing authentication and authorization assertions. When combined with WS-Security's SAML Token Profile, SAML assertions can be carried in SOAP message headers to propagate identity and access control decisions across web services boundaries.

This article describes a reference architecture for using SAML assertions in an enterprise web services deployment. The architecture involves three parties: a SAML authority (identity provider) that issues assertions, a web services consumer that attaches assertions to outgoing SOAP requests, and a web services provider that validates assertions and makes authorization decisions. We use the "sender-vouches" subject confirmation method, where the web services consumer vouches for the identity of the end user by attaching a signed SAML assertion to the WS-Security header.

Practical implementation is demonstrated using IBM WebSphere 5.0 with the Trust Association Interceptor framework for SAML assertion validation, and BEA WebLogic 8.1 with the Security Service Provider Interface (SSPI) for custom SAML token handling. We address common pitfalls including clock skew handling in NotBefore and NotOnOrAfter conditions, audience restriction validation, and the requirement to verify the XML Signature over the assertion to prevent tampering by intermediaries. A complete working example with WSDL, deployment descriptors, and Java source is available for download.

jturner_dev - Member since 2002-09-03 - Posts: 134

Posted: 2004-01-09 08:30 UTC

WS-I Basic Profile and Security Compliance

The Web Services Interoperability Organization (WS-I) published the Basic Profile 1.0 in August 2003, establishing a set of constraints on the use of SOAP 1.1, WSDL 1.1, UDDI, and XML Schema to promote interoperability across platforms. While the Basic Profile does not directly address security, many of its requirements have implications for WS-Security implementations, and the forthcoming Basic Security Profile will build on this foundation.

This article examines the intersection of WS-I Basic Profile compliance and WS-Security deployment. Key areas of concern include: the Basic Profile's requirement that SOAP messages use the http://schemas.xmlsoap.org/soap/envelope/ namespace (prohibiting SOAP 1.2 in BP 1.0 compliant services), the restriction on SOAPAction header usage that affects security policy selection, the prohibition of DTDs in SOAP messages (which aligns well with XML parser hardening guidance from this forum), and the requirements around WSDL binding styles that affect how signed elements are referenced.

We also discuss the WS-I testing tools and how to use them to verify that your WS-Security headers do not violate Basic Profile constraints. The WS-I Monitor tool can capture SOAP traffic and validate it against the profile, including checking that mustUnderstand processing is handled correctly for security headers. For organizations pursuing both interoperability and security, understanding these constraints early in the design process will avoid costly rework when interoperability testing reveals conflicts between security requirements and profile compliance.

xmlsecguy - Member since 2002-04-30 - Posts: 156

Posted: 2003-04-03 15:55 UTC

XML Canonicalization Pitfalls in SOAP Message Signing

XML Digital Signatures require that the signed content be canonicalized before the digest is computed, ensuring that logically equivalent XML documents produce identical byte sequences for signing purposes. The W3C defines two primary canonicalization algorithms: Canonical XML (C14N) and Exclusive Canonical XML (Exc-C14N). In the context of SOAP message signing, the choice of canonicalization algorithm and its correct application is one of the most common sources of interoperability failures.

The core issue is namespace handling. Standard C14N inherits all in-scope namespace declarations from ancestor elements, even if they are not used within the signed fragment. When a signed SOAP body element is extracted from one message and inserted into another (a legitimate operation in some routing scenarios), the inherited namespaces change, and the signature becomes invalid. Exclusive C14N (Exc-C14N) addresses this by including only the namespace declarations that are "visibly utilized" within the signed fragment, plus any specified in an InclusiveNamespaces PrefixList.

This article walks through three specific interoperability failures we encountered between Apache Axis (using the Apache XML Security library), BEA WebLogic 8.1, and Microsoft .NET 1.1. In each case, the signature was computed correctly by the sender but failed validation at the receiver due to differences in canonicalization behavior. We provide packet captures showing the exact bytes that differed and the configuration changes required to achieve interoperability. The key recommendation is to always use Exclusive Canonicalization with an explicit InclusiveNamespaces PrefixList in WS-Security signatures, and to test signature verification across all platforms in your deployment before going to production.