What is DataPower and Why DataPower?

IBM WebSphere DataPower SOA Appliances are purpose-built, easy-to-deploy network devices that simplify, help secure, and accelerate your XML and Web services deployments while extending your SOA infrastructure. Lets stop with that and talk a little bit about SOA, the current architecture and how DataPower fits in. The middleware infrastructure of an enterprise need to support XML and Web Services, since its emergence and popularity. This meant that the ESB or enterprise service bus had to support the emerging technology. This was proving to be an Problem because of 1. Traditional middleware installation has increased installation and maintenance costs 2. Operational costs involved in supporting the new data format (XML) and the existing formats (flatfile, cobol copybook etc) 3. Security New forms of attack on the infrastructure DataPower SOA appliances address these three challenges with the creation of specialized, purpose-built, consumable SOA appliances that redefine the boundaries of middleware. As the hardware ESB, DataPower SOA appliances are an increasingly important part of the IBM ESB family. As mentioned earlier DataPower is an appliance. So why exactly do we need an appliance what can it do?. Lets looks a typical infrastructure (this is not how it is but helps to explain the situation )

For security we have Firewalls, Virus Scanners, Proxy Servers etc. Then we have Mainframes, Databases, server clusters where services are hosted. Also there will be a server that is used for authentication. Given all these h/w and software, the cost to install, configure, maintain and operate any of these components are going to be huge. Not to mention that we have XML, Copybook, flatfile and databases. This would need data-transformations. Additional cost on h/w and s/w for that. Lets talk about security. We just cannot expose a service just like that, obviously it will be hidden behind a Proxy server and then we need SSL enabled for that. But given any web sever Apache / IIS SSL being resource intensive is going to cripple the server(s) badly and it wont be able to take in many connections. Now lets see how DataPower fits in here -

Throw away the Firewall/ Proxy server, bring in the DataPower XML Security Gateway XS40. This single appliance is able to provide the infrastructure with encryption, firewall filtering, digital signatures, schema validation, WS-Security, XML access control, XPath etc. If the infrastructure has to handle a lot of XML and XML based processing, then there is the DataPower XML Accelerator XA35. It can perform XML parsing, XML schema validation, XPath routing, XSLT, XML compression, and other essential XML processing with wire-speed XML performance. Talk about web service management and security you have DataPower Integration Appliance XI50. XI50 in itself has the capabilities of XS40 and XA35. In addition to that, it provides or has Any-to-any transformation engine Transport bridging Integrated message-level security Lightweight message brokering Which means that with all these capabilities you got yourself an ESB.

Talk about HTTP-to-FTP protocol bridging you got it, talk about MQ-to-HTTPS support you got it. Want to convert an XML to FlatFile- DONE. Spreadsheet to XML DONE. The possibilities are unmatched. Interestingly all these happens at wirespeed, with almost no delay. So you dont have to worry about the entire system getting slow, because the XML-CopyBook transformation takes 5 minutes. Or your enterprise h/w needs is going to cut a big piece for itslef from the budget.
Serveis :

XSL Proxy XSL Firewall WS Proxy Multi-protocl Gateway

XA-35 "A" => aceleracin Powered by unique purpose-built technology, DataPower XML Accelerator XA35 is a true network device capable of off-loading overtaxed servers by processing XML, XSD, XPath, and XSLT at wirespeed. The flexibility of the XA35 allows it to be installed in any number of different locations within the enterprise to off-load Web and application servers from the arduous task of XML processing. XS-40 "S" => seguridad Because corporations are struggling to deal with resource constraints, diverging business goals, and the requirement to assimilate new technology, DataPower XML Security Gateway XS40 is a network appliance that is easy to install and maintain, satisfying both application and network groups while supporting current and pending security standards out-of-the-box. XI-50 "I" => integracin DataPower Integration Appliance XI50 delivers common message transformation, integration, and routing functions in a network device, cutting operational costs and improving performance. By making on demand data integration part of the shared Service-Oriented Architecture (SOA) infrastructure, the XI50 is one of the few non-disruptive technologies for application integration. Engrunes The DataPower appliance uses the concept of Domains to separate logical configurations. All objects that you create on the DataPower device have names. These names are used primarily for identifying objects or referring to them from other objects. They are not visible from outside of the DataPower environment. The DataPower appliances have four Ethernet ports, each with an associated IP address. In addition, virtual IP addresses can be defined. The wizard chose a default value of 0.0.0.0, which specifies that the service should listen on ALL IP addresses configured on the appliance. Terminologia Datapower MPGW = MultiProtocol Gateway WAF = Web Application Firewall WSP = Web Service Proxy XMLF = XML Firewall

Hardware especializado : transformaciones XSLT de un mensaje XML encriptacion / decryptacion Firmware : Acceso al DataPower : Command Line Web Services Web GUI Control Panel

XSL Proxy Objective: to offload (and accelerate) XSL transformations. The XSL proxy can function in two modes. The XSL proxy service mode performs all transformations inline with the request. It can transform the inbound request or the outbound response. It sits between the client and the server. This scenario is the preferred and most widely used. When an XSL proxy is configured in co-processor mode, it acts as a call-out from a process, such as a Java program. Instead of using XML/XSL specific jars, a DataPower jar is used and will make calls to the DataPower hardware for XSL transformation.

DataPower XML services have two modes when performing XSL transformations: streaming and buffered. The default is buffered, where an inbound (or outbound) XML document is completely parsed prior to beginning an XSL transformation against it. This is similar to the DOM parser model. In some circumstances, it may be advantageous to begin the transformation process as the XML document is being streaming through the device. Streaming mode is similar to the SAX parser model. This is particularly advantageous when the inbound XML document is excessively large (i.e. half gigabyte per file). The DataPower device will automatically switch to streaming mode in the event that it determines that a received file is too large. It can also be configured to always attempt to use streaming mode. Of course, streaming mode comes with a price - the some XSL functions, such as sorting, or look-ahead searching, obviously cannot be used in streaming mode. The onboard XSL compiler marks compiled stylesheets as capable or incapable of being used in streaming mode.

XML Firewall Objective : to validate an XML message against a XSD schema.

We'll start with an XML Firewall that simply validates the inbound message against a schema while simultaneously checking for XML threats and malformed content. In general, DataPower acts as a full service proxy between a client and a server. When a request arrives, DataPower processes the request (checking for threats, transforming, etc), then forwards the request out the back to the original destination (or it can be routed to a new destination). The same process is repeated for the response from the server.

XML Threat Protection Objective : verify a XML message has no threat SQL Injection is an attack technique used to exploit web sites that construct SQL statements from user-supplied input. At the heart of the SQL injection threat protection mechanism is an XSL stylesheet that contains logic to scan the entire inbound XML message. First it strips all of the XML tags out of the document, leaving only the remaining attribute and element values, then it steps through each value and compares them against a list of patterns that represent potential injection threats. If one matches, the entire document is rejected. The patterns are represented as regular expressions. You can easily add additional regular expressions to the pattern matching criteria.

Transforming with XSL Objective : transform the inbound message against a simple XSL template. Show how custom XSL templates are used within a processing rule.

AAA Framework WS-Security: Digital Signatures Objective : add a digital signature to the message. We can also verify it. Sender first provides his public key to the recipient. To digitally sign a message, sender: Calculates a message digest (hash) from the original message. Encrypts the message digest with his private key - this becomes the digital signature. Attaches the digital signature to the message. Sends message with the digital signature to the recipient. To verify the signature, the recipient must:

Calculate a message digest on the received message. Decrypt the received message digest using the sender's public certificate. Compare the newly calculated message digest with the received one. If the two message digests are equal, the message was not changed in transit and it originated from the sender (integrity and authentication checked).

WS-Security: Encryption & Decryption Objective : to encrypt the inbound request message, and test the decrypt mechanism.

Encryption basics : Encryption is always performed using the recipient's public key (certificate). Decryption is always performed using the recipient's private key. The private key is never distributed. The public key can be freely distributed.

Authentication and Authorization with LDAP Objective : authentication, authorization and audit services.

Goals : Extract a user name and password from the WS-Security UserNameToken. Authenticate the user against a remote LDAP. Authorize the user using a remote LDAP. Create a SAML assertion and insert it into the SOAP header.

Customizing AAA with XSLT Objective : authentication, authorization and audit services, customized with XSLT

When the built-in functions don't meet the needs, any one of the seven AAA steps can be customized using XSL.

Authorization function will be performed by customLdapAZ.xsl

XACML Support Objective : XACML is declarative access control policy language implemented in XML and a processing model, describing how to interpret the policies. Security policies can be described in XML using XACML defined elements A XACML Policy Document is used by the Policy Decision Point (PDP) A Policy Enforcement Point (PEP) communicates with the PDP using XACML defined messages In addition to acting as the policy enforcement point, DataPower can also act as the policy decision point

Protocol Level Security: SSL/HTTPS Objective : add protocol level security to the firewall service DataPower has hardware based SSL acceleration Terminates inbound SSL connections Can create outbound SSL connections to the backend Keeps certificates in an encrypted portion of the file system Uses ID credentials to identify itself Uses Validation Credentials to identify other systems

Protecting Web Services Objective : create a WS-Proxy service by uploading a WSDL

Web Services Management : Hierarchical service level management at WSDL, service, port, or operational level

Web Service Proxy : Provides automatic configuration based on one or more WSDL documents Perform protocol mediation (HTTP, HTTPS, WebSphere MQ, etc)

WS-Policy Support Objective : WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. WS-Policy provides a way to describe complex requirements and constraints on both inbound and outbound messages. The WS-Policy assertions for inbound messages are always enforced. For example, if the assertion requires that the inbound message have a WS-Security UsernameToken element, it will reject any message that does not have it. The WS-Policy assertions for outbound messages (returned from the server) are handled in one of two ways: Filter - if the message does not meet the policy requirements, the entire message is rejected. For example, if the WS-Policy requires that outbound responses are digitally signed, and the server returns a response that is not signed, the entire transaction is rejected. Enforce - if the message does not meet the policy requirements, DataPower will attempt to fulfill them. For example, if the WS-Policy requires that outbound responses are digitally signed, and the server returns a message that is not signed, DataPower will add a digital signature to the message. Ex 1 : The WS-Policy document that you'll attach requires that all inbound messages contain either a version 1.0 or version 1.1 UsernameToken element in the WS-Security header {MathServer.wsdl}

Ex 2 : WS-Policy requires that all inbound messages contain a UsernameToken element, and outbound "add" and "subtract" responses should be digitally signed {MathServerWithPolicy.wsdl}

WebSphere Services Registry and Repository Integration Objective :

Use of a central repository can facilitate Discovery and Reuse of Web services

Protocol Bridging: HTTP to WebSphere MQ

Objective : configure the DataPower appliance to mediate between HTTP and WebSphere MQ

Mediates between incompatible protocols Client side: HTTP, HTTPS, FTP, NFS, WebSphere JMS, MQ Server side: HTTP, HTTPS, MQ, JMS Params : Host Name = "demoserver(1414)" Queue Manager Name = "QM_DataPower" Channel Name = SYSTEM.DEF.SVRCONN Channel Heartbeat = 300 User Name = "Guest" ;

Multi-Protocol Content-based Routing Objective : make content-based routing decisions based on some criteria from the inbound message

We define the discriminator string as "/MathServer/services/MathServer" The matching request is forwarded to "http://MathServer:9080/MathServer/services/MathServer" whilst the non-matching shall go to "dpmq://MyMqManager/?RequestQueue=MathRequests;ReplyQueue=MathReplies".

So, post soapAdd.xml http://datapower:40109/MathServer/services/MathServer request shall use WS, while post coboladd.dat http://datapower:40109 shall go to MQ queue, where the answer is generated using a program.

Protocol Bridging: FTP to MQ Objective : allow FTP clients to post transactions using standard FTP.

We start a "FTP Server Front Side Handler" as "Front Protocol"

Transforming non-XML Payloads Objective : Use WebSphere TX (Design Time) to create transformations to convert between XML and non-XML data, also called binary transform. We import files with extension .mts Upload Type Trees and Map for use in a Binary Transform action. Ex 1 : Transforming the SOAP message into a Flat Record (COBOL copybook) Ex 2 : Transforming the Flat Record response (from COBOL) into XML

XI-50 & Web Services Create and deploy Data Web Services on WebSphere DataPower XI50 Integration Appliance Intro : we shall focus on DataPower as a transformation and protocol conversation engine to transform Web service requests into database calls and the result back into service responses to implement a data access service. A transformation is defined by a set of rules which determine how an input is mapped to an output. A very common format for Web service is XML. XSL is a way to define such kind of mapping rules for XML-based inputs. DataPower provides first class support for XSL processing with it's purpose-build XML and XSL processing stack. Therefore, XSL is used to transform service requests into database calls and back. DataPower provides the XSL <dp:sql-execute> extension element to perform the database access operations.

Overview

1.Create a Data Web service and DataPower runtime artifacts with IBM Data Studio Developer 2.Create a DB2 data source on DataPower 3.Upload the generated service artifacts to DataPower 4.Configure an XSL Accelerator for HTTP POST XML binding 5.Configure an XSL Accelerator for HTTP GET binding 6.Configure a WS-Proxy for SOAP over HTTP binding

RedBooks :

WebSphere DataPower SOA Appliances Part I: Overview and getting started WebSphere DataPower SOA Appliances Part II: Authentication and Authorization WebSphere DataPower SOA Appliances Part III: XML Security Guide WebSphere DataPower SOA Appliances Part IV: Management and Governance Powering SOA solutions with IMS {Chapter 16. The use of DataPower with IMS} DataPower homepage; + XS40, XML Security Gateway; + XI50, Integration Appliance;

Cursos : SW550 i SW551.