Making Web Services Secure: WS-Security, Part 2

If you aren't using Web services yet, there's a good chance that you will in the near future, whether you intend to or not. More tools are appearing every day to make such services easy to develop and use, led by Microsoft's flagship Visual Studio.NET. Web services are one of a long line of Web technologies that has yet to prove itself in the real world, but there is plenty of momentum behind them already.

As someone concerned with security, you're right to look at Web services with a wary eye. As I discussed last week, Web services have the same basic security options as regular Web pages over HTTP, which is to say you can use the same tools to protect yourself. Web services have the same problems as Web sites, along with a few of their own.

To make the new paradigm secure, Microsoft, IBM, and VeriSign have introduced WS-Security and related specifications. WS-Security 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 encryption technologies.

WS-Security, which has yet to be submitted to any standards body, is short for Web Services Security and proposes a standard set of SOAP extensions that can be used when building secure Web services to implement integrity and confidentiality. Collectively, these extensions are called Web Services Security Language. WS-Security provides three main security mechanisms: security token propagation, message integrity, and message confidentiality. You can use these mechanisms independently, such as to pass a security token, or together, such as to sign and encrypt a message along with a security token hierarchy associated with the encryption keys.

The specification defines four "key driving requirements":

* Multiple security tokens for authentication or authorization.

* Multiple trust domains.

* Multiple encryption technologies.

* End-to-end message-level security and not just transport-level security.

The main part of the specification defines a new element as part of the SOAP header. Within that element and the usual namespace references, you can include user authentication, a digital signature (including encrypted digest), key information, and so forth. The structure is flexible enough to accommodate most any appropriate security protocols, using shared secrets and other options to make it as flexible as possible. The digital signature is based on the W3C XML Signature Recommendation.

WS-Security brings together a set of security technologies, some from network security and others related to XML, to provide protection against the risks of exposing confidential information or allowing a malicious hacker to essentially impersonate a legitimate caller. It is just one crucial technology that will ultimately make Web services a legitimate, secure means of building distribute applications on the Web.

Whether it and the myriad other technologies that make up Web servicesis enough to make it a compelling technology most certainly remains tobe seen.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article1

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark