Architect FAQ for WS-Security Projects

Two key events for web services security this week: (a) The RSA Security convenes in San Francisco; and (b) OASIS wraps up final comments on its plan to secure SOAP attachments via WS-Security. To give architects and devs some hands-on perspectives on securing web services projects, IDN spoke with Mark O'Neill, a leading web services security expert author.

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

As WS-Security continues to gather vendor momentum, a leading web services security author offers some hands-on insights to using the WS-Security specs (presently available, and to come) to solve enterprise and B2B security issues with XML, SOA and related technologies.

"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 Integration Developer News.

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.

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.

Just last week, the comment period closed on the final draft for , OASIS' Web Services Security: SOAP Messages with Attachments [SwA] proposal, which would allow architects and devs to ensure the end-to-end integrity, confidentiality and origin authentication or attachments for XML and legacy formats.

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:

Until SaW gets fully implemented, architects and devs will need to be aware of routing their web services apps, O'Neill said.

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.

"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.