Monday, December 31, 2012

Web Service Security: message level vs transport level

Why message-level security (e.g. WS-Security) is better than transport-level security (e.g. TLS/SSL):

  • End-to-end security: message-level XML-Encryption protects sensitive data also in the intermediaries / external proxies. The point-to-point security TLS/SSL doesn't prevent the intermediaries to read the sensitive data.
  • With WS-Encryption it's also possible to encrypt only a part of the messages for flexibility (e.g. in case the intermediary proxy need to peek the unencrypted part) or performance (it's cheaper to encrypt/decrypt only portions of the messages).
  • The message-level security (e.g. WSS Authentication, XML-Encryption, XML-Signature) is independent to the protocols thus it offers more flexibility to send SOAP messages across different protocols (e.g. http, jms, ftp).

On the other hand, message-level security has also disadvantages:

  • Performance (encrypt/decrypt, validate): processing time & increased message size
  • Configuration & Maintenance (but can be easier using declarative policy)
  • Can not peek the message values during development & debug
  • More complex, more difficult to find developers who master

     Transport level security (TLS/SSL)

Security protocol for internet communication with web protocol (e.g. web application, web services SOAP/REST)

The basic authentication scheme is by passing the credentials (userid & password) in the http header. This can be improved using password digest: the credentials are hashed (so that the attacker can not read the password) & using nonce (to prevent reply attack)

Certificates can be used for authentication, encryption and signature (non repudiation)

by setting in the web server (e.g. Weblogic, Apache, Tomcat): basically enabling the https listening port and register the location of keystore/certificates.

Message level security

Message standard for SOAP web services security e.g. WS-Security (WSS), WS-Policy.

  • Java: using handler/adapter to insert WSS header in the request and remove the WSS header in the received response. The handler also encrypt/decrypt the data. Futher info: read book by Kanneganti.
  • Java using Rampart/Axis2 framework: set security context (e.g. keystore) in the request, define security policy in the wsdl. Futher info: read book by Tong.
  • OSB: using OWSM by defining policy. Futher info: read OSB development cookbook by Schmutz

Messages examples:

WSS Authentication using user password token

<wsse:Security xmlns:wsse=".../oasis-200401-wsswssecurity-secext-1.0.xsd">

WSS Authentication using password digest
  <wsse:Password Type="">thepasswoorddigest</wsse:Password>
  <wsse:Nonce EncodingType="" >thenonce</wsse:Nonce>

WSS Encryption and Signature

The encrypted data is stored in <xenc:CipherData> inside <xenc:EncryptedData> in the body. The <ds:KeyInfo> inside <xenc:EncryptedData> in the body refers to the key information <xenc:EncryptedKey> in the header. So in this example the key is also sent in the message (in the <xenc:CipherData> inside <xenc:EncryptedKey> in the header)  but there is also a scheme where you can reuse the key so you don't have to resent it everytime.

In this example we show also the use of signature, the signature is in the <ds:Signature>  and the client key signature information is in the  <wsse:BinarySecurityToken> both in the message header.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap=""
                        <wsse:Security xmlns:wsse="..." soap:mustUnderstand="1">
                                   <xenc:EncryptedKey xmlns:xenc=""
                                               <xenc:EncryptionMethod Algorithm="" />
                                               <ds:KeyInfo xmlns:ds="">
                                                           <xenc:DataReference URI="#EncDataId-2" />
                                    <wsse:BinarySecurityToken .
                                   <ds:Signature xmlns:ds=""
            <soap:Body xmlns:wsu="..." wsu:Id="Id-16874657">
                        <xenc:EncryptedData xmlns:xenc=""
                                   Id="EncDataId-2" Type="">
                                   <xenc:EncryptionMethod Algorithm="" />
                                   <ds:KeyInfo xmlns:ds="">
                                               <wsse:SecurityTokenReference xmlns:wsse="...">
                                                           <wsse:Reference xmlns:wsse="..."
                                                                       URI="#EncKeyId-9B0F450EB80863260412615456546075" />

See also:

Web Service Security: Threats & Countermeasures
Please share your comment.

Source: Steve's blog


• SOA Security by Kanneganti

Oracle Service Bus 11g Development Cookbook by Schmutz & Biemond

Developing Web Services with Apache CXF and Axis2 by Tong

No comments: