Back to Article List

Originally published April 2006 [ Publisher Link ]

Securing Web Services: Locking down your SOA

For the many benefits an SOA brings to an organization, like having the capability to mix and match services with many different providers and suppliers or granting access to data in a platform-independent manner, there are many implementation details that are often overlooked when dealing with service type architectures. Security is one area that can bring any SOA initiative to the ground if the corresponding due diligence is not made.

Security is among the top issues for many IT departments, but with SOA security takes on a whole new dimension. While the mixing and matching of services can open up a rich set of possibilities for business processes, it can also open up a Pandora's box if the underlying services do not enforce a stringent enough policy to deal with the many interactions they can possibly take part in.

On another front, with platform-independent access to data comes openness, but with openness also comes vulnerability. The same channel used by your business partners can easily be employed by rogue users if the necessary provisions are not made.

Security can be tackled at various levels on the SOA stack, namely through WS-*/SOAP specifications, by provisions offered in XML standards or at the network level.

If you have an existing application operating in the context of a SOA, tightening network-level security is perhaps the most straightforward and non-invasive manner to heighten security, since its does not require modification to the underlying application.

Many of the SOA network security strategies are along the same lines as many Web-based applications, which can include creating a VPN (virtual private network) for exclusive communication between client and server, making use of digital certificates to establish SSL(secure socket layer) protection or HTTPS, or deploying firewall infrastructure in either hardware or software mode to detect suspicious requests coming into a SOA.

Network security, or transport security as it is often called, can thwart many attacks, but it does not preclude someone sniffing or intercepting the data which forms part of an application. To this end, many specifications built around XML can be used to protect the actual payload used by applications.

XML Encryption and XML Signature are two standards developed by the W3C, both of which can be used to bring added security to XML-based data.

The former specification is used to transform raw XML data by means of a cipher in order for it to be transported in an obfuscated manner between requester and responder. Since the cipher is intended to be kept secret from any third parties, this guarantees that even if data interception occurs, the information will be extremely difficult to read since the cipher alters the original content.

XML signature, on the other hand, can be used to incorporate tampering detection of XML documents. By using an XML signature, a service provider can offer any service consumer -- or vice versa -- an unequivocal means of checking if the XML payload has been altered in any way or form from its original state.

You should be aware that both XML encryption and XML signature are applicable to any XML type document. This is important to realize because not only can they be used to lock down the payload exchanged between service requests, but they can also be used for such things as WSDL contracts, which are also XML-based and form an important part of an SOA.

Rounding off the approaches to securing a SOA we find the WS-* specifications related to security, which are strictly designed to be used in the SOAP payload being sent between services.

Given this fact, the use of WS-* security standards for safeguarding services requires a lengthier analysis and design phase since they are generally entrenched in the service logic itself, although they will obviously provide the more robust security solution for this same reason.

At the center of OASIS specifications pertaining to security we find WS-Security . WS-Security dictates the way in which security tokens can be exchanged between service requester and provider in order for the token to be later used for authentication purposes.

WS-Security provides support for various token types like Kerberos and X.509 certificates, mechanisms that are also used for other security issues beyond those of SOA. The important thing to realize about WS-Security is that its usage is bound to the header of the SOAP payload, as shown in listing 1.1

<?xml version='1.0' encoding='iso-8859-1'>
<s12:Envelope 
 xmlns:s12='http://www.w3c.org/2003/05/soap-envelope'
 xmlns:wsse='http://www.docs.oasis-open.org/wss/2004/01/
             oasis-200401-wss-wssecurity-secext-1.0.xsd'>
 <s12:Header>
   <wsse:Security>

      <!-- WS-Security Token Data/Description -->
   </wsse:Security>
 </s12:Header>
 <s12:Body>

 </s12:Body>
</s12:Envelope> 

As you can notice from the previous code snippet, the wsse namespace which corresponds to WS-Security is enclosed within the SOAP envelope and its within this namespace that token data is embedded according to the specification for later retrieval by service consumer and provider.

While WS-Security was among the first specifications for dealing with security issues directly in the SOAP payload, many other specifications that work in the same fashion -- of embedding information in a SOAP envelope -- have followed. Among them are WS-SecurityPolicy, WS-Trust and WS-SecureConversation, all of which provide different degrees of security functionalities aimed at tightening your SOA infrastructure.

With this we conclude our overview of approaches to securing your SOA. As you can see, some techniques require a more lengthy implementation process while others are more straightforward, but whatever road you decide to take, your SOA can ill afford to ignore them altogether.

Originally published April 2006 [ Publisher Link ]

Back to Article List