Skip to Content

This blog is co-authored by Markus Schumacher:
Markus Schumacher is CEO of Virtual Forge.

It’s been a while since our last blog about Secure Enterprise SOA: Introduction and Part I – Authorizations. There we listed ten challenges that are crucial for successfully and securely implementing a SOA environment. This time we discuss challenge no. 2: End-to-End Security.

SSL is not the answer 

Common and widespread security measures such as SSL or TLS encryption can be considered as insufficient in a SOA world: they only focus on the low-level transport layer, i.e. on TCP/IP level. The messages and requests of a process are not individually protected, instead a secured channel between the two communication parties is established. This means that your data is secure only while in transfer but not when being stored or processed. This is especially true for cross-company processes, as you cannot enforce security measures in a business partner’s system landscape. If your partner does not apply appropiate security measures your data will be at risk.

Thus, security measures must be independent from the transfer channel. They have to aim at the protection of the business data itself. Only that way, the data itself remains protected, even when passed from one service to another beyond company boundaries.

WS-Security as the solution

For web service messages, the OASIS standard WS-Security looks like a suitable technology [1]. It provides confidentiality and integrity protection for messages by means of encryption and digital signatures. WS-Security is an extension to web service protocols; actually it can be used everywhere where XML data is processed and transferred. As WS-Security works on the message level (i.e. it protects individual web service messages), its security is indepedent from the underlying transport layer. Moreover, messages are still secured when they are saved on a hard disk or on backup media. SAP supports WS-Security with the NetWeaver application server. It must be noted though, that support is still limited. For example, you are not yet able to encrypt outgoing XML messages [2].

Do not (only) rely on technology

Besides these technical measures, you are encouraged to also ensure an adequate level of end-to-end security for your SOA applications by implementing organizational measures. Via security policies and the explicit definition of security requirements you can focus attentation at a very early stage. At the other end you confirm compliance to your policies by performing regular checks or audits of your application’s security level. Again, these points become most important in cross-company scenarios, e.g. when consuming a 3rd party service.

End-to-end security remains to be a challenge for Secure Enterprise SOA.

Literature

  1. OASIS Open. Web Services Security: SOAP Message Security 1.1 (WS-Security 2004).
  2. http://help.sap.com/saphelp_nw04s/helpdata/en/31/a6d13f83a14d21e10000000a1550b0/content.htm
To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

    1. Dominik Witte Post author
      Sam,
      thanks for your feedback. As you can see, I added TLS to the list considering your suggestions. In this blog, SSL shall serve as a (well-known) example for transport channel security such as SNC (for the SAP world) or the various VPN dialects. They all share the same disadvantage in SOA scenarios: Instead of protecting the data, the protect its transfer. Also note that the selection of a transport security mechanism automaticall dictates the transport channel to use (e.g. SNC won’t work for HTTP).

      Cheers,
      Dominik

      (0) 

Leave a Reply