Skip navigation

WS-Security Sets Standard for Web Services Transactions

The three core pieces of Microsoft's XML Web services—Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI)—form the foundation of Microsoft's approach to the .NET platform, but they don't represent the whole picture. To add greater security and better routing and lookup abilities to Web services, Microsoft is developing five other XML-based specifications: two for increasing messaging security (Web Services Security Language—WS-Security—and Web Services License Language—WS-License), two for improving message routing (Web Services Routing Protocol—WS-Routing—and Web Services Referral Protocol—WS-Referral), and one for making lookups more efficient (Web Services Inspection Language—WS-Inspection). WS-Inspection builds extensions to UDDI and WSDL, and the other specifications are extensions to SOAP. In this edition of .NET UPDATE, I'll look at the WS-Security standard.

WS-Security encompasses three functions: exchanging credentials between sender and receiver, checking the integrity of the messages, and keeping the contents of messages confidential. The idea behind WS-Security is to make information exchanges, such as credit card transactions, more secure. For example, using a WS-Security-based security system, the services on each side of the message exchange determine that a request for credit card information came from a legitimate source and is going to a legitimate receiver, that no one has added a request for a credit card number when the original message contained no such request, and that no one has intercepted the message and picked up the credit card number.

Exchanging Credentials
You can use WS-Security to exchange many different types of credentials, among them licenses and testaments. Licenses such as X.509 certificates or Kerberos tickets are functionally similar to a driver's license: They're collections of related statements (i.e., assertions) about the holder that a recognized authority has signed, in much the same way that my driver's license carries my picture and address and is signed by a representative of the commonwealth of Virginia. A license also describes the kind of keys used for signing or encrypting SOAP messages: public or symmetric. The WS-Licensing specification describes a license's form. A testament, which takes the form of a private key or session key, proves ownership of a license.

The credential exchange typically works as follows: When preparing to send a message, the sender signs the message with a testament and uses the public or symmetric key in the recipient's license to encrypt the message. When the recipient receives the message (and, optionally, the sender's license; the decision whether to send the license isn't part of the specification), the recipient uses the information in the sender's license to verify that the digital signature belongs to the sender. The recipient can then decide whether to trust messages from this sender—but the decision-making part of the process isn't part of WS-Security.

Verifying Message Integrity
WS-Security supports XML Signatures, which ensures the sender's identity and allows message senders to let message receivers determine whether a message was altered in transit. A SOAP message can have more than one signature, because in distributed applications (like the kind of application that Web services are supposed to enable), a message might contain information from more than one host. As long as all hosts sign their parts of the message, the recipient can sort out which host sent which information and check the information's integrity.

Keeping Messages Confidential
A sender can use XML Encryption to encrypt all or part of a SOAP message's contents. XML Encryption can also encrypt a binary attachment to a SOAP message; in that case, a confidentiality header holds encryption metadata that points to the attachment. If all data lies within the body of the SOAP message, the confidentiality header can tell the message how to decrypt the data, or the encryption metadata can be stored with the data it relates to. Encryption isn't an all-or-nothing proposition; a sender can encrypt some parts of a message and leave other parts in clear text.

You can find more information about WS-Security or global XML Web services at the following URLs.

"WS-Security Specification Index Page"
"Global XML Web Services Architecture" white paper

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish