Information Security Management Handbook, Sixth Edition (2012)

DOMAIN 6: SECURITY ARCHITECTURE AND DESIGN

Principles of Computer and Network Organizations, Architectures, and Designs

Chapter 22. Service-Oriented Architecture

Walter B. Williams

What Is a Service-Oriented Architecture?

To properly understand what a service-oriented architecture (SOA) is, it is helpful to understand where it sits as an architecture and the problem that an SOA tries to solve. An SOA, first, is a software architecture. Software architectures are the structures of software, their elements, and the relationship between them. SOA was developed by applying the concept of software architecture to solve the problem of how to connect disparate systems in a way that they could function together in a systematic manner.

Each application in an SOA is treated as if it can only perform one specialized function, or as if it were an element in the larger software. This specialized function is called a service. Thus, each service functions as an element of the SOA, where the structure and the defined relationship between the elements must transcend application and often corporate boundaries.

Distributed Computing and Services

SOAs are not the only approach to integrating disparate computer applications into a larger unified system. A message-oriented model (MOM) was developed with the idea of distributing the components of a system among existing and emerging applications and platforms. Messages were used to connect these systems, implemented through specialized platforms called message queues. Message queues are very reliable, but required not only a system to manage them, but also a staff to maintain the messaging system. Most importantly, support for the message queues had to be built into all the application components, restricting the implementation of a system built on an MOM architecture to the internal needs of a single corporate infrastructure.

An Architecture Based upon Services

As business realized that other companies applications provided a better solution to meet their requirements than their own internally developed systems, they realized that they could provide better products to their customers if they found a way to leverage the capabilities of other corporations expertise for components that were not part of the core competency of their own company.

As an example, a travel company might recognize that MapQuest’s maps (or Google Maps) were vastly superior to their own, and because their home-grown map application was not how they brought in new business, but still provided a desired component to their customers, it would benefit everyone if there was a way to leverage the capabilities of the other company’s superior product.

SOAs abstract the diverse applications, protocols, systems, and data into four key concepts:

Application front end

Service

Service repository

Service bus

An application front end is the owner of the business process the application provides and other services can use. A service is an implementation that provides business logic and data, and a service contract specifies functionality, usage, and constraints that must be observed by any client, and an interface exposes the functionality. A service repository stores the service contract of the individual services. A service bus interconnects the application front ends and the services.

There are various technologies that can be applied in the implementation of an SOA. Some of these are more appropriate for internal enterprise-specific projects, and others may be applied to any project with any scope. Precisely, because of the common architecture, there are issues that transcend the individual technologies that must be considered when establishing a security architecture appropriate for the protection of the business and its objectives as supported by the specific implementation of an SOA.

Process Integrity

Data integrity is a key factor in the success of many SOAs, as data is transferred from one service to another. However, the integrity of data is not sufficient to guarantee that the service returns the correct results due to the complexity of business processes that span multiple systems and often involve multiple corporations. Process integrity involves not only the integrity of the assets, but also their utility throughout the architecture.

The principles of entity, domain, and referential integrity are borrowed, where appropriate, from relational databases. Entity integrity requires that each row in a table be uniquely identified. Domain integrity requires that certain data be within a valid range (such as the date of purchase of an item not being in the future, or before the date of which the item was first placed on sale). Referential integrity refers to the validity of the relationship between different datasets, preserving as an example the names of the residents in relationship to their appropriate residence.

Where data must be processed across multiple systems through the use of their services, there is the risk of inconsistencies that impact the validity of both the data and the use of the data in all services. There might be technical failures, business exceptions, and special cases that impact the integrity of the process. Because the process is not centrally controlled, the impact of the failure of any particular component may be high.

There have been a number of techniques applied to solve this problem, each with their own merits and issues. The most common approach is to apply logging and tracing. This is similar to the use of transaction logs in a transactional system, allowing for recovery to a valid state in the event of a failure. The problem is that it is difficult for logging and tracing to resolve issues that relate to logical processes, which span the multiple systems involved in an SOA.

Online transaction processing systems were developed to enable large numbers of users to concurrently manipulate shared data. Such systems are based upon the concept of transactions on a unit of work that transforms data from one state to another. A unit of work is presumed to be atomic, or indivisible, consistent (move from one consistent state to another), in isolation where no process is visible to any other, and durable where committed updates are permanent. Such systems depend upon a central control mechanism that resolves conflicts. Such a central control mechanism is often unavailable to an SOA that leverages services from multiple organizations.

The Two-Phase Commit Protocol (2PC) was developed to allow online transactional processing to span multiple systems. A transaction coordinator is implemented as part of a transaction monitor. This enforces that in the first phase of the processing, all relevant locks have been acquired and that the state of the data has been properly captured. Depending upon the results of this examination, the transaction coordinator informs the participating systems if they should roll the transaction forward or backward. These systems “vote” on how to handle the data, a single abort vote will cause the entire transaction to be rolled back.

All of these mechanisms of tracking changes to data are predicated on some assumptions that often do not apply in an SOA. One is that it is possible to ensure the isolation to the data; another is that the transaction is short-term. Neither can be assumed in an SOA, where the various services may be entirely ignorant of access and use of data by other services, and transactions are often long-lived. SOAs are also often implemented on discontinuous networks, and none of the above mechanisms are designed to operate under such conditions.

Two techniques scale well to address the issues of process integrity. The first is that of persistent queues with transactional steps. Persistent queues, which follow the data, can guarantee consistency of the individual steps of the process, where errors are handled by a dequeue and the error is returned with the data. Such systems depend heavily upon the presence of a message queuing system and are more often implemented in internal SOAs where such systems are present.

The second is transactional chains and compensation. Complex workflows are created through individual process steps (transaction chains); where failures are dealt with through compensating transactions that logically undo a prior transaction. Each transaction is made visible to each service, so that data may be made available to a compensating control.

To permit these workflows to transcend the boundaries and controls of a single corporation, the Business Process Execution Language (BPEL) was developed. It is based upon Business Process Markup Language (BPML), an extension of XML as a formal meta language for modeling business processes, which provides an abstract execution model for describing collaborations and transactions. BPEL allows the capability to:

Describe the logic of business processes through composition of services

Compose larger processes from smaller processes

Handle synchronous and asynchronous operations

Invoke services in series or parallel

Selectively compensate completed activities in case of failure

Maintain interruptible long-term transactional systems

Resume interrupted and/or failed activities

Route incoming messages to the appropriate service

Correlate requests within and across business processes

Schedule activities based upon predefined times

Define order of execution

Handle both message- and time-related events.

With BPEL, business processes can be described in two distinct ways:

1. As executable business processes wherein the exact details of the process are defined and follow the orchestration paradigm

2. As abstract business processes or the public message exchange. These are not executable and follow the choreography paradigm.

In the orchestration paradigm, a central process, which can be another service, takes control and coordinates the execution of different operations in the services involved in the operation.

The Choreography paradigm does not rely upon a central process, but is a peer-based system where each service knows when to execute its operations and with what other services to interact.

Enterprise Service Bus

An enterprise service bus is the technical infrastructure of the distributed environment. It is composed of an XML-based communications protocol with a message-oriented middleware core to perform the actual message delivery. There are a variety of message bus frameworks in common use. Some, such as Enterprise Java Beans within the J2EE specification and Microsoft’s .Net, are based upon the capabilities of an application architecture. Others rely upon either message queues or object-oriented communications infrastructures such as Common Object Request Broker Architecture (CORBA). In practice, a successful Enterprise Service Bus is not a single product, no matter how flexible or how many communications protocols it supports, but one that supports accessing services on a meta level, which can leverage the capacities of all application architectures, allowing .Net, Enterprise Java Beans, and other diverse applications to function within a single business process.

Web Services and SOA, an Alternative Service Bus

Unlike an internal SOA, a Web services–based SOA cannot rely upon a single monolithic service bus. To this end, Web services are based upon slightly different principles than a traditional SOA. Each service needs to be reusable, stateless, autonomous, abstract, discoverable, and loosely coupled. Instead of a form service bus, you have a service integration layer, which operates as a logical or virtual service bus (Exhibit 22.1).

Services engage with this service integration layer and each other through a formal contract, which defines the terms of information exchanged and provides supplemental service description. Because services need to be discoverable, they make themselves known through a service provider. Services also need to know which service to call and thus will have a service requester. These roles can be and often will be reversed, as the role of the service changes within the larger workflow from the client to the server. There may be more than one service provider through which a workflow must pass before it arrives at its ultimate destination, and these are called intermediary services. Intermediary services may or may not do more than discover the next step in the workflow, depending upon the nature of the service and the contract it has as a service provider.

Exhibit 22.1 Web 2.0 and SOA (Web Services)

Web services tend to be broken down into one of a set of roles:

Utility service

Business service

Controller service

Proxy service

Wrapper service

Coordination service

Process service

The nature of the service offered, how to engage it, and the results to be expected are all defined in a specialized XML document present on the service provider. This document will be written in the Web Services Description Language (WSDL). The WSDL functions as the integrations layer of the Web service, providing the basis for other services to discover how to engage the particular service.

Some implementations of Web services will register themselves in a central registry of services using a specification called the Universal Description, Discovery, and Integration (UDDI). UDDI repositories provide a market place of generic services and are often hosted by major corporations.

Many protocols can be used and are used to communicate between the various Web services over TCP/IP. The most common is the Simple Object Access Protocol (SOAP). SOAP provides a standard message format that consists of an XML document capable of hosting RPC and document centric data. SOAP can be easily leveraged by both synchronous and asynchronous data exchange models. SOAP, as a raw protocol set, does not define a preset language, allowing the application designer to create a language specific to the architecture.

An alternative to SOAP-based Web services is the Representative State Transfer (ReST)-based Web services. ReST leverages the existing vocabulary of the Hypertext Transfer Protocol (HTTP) or other robust application layer protocols with existing vocabularies. SOAs based upon ReST are easier to implement, but less flexible.

With second-generation Web services, or Web 2.0, a limited vocabulary was developed to provide a common framework for common constructs that all business services rely upon, such as business process or workflow, security, reliability, policies, and attachments. These standards, managed by the Organization for the Advancement of Structured Information Standards (OASIS), are called the WS or Web Services standards. The most common of these protocols are defined next.

Web Services Description Language

WSDL, currently in its second revision, serves to define a Web service to service discoverers. It does this in two ways, one abstract and the other concrete. In the abstract, a WDSL will describe the messages the service sends and receives, typically using XML schema. It defines operations associating message exchange patterns with one or more messages. Message exchange patterns are the sequence and cardinality of the messages sent and received. At the concrete level, a WDSL will specify bindings of transport and wire format details for an interface and associate a network address with a binding.

Simple Object Access Protocol

SOAP is probably the most commonly used protocol within an SOA because of its versatility. It has a very simple structure to it, being composed of an envelope, a header, and a body as shown in Exhibit 22.2.

The envelope is a construct that defines the overall framework for interpreting a SOAP message, in essence defining the vocabulary, who should deal with it in whole or part, and what parts, if any, are mandatory.

The header carries a representation of a resource that is needed to process the SOAP message, but that cannot be obtained through the URI for the resource carried within the message.

The header and the envelope allow SOAP to provide a flexible and custom workflow implementation for the SOA. However, this flexibility comes at a cost of lower performance as each SOAP message must be parsed so that the vocabulary may be learnt and its instructions followed appropriately by the service.

Exhibit 22.2 SOAP Structure

Representative State Transfer

ReST is used by SOAs where performance considerations outweigh flexibility and security. ReST depends upon six fundamental architectural assumptions in the use of HTTP and other protocols:

Clients are separated from the servers by a uniform interface, with the clients remaining unconcerned with data storage and the servers unconcerned with a user interface. This preserves the portability of the clients and the scalability of the servers.

No client information is stored on the server between requests, providing a stateless environment. The server can be stateful, as needed, providing reliability and scalability.

Clients may cache information from the servers and reuse it in preference to fresh data from the servers.

Clients cannot determine if they are connected directly to the terminal service provider, or to an intermediary service provider, allowing scalability and load balancing.

Clients can have their code extended on a temporary basis by the servers. Examples include JavaScript run within a browser or Java applets.

Clients and servers have a uniform interface consisting of identification of resources, usually through URI, manipulations of these resources, self-descriptive messages, most often through MIME types, and the use of hypermedia as the engine of application state.

Distributed Component Object Model

Distributed Component Object Model (DCOM) is a set of remote procedural call libraries designed for the Microsoft Windows operating system (OS). DCOM is often used within an enterprise-specific SOA and is an alternative to SOAP or ReST.

Common Object Request Broker Architecture

CORBA is a platform agnostic method of remote procedural calls with predefined mappings into many common languages designed to allow different applications written in different languages to interchange instructions and data. CORBA is often used within an enterprise-specific SOA and is an alternative to SOAP or ReST.

Data Distribution Service

Data Distribution Service (DDS) was developed to provide a mechanism to distribute data in a publish/subscribe model. It is an alternative to SOAP or ReST, but is rarely used in modern implementations.

Windows Communication Framework

Windows Communication Framework (WCF) is a Microsoft-specific technology designed for building Web services using Microsoft products. Until recently, Microsoft technology did not support key Web services technologies such as Security Assertion Markup Language (SAML) and relied upon WCF to provide proprietary alternatives. It is a replacement for DCOM and is an alternative to SOAP and ReST.

WS-Coordination

A defined set of instructions to coordinate the behavior of various Web services within the SOA. It is used to maintain process integrity and functionality. WS-Coordination can manage any of the protocols typically used to call services and provide them with the required information.

WS-Transaction

A defined set of instructions to handle atomic (individual) transactions and business transactions for long-term operations. WS-Transaction is an alternative to BPEL.

BPEL for Web Services

BPEL as such has been a very successful language for defining workflow in SOA specific to enterprises. BPEL-WS (also written WS-BPEL) is just an extension of BPEL for Web services.

WS-Security

WS-Security is a suite of standards that provide the security layer of a Web 2.0 SOA. The Suite consists of WS-Policy, SAML, XML Signature, and XML Encryption; though WS-Trust, WS-Authorization, WS-SecureConversation, and WS-Privacy also exist, they are less common. SeeExhibit 22.3.

Exhibit 22.3 WS-Security Sack

Security Assertion Markup Language

SAML provides the authentication service for Web services–based SOA. It is not mandatory and not supported by all platforms and vendors. There are major compatibility issues between the different versions of SAML, where products that support SAML 2.0 will not likely also support SAML 1.1. SAML is commonly used to extend trust boundaries, allowing for federated identity. SAML assertions will contain information necessary to provide both authentication and authorization.

.Net Passport

.Net Passport is a Microsoft propriety alternative to SAML, which was not supported in Microsoft products until recently.

XML Encryption

XML Encryption provides XML with the structure to encrypt the whole of a separate XML document, part of an XML document, or the attachment to an XML document. The most common tags are:

EncryptedData

EncryptedData Schema

EncryptedType

EncryptionMethod

EncryptionProperties, which likely will contain CipherData, CipherValue, and/or CipherReference

KeyInfo

EncryptedKey

ReferenceList (where multiple items have been encrypted with the same key)

XML Digital Signature

Provides the use of digital signatures in the signing of the whole, part, or attachments to XML documents. XML Digital Signatures can leverage certificates issued by a public key infrastructure.

WS-Policy

WS-Policy is often considered to be a component of WS-Security, as it is used to communicate the security policy of the Web service much like the WSDL is used to communicate the rules of engagement for the service. Like the WSDL, it defines those rules that must be followed and those that are optional, but in a hierarchical manner wherein some or all of the child objects must be satisfied to comply with the defined policy.

Attacking SOAs

Despite very impressive security controls to guarantee the integrity of data, the utility of process, and the confidentiality and availability of information, there are numerous ways to successfully attack even the best-protected Web service.

Many Web services are not authenticated properly; often authorization is not checked after authentication. Most importantly, the service logic itself may be used in ways that the developers never intended.

To footprint a Web service, you often have to go no further than the UDDI and the WSDL. The UDDI will provide the location of the specific service, and the WSDL provides, in unprotected detail, how to engage the service. WSDL can often be discovered by simply appending “?wsdl” to the end of a URL. You look in the WSDL for open methods and resources that are unprotected. Service tags, easily found with a <service.*?> regex pattern, define the name of the service and how to engage it.

Once the Web service is understood, it can be attacked. If .Net is used, vulnerabilities associated with that platform may appear. Same with J2EE or ReST. Often, because the XML in the SOAP packets can be encrypted, the transport between the services is not protected with SSL/TLS. The SOAP packets can be intercepted with a sniffer, and those values not encrypted can be readily replaced. Also, if the encrypted components are not properly digitally signed, then the entire encrypted section of the SOAP message may be replaced by the one that matches the requirements of the WSDL exactly.

As many Web services are developed to respond to XPATH queries, one can manipulate XPATH to transverse through any XML document in search of key information.

If the Web service is using DOM, the DOM parser will read the entire XML into memory before processing. One can overload a DOM processor using complex XML structures and large envelopes. Once the DOM processor is overloaded, it is often possible to run arbitrary code or take down the service entirely.

Another technique that can be used to elevate privileges is to poison the XML with SAX parsing. One can place a tag inside the logic of another tag and overwrite data without authorization. As an example:

If later in the same XML, the following is written, the Privileges will be overwritten to become 1:

Just as in URL manipulation, the parameters of a SOAP packet can be tampered with if they are not signed. Metacharacters can be injected into the parameters and break the services logic. Where data in the XML is not signed, one can often cause a denial of service within a service provider by mistyping the data expected in a tag.

Just as with any Web application, SQL injection and LDAP injection may reveal information in services exposed to the architecture but not designed to provide the information you request through the injection attack. If the underlying database or directory service does not properly check authorization, price lists, account information, and even password hashes and x509v3, private keys may be provided.

When Web services leverage file systems and the underlying OS, the SOAP packets can manipulate the Web service to providing file data or executing code in the context of the account under which the Web service is running.

In the absence of proper account lockout policies, Web services accounts can be brute forced by using a SOAP message that contains account after account. Proper logging can record this, but may not alert you to the attack unless the log is monitored.

Web services messages can have their sessions hijacked when the session is maintained with either cookies or information in the SOAP header.

Tools exist to assist in attacking Web services. WS-Knight, WS-Audit, Crowbar, and, of course, the many proxy-based tools used in attacking a Web application all serve to simplify the steps needed to compromise a Web service.

Defending SOAs

Fortunately, Web services have many excellent and robust controls that can be applied to diligently and proactively protect the service, data, and business process.

There are three layers to defend: the service container, the service, and the messages between the services.

SSL/TLS provides excellent and well-understood transport layer security, which can easily be deployed in a Web service. Unfortunately, if the WS-Routing protocols are used in the Web services, SSL/TLS will not work.

In the absence of SSL/TLS, or even while using an encrypted transport, XML Encryption and XML Signature can be leveraged to sign and encrypt data within the SOAP packets. XML Signature contains four major items, though two of the four are optional.

1. Pointers to the object to be signed

2. The actual signature

3. They key (or means to discover the key) (optional)

4. Options tag (optional)

The item to be signed can be internal to the XML document itself, can be an attachment, such as a binary object, or can be another XML document. There are three classifications of XML signatures:

1. Enveloping

2. Enveloped

3. Detached

Enveloping signatures wrap the data that is being signed within the tags. Enveloped signatures refer to a parent XML element through a reference contained within the tag. Detached signatures obviously refer to objects external to the XML, which are signed.

XML encryption works much like that of SSL/TLS where the recipient’s public key is used to encrypt the symmetric key used to actually encrypt and decrypt the message. Upon receipt, the private key is then used to decrypt the encryption key, which is then used to decrypt the encrypted portion of the XML. This is both the strength and weakness of XML encryption. The data confidentiality is maintained, but unless the portion of the XML containing the XML encryption is signed, it is a trivial thing to replace the encrypted data with other encrypted data, and because a public key is known (being public), the recipient will be able to decrypt the substituted strongly encrypted data and process the related workflows.

Depending upon the service, it may not be advisable to expose it to the entire Internet. Access control at the IP address level can provide a measure of assurance. Although IP addresses can be spoofed, the permitted IP address has to be known in advance by the attacker. In the absence of that information, even the normally unprotected WSDL file will be unavailable.

To provide for both authentication and the basis of authorization, all Web services support multiple authentication frameworks. One that is unique to Web services and provides support for distributed administration is SAML. SAML allows company A to provide authorization to accounts created and maintained by company B, and a mechanism for services providing those accounts to be made available to the members of company A without having to provide company A with the passwords of their members or customers.

As with every application, the Web service must be configured to handle errors and exceptions gracefully so that no information regarding the technical details of the error are passed to the service caller, but are logged so that support staff can debug and resolve the issue.

Auditing SOAs

The auditing of an SOA will involve inspecting the WSDL and WS-Policy for each service to make certain that only those functions desired for the workflow can be called; that all services, which provide sensitive functionality or operate on data which remain confidential, require authentication; that data is encrypted; and that encrypted data is signed. The auditor must also verify that authentication and authorization are logged by the service and that logs can record who did what, when, and with what authority.

Because the SOA is a complex multiplatform cross-enterprise unity of capabilities in the service of business objectives, properly auditing any SOA for compliance with internal or external standards will take time and diligence. However, no shortcuts should be taken as a flaw caught in an audit may prevent the business from compromise by a criminal who found a service without authentication or sensitive data that remained unencrypted.

About the Author

Walter B. Williams has over 25 years of experience in information technology, over 12 of which have been in information security. He has designed and implemented successful PKI, metadirectories, and the security layer of SOA-based E-commerce solutions. He helped create the risk management program at multiple enterprises in various business sectors and has served as the chief security officer of a start-up in the identity theft prevention industry. He has sat on the board of the New England chapter of the ISSA, where he remains an active member. He currently manages security and compliance for a Massachusetts-based hospitality service provider. Walter holds the SSCP, CEH, CPT, and CISSP certifications.

References

Chappell, D. Enterprise Service Bus. O’Reilly Media, Sebastopol, CA, 2004.

Erl, T. Service-Oriented Architecture, a Field Guide to Integrating XML and Web Services. Prentice Hall, Upper Saddle River, NJ, 2004.

Juric, M. Business Process Execution Language for Web Services. Packt Publishing, Burmingham, 2006.

Krafzig, D., Banke, K., and Slama, D. Enterprise SOA, Service-Oriented Architecture Best Practices. Prentice Hall, Upper Saddle River, NJ, 2005.

Shreeraj, S. Hacking Web Services. Charles River Media, Boston, MA, 2007.

Rosenberg, J. and Remy, D. Securing Web Services with WS-Security. SAMS Publishing, Indianapolis, IN, 2004.