Menu
SOA Security: The Basics

SOA Security: The Basics

Diving into Service Oriented Architecture? Vordel's Mark O'Neill covers basic SOA security threats and defenses--and explains how security helps increase SOA's business benefits.

WS-Security

WS-Security is a newer technology which was standardized in 2004. It builds on what has come before. It defines how XML Encryption and XML Signature apply to SOAP, so that a SOAP message may be encrypted and/or signed. Additionally, it defines where passwords and X.509 Certificates are placed in a SOAP message, and how SOAP may operate with Kerberos. This allows for interoperability between different applications which use WS-Security.

Platforms such as Suns Glassfish and Microsofts .NET incorporate WS-Security. These allow processing of signed XML (using XML Signature with WS-Security), authentication (using passwords, Kerberos, or certificates), and encryption (XML Encryption with WS-Security).

XML Gateways

XML gateways provide security for SOA by providing security processing on the network, using hardware acceleration. The XML gateway applies security policies to the services in the SOA which it protects. It presents "virtual services" which sit in front of the actual Web Services themselves. These virtual services are accelerated, and may include transformation which occurs before the actual SOA services are called. For example, an XML gateway may present a REST interface in front of an actual SOAP Web Service. In this way, XML gateways often provide protocol mediation, transformation, and acceleration as well as security.

The future of SOA Security-to the Cloud

Once defined only in terms of internal application-to-application networking, SOA is now finding links with cloud computing. In many ways, the services offered by Amazon, Force.com, and Google are like a "global SOA". They provide many Web Services, generally accessed by REST and AJAX interfaces, which may be incorporated into applications.

The predominant approach is the "hybrid model", whereby services in a local SOA are augmented by services in "the Cloud". For example, a local application may already pull sales data from a database and then put it onto a TIBCO Rendezvous queue. However, it can be augmented by calling out to a Force.com service [Force.com is Salesforce.coms cloud service]. The data retrieved from Force.com may then be used to "enrich" the data before it is put onto the Rendezvous queue. Another example would be if a local application uses Amazons S3 Cloud service for storage.

In the hybrid model which links a local SOA with the cloud, it is important to ensure that no private data is sent up to the cloud. This can be achieved by selectively encrypting the data as it goes to the cloud service. Additionally, it is important that a network outage, or a failure of the Cloud service, does not unduly impact local applications. This can be achieved by using an XML gateway as a local "Cloud Broker" which controls the connection to the cloud from the local SOA.

Cloud services promise to add to the current usage of SOA, joining local SOAP and REST Web Services.

Mark O'Neill is CTO at Vordel, the XML network management company.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags SOA

More about Amazon Web ServicesCA TechnologiesetworkGatewayGoogleSDLUDDIVordel

Show Comments
[]