Secure your SOA

Enterprise-grade SOAs require a plan for addressing diverse security needs

By Ash Parikh, Anthony Sangha and Murty Gurajada, JavaWorld.com, 04/10/06

Service-oriented architecture (SOA) is rapidly gaining adoption in enterprises world wide. Data and applications that were once silos are now being exposed as services across departments and organizations. This poses unique challenges of securing and governing data exchange. While security has traditionally been an IT domain, SOA governance encompasses the business domain by extending security to include organizational policies and practices. How do you mature your SOA to account for security and governance? What are the standards and specifications in XML security today, and how do they work with each other? What are the important considerations for SOA governance? How do you implement these in a scalable way without sacrificing performance and maintainability? This article attempts to answer these questions.

Let's examine a few applications of SOA. Consider supply chain management. You have scenarios of manufacturers, retailers, and consumers interacting with each other using numerous systems and applications, mostly over the Internet. An SOA is an ideal enabler of such loosely coupled interactions. An integral part of an enterprise-grade SOA is the application of security services and governance policies in the various layers of communication between trading partners.

When a customer places an order at a retailer's Website, it is readily apparent that the order transaction must be secure. However, there is more to it than meets the eye. The retailer's order fulfillment applications should involve interactions with inventory management systems. Once the order is ready to be shipped, the retailer interacts with a shipping trading partner, and the customer should be provided with services to monitor the order's status. Each of these interactions would need security implementation at the application layers and, generally, the transport protocol layer as well. Moreover, organizations must set up and manage various policies: Who owns the data? Who is responsible for its veracity? How do departments and trading partners share their data? This is what SOA governance is all about.

These interactions bring up requirements similar to a customer placing an order on a Website. Security must be enforced in several layers during the message exchanges between these two trading partners, and policies must be established to govern the services.

Another use-case is a manufacturer's product development lifecycle. This process may or may not involve external trading partners, but typically, a large manufacturer has several departments participating in the production of a single finished product. SOA delivers the benefits of reuse and agile development even in scenarios where the manufacturer is not involved with external partners; and, you guessed it, the same security and policy requirements manifest themselves here.

The security requirements common to these scenarios include:

Authentication: How do I know your identity is true?
Authorization: Are you allowed to perform this transaction?
Integrity: Is the data you sent the same as the data I received?
Signature: Create and verify an electronic signature analogous to a handwritten signature.
Confidentiality: Are we sure that nobody read the data you sent me?
Auditing: Record all transactions for verification after the fact.
Nonrepudiation: Both sender and receiver can legally prove to a third party (e.g., a judge) that the same data was sent and received in a transaction.

Other security requirements such as single sign-on (SSO) have become important due to the proliferation of silos of identity information across applications. Threat prevention has also evolved as another important security requirement for excluding bad data (spyware, malware, etc.).

This article details the standards and approaches necessary for incorporating the above mentioned security requirements into an SOA.

XML security standards and SOA

XML is a standards-based choice for representing the above requirements, thus XML security standards can be employed to enable them. XML security standards leverage existing XML standards and also enhance these standards as follows:

The XML security standards define XML vocabularies for representing security information, using XML technologies such as XML Schema for definition—for example, the <KeyInfo> element defined in the XML-Signature Syntax and Processing recommendation for carrying, signing, or encrypting key information.
The XML security standards use other existing XML standards where possible to leverage current XML efforts. For example, XML-Signature Syntax and Processing allows XPath expressions to extract portions of XML for processing. It is important to note that this type of selective signature processing was not really possible prior to the established XML security standards; either the entire document was signed or not at all. The XML security standards are designed to offer XML's flexibility and extensibility. They allow security to be applied to XML documents, to XML elements, and element content, as well as to arbitrary binary documents. They support the extension of XML vocabularies through the use of XML namespaces and extensible XML Schema definitions.
XML security technologies may be applied to end-to-end security, which is especially important when XML messages are routed through numerous processing intermediaries. Persistent security is associated with the content, rather than with a transport pipe. The security remains with the content. XML security technologies may be also used in conjunction with transport security technologies, such as Secure Sockets Layer and Transport Layer Security (SSL/TLS). Another point to note here is that identities designed for SSO capabilities travel with the message as well.
XML security technologies reuse existing cryptographic and security technologies whenever possible, without reinventing the wheel. For example, X.509 V3 certificates are used without redefinition when needed—they are simply encoded in a text format. Existing algorithms, such as the SHA1 digest algorithm, are also brought into the XML security standards world by associating unique URI identifiers with them and defining how they may be used in the XML security processing models. It is important to note that URI identifiers are used pervasively in XML security for encryption and signature algorithms as well, not just hashing.

The core XML security standards are:

XML Encryption
XML-Signature Syntax and Processing
Digital certificates
XML Key Management (XKMS)

XML Encryption, a World Wide Web Consortium (W3C) specification, provides end-to-end security for applications that require secure exchange of structured data. As we know, XML itself is the most popular technology for structuring data; therefore, XML-based encryption is the natural way to handle complex requirements for security in data interchange applications.

XML-Signature Syntax and Processing, a W3C recommendation, provides integrity, message authentication, and signer authentication services. XML signatures are digital signatures designed for use in XML transactions. The standard defines a schema for capturing the result of a digital signature operation applied to arbitrary (but often XML) data. Like non-XML-aware digital signatures (e.g., Public-Key Cryptography Standards, or PKCS), XML signatures add authentication, data integrity, and support for nonrepudiation to the data they sign. However, unlike non-XML-Signature Syntax and Processing standards, XML-Signature Syntax and Processing has been designed to both acknowledge and leverage the Internet and XML.

Digital certificates are electronic files that act like online passports. They are issued by a trusted third party, a certificate authority (CA), which verifies the identity of the certificate's holder.

XKMS, a W3C note, simplifies the securing of XML-based Internet transactions using public key infrastructure (PKI) and digital certificates. It specifies protocols for distributing and registering public keys suitable for use in conjunction with W3C's XML-Signature Syntax and Processing. XKMS is composed of two parts—the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).

As understood from the supply-chain use-case referenced earlier, accessing information over the Internet is essential to the solution. Web services allow such functionality as they permit the exchange of information over a network. Web services are based on three key standards:

SOAP (Simple Object Access Protocol), a protocol for data transmission
WSDL (Web Services Description Language), a language for the description of Web services
UDDI (Universal Description, Discovery, and Integration), a registry for locating a Web service

Note that all of the above can be defined in XML. However, two issues must be specifically addressed in our supply-chain solution:

Restricting access to XML-based Web services to authorized users. This is addressed by XACML (Extensible Access Control Markup Language) and WS-Policy standards.
Protecting the integrity and confidentiality of XML messages exchanged in a Web services environment. This is addressed by Web Services Security (WSS) and Security Assertion Markup Language (SAML).

This article provides a brief overview of WS-Policy, WSS, SAML, XACML, and how security is empowered by XQuery and XML databases. WSS provides message protection in a SOAP environment. SAML and XACML support authorization and offer considerable support for large-scale distributed systems. Most importantly, all these standards represent information using XML. WS-Policy, WSS, SAML, and XACML all have some commonalities. While all of these standards enable security services used in previous years, each has specific features intended to make them suitable for large-scale, distributed environments, such as the Internet. Additionally, these standards reference and incorporate preexisting security standards.

As previously mentioned, these standards use XML. XML enables technologies to be conveniently extended to meet special requirements in a way not possible using older formats. In addition, XML allows implementers to use the many software tools available for processing. In the case of WSS, it is designed to integrate closely with the syntax and processing model of SOAP, which is defined in XML.

Furthermore, XML is a markup language, capable of labeling the information content of diverse datasources, including structured and semi-structured documents, relational databases, and object repositories. With so much relevant data available in XML form, it becomes imperative that this data be queried and mined for further applicability. The query language that understands XML and can express queries across all forms of XML data, whether physically stored in XML or viewed as XML via middleware, is XQuery. XQuery is broadly applicable across many types of XML datasources.

The recommended practice for persisting XML data is to use a native XML database technology that treats XML not as another relational artifact, but as a natural XML artifact. XML database management servers (XDMSs) are enterprise-grade XML persistence mechanisms with all the bells and whistles that come with a traditional relational database. XDMSs that feature powerful XML indexing, profiling, and acceleration are a big plus.

WS-Policy

As shown in Figure 1, the Web Services Policy Framework provides a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities.

Figure 1. The Web Services Policy Framework stack

WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. WS-Policy defines a framework and a model for the expression of these properties as policies. Policy expressions allow for both simple declarative assertions as well as more sophisticated conditional assertions.

1 | 2 | 3 | 4 | 5 | Next >