Tip

Using an XML security gateway in a service-oriented architecture

One of the main architectural advantages of the loosely coupled nature of service-oriented architectures (SOA) and Web services is the strict separation between the interface (the service's method of listening

    Requires Free Membership to View

    Login

on the network) and the implementation (the actual business logic). This presents the security architect with interesting options in deploying security for SOA and Web services.

Gunnar Peterson answers your questions

Join us for our live SOA and Web services security webcast with Gunnar Peterson on Wednesday, July 25th at 12:00 ET. Pre-register today!
For example, a SOAP Web service interface (say, GetAccountBalance) can be hosted as a proxy on an XML security gateway instead of the "real" endpoint that hosts the business logic implementation (like a Java Web service). In a nutshell, an XML security gateway is a specialized service that performs security policy enforcement, enabling decentralized security architectures.

The XML security gateway proxies communication to and from the Web service and performs security functions on behalf of the service endpoint. While the XML security gateway virtualizes the endpoint, the service requester thinks it is talking directly to the service provider. Instead, it communicates through the XML security gateway proxy.
Figure 1: Communication options in Web services

Any problem in computer science can be solved by adding a layer of indirection. The XML security gateway leverages the loosely coupled architectural approach inherent in SOA and Web services to provide specialty security services that may not be cost-effective to deploy on all endpoints directly.

Standards and SOA/Web services security
The interoperability required to enable a decentralized security architecture is made possible by standards. The service interfaces use common technologies and semantics, for example SOAP/XML messages and WSDL for service interface description. This allows the XML security gateway to "hide" or virtualize the ultimate endpoint. Security standards such as SAML, WS-Security, XML Signature, and XML Encryption allow the XML security gateway to provide robust security services that span business and technical domains.

Security as a service: Deploying security services in a XML security gateway
XML security gateways are able to provide a myriad of security services. One way to visualize your specific security architecture is by using architectural views that separate the concerns of what security services to deploy based on risk.

There are three main concerns in identity attributes as they relate to XML security gateways:

  • The ability to enforce policy regarding the identity of service requesters and service providers using identity standards like SAML.
  • The ability to map identity and attribute information: SOA and Web services are fundamentally about integration across business and technical domains. So a given transaction is likely to span multiple identity domains (like Active Directory, LDAP, and RACF). The XML security gateway can provide a central point to deploy the necessary identity mapping.
  • The XML security gateway must have an identity that it uses to vouch for the authenticity of any authorization claims regarding whether the security services have been performed.

For more information

See how XML gateways are gaining in popularity and contributing to SOA and Web services security. 

Senior Technology Editor Neil Roiter reveals how Web security gateways are keeping up with rising malware threats.
One of the main differences in securing SOA and Web services instead of standard Java or Visual Basic-style applications is the focus on message-level security. The message is the unifying construct in an SOA and Web services world, and as such, message security is critical. Since the services in SOA are loosely coupled, there is nothing to guarantee the validity or safety of the XML message that the service exchanges, so content validation must be performed to ensure that the message does not enable malicious activity like SQL injection, denial of service, malware or other malicious payloads.

Next steps
In terms of evaluating what type of XML security gateway to deploy, the available options and the granularity of services, the OWASP XML security gateway Evaluation Criteria Project provides some guidance. The project is made up of vendors and industry experts to help companies understand the role and utility of XML security gateways and how to get the most out of them.

About the author
Gunnar Peterson is managing principal and founder of Arctec Group (www.arctecgroup.net). Arctec is an enterprise architecture provider focused in enterprise software and security architecture. Arctec has consulted numerous global 500 companies, electronic financial exchanges and emerging startups. Peterson is primary author on several documents on the DHS Build Security In portal. Peterson leads the OWASP XML Security Gateway Evaluation Criteria project and is a frequent speaker at Black Hat, SANS, ISSA, OWASP and other industry conferences. He maintains a popular blog on information security at 1raindrop.typepad.com.

This was first published in July 2007

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top