Secure your SOA

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.

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.

WS-Policy defines a policy to be a collection of one or more policy assertions. Some assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (e.g., authentication scheme and transport protocol selection). Some assertions specify requirements and capabilities that have no wire manifestation, yet are critical to proper service selection and usage (e.g., privacy policy and quality-of-service characteristics). WS-Policy provides a single policy grammar to allow both kinds of assertions to be consistently considered.

Note that the new OASIS Web Services Secure Exchange (WS-SX) Technical Committee is the new OASIS working group for WS-Policy and other related standards.

The XML representation of a policy assertion is called a policy expression. Policy assertions are combined by using policy operators: All, ExactlyOne, OneOrMore, etc.

The following illustrates a simple example of a policy:

 
<policy Priority="200">
   <All>
      <Language Usage="Required" Language ="it" />
         <ExactlyOne>
            <SecurityToken TokenType="UsernameToken" Usage="Required">
               <Claims>
                  <Username>Claudio</Username>
                  <UsePassword/>
                </Claims>
            </SecurityToken>
            <SecurityToken TokenType="X509" Usage="Required">
               <Claims>
                  <SubjectName>Role=Student</SubjectName>
               </Claims>
            </SecurityToken>
         </ExactlyOne>
   </All>
</policy>

Other policy-related specifications are:

• Web Services Policy Assertions Language
• Web Services Security Policy Language
• Web Services Policy Attachment
• Policies for other technologies such as WS-Privacy, WS-Authorization, and WS-ReliableMessaging

For administration purposes, a policy repository is required. The administration tool should provide an interface for inserting, modifying, and removing policies. It should provide all the related policies to the requestor, and the policies should be realized through an XML database. A SAX (Simple API for XML) parser, which is fast and uses little memory, should parse the XML data.

WSS

WSS, developed by the Organization for the Advancement of Structured Information (OASIS) per the Web Services Security Technical Committee, defines a standard way of applying digital signatures and encryption to SOAP documents using XML security standards. WSS specifies how to protect SOAP messages as they pass over a network. It includes authentication, integrity protection, and confidentiality. It does not specify how to implement access control, but instead provides information that may be used for such control. WSS allows encryption to be applied selectively. For example, it allows application firewalls to inspect the unencrypted portion.

In addition, WSS allows more flexibility in infrastructure choices. It can not only utilize X.509 technology, but also Kerberos, SAML, or plain-old username and password. Since WSS operates at the SOAP layer, it can travel with the message throughout the network and even persist when the message is queued or stored.

WSS uses the XML-Signature Syntax and Processing and XML Encryption standards developed at the W3C. WSS operates by inserting an XML element called security into the SOAP header. The SOAP header contains all of the information about authentication, digital signatures, and encryption that have been applied to the message. It gives the receiver the information necessary to decrypt and validate the message. The keys and authorization information may be specified using X.509 certificates, Kerberos tickets, SAML assertions, or other methods.

An example of a SOAP envelope with <security> element is as follows:

 <S:Envelope>
<S:Header>
<wsse:Security S:mustUnderstand="1"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<wsse:BinarySecurityToken EncodingType="wsse:Base64Binary">
MIIDQTCC4ZzO7tIgerPlaid1q ... [truncated]
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
....XML Signature...
</ds:Signature>
</wsse:Security>
</S:Header>
<S:Body>
<m:OrderAircraft quantity="1" type="777" config="Atlantic"
xmlns:m="http://www.rdta.com/XMLDatabaseOrderSubmission"/>
</S:Body>
<S:Envelope>

Web Services Secure Conversation Language is another useful specification—it allows a session to be created between a Web service requester and a Web service, using symmetric keys. WS-SecureConversation is analogous to SSL, which also involves the negotiation of a symmetric key to streamline encrypted message transfer. WS-SecureConversation is available in Microsoft’s Web Services Enhancement 2.0 toolkit, but no Java implementation is available at present. WS-SecureConversation is now also part of WS-SX.

SAML

The XML Security Assertion Markup Language defines an XML vocabulary for sharing security assertions, including authentication and authorization assertions, enabling single sign-on and third-party management of these functions. It also defines a request/response protocol definition and an XML protocol (SOAP) binding. The SAML specification defines a general assertion framework, allowing assertions to be given validity time periods and allowing assertions to be targeted to specific audiences (avoiding the potential for misuse). Assertions are associated with a given “subject” or named entity.

SAML is a standard way of exchanging security and related data across heterogeneous, distributed systems crossing domain boundaries. Authorization and audit trail are familiar security services. In the past, most systems were designed under the assumptions that a single system would posses all of the information necessary to make access control decisions and all the data would be recorded in the audit trail. However, large-scale distributed systems are always built by multiple organizations with a mixture of products. Thus, users may be authenticated by different authorities using different methods. In addition, different authorities retain different information about user properties and attributes. Centralizing all capabilities and information is just not practical. SAML provides standard formats to express authentication and user attributes, and the protocols to request and receive.

The SAML specification defines:

• An XML vocabulary for expressing authentication and authorization assertions, allowing statements to be passed among parties about how and when authentication and authorization occurred.
• A request response protocol for conveying SAML assertions, as well as an XML protocol (SOAP) binding.
• Unique identifiers (URNs) for different authentication mechanisms and authorization actions.
• How digital signatures are associated with assertions.
• SAML Token Profile, which describes how SAML assertions are carried in and referenced from <wsse:security> headers, and how SAML assertions are used with XML-Signature Syntax and Processing to bind the statements of the assertions (e.g., the claims) to a SOAP message.

XACML

Although SAML provides a mechanism for making authentication and authorization assertions, and conveying these assertions using XML, a vocabulary is also required for expressing the rules needed to make authorization decisions. XML Access Control Markup Language was created specifically for expressing authorization rules.

XACML is a language for expressing access control policies; in other words, it protects content in data exchange. Access control lists (ACLs) lack the ability to express the complex policies often required in real-world systems. As a result, access control policies are often embedded into application code. This complicates the changing of policies or even discovering what policies are being enforced.

XACML is capable of using practically any available information to decide if access to a resource should be permitted. It can also associate additional actions, called obligations, with the decision—for example, requiring that the requested data be destroyed after a certain period.

XACML can base its decisions on a resource’s properties, including its content, or on environmental factors, such as date, time, or location. It may also take into account properties of the parties associated with the request, such as role or group membership. This might include not only the party making the request, but also the party receiving the data or intermediaries to the request.

As shown in Figure 2, a typical usage scenario of XACML is where a subject wants to take some action on a particular resource such as a filesystem or a Web server. That subject submits its query to the entity to protect the resource. This entity is called PEP (policy enforcement point). The PEP forms a request, using the XACML request language. The PEP then sends this request to a policy decision point (PDP), which examines the request, retrieves policies (written in the XACML policy language) applicable to this request, and determines whether access should be granted according to the XACML rules for evaluating policies. That answer (expressed in the XACML response language) returns to the PEP, which can then allow or deny access to the requester.

SOA security enabled by XQuery and XML databases

Security standards and secure documents are described using XML and the various XML markup languages discussed in this article. An XDMS is an ideal mechanism to persist and query both security policy documents and secure messages in an SOA. As mentioned earlier, XQuery can be used to extract information from XML documents. XQuery is basically a functional language that uses expressions as the central component to assemble queries. Each query can be described as a set of expressions, which may be nested. This main feature makes XQuery a flexible and well-rounded approach for manipulating XML data.

To effectively access or store XML documents, one needs an XDMS. An XDMS that supports XQuery can enable the retrieval of information from the XML security documents quickly and easily. XML databases have matured and readily provide XML content search and storage.

For example, an XDMS can maintain different versions of security policy documents, providing an audit trail for policy changes. Furthermore, XML security messages and requests can also be persisted, providing an audit trail of all security transactions in an SOA.

SOA security enabled by federated identity management

According to Jason Rouault and John Worral, authors of “Federated Identity Management Addresses E-Business Challenges”:

“a single organization cannot effectively manage or control an e-business initiative from beginning to end, especially when multiple partners are involved. Even within the enterprise, different business units often manage distinct sets of users and resources. That’s why organizations are turning to federated identity management to address their e-business challenges.”

Applying these ideas to our typical supply-chain use-case that involves many disparate applications collaborating with each other through Web services, we can see that without federated identity management, total chaos caused by unauthorized and untrusted access to the underlying SOA-enabled business processes would reign—thus defeating the very purpose of collaboration.

Federated identity standards such as SAML and alliances such as the Liberty Alliance form a wrapper around disparate systems and their respective security infrastructures, and enable them to interoperate, forming what is called a circle of trust. This is the first step towards developing business relationships across trading partners and business applications.

SOA governance

As SOA implementations scale and become more mature, governance becomes imperative to their success. SOA governance is the process of defining and enforcing organizational policies and standards. These policies are geared towards the business requirements of managing liabilities and dependencies, ensuring continuity of business operations and reducing costs. They also benefit the IT departments by defining controls for service proliferation within the enterprise, incorporating evolving standards and promoting interoperability.

Today, most organizations already have policies in place for all of the above. However, these may either be manually enforced or in disparate places across departments and applications. We need federated information and policy management as XML metadata that resides with the SOA artifacts to facilitate automatic enforcement, without manual intervention. This is the only way to guarantee fast, reliable, and consistent application of SOA policies within and across organizations.

Federated information management needs features for organizations to share and link information securely. Enterprises may need to maintain their own data repositories as well as a unified view of data that must be exchanged between trading partners. Federated policy management includes publishing, managing, discovering, and governing organizational policies. When multiple partners interact with each other, these policies must be linked and composed across enterprises.

The goal of SOA governance is to create an infrastructure that is robust and secure. This is not possible if you only provide policy enforcement at an XML registry level. The bulk of SOA artifacts created by your organization is in the documents you exchange with your trading partners. Hence, you must have fine-grained governance over this data to truly secure your enterprise. For this, you need an SOA repository, not just an XML registry.

An SOA repository should be the central point for governance of all your SOA artifacts. But imagine the vast amounts of XML SOA metadata that needs to be persisted with the SOA data. Only a fast and scalable SOA repository that provides querying and management of enterprise data would work for Federated Information and Policy Management. The most optimal way to achieve this is if the repository is powered by a native XDMS with XQuery to provide both speed as well as scalability to realize effective SOA governance.

As we noted earlier, XQuery is a flexible and powerful language for XML data retrieval and management. When this is coupled with a native XDMS, you have an elegant, high-performance option to the complex and sluggish middle-tier conversions of your XML data using the traditional parsing approach with an RDBMS (relational database management system) SOA artifacts store.

Conclusion

As we have seen throughout this article, XML plays an important role in describing the key security standards for SOA. Persisting XML data, including security and organizational policies and secure messages described in XML, should be handled by an XDMS. Though many XML and SOA security standards are still evolving, an XDMS enables the implementation of SOA security standards today and minimizes disruption as the standards evolve. For example, XQuery can be utilized in parsing and updating these XML security documents that are persisted and managed in an XDMS. Furthermore, an XDMS can handle any type of XML data without prior knowledge of the XML Schema structure. This powerful functionality proves highly advantageous when handling XML messages and security documents from federated systems with different security approaches. An XDMS can persist these diverse documents, and, along with XQuery, transform and map the various security standards.

Additionally, an XDMS offers the full power to manipulate, browse, search, integrate, and aggregate enterprise data in an SOA. Hence, an XDMS powered with XQuery provides compelling benefits to secure your SOA.

We would like to thank Ajay Ramachandran, vice president, enterprise applications group at Raining Data, for technically reviewing this article.