Securing Applications That Use Web Services

Web services can be secured, but limitations exist when it comes to building scalable distributed applications based on Web services. Specifically, it is difficult to build scalable applications that cross security domains. Currently, you can secure Web services by having a message sent over a secure transport, such as Secure Sockets Layer (SSL), but that only works when the communication is point-to-point. That is, if the SOAP message must be routed to one or more intermediaries before reaching the ultimate receiver and the entire route uses SSL, then the ultimate receiver still has to communicate with the sender to authenticate the sender of the SOAP message. Such a scenario is difficult to scale.

Support for Message-Level Security

WSE provides three features that contribute to the secure transmission of SOAP messages:

• Security credentials enable the scalable securing of Web services over the complete route a SOAP message takes. This is different from a secure transport, such as SSL, which only secures from one point to another. For information about how to use WSE to add security credentials, see How to: Add Security Credentials to a SOAP Message.
• Digital signing allows a SOAP message recipient to cryptographically verify that a SOAP message has not been altered since it was signed. For information about how to digitally sign SOAP messages using WSE, see Digitally Signing a SOAP Message.
  The following graphic illustrates the keys needed by the sender and receiver to both sign a SOAP message and to verify the signature. To sign the SOAP message, the sender needs its private key and for a receiver to verify the signature within a SOAP message it needs the sender's public key.
  
• Encryption makes it highly likely that only the intended recipient can read the contents of a message. Encrypting a SOAP message creates a cryptographic secret that is shared with the intended recipient of the message. For information about how to use WSE to encrypt and decrypt SOAP messages, see Encrypting a SOAP Message.
  The following graphic illustrates the keys needed by the sender and receiver to both encrypt and decrypt a SOAP message. To encrypt a SOAP message, the sender needs the receiver's public key, and the receiver needs its private key to decrypt the SOAP message.
  The following graphic illustrates that only the intended recipient of an encrypted SOAP message can access the encrypted portions of the SOAP message, as it is the only one with the private key that decrypts the SOAP message.
  

One of the ways WSE helps to build scalable distributed applications is by providing an efficient and scalable mechanism to secure Web services. It uses the mechanisms defined in the WS-Security specification to place security credentials in the SOAP message itself. This is done by having a client obtain security credentials from a source that is trusted by both the sender and receiver. When a SOAP message sender sends a SOAP request, those security credentials, which are generically known as security tokens, are then placed in the SOAP message. When the Web server receives the SOAP request, it does not need to make another network request back to either the client's computer or a trusted third party to verify the integrity of the security tokens. This is possible when the security credentials are from a trusted source and the client has proven that they own the security token. A client can prove that they own the security token by performing a cryptographic operation, such as digitally signing the SOAP message. A recipient can then verify that the client owns the security token from the trusted source by performing another cryptographic operation, such as verifying the digital signature. By not having to go back to the source of the credentials, at least one network request is saved, further improving application scalability.

WSE 3.0 extends the notion of adding security credentials to a SOAP message through its support of the WS-Trust, WS-SecureConversation, and WS-Security Profile for XML-based Tokens specifications. Through this implementation of these specifications, WSE provides a mechanism for issuing lightweight security tokens, called security context tokens, as well as allowing the developer to develop their own security token service that issues other types of security tokens. These security tokens can then be used to communicate with Web services that trust the security token service.

Digitally signing and/or encrypting the SOAP message can further secure Web services. Digital signing of a SOAP message helps secure a Web service by enabling a SOAP message recipient, such as a Web service, to cryptographically verify that a SOAP message has not been altered since it was signed. Encryption of a SOAP message helps secure a Web service by making it highly likely that only the intended Web service reads the contents of the message.

See Also

Other Resources

Major Features of WSE
Data Confidentiality
Data Origin Authentication