Motivation to SOA and Security

SOA Security in Action

by Ramaro Kanneganti and Prasad Chodavarapu

Unedited Draft Chapter 1

Copyright 2006 Manning Publications

For more information on this and other Manning titles go to

www.manning.com

http://www.manning.com/

1

1 Introducing SOA Security Imagine buying a DVD online. As you check out your shopping cart, you make sure that the little lock on your browser is “on” to indicate that your communications with the merchant are over a secure channel. You submit your credit card information to the merchant so that he can in turn submit the same to the credit card company. From then on, it is a mystery to you as to who gets access to the information you submitted. Will the merchant misuse the credit card information you gave him? If the merchant uses another agency to integrate with the credit card company, can that agency misuse your information1?

Or, say you visit a hospital. The hospital’s workflow application needs to do quite a few activities on your behalf. It may collect your medical history from other hospitals, verify coverage with your health insurance provider, and submit prescriptions for pick up from your neighborhood’s pharmacy. Each of these activities may be accomplished by different applications. How does the hospital’s workflow application prove to these applications that it indeed has your permission to carry out these activities?

Both these examples have certain common elements. They both involve multiple applications coming together to provide a “higher level” service than what each of them can provide by themselves to the users. A merchant’s online shopping application is integrating with a credit card firm’s application to help you make purchases online. A workflow application is integrating multiple applications to carry out a business process. We can clearly see from these two examples that the possibilities for security breaches are much higher when multiple applications come together to provide a service than when a single application takes care of all needs. In other words, integration of applications makes security design more complex than it would otherwise be.

Integration of applications is not new; there have been many technologies and approaches used for integration. Service Oriented Architecture (SOA) is the latest approach that vendors, enterprises2, and developers are adopting for integration. More accurately, SOA is a new approach to organizing IT capabilities that makes widespread integration of IT applications easier and cheaper than before. Consequently, SOA Security is lot more complex than traditional IT application security.

But unlike other integration technologies that pre-dated it, SOA is positioned well to tackle security challenges in integration. By its own nature and by being standards-based, SOA allows new techniques that can help solve the age old problem of integration security to a greater degree than before. However, these techniques are not yet known widely enough to practitioners of SOA. Even though most practitioners understand that SOA introduces new security challenges, they are often not very clear on how to address those challenges. This lack of clarity usually results in one of two situations. Either the SOA implementation errs too much on the side of caution and loses the benefits of easy and open integration SOA could otherwise have brought about, or, it ends up with security loopholes waiting to be exploited. Obviously, both of these situations are undesirable and this book helps you to avoid those mistakes.

1 In fact, this exact scenario happened. In 2005, a large credit card processing company that stands in the middle of vendors and the credit card companies was storing credit card numbers for analysis even though it is not supposed to keep them for more than 15 minutes. That storage system was compromised exposing millions of credit card numbers to thieves. You are right to be paranoid about security – in fact, it pays to be paranoid. 2 By enterprise, we refer to any organization, or collection of organizations with a common set of goals with substantial investment into IT.

Please post comments or corrections to the Author Online forum at www.manning.com/kanneganti

http://www.manning-sandbox.com/forum.jspa?forumID=264

2

In this opening chapter, we will tell you why SOA Security needs a different approach than traditional application security and what new techniques characterize the approach needed. We will first introduce you to basic security issues in IT and highlight how they get complicated in integration scenarios. Then, we will introduce SOA as a technology for integration. In that section, we will briefly cover the basics of SOA and how we can use it for integration. Finally, we will describe how SOA can solve the security issues in integration and describes the techniques it enables. In fact, the rest of the book is focused on these techniques – including standards, implementation choices, and the sample code. We will also mention if and how current generation SOA products are supporting the techniques described here.

1.1 Basic issues in application security Consider the applications that you use on your personal computer. There are some applications that do not have any security safe guards built into them. For example, when you use a calculator application, there are no security measures you make use of. On the other hand, there are applications that manage your personal data. These are typically secured using passwords. For example, when you use an email application to check your email account, typically you are asked to provide a username and a password before you are allowed to access your messages. There are still other applications that use lot more security safeguards. Your operating system does not allow you to replace a system file unless you have system administration privileges. Your web browser encrypts all the messages you exchange with your bank’s web server. As you can see, the word ‘security’ is not uni-dimensional; there are multiple aspects we refer to when we talk of security in IT.

Security management in IT can be broadly classified into network security, platform security and application security. Of these, the first two have little to no relationship with SOA Security conceptually3. Hence, the issues we introduce in this section are limited to the ones needed in application security. In this section, we will briefly discuss the security issues that an application should address. Of course, not all applications need to take care of all these issues. Typically, any application that is available to multiple users as a shared resource has to address at least a few of these issues. A web application catering to different users with different privileges is a good example you can consider when trying to understand each of the security issues described below.

1.1.1 Verifying identity of users Applications need to verify that only legitimate users are trying to use them. The burden of proving identity rests with the users. Users may prove their identity in multiple ways, each with their own pros and cons.

1. Users may present one or more secrets that the service expects them to know. For example, users may present username and password that they previously registered with. Alternatively, users may have to respond to a challenge question that can be only be answered correctly by those who know the secret.

2. Users may prove that they are indeed in possession of something the service expects them to have. For example, the service may challenge the user to present a number currently being displayed on a RSA token she should possess.

3. Users may present proof of who they are by presenting biometric evidence such as a digitized finger print or retina scan.

3 In practice, the difference between network security and application security is getting blurred with the network starting to take on some of the security tasks traditionally handled by applications. We will discuss more about this in chapter 8 when we introduce Application-oriented Networking (AON).



3

The process of verifying identity of users is referred to as “authentication” in security literature. We shall use the term to mean precisely the same through out the book.

1.1.2 Granting access to users Once a user is authenticated, the application needs to determine if the identified user is allowed to access the functionality he is requesting. The decision to grant access may depend on multiple criteria such as the action that is being requested, the resource on which the action is being requested, the groups to which the user belongs to and the roles that the user plays. For example, the super user or the administrator may access all the files in a system, but the user belonging to HR group can access only those files that are allowed for that group. The process of making this determination is referred to as “authorization” in security literature and we shall refer to it in that way through out the book.

Novice engineers often use the term “authorization” when they mean “authentication” and vice-versa. It is critical to not make this mistake as both refer to quite different aspects of security. You may remember it this way: Authentication establishes who you are. Authorization determines what you are allowed to do. Your photo id may establish who you are. Your age and local laws may determine whether you can legally take a drink.

1.1.3 Keeping data confidential with Encryption Data exchanged over the network as well as data stored by applications needs to be safeguarded from prying eyes. There are applications that can sniff out the packets that go over the wire. Using these applications, rogue users can gain access to data that we are exchanging with legitimate users.

The standard technique to keep data confidential is encryption. Without encryption, web commerce would never have succeeded as it would have been unsafe to transmit credit card information on the wire. The encrypted data can be understood only by the intended party and nobody else.

1.1.4 Guaranteeing data integrity and Non-repudiation Keeping the data confidential is not sufficient. When the receiver gets a message, neither the sender nor the receiver should be able to repudiate it – that is deny the authenticity of the message. As you can see, there are two aspects to non-repudiation: from the perspective of the senders and the receivers.

Suppose you authorized withdrawal of certain amount from your bank account for purchases at an online merchant. How can you be sure that the merchant or even the bank did not modify the amount in your authorization?

Looking at the aspect of data integrity from a recipient’s point of view, how can you protect yourself as a merchant against customers that falsely report fraud claims against you? As a recipient of a sensitive email, how can you be sure that the message was indeed sent by the person whose address appears in the mail headers?

These concerns can only be addressed by techniques that guarantee integrity of data in transit. “Digital Signature” is a common mechanism to guarantee data integrity, which we will discuss in Part II of this book.

1.1.5 Thwarting common attack strategies Quite a few common attack strategies are identified and named in security literature. Not all of them can be addressed within the scope of this book. For example, attacks that seek to take advantage of fatal bugs such as “buffer overflows” in application code or attacks that effectively cause a “Denial of Service” (DOS) to legitimate users by bombarding a service with invalid requests cannot be completely avoided using the techniques described in this book. However, the risk posed by them can definitely be mitigated by adopting appropriate security architectures and deployment strategies described in Part III of this book.



4

There are a few other security threats that are common. For example, suppose you sent a message authorizing the recipient to withdraw a certain amount of money from the bank. Can someone else other than the recipient pose as the recipient and intercept your messages? How do you prevent the recipient herself from submitting the message multiple times to withdraw more money than you intended to authorize? The techniques described in this book can take care of such “man in the middle” and “replay” attacks.

1.1.6 Guarding Privacy Service providers are often obligated to guard the privacy of users by law or by business policy. First let us understand what we mean by privacy. According to law, privacy places restrictions on disclosure of personal information to others. There are two aspects to it from application perspective. One is that of information kept in the applications and how it is dispensed. The other is about how services themselves expose the personal information of the users.

Let us consider the first aspect. We often hear about breaches in security exposing user information kept in applications and databases to unauthorized people. These can be several reasons for these breaches. Some of the security issues such as buffer overflow happen to be in the implementation of applications, which we are not going to discuss in this book. Other issues, mostly concerned with application design are discussed at length in this book.

The second aspect of privacy is about how applications divulge information on users. For example, consider the simple scenario of identifying the sender of a message. Even if we disable all possible ways of linking a message to a sender, we might still be not doing enough. If user identity can be narrowed down to a small enough set in anyway, user’s anonymity is clearly diluted. For example, if it can be gathered from multiple messages that their sender is living in a particular town, is working for a particular bank, is a security guard and works on night shift during weekends, the user’s identity can be narrowed down very quickly to a small set.

In this book, we will not be able to pay much attention the second aspect of privacy. Privacy protection is too specialized a topic to be thoroughly discussed within the scope of this book. Of course, as we mentioned earlier, one aspect of privacy can be addressed by the security choices we outline in this book.

All these security issues are well understood. There are several excellent books that describe how to address them. You can find reusable code, libraries, and frameworks to help you to implement solutions. However, all of them typically deal with security of single applications (by which we mean standalone as well as n-tier distributed applications) or two-party interactions such as a client-server interaction. When we are designing a system in which multiple applications are brought together (to execute business processes, for example), most of those books, code, libraries, and frameworks do not help as much. To understand why, we will introduce application integration in the next section and discuss the security issues in that context. What you will see that integration, which is a necessity in large enterprises, makes security issues lot more complex than single application or point to point interactions.

1.2 Integration complicates security Before proceeding further, let us understand what integration means. Integration is the act of bringing together data and/or capabilities from two or more independent applications, within the same enterprise or across multiple enterprises. For example, in a brokerage firm, there may be two different systems, one keeping track of savings account and another investment account. If we need to devise an application that



5

provides a unified view of the information, or transferring money from one account into another, we need to integrate two applications.

The level of integration between applications could be different. Not all applications can be cleanly be integrated. Consider the scenario of the investment account where money can be transferred from one fund to another. If we want to integrate with another application, that reports all the monetary activities, we would need the internal transfer information.

Of course, easy way of integrating is to rewrite the applications, which is not a choice most of the times. Instead, we use several different techniques to integrate the applications. Here are a few:

• File transfer (most commonly used in EDI – a very popular B2B integration standard) • Point-to-point message exchange: over synchronous transport protocols such as HTTP (as in AS2

– a B2B integration protocol) or asynchronous transports such as Message Queues (MQ) • Multicast messaging using a publish-subscribe protocol (such as TIBCO RV) • Distributed computing using Remote procedure calls (RPC), Microsoft DCOM or CORBA For full details on the history of integration, please refer to the appendix A. Integration comes with several challenges: it is costly; it can be error prone; it can be inflexible;

above all – it can be a security nightmare. Despite all those headaches, we still have to integrate applications. Large companies are able to

realize good ROI when applications are integrated across the enterprises. For example, automobile companies integrate their supply chain with their suppliers to reduce the inventory sizes. Even within an enterprise, integration is highly valuable.

There is a reason why integration is a must in any large enterprise. Even though we are building more technically complex applications than before, any enterprise still has several applications serving its needs. For example, a manufacturing facility may have an enterprise application managing personnel, another dealing with supply chain, and yet another providing business analytics. To build each of these applications, it takes deep understanding of the domain and cumulative experience of the users. Thus, corporations are forced to use diverse applications, often from different vendors.

In summary, commerce grows with integration. Integration brings forth new possibilities and business opportunities. Integration enhances convenience for customers and drives down business costs. Integration allows for incremental solutions that leverage existing applications. It lets us build best of breed systems. All these benefits come at additional complexities, one of which is security.

Complexity of security issues that can arise with integration is itself not very well understood. Consider the example of a web portal such as My Yahoo or an enterprise web portal you may have used at work. A web portal collates information from multiple applications and hence, is a good example of integration in action. When you login into a portal, how does the portal application pass on your credentials to each of the applications from which it needs to pull your data? In the simple case, all of the applications portal integrates with may be using the exact same password store to authenticate users. In a more complex case, each application may rely on its own password store. How do we deal with such complexity?

In fact there are several such issues with security in application integration. To understand all those, let us study a few real or near real world examples. In the next two sub-sections, we present two such examples. Subsequently, we will return to the basic security issues we discussed in the previous section and discuss how they become complex in integration scenarios.

1.2.1 Stock Brokerage Example Most of us are familiar with the way stock brokerage firms work. They may have different kind of clients: individuals, corporations, financial institutions, and smaller brokerages. They have different kind of



6

partners: financial institutions, other brokerage firms, and government. They have policy requirements: auditing, taxation, privacy, and financial requirements.

Let us introduce such a firm, say ACME brokerage firm, described in the abstract picture as shown in figure 1.1 to understand its operations from an IT integration perspective.

Figure 1.1 Integration needs of a large Stock Brokerage: Diverse customer segments are served by a variety of front-ends and interfaces, trades are executed on multiple exchanges, financial settlements happen in banks/clearing houses and activities are reported to regulatory authorities.

An interesting aspect to note is that different clients use different interfaces: • Individual investors need to be served through a front-end application that is customized

to their needs. • Corporations require a different front-end application that helps them hedge their assets. • Institutional clients require facilities to integrate their back-end systems with those of the

brokerage. • Smaller brokerages need provisions to integrate their own front-end applications with the

back-end systems of the large brokerage. Therefore, the brokerage firm has to offer the services that interoperate with many different

technologies. We will come back to this concept of services later on; for the present, just think of them as the functionality that needs be offered to the other applications and users.

To complicate the picture, the brokerage is also a consumer of services. For example, it may integrate with banks and clearing houses to allow investors tie their banking and brokerage accounts. Or, it may get market data to let the traders make decisions. Thus, it needs to consume services built on different platforms using diverse technologies.

All these tasks -- serving clients, working with partners and service providers -- are carried out by multiple applications inside the brokerage house. There may be CICS applications running on main frame



7

systems or client/server systems serving other brokerage firms and corporations. There may be web based systems for end users.

Since all these applications need to operate in unison using the same data, participating in the same workflows, and supporting the same regulatory practices, we expect them to be integrated. What kind of security requirements does such integration require? Let us enumerate a few:

1. We expect the user to login only once to use any of the brokerage services. 2. Once the user submits his order to buy a certain number of shares, we expect that the brokerage

firm can use that authorization only once. 3. We expect to support any third party (such as a smaller brokerage) to login on behalf of the user

and make use of the services of the brokerage, only to the extent that user wishes. 4. Corporate customers expect the brokerage to look for appropriate authorizations before carrying

out transactions on behalf of corporations. 5. We expect that transactions exceeding a certain limit are reported to a central agency as may be

required by laws. 6. We expect the brokerage to not divulge our information to other parties in a manner that allows

misuse of it. Some of these concerns are specific to integrated systems. If the system is a monolithic application,

they would have disappeared. For example, we can expect the user to login only once if there is only one application. While it is possible to have a monolithic application serving the brokerage house, we cannot expect it to run its partner systems also. Therefore, integration of multiple applications is a real need in this system.

1.2.2 Supply Chain Management Example: RFID Solutions Let us see another example of an integration scenario with complex security needs. This time, we pick an example from Supply Chain Management (SCM).

SCM is all about keeping track of goods as they are produced, stored, moved and consumed. Keeping track of goods is about to become a whole lot easier with the adoption of Radio Frequency Identification (RFID) technology. We can place an RFID chip in each object in the warehouse. This chip can contain, among other things, an Electronic Product Codes (EPC), which uniquely identifies the object. Unlike a barcode reader that can only read barcodes placed in its line of sight, a RFID reader can read all RFID tags within its range. That is, we can walk around the warehouse and identify all the objects in the containers, without having to open them.

For example, if all the printed copies of this book bore a RFID tag, RFID readers in a book store can not only detect that printed copies of "SOA Security in Action" are in stock but can also detect which particular copies are moving in and out of store. This capability of course leads to very interesting possibilities (including privacy concerns). We will focus here on how integration can help maximize the return on investment into RFID/EPC technology and how new security needs arise from integration.

Supply Chain Management applications used by manufacturers, warehousers, transporters, distributors, retailers and enterprise customers manage the mechanics of storing and moving goods. With the adoption of RFID technology, applications belonging to each of these parties will capture event data in different portions of an item's life history as the item, identified by its EPC, passes through the supply chain, as shown in Figure 1.2. In most cases, no one organization or no one application within an organization may hold all the information on what happened to an EPC. However, if we manage to integrate these event histories captured by multiple applications in multiple organizations, we can answer important questions like:



8

Do the medicines in the case a drug store received from a distributor belong to a defective batch? This case of meat is tainted. Where has it been and which other food products crossed paths with

it?4 Where is my bag that I checked in at Bangalore as I flew to San Francisco, via Singapore and Hong

Kong? Is an out of stock item in one store available from some other store in the same city?

Figure 1.2: As an item, identified by its EPC, passes through the supply chain, applications in each enterprise capture event data in their local EPCIS (EPC Information services) repositories. An enterprise may directly or indirectly enter into relationships with others allowing them to query and take advantage of data captured in its EPCIS repositories. Only two parties - Manufacturer and Retailer – are shown in this figure. Many more parties such as warehousers, transporters and distributors may be part of a supply chain.

Here is the complexity in answering these questions: you have to interact with every application that

came in contact with the object. Imagine the complexity of interacting with so many applications! In addition to such complexity, the following security concerns are to be addressed by any system that integrates these applications5. These concerns come up mostly because we are integrating applications from different companies that cannot trust one another.

How can each application identify the users? An application may only have information on users belonging to direct partners. How would it then identify users from other players in the supply chain? For example, a manufacturer’s application may only know about distributors and may know nothing about most retailers.

How can each application determine the permissions to grant to a user? Can an application provide access to information on a particular EPC without violating the privacy

of the final purchaser?

4 Source: EPC Information Service – Data model and Queries, Mark Harrison, Auto-ID Centre, University of Cambridge 5 Once we introduce SOA in the next section, you will see that this example is tailor made for SOA based integration.



9

As this example shows, integration is allowing businesses to enter into dynamic and complex relationships that traditional application-level security models cannot handle. Security techniques you will learn in this book will come in very handy in devising secure integration.

Now that we presented a few examples of application integration, we can see how the security issues become more complex compared to single applications.

1.2.3 Security issues in integration In the previous section, we looked at two examples: stock brokerage integration and RFID integration. We also posed some questions about the security for each of those scenarios. Let us classify them into the same categories as the ones in the section 1.1.

Authentication Consider the case of ACME stock brokerage company. Individual investors that are directly placing orders with it need to identify themselves, possibly with a username and password combination. Corporate customers might need multiple "signatures" authorizing their orders. Smaller brokerages that wish to route orders from their customers to the larger brokerage need to some how prove that the orders are emanating from their customers. They may do so by attaching signed "assertions" about the identity of their customers placing the order. Institutional clients need signatures on their orders as well.

Consider the other example with RFID. Here, applications need to serve users about whom they may not have prior information. In this scenario, no single application has access to all the username and password information.

What these scenarios point to is that there are several different kinds of authentication systems possible within the enterprise. If we are building authentication for one application, we can keep the username and password within the local store and manage user logins. We can even implement more fancy authentication schemes based on technologies such as digital certificates. However, if we want to share the same user credentials with other applications, we have to make sure that the credentials are available to those applications. If we make that data available, especially to applications that do not belong to the same enterprise, how can we make sure that data is not abused?

Authorization In a single application, the authentication and authorization are essentially one single step, though engineering practices may make them into different modules. That is, the application can determine who should have access to which resource. However, in an integration scenario, the user authentication can be separate from authorization. This situation calls for keeping authorization information separate, available for all applications. What complicates this decision is that there may not be a uniform model for authorization. In a single enterprise, we may force users into groups and assign rights to groups. As groups proliferate, it can lead to a manageability problem. In a multi-enterprise integration example like in RFID, we may not be able to do even that.

Ultimately, the complexity is in mapping the permissions in one system to permissions in another system. This issue comes up because we are integrating multiple applications.

Data Confidentiality In point to point communication, the technology for guaranteeing data confidentiality is well known. This is not the case when multiple parties/applications are involved in message exchange; different parts of a message may be intended for different recipients. For example, as shown in figure 1.7, part of a request to use bank funds for an order is intended for the bank but is forwarded via the brokerage. Thus, that



10

information itself needs to be guarded from everyone else except the bank. That includes the brokerage that is forwarding the funds withdrawal request.

If there is only one sender and one receiver, these problems are easily solved. If the message is potentially touched by many applications, that need to act on the message, we must some how ensure that the right party sees the right part of the message. These scenarios are common in integration of applications.

Data Integrity and Non-repudiation In a two party situation, where there is only one sender and one receiver, we can meet data integrity and non-repudiation requirements using digital signatures. A receiver can make sure that the message was not tampered with along the way by checking the sender’s signature in the message. The receiver can also prove that nobody else other than the signing sender could have sent the message.

The situation gets complex when there are several senders and receivers. As the message goes through multiple applications, each of them may add some information to the message. They need to vouch for only that part of the information. While technically it is not difficult, it can be difficult to manage without clear standards. Applications will have to clearly understand who is signing what part of the message.

Privacy If we have only a sender and a receiver, the threat to privacy of the involved parties can only come from the sender or the receiver. As long as the message exchanges is done on a secure channel and the receiver takes good care of the information provided by the sender, privacy of the sender is somewhat easy to guard.

When there are several senders and receivers, the threat to privacy can come from anywhere. Each system can contain some information about the particular investor, which by itself is not a threat to his privacy. When we add up all these pieces of information, it can reveal more information than it is supposed to by law. These legal restrictions may impose constraints on how we can integrate applications. Technically, it is difficult to model privacy requirements in a complex integration scenario.

Man-in-the-middle and Replay Attack If we have one sender and one receiver, the only possibility of man-in-the-middle is somebody who is listening over the wire. By suitable encryption at transport level, we can avoid giving away any information on the message to such attacker. To prevent message replay, we can resort to several techniques, including timestamps, message sequence numbers and so on.

When integrating multiple applications, any application can play man-in-the-middle role. That is, potentially, one of the applications in the integration can be the attacker. Since that application has access to the message, it can replay the attack easily enough, unless we take extra precaution. Thus, the need for protecting from untrusted applications makes defending against man-in-the middle attacks difficult.

Manageability and Traceability There are some issues which are easy to manage if there is no integration involved. Manageability of security is one such issue. How does integration complicate manageability? Read on.

To be sure, any security management is difficult. If there are several applications in the enterprise, managing user names and passwords can be a nightmare. Even when all the applications use centralized directory6 for username and passwords, managing security policy can be complex. How do we make sure 6 A Directory server is what enterprises use to manage information on all users, machines and other resources. For the purpose of our discussion here, you can think of it as a database server that manages user accounts and related



11

who can play which role in an application? How do we keep track of the role changes for a person? How do we take care of it when corporations merge?

These questions become even more complex with integration. In integration, applications will have to deal with not only end users, but also other applications and its end users. As more and more applications participate in integration, potentially, applications may not have much idea of which user they are dealing with. Any changes in either an application, or user directories, may cause wide repercussions, which are difficult to understand. Thus, any manageability solution must cope with this kind of complexity.

In addition to manageability, the other issue often comes up in integration is traceability. Since a message can go through several applications, for regulatory purposes, we may have to keep an audit trail. In addition, to tune and manage the applications, we may have to trace the data and actions to their full path through the systems.

Integration and Security: What is the solution? From what you have seen, you would be right to conclude security in integration is difficult to take care of. You can even ask how technology and vendors addressed these issues.

Until quite recently, integration technologies did not attempt to address security comprehensively. Often, they resorted to an add-on solution like using transport layer security, or adding a limited form of security. One notable exception is CORBA, which addressed security extensively, without much adoption in the market. As per the vendors, since there was no widely accepted standard to build the solutions against, their offerings are incomplete, proprietary, and did not interoperate with wide variety of applications.

With wide adoption of SOA all that is about to change. SOA, a technology that has many uses, is a leading solution for integration these days. SOA brings several standards to make integration easier. In particular, there are standards that address specific security issues we were describing here. There are several reasons why these standards are poised to succeed:

These standards are concrete enough to provide support for most common scenarios. These standards leave enough options for enterprises to build upon the standards. If an enterprise

has specific security needs that are not supported by the standard, they can extend the standard to suit their need. The fact that there is a standardized way of extending a standard speaks well for the longevity of a standard.

The standards make it possible for implementations to state what part of the standard they implement. That means, we can build interoperable solutions that gracefully degrade when they encounter other solutions that have limited support for standards.

The standards support innovations by vendors, by wisely leaving out actual end user solutions out of the standard. For example, security standards do not specify how they should be built and operated. They only provide details on how applications should communicate with others about security.

In the next section, we will study SOA as an integration technology. Since SOA is a vast subject, we will necessarily provide an abbreviated look. If you are familiar with SOA, the next section will provide you with an overview. If you are not familiar with SOA, we urge you to refer to the references to familiarize yourself with SOA more than what we attempt here.

credentials. Lightweight Directory Access Protocol (LDAP) is a protocol that most applications use to integrate with a directory server. Examples: Microsoft Active Directory Server, iPlanet Directory Server, OpenLDAP Server.



12

1.3 SOA as Integration Technology This book is about security in Service-oriented Architecture (SOA). The fact that you are reading this book indicates that you have at least some familiarity with the ideas behind SOA. Still, we will formally introduce SOA in this section for the sake of completeness and for making sure that all of our readers have a base common understanding of SOA.

Understanding SOA from a non-technical perspective A significant percentage of technical people we meet seem not too sure that they fully understand the idea of SOA. They understand the technical details; yet there still seems more to learn to fully appreciate how businesses see SOA. Knowing different perspectives on SOA may help you get into the right mindset when attempting to understand SOA. The following are some of points to remember when reading about SOA.

• Ideas behind SOA are easier to appreciate if one can see that IT is not able to support change at the pace business needs to move. Market conditions change overnight creating new business opportunities that did not exist until then. Businesses need to quickly change their business models if they are to tap into such opportunities but alas, the IT systems of a business cannot change fast enough. Where existing systems are sufficient to support a change in business model, artificial barriers such as platform differences and technical complexities raise their ugly head, slowing down the rate at which customers can be acquired. These are the kinds of issues SOA seeks to address. However, a majority of technical people do not usually get to experience these issues first hand and hence, have difficulty seeing SOA as anything more than hype.

• Technical people tend to look for concrete information. This makes them very liable to confuse the abstract concept of SOA with concrete technologies such as Web services or SOAP. (We will introduce Web Services and SOAP later on in this chapter.)

• Principles of SOA can be applied at various levels. For example, at the infrastructure level, administrators may create horizontal services that address common concerns such as security. At the application level, developers may expose back-end capabilities as services that multiple front-ends can consume. At the enterprise level, integrators may bring together the capabilities of multiple low-level services as a higher-level service that manages a business process. Technical people who get to apply SOA at only one of these levels are hence liable to acquire a not so well-rounded understanding of SOA.

In summary, it is important for you to think from different points of view to appreciate the ideas behind SOA. This includes: Business leaders, IT administrators, application developers and integrators.

Technically, SOA can be useful for solving several different technical problems. For some people it can be a better way of developing applications, freeing them from dependency on the platform. For some others, it can be a better way to organize their applications along the lines of services, leaving the end user applications to be developed as per the local needs. For others, it can be way to offer applications that can make use of the best of the breed systems.

If we use SOA to develop single applications, then the security challenges are exactly the ones you face in developing those single stand-alone applications. One of the main purposes of SOA is integrate applications. As you have seen in the previous section, integration complicates security, no matter what technology we use. Since we are studying the security issues in SOA, we are going to study SOA as an integration technology in this section.



13

1.3.1 Basics of SOA We should first tell you that SOA is an abstract idea and not a concrete technology, strictly speaking. The easiest way to understand SOA for a software developer is to compare it with Object-oriented Programming (OOP).

OOP principles helped us figure out the best ways to structure the internals of a single software application. SOA helps us figure out the best ways to expose the capabilities of software applications to other applications that have the need for those capabilities.

The motivations behind the adoption of OOP were to deal with real-world complexity and enhance code reuse within a single application. The motivations behind SOA are to allow software to become as agile as business requires it and enhance reuse across application boundaries.

In other words, what OOP did for development of single applications, SOA seeks to do the same across application boundaries. What works within a single application is not the same as what works across applications. So, SOA is of course not the same as OOP. They are different approaches to different problems. Let’s formally state the problems SOA seeks to solve.

Problem: Application and Technology boundaries Traditionally, IT assets of an enterprise have been organized and managed along application boundaries. There are quite a few downsides, from technical as well as business points of view, to such an organization. For example:

By not being organized along the same lines as business, IT slows down the pace at which business can change. Business changes often require modifications in multiple applications and as each application may be managed by a separate team, a lot of negotiation is needed for making a change.

Similarly, it is difficult to create Service Level Agreements (SLA) and enforce them when separate teams are managing the applications involved.

Bringing together the capabilities of multiple applications is expensive as integrators need to understand the unique way in which each application exposes its capabilities. Differences in hardware platforms, operating systems, and runtime environments also increase the cost of integration.

Reuse is low too as it is not easy for an application to rely on the capabilities of another, in the absence of a uniform way of doing so.

When exposing capabilities to outsiders such as customers and partners, an enterprise needs to dedicate substantial time and energy of its resources to help outsiders understand details of the applications they are integrating with. This added burden reduces the scope for widespread integration with partners and customers.

Enterprises could however not do away with application-centric IT organization as the technology required to blur out application boundaries was not deployed widely enough. Application integration – be it via distributed computing technologies like RPC, COM and CORBA – or, be it via messaging as in EAI (Enterprise Application Integration) and B2B – was too expensive to attempt on a large scale. The dawn of Web services (introduced a little later in this chapter) and subsequently, the conception of SOA changed this scenario.

Solution: Service-orientation of software and infrastructure SOA envisages a new way of organizing and utilizing IT assets such as software and infrastructure.

SOA looks upon IT assets as a collection of units named services. Services, if defined correctly, possess desirable attributes that come in handy in overcoming the drawbacks of organizing IT along application boundaries. Some of these attributes are as follows:



14

A service is defined at the right level of granularity, from the point of view of a service consumer. In other words, convenience of the consumer drives the service definition. If this means that the service needs to bring together capabilities from multiple applications, so be it. Or, if this means that an application must be broken up to offer each of its capabilities separately, that is Ok too.

A service is self-describing. Potential consumers of the service can learn by themselves how to invoke the service. Service description should include service interface, wire format, transport, location, policies and SLAs.

A service is technology-agnostic. Potential consumers of a service are not constrained from using the service because of mismatch in hardware or software platforms. In other words, an ideal service “interoperates” with every possible consumer.

A service is discoverable. Consumers looking for a service can discover the presence of the service, usually, by looking up a service registry (a la yellow pages in a phone directory).

A service can be composed with other services to create a higher-level service. A service is context-independent. That is, it is usable irrespective of what the caller did before

invoking the service. This characteristic allows the service composition. A service is stateless, making it easy for service providers and service consumers to create and

consume services, respectively. Observe how SOA is seeking to break down application and technological boundaries by setting the

expectation that these boundaries should not matter when defining or consuming services. Also see how SOA is seeking to maximize reuse and reduce the cost of integration by insisting that services be discoverable and self-describing. Given that SOA depends heavily on the attributes of a service, a lot of attention needs to be paid to service definitions. Otherwise, the vision and benefits of SOA may not be fully realized. It is important that services be defined by those who understand SOA as well as the business domain.

Business Benefits of SOA Well defined services can give businesses an edge over competitors. For example, if a business aligns its high level service definitions with its core business capabilities (the core functions a business is set up to do), then responding to changing market needs should be easier than before. This is because core capabilities of a business do not change very often; what may change often are how a business combines its core capabilities to support the business offerings it wants to take to the market. That means, new applications can be built easily that combine the core capabilities in the ways that the market needs. They can be offered over novel channels – desktop, web, mobile phone, and any new platform that comes along. As shown in figure 1.3, if a business is successful in aligning its high-level service definitions with its core capabilities, then the changes needed to support new business offering should be as simple as composing services as needed.



15

Figure 1.3: By aligning service definitions with core business capabilities that seldom change, IT can enable business to quickly respond to changing customer needs. Core capabilities of a business can be innovatively combined to better meet the needs of the market.

Further, SOA adoption by itself can generate new business opportunities. Consider a telecom

company that is exposing its capabilities in the form of services. The services offered by the telecom firm may allow potential partners and customers to order new accounts, choose service plans, check usage and billing information, and file support requests. Can you see how the telecom firm’s business can grow by virtue of these services?

Say, you are a real estate business looking to rent out office space to other businesses. You can now bundle the services offered by the telecom firm with your existing business offering (namely, office space) to create a more attractive offering to your potential clients. You can now not only provision all the telecom services your clients need but can now integrate any support services you have in your offering with the support services offered by the telecom firm. For example, the renters of your office space can go to the same web page or call the same customer service agent to report problems with the space you rented out as well as the telecom services you provisioned. What is in this for the telecom company? It can now attract more partners to sell its services; better yet, as the telecom firm’s services are discoverable, self-describing and technology agnostic, the telecom firm does not have to hand-hold its partners in order for the latter to integrate the telecom firm’s IT applications. Threfore the telecom firm can partner with a large number of small partners – something it could not attempt before given the cost of integrating each of the partners with its IT systems. This is what we mean when we say SOA enables cheap integration on a large scale.

The hypothetical example we just discussed is in fact a real possibility today. Sprint, a large telecom services provider in US, publishes its web services openly at http://webservices.sprint.com/. Are we not living in exciting times?

Technical benefits of SOA SOA makes sense from a technology perspective too. SOA makes possible a lot of technical goals that could not be implemented previously. We list a few of these below.

SOA enables for the first time, solutions that can truly claim to transcend platform differences. Previous to the advent of SOA, creating a solution that transcended platform and other technology boundaries was an expensive proposition. Thanks to SOA’s insistence that technology boundaries should not matter, the effort needed to create solutions that can interoperate with almost everything else is much lesser.


http://webservices.sprint.com


16

SOA allows technology vendors to create products that have much wider range of applicability than before. Vendors can create products that make development, testing, deployment and management of services easy.

We will see later in this chapter that SOA allows new approaches that help tackle the complexities of security enforcement in integration scenarios. For example, security vendors can now offer solutions or devices that manage security of services.

Although the idea of SOA, in the form we are discussing here, may have been understood and acted upon by seasoned architects much before the acronym SOA got popular, the technology and tools needed to make the vision possible have only been evolving for a few years now.

Of all the approaches to realizing SOA, use of “Web Services” is currently the most popular one for various reasons. The essential ingredients in web services, namely, WSDL and SOAP form the underpinnings of the security solutions we will show in the later chapters. Hence, it is important to see how they work. In the next section, we will describe web services, and how they help develop Service Oriented Architectures.

1.3.2 Web Services: Leading Approach to SOA The web provides a uniform model of interaction between users and applications. Buying a book, making a reservation, finding driving directions, checking weather forecast, reading news – no matter what the activity is, users know what to expect and quickly learn to interact with any web application for fun and profit. The power of a uniform and universal interaction model is apparent to everyone who uses the web.

What if applications can similarly know what to expect when interacting with other applications? Can applications learn, just like humans do, with the benefit of a uniform interaction model, how to use the capabilities offered by the other applications? What if differences in platforms, languages and business process context no longer matter just as in user-application interaction over the web? It sounds like a dream, but technically it is made possible through Web Services.

What are Web Services? This term has become too colloquial to have a formal definition. We will start with a working definition and examine the popular usage to identify defining characteristics of web services. We will do this exercise to understand the practical import of the term, particularly in the context of integration.

In practice, a web service can be defined as any software offering that can be described using the Web Services Description Language (WSDL). A Web Service can use WSDL to unambiguously specify what operations it provides and how they can be invoked using one or more protocols and data formats. Any WSDL-aware application can hence learn how to invoke a web service. There is a companion standard awkwardly called UDDI (Universal Description, Discovery, and Integration) that provides for discovery of services and retrieval of their WSDL descriptions. Together, these standards let applications discover and use web services.

Once an application obtains WSDL for a service, how does it invoke the described service? Frameworks such as Apache Web Services Invocation Framework (WSIF) let applications invoke web services without bothering about the details of service locations, data formats, and protocols. These frameworks are capable of figuring out all these details from WSDL at run-time, providing loosely-coupled integration between service consumers and service providers.

There are three aspects of service invocation that a framework must figure out: format, protocol and the location. First, let us turn our attention to formats and protocols. The most popular data format and protocol in use for web services are XML and SOAP, respectively. What is special about XML and SOAP? Can one use any format and protocol? While the quick answer is “yes”, there are special reasons why XML and SOAP are the most popular. In Chapter 2, we will describe XML and SOAP to the



17

level needed for following the rest of the book. For the present, let us observe at a high level why these are the primary vehicles for web services.

EXtensible Markup Language (XML) provides the needed “plain-text” like messaging format for integration. Unlike plain text format, XML carries enough structure in the message that applications find useful. For example, we can easily transform the structure, extract elements, and validate messages, with standard libraries. We will learn more about these facets of XML in the later chapters. First, let us see why XML is a popular choice for web services:

1. XML innovated to just the right extent. It provided a standard data structure that can accommodate the needs of most data exchanges. Room was left open for further standardization within each usage domain. Even without such standardization, XML was readily usable, making the early adoption possible.

2. There are several standard tools and technologies to support XML. For example, the technology for transforming one XML representation is standardized as XML Stylesheet Language for Transformation (XSLT). Several open source implementations in different languages (for example Expat in C, Xerces in Java) support XML processing. These factors led to XML being accepted instantly as the lowest common denominator format for data representation.

Suffice to say that XML has become the lingua franca of applications and protocols. Now, let us look at the protocol of choice: SOAP. SOAP dictates how applications interact by

exchanging messages packaged in particular ways. There was a precursor to SOAP named XML-RPC, which used XML for supporting RPC. SOAP evolved shortly afterwards, supporting RPC as well as document exchanges. What makes SOAP successful?

1. Despite the origins in HTTP, SOAP is transport protocol independent. For example, it works well with JMS supporting EAI applications.

2. More importantly, SOAP supports mechanisms for extending itself. These mechanisms allow SOAP to be extended for meeting additional such as security. If an extension proves successful, it can be made a standard. Thus, SOAP supports innovation by vendors and standards bodies.

There are of course alternatives for XML and SOAP that are technically capable of providing web services. The most popular among these alternatives is REST, described as a callout in this section. In our book, we are going to focus on SOAP based web services exclusively, as they are the most popular ones.

REpresentational State Transfer (REST) Can the Web itself be used as an integration platform instead of discovering additional protocols such as SOAP? To answer this question, we need to pay more attention to what we mean by the “Web”. At a superficial level, we can think of the Web simply as Hypertext Transfer Protocol (HTTP) and Hypertext Markup Language (HTML). Can these technologies form the basis of a standard for distributed computing and message based integration? It appears that they can provide the inspiration for those standards without actually being the right candidates. HTML is not a suitable information vehicle for application integration since it was designed for human consumption. That is, the HTML markup does not denote any semantic significance that is required in application integration. However, the use of a text markup language as a representation format is an idea clearly inspired by the success of HTML. HTTP does provide a popular application level transport protocol; however, it need not be the only choice for integration. There are advantages in taking advantage of the infrastructure built for HTTP. For example, quite a few industrial strength load balancing solutions exist for HTTP based applications. As such, it makes a popular choice for the integration infrastructure. At a deeper level, the Web is really about Identifying, Representing and Interacting with Resources. Uniform Resource Identifiers (URI) help uniquely identify a resource. Standard and



18

open data formats are used to represent a resource view. Standard and open protocols are used to interact with the resource. If we review our web browsing experience with the benefit of these abstractions, we can abstract a web application as a state machine that changes from one state to another by requesting and receiving a particular representation of a resource. Such a view of the web’s architecture is referred to commonly by the term, REpresentational State Transfer (REST). Given that the Web is already in place, can’t we use REST as the architecture for integration? HTTP verbs such as GET, POST, PUT and DELETE can be considered as services that resources offer over the Web. Representation of a resource can of course vary based on the need. If a service needs to be offered for use by programs, a XML based representation can be chosen and if humans need to invoke a service, a HTML based representation can be chosen. Does this not offer a faster, easier path to realizing the vision of Web Services? This question is frequently posed and debated intensely in the technology blogosphere. The fact however remains that influential technology vendors such as Microsoft and IBM have invested on SOAP being the foundation for “Web Services”. Given that almost all investment in the integration space is currently focused on developing SOAP-centric solutions, it is quite likely REST will be embraced only in a limited way to expose existing web applications as web services. WSDL already provides explicit specifications on how web service interfaces can be bound to HTTP GET and POST protocols. So, REST has limited applicability for us SOA practitioners, judging by the current trends. Hence, we will not focus on REST in this book.

Form the description in this section, you can see that SOA can be implemented in many ways. Figure 1.4 depicts the many possibilities. We already described SOAP based services and RESTful services earlier in this section. There are other kinds of services that can be defined using WSDL. For example, EJBs and database queries can be exposed as services described using WSDL and invoked using frameworks such as WSIF. Still there are other services that are not described using WSDL. That is, technically they have all the defining characteristics of services, expect that they are not described using WSDL.

Figure 1.4 SOA can be implemented in many ways. Web services make up the biggest chunk of the SOA pie but other kinds of services are possible as well. SOAP and REST are the two most popular protocols for web services but legacy services that can be described by WSDL can be thought of as web services as well.

Let us briefly recap what you have learned about SOA so far: In SOA, services become fundamental building blocks in the organization of IT capabilities within

an enterprise. Services, by definition, possess characteristics that make IT capabilities more reusable than ever

before. If aligned correctly with business capabilities, services can help enterprises overcome the obstacles

put forth by technology and application boundaries to change in business models. Currently, most enterprises are implementing Services as SOAP based Web Services.



19

As stated before, security challenges in SOA arise primarily from its use as in integration. In the next section, we will see how SOA facilitates integration.

1.3.3 Integration with SOA SOA introduces a consistent strategy for integrating two or more applications. Before SOA, the strategy to use for integration of two applications varied based on the applications involved. Some applications were easier to integrate using file sharing while others were easier to integrate with messaging. Some others allowed integration via distributed computing technologies such as DCOM and CORBA. Application-specific integration strategies lead to tightly-coupled integrations. If one of the integrated applications is modified or replaced by another, the existing integration strategy may have to be modified too. SOA solves this problem by introducing a technology-agnostic strategy for integration between applications, as shown in figure 1.5.

Figure 1.5: Before the advent of SOA, the strategy to use for application to application integration varied based on the technology involved. SOA introduced a consistent strategy for integrating applications, irrespective of the technologies involved.



20

By insisting that services should be discoverable and self-describing, SOA allows for loosely coupled integration. An application wishing to invoke a service can dynamically retrieve a description of the service and use that description to learn how to invoke the service. This strategy builds-in insurance against changes in one or more applications that enable a service.

SOA helps integration in another way. As services are also defined to be context-independent, low-level services can be integrated or composed, with each other to create higher level services as illustrated in figure 1.6. This is precisely the idea behind Business Process Execution Language (BPEL), a technology that underlies the integration offerings of leading vendors such as BEA, Oracle and Microsoft.

Figure 1.6: Lower level services can be integrated or composed to create composite services

How well does SOA support integration? In fact, most vendors are supporting SOA based integration.

They take an evolutionary approach from their existing products to make SOA possible. They use their application servers or message buses or process orchestrators to make support SOA, specifically, through web services. This web-services based SOA, through standards, brings several benefits to integration as compared to older technologies:

Table 1.2 SOA approach to solving the challenges in Integration Integration Challenge Description Language/Platform dependency Since web services are based on plain text protocols, they are easy to implement in any

language and platform. In fact, working implementations exist on almost all popular languages and platforms. Moreover, all these implementations strive to interoperate well and succeed largely.

Data inconsistency Like EAI, we can use messages to synchronize the applications. Since those applications that have the necessary data can offer the related functionality as services, the need for hoarding data locally diminishes.

Poor performance Unlike binary formats, XML can be verbose for two reasons: it is in plain text, and in addition, it has the markup text. Thus, web services still suffer from poor performance. However, there are a few reasons why it may not be such a problem. Since all XML documents have a standard structure, it is possible to achieve hardware acceleration for common tasks such as parsing and transformation. In addition, since SOA offers the tools to do the right kind of design, it is possible that the overall number of messages required may decrease, even if the message size increases. In the final analysis though, the ease of working may be more important than raw performance, and it is possible to achieve adequate performance using web services.

Lack of robustness To design robust solutions, we need to handle exceptions. SOAP addresses the issue of exceptional handling by standardizing on the way fault messages are transmitted back to the caller. More effort is still being put in dealing with nested exceptions as they relate to transactions.



21

Lack of knowledgeable people The basic technology underpinnings of web services are common place enough that several people understand them. Software vendors are also supporting web services by exporting the functionality of their applications as web services. While a solution that makes use of these services may require domain-level understanding of the application, the technology does not require any special training.

Fragmented state of tools and methodologies

Since these technologies have been standardized and are easy enough to implement, good open source implementations are available. In addition, several old tools can be retrofitted to be useful to deal with these technologies. The methodologies are continuing to evolve to bring uniformity in service definitions. However, retrofitting should be done with care taking into account of performance, granularity of the services, handling of failures, and roll backs.

Security, trust and privacy We will discuss this in the next section

So far, we have learnt the following: There are several standard security issues in single applications,

which are well understood. Irrespective of the technology used, integration complicates these security issues. SOA is increasingly becoming the technology of choice for integrating diverse applications in an enterprise. Therefore, all the security issues that are present in integration are sure to be present in SOA as well. Thankfully, SOA does bring support of standards to address these challenges of security in integration. We will study that topic in the next section.

1.4 SOA allows new techniques in Integration Security We have started this chapter describing how integration complicates security enforcement. We have now also introduced SOA as an enabler of cheap integration on a large scale. How then does SOA address the tricky question of security in integration?

With the exception of CORBA, integration technologies prior to SOA have struggled to address security challenges. Even in the case of CORBA, security enhancements to CORBA evolved much after CORBA was widely perceived as a failure. Hence, CORBA security mechanisms never gained large enough mindshare. SOA (SOAP based web services to be exact), on the other hand, allows new techniques that can help solve the problem of integration security to a good degree. Better yet, these techniques are seeing wide acceptance. In this section, we will discuss three new techniques that SOAP allows for tackling integration security:

1. Applying security at a Message level as opposed to applying it at the network layer 2. Converting security enforcement into a service 3. Declarative and Policy-based Security It is not as if all the technologies that enable these techniques did not pre-date SOAP. Some of the

technologies like Kerberos (introduced in chapter 5) and PKI (introduced in chapter 6) pre-date SOAP by quite a few years while some of the newer technologies such as SAML (introduced in chapter 8) evolved along with SOAP. Even in the case of security technologies that pre-dated SOAP, SOAP is the first integration technology that made their application popular. In that sense, SOAP should definitely get the credit for advancing the art of integration security.

Let us now dive into the details of each of the three techniques listed above. For each technique, we will first describe the motivation for the technique before going on to describe the technique itself. We will point out the portions of the book that describe each of these techniques in detail and finally, mention how they are being supported by current day SOA vendors.

1.4.1 Technique 1: Applying security at the message level Most applications completely rely on the network layer to secure data over the wire. That is, they assume that the underlying network layer will provide the guarantees against the threats to data integrity and



22

confidentiality. However, network layer security is not always adequate in integration scenarios. Network layer security works well for point-to-point message exchange; integration scenarios can involve message exchanges touching multiple applications. What is required in such scenarios is message level security and fortunately, SOAP provides enough mechanisms to enable message level security. This section will introduce you to message level security.

Typically, private networks are used as a first line of defense against threats to network data security. However, plain private networks are not good enough for two reasons:

1. Private networks cannot defend against internal threats. 2. Applications that depend on private networks cannot be made available for use by customers,

partners and vendors without enabling each one of them to access the private network. Same problem exists for employees who need to access enterprise applications remotely.

So, to extend the benefit of private networks to all potential users, we can use Virtual Private Network (VPN) tools. VPN tools seek to extend the private network to outsiders by tunneling private network traffic over public networks. All the data over VPN is encrypted providing the same level of security as any private network.

However, there is a downside to these VPN solutions: everybody who wishes to access the applications needs to install the additional software/hardware. While it may be feasible for partners, who may have sophisticated IT setup, it is onerous for casual users, or large number of clients. Therefore we need more widely available, easily deployable mechanisms to allow secure data exchanges with the larger customer base.

Fortunately, there is a solution for just such need. Web applications routinely make use of Secure Sockets Layer (SSL)/Transport Layer Security (TLS) to encrypt all traffic exchanged using HTTPS. For example, most corporate users rely on HTTPS enabled web interfaces to read their email remotely. Or, they use HTTPS to access company intranet portal from homes.

This kind of blanket network data security is not enough when we contemplate integration of two or more applications to offer a higher level service to a consumer application. Consider the all too familiar example of a merchant seeking to enable online purchases with credit cards. Here, two applications, the shopping system that merchant uses and the authorizing system that the credit card company uses, are integrated to offer a higher level service that enables customers to make direct purchases from the merchant. When you submit your credit card information, perhaps you use HTTPS to transmit the information. As your HTTPS connection is with the merchant’s application and not with the credit card company’s application, the merchant gets to see your credit card details. The merchant can of course reuse the information for making additional purchases without your knowledge. Even if you trust the intentions of the merchant, there is no guarantee that the merchant’s application handles your credit card information securely. For example, the merchant application may store your credit card information in a database that is not well secured against attacks by hackers. Or, your merchant application may relay your credit card information to the credit card company over an insecure connection. (Granted that credit card companies will not allow insecure inbound connections but the point continues to be valid as the merchant may not be directly connected your credit card company; the merchant may use an intermediary with whom his connection is insecure.)

What we do now is to implicitly trust the merchant to treat the credit card data carefully by using only secure mechanisms. We can however ensure end to end security for our credit card information ourselves if there were a mechanism to hide parts of a service request from some of the applications that make up the service. For example, can we secure the credit card information within a purchase request in such a way that only the credit card institution can read it? The rest of the purchase request should of course be readable by the merchant’s application. The merchant’s application can relay the opaque credit card



23

details to the credit institution in order to charge the customer’s card. Of course, the opaque credit card details should not be usable more than once to prevent the merchant from simply “replaying” them.

This technique of securing a message without relying on the underlying network is known as Message level security. Message level security provides end-to-end security where as network level security can only provide point-to-point security. Need for message level security is all too common in integration scenarios. In integration, there is often a need to compose the capabilities of multiple services to create a higher level service. In such case, various parts of a message received by the high-level service may be processed by different lower-level services. Not all of the lower level services may be belong to the same security domain (organization or entity). This translates into the need for securing same or different parts of a message differently for consumption by different parties. This of course cannot be done using network level security as the network can only secure a message in one way and does not distinguish one part of a message from another. There are no such limitations with Message level security and hence, it is a good technique for use in integration security.

Figure 1.7 shows an example of message level security in integration. This example is very similar to the credit card example we just discussed. In this example, an individual investor is paying for his stock purchase using his bank funds. The investor requests the bank to pay the brokerage for his purchase by attaching an opaque “payment authorization”. The brokerage cannot read the user’s bank account details present in the payment authorization but it can forward the authorization to the bank.

Bank

To: My Bank

To: My Bank

To: My Brokerage

`Individual Investor

Large Brokerage

Figure 1.7 “Message level security” in integration of a Brokerage with a Bank: Investor securely attaches an authorization to withdraw funds from a bank account to the trading request submitted to the brokerage. The attached authorization is secured from everyone including the brokerage. Only the bank can make use of it.

How does SOAP allow for message level security? SOAP allows itself to be extended for carrying

additional information in message exchanges. A standard extension of SOAP named WS-Security specifies how SOAP can be extended to carry security information in messages. WS-Security can be used



24

to carry identity information such as usernames and passwords, Kerberos tickets and digital signatures. It can carry information on the keys and algorithms used to encrypt different parts of a message. It can hold the signatures on different parts of a message, made by different parties involved in a message exchange. In summary, WS-Security allows us to carry as part of a SOAP message, arbitrary security claims made on different parts of the message by parties involved in a message exchange.

You will learn about WS-Security starting with chapter 3 of the book. Making identity claims in a SOAP message is described in chapter 4 (username/password), 5 (Kerberos) and 7 (digital signatures). Encrypting and signing different parts of a message differently are described in chapters 6 and 7, respectively.

1.4.2 Technique 2: Converting Security into a Service One of the irritants to security enforcement in integration is the presence of hard-coded security models in each application. Most applications, even to this date, come with their own custom solutions to security issues. For example, applications have their own user/password stores which they use to authenticate; they have their own way of doing authorization based on the user name, resource, activity, and perhaps even internal system status. The problem with this state of affairs is that the security model in each application may make assumptions that are only valid when the application is used by itself and not when the application is integrated with others.

For example, if an application uses its own authentication and authorization mechanisms, integrating it into an enterprise portal will require a Single Sign-on (SSO) mechanism that derives the user credentials required by the application from a different set of credentials user presents to the portal. Enterprises have sought to eliminate this cost asking application developers to deprecate the use of custom password stores in favor of corporate directories. Applications can use standard protocols such as LDAP to authenticate users against a LDAP directory.

In a limited sense, a corporate LDAP directory represents “centralization” of security enforcement. Instead of every application creating a custom authentication mechanism, LDAP directories offer authentication as a service the applications can rely on. However, LDAP directories do not provide everything that a security service should provide in an integration context. For example:

1. LDAP still requires the application to obtain and forward credentials from the user. Submitting

user name and password to every application is dangerous. For example, as shown in figure 1.8, some enterprise applications are hosted by external Application Service Providers (ASP). Some applications are hosted by partners or vendors. Based on the time-tested security paradigm, “Do not provide access unless you have to”, it is unwise to trust externally hosted applications with what is essentially the weakest link in security chains – the username and password of an employee. Even if the application is hosted internally, the application may not have been carefully audited for security.



25

Figure 1.8 If each application manages its own security, user credentials need to be passed to each application. When applications are hosted by external entities such as Application Service Providers (ASP) or partners, user credentials are transmitted across enterprise boundaries.

2. Large enterprises often employ multiple directories and password stores for non-technical reasons. For example, recently acquired subsidiaries of an enterprise may still be using their own directories. Authentication against a single directory is hence not good enough.

3. LDAP directories do not offer authorization as a service; at best, they provide the information necessary for making an authorization decision. For example, an application may retrieve the list of roles assigned to a user (or groups the user is a member of) to apply role-based authorization. Custom authorization schemes can become hurdles that need to be worked around by integrators. For example, if the capabilities of an application using role based access control are opened up to partners and/or customers, the set of roles recognized by the application may not be granular enough to distinguish what an employee can do with what a partner or a customer can do.

4. As you saw at the beginning of this chapter, there are many more aspects of security than just authentication and authorization. LDAP is not designed to address any of these other aspects of security such as data confidentiality and data integrity.

In other words, LDAP has given applications a way to delegate away authentication (and authorization to a small degree as described before) and this has reduced the cost of security management in enterprises. Integration can definitely use more delegation of security tasks by the applications. But the question is: Are there any technologies that enable such delegation? With SOAP, the answer to this question turns out to be yes.

A security service can offer applications (services in the case of SOA) the ability to authenticate, authorize, encrypt/decrypt messages, sign messages/verify signatures, log messages and scrub messages to protect applications against known and unknown vulnerabilities. Security service not only facilitates integration; it can also drastically bring down the cost of developing, auditing and managing security in each business application (or service). Figure 1.9 shows one of the possible ways in which a security service can work. We will discuss in detail, this and other possibilities in chapter 8.



26

Figure 1.9 A security service avoids the need to pass on user credentials to each business service. The security service forwards authorized requests to the called business service along with security assertions. The called business service can in turn submit some of those assertions to the underlying applications as required.

What is SOAP’s role in enabling the use of a security service? As you will see later in this book

SOAP allows clear separation between security tokens and the rest of the message so as to allow the use of a generic security service by all business services. Further, SOAP allows for the possibility of a security service as an intermediary in a message path if that is how you want to use a security service. If you want either of the endpoints to invoke the security service, a standard named WS-Trust provides a way to do that using SOAP.

Although security enforcement can be decoupled from business services in the form of a security service, business services nevertheless require some amount of security context to do their work. For example, an order creation service will need to know the identity of the user placing an order. If identity claims made by the user never make it to the business service, how will the business service get to know who placed the order? Hence, a security service needs to transmit to business services some of the context it establishes during security enforcement. Security Assertions Markup Language (SAML), in combination with WS-Security, helps SOAP carry security context established by the security service.

Chapter 8 of this book describes SAML, WS-Trust and other technologies that help offer security as a service in web services implementations.

1.4.3 Technique 3: Declarative and Policy-based Security As the preceding sections illustrated, SOA supports technical mechanisms to securely integrate the applications. However, merely securing the integration is not enough. Even if you develop a solution for the secure integration of most of the applications in enterprise, you will still face the problem of managing the resulting solution.

Let us understand by what managing means: If there is only one application, managing its security is simple. We may have to support adding new users to the application. We may have to change permissions for the users. In some cases, we may need to reconfigure the application to secure parts of it differently.



27

That is, apart from managing the users, we also have to change the security model of the application as well.

In integrating applications, apart from all the above, we have additional responsibility of managing the interactions between the applications. For example, a password change in one place may have to be propagated to multiple applications. Or, a change in the security policy of one part of the application may impact the access policy of another application.

Traditionally, these needs are met only to a limited extent by proprietary solutions. For example, there are several single sign on solutions that manage the users for many different applications. However, these solutions did not reach their full potential due to lack of standards.

Most of these solutions came with support for well established applications or platforms. There was no easy and uniform way to support any existing home-grown applications. Worse still, even if you are building an application from scratch, there is no way that you can make it work with these solutions.

SOA brings order into this situation. It provides a declarative way of specifying security for applications, which has two important repercussions – the first being easy implementation of security solutions and the second being ability for clients and servers to dynamically negotiate security policies.

First let us briefly understand what declarative security means. A declaration merely specifies what to be done instead of how it is done. In the case of security, it specifies how the application is secured – that is which part of the application is accessible to which group of users and so on. It also specifies where these groups are found and how users are associated to the groups.

For example, an advanced security solution, built on such standards, not only supports user management, but also let the application security be configured, extended, modified, without modifying any code. That is, the security requirements of applications are available to a management solution for full manipulation.

To be fair, there were ways to specify security declaratively, to a limited extent, even before SOA. SOA defines standards for this declarative security mechanism, making the task of management solutions easier. Unlike before, where these solutions had to cope with different formats with different semantics, now, they can target a standard. If you are developing an application, as long as you follow the standard, you are assured that your application can be managed by these solutions.

Traditionally, the declarative security confined itself to the users and roles in an application. They may go to the extent of separating the application into different zones, each with different access control. In SOA, we specify lot more than that in security declaration. For example, we specify their security policies – what kind of encryption they expect, what kind of certificates they accept, and what part of messages need to be encrypted and or signed and so on. Consequently, SOA Security frameworks can then enforce security policies consistently across all the services offered by an enterprise.

One important aspect of the standard is how a management solution can discover these security declarations. As it is the general philosophy in SOA, these declarations are available to the management solutions as well as the client applications. Along with data formats, interfaces and transport information, description of a service can also include security policies attached to the usage of the service. There are interesting repercussions when the clients can discover the security policies of the server applications.

When the clients have access to the security policy of the servers, they can make sure of interoperability between themselves. For example, a service provider can declare the kinds of security tokens it can accept where as a service consumer can declare what it can provide. By comparing these declarations, a security framework on either side can dynamically ensure interoperability with the security implementation on the other. In fact, clients can dynamically decide what kind of security information it requires from users based on the information they are requesting.

To summarize, standards in declaring security configuration and policies in SOA advances the state of art in security management: it makes certain difficult tasks easy, such as developing security



28

management solutions. It makes certain impossible tasks possible, such as policy negotiations and policy based security.

Naturally this degree of declarative security can only succeed with standards. Standards for codifying security policies are not fully mature yet. The next section describes the current state of the art in security products. You can understand the description capabilities of different toolkits and products even though we used some terms that are yet to be introduced.

1.5 Security Support in current generation SOA products The primary audience for this book is practitioners of SOA. As a practitioner, you need to know how you can put into action the techniques described in the previous section to tackle SOA Security. If you are an application developer using a web services toolkit in Java, .Net or a legacy platform, you need to know if and how your toolkit supports these techniques. If you are an IT administrator or an enterprise solution architect, you need to know about products that help you implement these techniques enterprise-wide. In this section, we will tell you what’s available in current generation SOA products to meet your needs.

The choices current generation SOA products present to practitioners of SOA security fit into the following four patterns.

1. Select a pre-packaged policy offered by a web services toolkit: If your SOA security needs are really simple and are in line with what vendors want to cater to at this time, you can simply choose one of the pre-packaged security policies provided by a web services toolkit. For example, BEA WebLogic Server (WLS) 9.1 provides three “simple” policies and .NET WSE 3.0 provides five policies (called turnkey security profiles). While pre-packaged policies in WLS 9.1 support authentication using username/password and digital certificates, those in WSE 3.0 also support authentication using Kerberos tickets. Both restrict encryption/signing to the whole message body; if you want to encrypt/sign different parts of the message differently, you cannot use the pre-packaged policies. You also cannot use other forms of authentication (such as SAML assertions, introduced in chapter 8) in both cases.

2. Declare your own policy using your web services toolkit: If your SOA security needs cannot be met with pre-packaged policies, you can declaratively specify your own security policies using a toolkit vendor specific policy language that is usually a variation of WS-SecurityPolicy (described in chapter 9). Toolkit vendors also allow you to extend what you can enforce with a policy by coding up your own assertions. BEA WLS 8.1 and .NET WSE 2.0 are examples of web services toolkits that offer this level of support.

3. Extend your web services toolkit: If you are using a web services toolkit whose support for SOA security is primitive, you will have to use extensions that are publicly available or code up your own extensions. For example, if you are using Apache Axis, an open source web services tool kit, publicly available extensions named Apache WSS4J (for Axis 1.x) and Apache Rampart (for Axis2) will let you handle via a combination of declarations and code, usernames/passwords and encryption/signing of entire message bodies. For every thing else, you will have to code up your own extensions.

4. Use a network appliance that specializes in SOA Security: This option is really for IT administrators and enterprise solution architects who are looking for enterprise-wide solutions to SOA Security. Network appliances that specialize in SOA security enforcement implement the “security as a service” technique and are described in greater detail in chapter 8. They are intermediaries in the message path that enforce the security policies configured by the administrator. The applicability of such appliances is currently limited by two factors. First, effort



29

needed to provision the security service can be high if the security policies for a large number of applications need to be codified in the security service. Second, a large number of existing applications do not make it easy to factor out security into an external service. Even when they do, additional effort is needed to make the applications consume the security context produced by the security service. Chapter 10 describes these challenges in more detail.

As you can see, some of these options offer easy to use support for SOA security while others require you to do some or all of the heavy lifting. Even with the seemingly easy options 1 and 2, you need a good understanding of how the underlying technologies work to choose the right pre-packaged policy or declare the right security policy. This book will help you gain this understanding. For those of you using open source toolkits, sample code in the book will help you see how to write your own extensions. This sample code will also be useful for advanced users of commercial toolkits who need to implement their own security extensions. For those of you looking into deploying enterprise-wide security services, chapters 8 and 10 in this book will describe the possibilities and the underlying technologies.

1.6 Summary There are a few points worth remembering from this chapter as they provide the basis for the rest of the book:

• SOA can be used for many purposes. However, security concerns are most complex when it is used for integration. Consequently, this book focuses on SOA based integration and its security challenges.

• Security in applications has several aspects: authentication, authorization, data confidentiality, data integrity, non-repudiation, privacy and vulnerability management. In SOA, all these aspects bring up additional complexity beyond what comes up in a single application.

• There are three interesting mechanisms to solve SOA security needs that we are going to discuss in the later parts of the book:

a. Security as a service in the enterprise, instead of embedding in every application b. Message level security that enables different parts of the message to be destined to

different applications. c. Declarative security to consistently enforce security policies in a large number of services

In subsequent chapters, we will describe the machinery to build such complete and comprehensive security solutions. At every juncture, we will discuss the lessons for architects, designers, and developers – in short, for all the practitioners of the SOA technology.

Suggestions for Further Reading 1. “Reference Model for Service Oriented Architecture”, OASIS Committee Draft 1.0, February

2006, is available at http://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ED.pdf.

2. “Web Services Architecture”, a W3C Working Group Note, is available at http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/.

3. “Architectural Styles and the Design of Network-based Software Architectures”, Ph.d. Dissertation, Ray Thomas Fielding, 2000. An online version is available at http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

4. “Understanding Enterprise SOA”, a book by Eric Pulier and Hugh Taylor, published by Manning Publications in November, 2005. ISBN: 1932394591.


http://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ED.pdf

http://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ED.pdf

http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/

http://www.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm


30

5. “Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions”, a book by Gregor Hohpe and Bobby Woolf, published by Addison-Wesley Professional in October 2003. ISBN: 0321200683.

6. “Security in a Web Services World: A Proposed Architecture and Roadmap”, a white paper published in 2002 by IBM and Microsoft, is available at http://www.ibm.com/developerworks/library/ws-secmap/.

7. Support for Declarative Security and WS-Policy in BEA WebLogic Server 9.1 is described at http://edocs.bea.com/wls/docs91/webserv/security.html#210122.

8. Support for Declarative Security in Web Services Enhancements (WSE) 3.0 for Microsoft .NET is described by http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/html/newwse3.asp and http://msdn.microsoft.com/webservices/default.aspx?pull=/msdnmag/issues/06/02/wse30/default.aspx.

9. Apache WSS4J, a publicly available extension of Apache Axis 1.x to add limited support for security is available at http://ws.apache.org/wss4j/.

10. Apache Rampart, a publicly available extension of Apache Axis2 to add limited support for security is available at http://ws.apache.org/axis2/modules/rampart/1_0/security-module.html.


http://www.ibm.com/developerworks/library/ws-secmap/

http://edocs.bea.com/wls/docs91/webserv/security.html#210122

http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/html/newwse3.asp

http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/html/newwse3.asp

http://msdn.microsoft.com/webservices/default.aspx?pull=/msdnmag/issues/06/02/wse30/default.aspx

http://msdn.microsoft.com/webservices/default.aspx?pull=/msdnmag/issues/06/02/wse30/default.aspx

http://ws.apache.org/wss4j/

http://ws.apache.org/axis2/modules/rampart/1_0/security-module.html


Documents

Motivation to SOA and Security