- Meet the Family!
- Typical Usages of Appliances
- A Closer Look at the DataPower Products
- DataPower as a Member of the Network Infrastructure
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Typical Usages of Appliances
While the appliances are quite versatile and can thus be used to solve many different types of problems (and implementers have been quite creative in this regard), we find there are a few common use cases that are typical. These generally focus around security, performance, cost savings, and integration. In the following sections, we discuss each of these in more detail.
Solving Security Problems
Let’s think about what it would take to deploy a software-based proxy product in the DMZ. Each of the layers of the ‘typical server’ shown in Figure 1-2 requires specialized skills to install and maintain. Particularly for DMZ deployments, the server hardware itself must be hardened. In highly secure environments, this can involve removing any components that might allow information to be taken from the server, such as USB ports and writeable CD/DVD drives. The operating system must also be hardened, removing components such as telnet and sendmail.3 Often, this results in other layers of the software stack not installing or operating properly! If you are successful in installing the application software stack, it must be hardened as well. These are common requirements for high security environments such as financial companies, intelligence services, and military applications.
)
Figure 1-2 Typical server components.
Although software-based DMZ components can be hardened successfully, it is a lot of work. Compare this with the simplicity of installing a dedicated, highly secure hardware appliance, purpose built to do a few things well with fairly simple administrative interfaces, as shown in Figure 1-3.
)
Figure 1-3 High-level SOA appliance components.
The appliances are hardened out of the box. For example:
- They are designed with security in mind from the ground up, before anything else.
- They are shipped secure by default; virtually every feature is disabled, including the network adapters and administrative interfaces (except for the serial port used to do initial bootstrap). If you want something, you must turn it on!
- They have an encrypted file system.
- They have no Java, print services, or shareable file system.
- They are tamper-proof—backing out the screws on the case disables the appliance.
- They have specialized secure handling of crypto keys and certificates.
- They have an embedded operating system, not prone to known exposures of common OSs.
- They reject messages by default, unless specifically accepted by configured policies.
The age-old rule for the DMZ is to terminate client connections there and then proxy connections to the backend from the trusted DMZ servers. However, in the field we find even more stringent security policies that do not warrant any traffic (even proxied through these secure intermediaries) to the backend until the client is authenticated and authorized. This is referred to as perimeter security and is an increasingly common requirement, driving sales of DMZ security products such as TAM. Later, we show how DataPower appliances can also solve this problem.
Another requirement for DMZ components is to virtualize or hide the implementation details of backend servers and applications. Typical DMZ products interact only with the protocol layer of the network stack, so they can hide things like hostname/IP, ports, and URIs, whereas XML-centric application proxies such as DataPower appliances can virtualize on a much more intelligent basis and can analyze the entire message stream.
A strong reason for using these types of appliances is the burgeoning risk of systems becoming compromised by XML-based threats. Just as once upon a time we felt HTTP to be innocuous, today we are susceptible to underestimating what can be done by virtue of XML. In Chapter 20 “XML Threats,” we show how entire infrastructures can be brought down using small, simple, well-formed XML files. Only hardware appliances have the processing power to check for the many variations of XML threats.
Another common security problem is a mismatch in the specification levels or credential formats of various technologies across large corporate IT infrastructures. For example, consider a marketing IT silo running on Microsoft®.NET using WS-Security 1.0 and SPNEGO credentials for identity and a manufacturing silo using IBM WebSphere Application Server (WAS), WS-Security 1.1, and LTPA credentials for identity. In today’s ESB-driven SOA architectures, a single transaction may have to pass through both environments, so this presents challenges. Because DataPower appliances incorporate a wide range of the latest specification implementations and credential formats, they can be used to transform messages and credentials to fit the target each step of the way. Notice that this can be used to achieve cross-platform single-signon (SSO), although that also depends on other factors such as having a common registry.
To Lower Total Cost of Ownership (TCO)
Refer back to the scenario in Figure 1-2, where there are numerous skills required to install and maintain a typical server and software stack. Now think of this in terms of the staff required and cost to the organization. With self-contained appliances where the operating system and file system characteristics are irrelevant from an administrative perspective, this becomes much less work. The function of the appliances is dedicated and streamlined, hence the administrative tasks and interfaces tend to be as well. For example, in the scenario in Figure 1-2, you have to continually install fixes and updates at every layer of the stack. However, for appliances, you typically do this by uploading a small firmware update and rebooting, which takes only minutes. In the server scenario, you have multiple different administrative consoles to manage the layers of the stack; with the appliances, you have only one console.
The TCO return does not solely manifest itself in the setup and administration of the platform. Consider the silo example in the prior section—where various areas of a corporate IT infrastructure are running Web services across different platforms, such as those from IBM, Microsoft, and BEA. If the corporation has one set of policies for security and SLM that need to be implemented across all these platforms, then it must be done multiple times, by multiple people, with skills on each platform. Not only is the configuration redundant and therefore expensive, but this problem is repeated each time it needs to change, and there is always the risk that the policy will not be implemented exactly the same on each platform, which can lead to security holes or application failures. This is depicted in Figure 1-4.
)
Figure 1-4 Redundant administration versus simplified appliance model.
A more concrete example can be implemented by creating a single service that acts as a Web service proxy on the DataPower appliance, importing the WSDL files for the Web services providers on each of those backend platforms, and then applying the security and SLM policies on the proxy, thereby gaining policy definition and enforcement one time for all platforms. All this is based on standards that we discuss later, not only Web services itself, but also the accompanying standards such as WS-Security for security, WS-Policy for policy definition, WS-Addressing for endpoint resolution, and WS-Management and WSDM4 for management.
Enhancing Performance
XML is the foundation on which many modern architectures are built—it has evolved into SOAP for Web services and is found across the breadth and depth of the SOA stack and related specifications. Over time, it has evolved from a simple markup language to something quite complex and sophisticated. Of course, the problem as far as performance is concerned is that XML is fairly easy for humans to read, but not for computers. It is a verbose representation of data and typically requires significant resources in terms of CPU power and memory to process. This overhead is typically found in parsing the XML document into an in-memory representation and in validating the XML against its schema file.5
Consider the impact of parsing and validating the storm of XML/SOAP documents that hit your systems during peak production levels. Now consider the overhead of security that may be embedded in those messages—validating client identities against LDAP servers, verifying digital signatures, and decrypting encrypted data. This requires a tremendous amount of processing power and time and robs precious cycles away from what your backend systems should really be doing—focusing on transactional business logic! Also consider the absolute waste of expending these cycles for messages that come in badly formed, with schema violations or illegitimate security issues. The cycles expended on processing them and handling the errors are wasted. Figure 1-5 shows a graph demonstrating the CPU overhead of various common tasks. (Notice the parsing level is low here—the main hit when parsing is memory utilization.) Notice the impact of security operations. This can be helped somewhat with hardware-assisted acceleration, but the cost-benefit of hardware acceleration boards is often debated. Also note that abusing these security features to consume CPU resources is one way of mounting attacks.
)
Figure 1-5 Security impact of common tasks.
A grand solution for this, of course, is to use appliances to do all that heavy lifting at near wire speed. As you will see when we discuss the appliance characteristics, they are amazingly fast and can handle these tasks at orders of magnitude faster than software-based solutions running on standard servers. Now focus on another scenario—one where the appliance makes sure that only clean traffic gets to the backend systems. Imagine the huge differential in available processing power on the backend if the validation and security tasks are done by the time the traffic gets there. The appliances can validate schemas, verify signatures, decrypt the data, and more. This can often result in huge performance returns, depending on considerations such as message sizes, cipher strengths, network latency, and so forth.
Speaking of message sizes, this is often another major stumbling block for Java-based software systems processing XML. In modern day real-world systems, we are now seeing huge SOAP messages on the order of hundreds of megabytes or even gigabytes in size. The conundrum is how to process these, given constraints on maximum JVM heap sizes in many platforms. Due to aggressive built-in streaming and compression, appliances can handle messages larger than their actual memory space.
On another message-related topic, consider applications that do XML transformation between differing schemas; for example, an application that consumes XML purchase orders and must understand a variety of incoming purchase order formats from business partners, and then transforms each into the one “golden” purchase order schema that this company uses. These transformations can be quite expensive to process (see Figure 1-5) and result in bloated application code. We all know that line-for-line, application code is expensive in terms of programmer time, testing, and debugging. Now consider the effect on the application if the transformations were moved out to the appliance on the frontend so that the backend application now gets only the one “golden” schema format. Yes, our application has gone on quite a diet, is less expensive to maintain, and is much faster. One field scenario consisted of a frontend cluster of Java EE applications to do such transformations to keep the cluster of business logic applications behind it lightweight. However, since this was running on a platform that charged for CPU time, and given the overhead of XML transformations shown in Figure 1-5, it was expensive. The solution was to move the transformation layer out to DataPower appliances. The result was a huge cost savings and orders of magnitude faster processing.
Integrating Platforms
In the previous section, we discussed a scenario in which the appliance could be used to bridge differences in standards specifications (WS-Security v1.0 versus. v1.1) and identity credentials (SPNEGO versus LTPA) across systems. This is one good example of easily integrating disparate platforms, particularly when the standards and specifications are in flux. It is difficult for software-based solutions running on standard servers and products to keep up with this. On the appliance, you load a firmware update to get the latest and greatest.
However, there are other issues that arise when integrating different platforms. Consider a scenario in which a medium-sized business XYZ Corp has its infrastructure running on legacy platforms and technologies, perhaps mainframe-based EDI. The business partners that they depend on have long since moved their platforms to Web services and are telling poor XYZ Corp that they can no longer afford to support XYZ’s legacy interface to that system, and they must provide a modern SOA or Web services interface or lose the business. This puts XYZ in a bad position; what will it cost to retrain its programmers, rewrite its COBOL applications, and revamp the backends to its Java EE platforms? Likely, it would be a staggering amount! A common solution to this problem is to place appliances at the front of the network as proxies, cook up a WSDL file to describe some Web services, begin receiving the ASCII SOAP messages from the now-happy business partners, and convert them on-the-fly to EBCDIC EDI or COBOL Copybook messages and send them over MQ or IMS Connect to the legacy backend. The backend does not have to change, and no programs have to be rewritten—a win-win!
Due to the variety of protocols (HTTP(S), FTP, MQ, JMS/JFAP, IMS, NFS, TIBCO, MQ, ODBC, SNMP, and so on) supported by the DataPower appliances, there is a wealth of opportunity for protocol bridging, content enrichment, and integration between platforms. Notice that the previous scenario involved message transformation. The XI50 DataPower appliance can handle either XML-to-XML or non-XML transformation scenarios, meaning that messages can be transformed to the appropriate format for any intended backend.
Another common and age-old scenario related to integrating platforms is dynamic routing. Because it is often a requirement to make dynamic routing decisions “on the edge of the network,” we have DMZ Web servers, proxies, and load balancers handle this. The problem is that they can understand only the protocol and not the payload of the message. To accomplish the goal, applications place some value in the protocol header to facilitate the content-based routing. As an example, if we want any purchase orders over one million dollars to be routed to high-priority servers, the sending application would place a cookie or attribute in an HTTP header or URL parameter. The Web server, proxy. or load balancer in the DMZ would be configured to check for this and then route the traffic accordingly. The problem with this scenario is that you have to put this hack in the applications and the HTTP payload, potentially disclose message data to attackers, and involve the sender/client. This solution doesn’t scale because if you continually do this, the HTTP header and application code bloat.
Because SOA appliances are XML-savvy and can use technologies such as XPath, they can check inside the message payload to look for the actual <po_value> element rather than alter the application and HTTP header. If the message is encrypted, you don’t need to expose this by externalizing the data; you can just decrypt the message and check the value, and then route accordingly. The client in this case does not have to be complicit—the routing is truly dynamic and transparent. The XML Aware Network layer is shown in Figure 1-6.
)
Figure 1-6 XML Aware Network layer.
One last important feature in regard to the integration story is the use of appliances as ESBs. The appliances fulfill the model of an ESB by virtue of their strong routing, transformation, mediation, and protocol-switching capabilities. IBM has other ESB products capable of implementing the ESB pattern—WebSphere Message Broker (WMB) and WebSphere Enterprise Service Bus (WESB). Each of these have unique capabilities that may suit them for particular usages. Although DataPower may be thought of as a highly secure and performant ESB, the others have features that DataPower does not have in the arenas of transactionality, persistent message handling, and the capability to work in other programming languages. We discuss ESBs in Chapter 5, “Common DataPower Deployment Patterns,” and Chapter 9, “Multi-Protocol Gateway.”