WS-Security Set To Become a Core Standard

The lead author of a comprehensive book on web services security expects WS-Security to become a foundation standard for securing web services, and tells developers to dismiss remaining debates as mute. Mark O'Neill, author of Web Services Security, shares with IDN various insights on a wide range of security topics, with sample code thrown in for "safe" measure.

Tags: Web Services, SOAP, Web Services Security, XML, WS-Security, Routing, SOAP Message,

The lead author of one of the most comprehensive books on web services security thus far says that WS-Security is destined to become a core foundation standard for building secure web services, and that developers should assume any debates on the subject are mute.

"WS-Security will be how XML Signature and tokens can be put into a SOAP message. So, WS-Security, with its support for XML Encryption and XML Signature, will be a baseline for web services security. The days of the dispute between SAML and WS-Security are over," Mark O'Neill, co-author of Web Services Security (McGraw-Hill/Osborne Media) told IDN.

"When OASIS and the Web Services Security working group put their stamp on WS-Security, the result isn't going to be a lot different from what IBM and Microsoft have already published. It won't be 100% the same spec, but close enough," O'Neill told IDN. For developers, he added, the general principles will be the same:
  1. You'll put a token into SOAP message and that will be important.
  2. XML Signature and Encryption will be like SSL hand-shaking, and neither C# or Java developers needing encrypted XML will be required to know much about how to write them.
O'Neill points to SAML as an example. While SAML says 'This entity was authenticated,' that's one type of token. But SAML didn't include a SOAP profile, so WS-Security will be used to put that token, and many others, O'Neill said, into a SOAP message.

The WS-* series of proposals, in conjunction with other security work by OASIS and W3C, addresses an important element of security for SOAP and web services, O'Neill said, and suggest that mature technologies and standards will be available in 2003. "In fact, WS-Security is the only game in town right now, and if I were using Sun hardware, I'd be asking Sun, 'When will you include support for WS-Security?'"

O'Neill is CTO at Vordel, a provider of XML security solutions based in Dublin, with offices in the U.S. He brings a long-term perspective to the issue of web services security -- prior to his work with XML, he worked as an engineer supporting legacy and EDI systems.

O'Neill's co-authors also bring some clout to his perspectives on security. They include Phillip Hallam-Baker, principal scientist at VeriSign; Mike Shema, principal consultant of Foundstone, Inc., and the co-author of The Anti-Hacker Toolkit; Ed Simon, Entrust's XML Security Architect, co-author of the W3C's XML Signature specification and contributor to W3C's XML Encryption; Paul A.Watters, author of the Solaris 8 Administrators Guide; and Patrick Gannon, CEO of OASIS.

Knowing Attacks -- and Guarding Against Them
With this broad legacy-to-web service perspective, O'Neill predicts that as web services mature, developers will need to familiarize themselves with new types of content-centric attacks. Among them:
  • SQL attacks: Inserting SQL statements into web forms in order to force a database to return inappropriate data, or to produce an error that reveals database access information. For web services, this category of attack translates to manipulating data in a SOAP message to include SQL statements that will be interpreted by a back-end database.

  • Directory traversal attacks: Attempts to bypass hyperlinks by directly accessing resources. For example:
    * If a URL is, what happens if is requested?
    * Does a directory called /test/ exist?
    * For web services, this category of attack translates to attempting to detect other SOAP services which are not explicitly offered.

  • URL string attacks: Manipulating CGI name/value pairs in the URL string; for example, changing "maxResults=10" to " maxResults=1000" to return more information from a database. For web services, this translates to circumventing the rules on SOAP parameters (for example, if a search SOAP service takes an integer between 1 and 10 as a SOAP parameter, what if the number 1000 is submitted?).
While many of these can be avoided by careful programming practices and by cleaning up resources not required on the web server, O'Neill suggests that developers working on B2B web services consider the use of an XML firewall or XML proxy to filter SOAP requests before they reach your application.

Coming "Clean" on Routing with SOAP
In Web Services Security, O'Neill notes that "Core elements of web services security are in place [so] SOAP routing does not have to depend on routing information in the SOAP message itself." Routing, he says, can be performed for a number of reasons, including
  1. Scaling a Web Services infrastructure between multiple SOAP servers;
  2. Bridging between two different networking protocols; or
  3. Transforming message content from one format to another.
These three scenarios extend the security context beyond a single SOAP request/response. To address this issue, O'Neill describes how developers should scope the problem, and then provides examples, a template and even some sample code.

Scoping the Problem:
When routing between web services, the requirement for confidentiality can apply from the originator through to the final SOAP endpoint. It may be a requirement that information be kept secret from SOAP intermediaries.

There may be a chance that intermediaries may disclose the information, either deliberately or through leaving gaps between one transport-level security session and the next. While the data is decrypted, it is vulnerable. Confidentiality for a SOAP transaction should not involve simply chaining instances of confidentiality together, since "SOAP gaps" of unencrypted data are available between each decryption and encryption

An Example:
WS-Routing defines how to insert routing information into the header of a SOAP message. This routing information can be considered equivalent to routing tables that operate at lower layers of the OSI stack for routing IP packets.WS-Routing means that one SOAP message may traverse multiple SOAP " hops" between the originator and the endpoint. The systems that implement these hops may have nothing in common apart from the ability to parse and route a SOAP message.

Sample Code:
A code sample shows an example of a SOAP message that uses WS-Routing in order to route between web services. (It routes from the originator, via an intermediary, to an endpoint.) Details and more sample code on this web services security topic is available here.

And here's a code sample developers can use now.

More on Web Services Security -- The Book
Web Services Security includes perspective, code samples and a plain English explanation of many key topics, including the way details of a web services architecture (SOAP, UDDI, WSDL) will affect your security choices; an in-depth implementation look at WS-Security and its use of XML Signature/XML Encryption, specific background and suggestions for using legacy and web services security tokens (including Kerberos and PKI) and mark-up languages (including SAML, XACML and XKMS).

In addition, the book has a proactive feel, intended to help the developer build security solutions -- not simply read about options. Practical projects addressed include:
  • WS-Security and the GXA road map, including WS-SecureConversation and WS-Policy;
  • Using XKMS for validation and accountability;
  • Ensuring data integrity and confidentiality using XML Signature and XML Encryption;
  • SAML and XACML for single sign-on authentication and authorization;
  • The approach of ebXML to security; .
  • Navigating the legal aspects of web services security -- including digital signature laws, privacy issues and application-to-application transactions and others
Get more info on the book Web Services Security.