WSE Series II: WS-Security

Web Services sound great with all its Discoverability and Interoperability, but this involves data transmission through the Internet as SOAP messages. While SOAP provides a standardized interface for accessing Web Services, since SOAP messages are transmitted as a stream of human-readable XML, intercepting the message or tampering it becomes much easier. Also requirements of some Web Services mandate access control to its services. This speaks the need for designing the Web Services from the ground up to use the best available security features and best practices. Until recently there were some gaping deficiencies in the Web Services domain, particularly in the Security like ability to handle security, authentication, encryption, digital signature, routing and attachments at the message level, rather than using out of band or OS-proprietary techniques.

With WS-Security, getting down to the business of providing interfaces and programming toolkits that all "speak the same language" has become easier and developers can begin to use the benefits of these efforts. A SOAP message, on its own, can be authenticated, its integrity verified, and it can be encrypted in whole or in part using the mechanisms defined in WS-Security. The architectural model of WSE is built on a "pipeline" of filters that process inbound and outbound SOAP messages. This is built on the pre-existing SOAPExtension classes, and developers who have experimented with SOAP Extensions for compression, encryption, logging and other purposes will find the implementation familiar.

WS-Security and the WS-Security addendum are published at http://msdn.microsoft.com/ws/2002/04/security and http://msdn.microsoft.com/ws/2002/07/Security respectively. Since the release of WS-Security it is emerging as the primary industry standard for secure Web service communication. This spcification fully leverages the existing XML signature and XML encryption protocols and optimizes them for use in SOAP message-based Web services environment to support the transmission of security tokens as well as encryo\ption and digital signatures. WS-Security describes the folowing SOAP header elements:

• Security - the root WS-Security element in the SOAP header
• UsenameToken - A child element that supports simple username and password authentication mechanisms
• BinarySecurityToken - A child element that supports binary-based security tokens such as Kerberos tickets and X.509 certificates
• SecurityTokenReference - A child element that supports referencing remote security tokens that are available at a URI
• KeyInfo - A chil element that supports inclusion of key information (derived from XML signature)
• Signature - A child element that supports signing one or more parts of a SOAP message (based on XML signature)
• ReferenceList - A child element that supports referencing one or more encrypted elements in the body of a SOAP message (based on XML encryption)
• EncryptedKey - An element that supports encryptionspecifically for keys (based on XML encryption)
• EncryptedData - A child element that supports including additional encrypted data in a SOAP header (based on XML encryption)
• Timestamp - The WS-Security Addendum specification that supports including timestamp info in the SOAP header that can be used to prevent replay attackes when an attacker tries to reuse an ols message.

The subsequent posts we will discuss the other WSE specifications.