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 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.
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.
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.