Data Power
Funciones :
- protección externa / interna
- transformación
- manejo de Web Services (límite de accesos por minuto, tamaño, etc)
Serveis :
- XSL Proxy
- XSL Firewall
- WS Proxy
- Multi-protocl Gateway
Features/caraterísticas :
- proceso de XML/XSLT/XPath en hardware
- validación XML
- extensiones XSLT
- compresión XML
- two-way SSL
- compresión HTTP
- balanceo de carga para conexiones salientes
- no almacena mensajes
- Firewall XML/SOAP
- validación de datos
- seguridad a nivel de mensajes y de campo
- control de acceso (AuthN + AuthZ)
- Web Services management
- encaminamiento basado en contenido
- Web Application firewall
Summary
XA-35
"A" => aceleración
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" => integración
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 :
- actualización cada 1 o 2 meses
- release (nuevas funciones) una vez al año
Acceso al DataPower :
- Command Line
- Web Services
- Web GUI
Crecimiento : añadir HW + balancedor de carga delante.
Se requiere un filtro de IPs delante del DataPower.
Control Panel
[u/k]
[2] XSL Proxy
Objective : to offload (and accelerate) XSL transformations.
Request is
http://datapower:8001/labs.xml
We shall send back
http://demoserver/labs.xml
transformed using
http://demoserver/pagelayout.xsl
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.
[3] XML Firewall
Objective : to validate an XML message against a XSD schema.
Request post soapMsg.xml http://datapower:40101
is verified against simpleSchema.xsd
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.
[4] XML Threat Protection
Objective : verify a XML message has no threat
Request post soapSqlThreat.xml http://datapower:40101
is scanned using SQL-Injection-Filter.xsl to watch for
SQL-Injection-Patterns.xml
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.
[5] Transforming with XSL
Objective : transform the inbound message against a simple XSL template.
Request post soapMsg.xml http://datapower:40101
is transformed using productTransform.xsl
Show how custom XSL templates are used within a processing rule.
AAA Framework
[6] WS-Security: Digital Signatures
Objective : add a digital signature to the message.
We can also verify it.
Request post soapMsg.xml http://datapower:40101
is signed using datapower.abc.com-privkey.pem
Response post signed.xml http://datapower:40101/verify
is verified using datapower.abc.com-sscert.pem
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).
[7] WS-Security: Encryption & Decryption
Objective : to encrypt the inbound request message, and test the decrypt mechanism.
Request post soapMsg.xml http://datapower:4nn01 > encrypted.xml
is encrypted using MyPublicCert.
We can see it decrypted
post encrypted.xml http://datapower:4nn01/decrypt
using MyPrivateKey.
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.
[8] 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.
[9] 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
[10] 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
[11] 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
post soapMsg.xml http://datapower:40101 does not work anymore
sslpost soapMsg.xml https://datapower:40101 works as before
[12] 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)
The request
<soapenv:Body>
<math:add>
<augend>308</augend>
<addend>20</addend>
</math:add>
</soapenv:Body>
sent by
post soapAdd.xml http://datapower:4nn02/MathServer/services/MathServer
produces as output :
328
[13] 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}
[14] WebSphere Services Registry and Repository Integration
Objective :
- Use of a central repository can facilitate Discovery and Reuse of Web services
[15] 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" ;
[16] 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.
[17] 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"
[18] 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
- Create a Data Web service and DataPower runtime artifacts with IBM Data Studio Developer
- Create a DB2 data source on DataPower
- Upload the generated service artifacts to DataPower
- Configure an XSL Accelerator for HTTP POST XML binding
- Configure an XSL Accelerator for HTTP GET binding
- Configure a WS-Proxy for SOAP over HTTP binding
- que passa si rebem un missatge XML de 2 MB ?
Links
POT - "XI50 can perform all labs in this document"
RedBooks :
DataPower homepage;
+
XS40, XML Security Gateway;
+
XI50, Integration Appliance;
Cursos : SW550 i SW551.
J.A. Flores :
- Firmware & Documentation
url
- El forum interno de IBM de Datapower es el siguiente:
url
- Por supuesto en el developerworks se pueden encontrar algunos articulos
url
