Me, myself and WebSphere

Ok, whether or not you have run into problems or are simply planning your DataPower network setup you should take two steps back and review your options and needs!

This post is for anyone who intends to use more than one IP address on their DataPower box!

DataPower works in mysterious ways when it comes to handling the Network Interface Cards (NIC) and network routing. Most often this is to an advantage but it can sometimes put you in a rough spot and this blog article is intended to clear out a few of the questions you might have…

The first thing to be aware of is that DataPower has a ”random” behavior when it comes to sending network traffic outbound if it can’t determine a specific route. What this means in the real world is that DataPower will send your traffic to any of the available NIC’s randomly and this can lead to much confusion and anger. This is also true for a response to a inbound (ingress) synchronous request to DataPower. There is no guarantee that DataPower will send the outbound (egress) response back out on the same NIC. This is a behavior that most firewalls that happen to sit between your client and DataPower does not like at all and therefore the response (which the firewall sees as an uninitiated request) is blocked. Furthermore if the egress NIC happens to be on a different subnet with no route back to your subnet the response will be lost and you’ll get that dreaded network time-out error.

Any request originating from the DataPower box itself behaves in the expected manner though and pulls the returning response back on the same NIC as the request exited.

Sometimes you might run into intermittent problems where it fails a few times but then work fine. This is because DataPower caches the “best known route” so if it found its way through once it will keep using that NIC for any following requests. That is, until you restart the box or make any changes to the network setup, then it might start failing again. In these circumstances it is easy to blame the network or the receiving servers to be unstable, even though it is DataPower routing your traffic out on the wrong NIC. This means that even if everything seems to be working fine, you might benefit from taking a look and make sure you at least follow the below stated rules…

I will not go through all various versions of routing here but hopefully enough to get you started and avoid the most common pitfalls…

There are a few ”rules” you should always follow:

1. There should be a Default Gateway (“default route”) on ONLY one NIC!
2. You should have a distinct subnets for each NIC!
3. You must carefully consider each route for each NIC!

Following point number one above is quite easy but it is important to distinguish between a default route and a static route.

The default route and static routes on the DataPower appliance have different functionality and behavior. A static route forces the DataPower box to use a specific interface and a specific set of network hops to access a given destination. The "default route" is created by setting the Default Gateway of a NIC in the DataPower box.

A default route will be used if a known route doesn’t exist for the destination address. If multiple default routes are configured, the appliance will randomly pick which interface to use (but there might be a cached “best known route”).

So, only for one NIC, and one NIC only, you should set a Default Gateway. This would normally be the NIC facing the Internet in a DMZ deployment or the Intranet for an internal network deployment.

The rest of the NIC’s should rely on static routes!

The most common scenario would be that you (think you) want your management network and “traffic” network separated where you’d place management on MGT10 and traffic on ETH10 (where 10 really means zero, i.e. MGT0 and ETH0).

In this case the first question to ask is if you really need/want a separate management interface?

There is something of a misconception that you should always run a separate management NIC, why else is there a MGT0 and MGT1 marking on the box?

It is important to firstly understand that MGT0 and MGT1 is exactly the same as ETH10 or ETH11 apart from them being separate hardware cards. DataPower does not separate MGT0 traffic from ETH10 traffic, that is up to you to do!

The only real reason to run a separate management NIC is if you in fact have a real management network. In some cases you might have a management network for monitoring appliances and then that network is normally only accessible for the network team. They might require SSH access to the box and for that you SHOULD run a management NIC!

For the Web GUI you should only run a management NIC if you have a separate subnet for “management” but in this case it would really mean “Development” and “Monitoring”.

How to you know if you have a separate subnet, well, that’s up to the IP mask or range.

I’ll put aside network masks and CIDR rules here and only discuss IP ranges in numbers for clarity. When you do the actual setup in DataPower you’ll need to use CIDR notification and understand subnet masks to get all the rules in!

So, say for example that you are on the 10.0.0.0 network, meaning your computer (or laptop) have an IP address that would be 10.0.0.125 for example.

Further your DataPower box is in the DMZ and have a “front facing” (=Internet) address in the 172.0.0.0 range. This would now include two separate subnets so if we add a third for management on 192.168.0.0 we have three networks to deal with.

In this example we would have two NIC’s configured in DataPower, one for MGT0 (management) on 192.168.0.0 and another on ETH0 (“traffic”) for 172.0.0.0. The ETH0-interface (172) would have a default gateway set while the MGT0 (192) would have a static route set to the 10.0.0.0 network (=your computers subnet).

This way any traffic going back to the 10.0.0.0 network would go out on the MGT0 NIC and all other (unknown) traffic will go out on the ETH0 NIC (towards 1720.0.0).

After the data has left DataPower it is up to the network (next hop) to decide where the traffic is going to end up.

Now you might be thinking, but wait a minute, my infrastructure and other backend/internal servers are also on the 10.0.0.0 network but they can’t run their traffic over the MGT0 NIC!

Yes, that is absolutely true and they should absolutely NOT do that and your network team will most likely be very upset to see you running all sorts of data on the management network.

This leads us back to the original question, do you really need/want a separate management interface?

In the above setup the answer is probably no, you shouldn’t run a separate MGT0 NIC. You only need that if you have a separate subnet to which your computer belongs and you want/need to route traffic out to that network only for management. There are normally two scenarios where that is true, either the network team has their own management network wired in the data-center or you have a separate VPN connection for the management network. In those cases a separate management network is valid, but then only if the computer connecting is on that separate network!

So, in my opinion most companies don’t need (or should have) a MGT0 setup!

With that out of the way you might want to consider having a ”front” and a ”back” to your DMZ; let’s assume that we skip the management idea and instead put 10.0.0.0 as the backside network on ETH1 (=ETH11) and 172.0.0.0 as the front (towards Internet) on ETH0.

Now the previous setup we had discussed will work just fine, a default route (Default Gateway) on the 172-network and a static route for 10.0.0.0 to the 10-network will accomplish what we want.

Any “unknown” traffic will be routed to the front-side (=Internet) while any 10.0.0.0 traffic will go out on the 10-network to your back-end servers and your laptop.

Another very common scenario is that you run Development, Test and QA/Staging environments on the same box (in different domains) and you need separate IP addresses for these or you have different traffic types, e.g. “secure” and “normal” that requires separate NIC’s.

Same thing applies here, first question, are the different environments/types in separate subnets?

In most cases the answer would be “No”, they are not and thus we should route the traffic to the different environments out on the same NIC using a static route. If the answer is “No” you might also consider using secondary IP’s instead of separate NIC’s since the routing will be the same for all three IP addresses. Another option is of course VLAN interfaces but that would all be up to your network team if they want one cable per IP or allow for Secondary or VLAN interfaces instead.

For a multi-environment box I would always recommend NIC’s or VLAN’s though so you can set Alias on the IP addresses and use them in the Front-side-handlers in the various domains more easily.

If however your answer is “Yes”, then you’d need to setup static routes to the various subnets for each NIC/VLAN and you need to setup any firewalls for the appropriate source/target IP.

In regards to this, I also often get the question about a “multi-homed” box, meaning a DataPower box that simultaneously exists in different network zones. This would normally be the DMZ and the Intranet. If you are using a virtual DataPower instance you shouldn’t even consider it!

If you however own a hardware appliance you could consider it, I won’t recommend it and you need to be very, very careful with your routing setup!

You should in that case also make sure that you have a firewall for the DMZ in front of the DataPower box. DataPower is a “hardened” hardware appliance and thus it is very capable of handling network traffic, if you know what you are doing!

Why you would do this is of course to save money, especially if you run API Management and want/need your API’s accessible both to external customers and internal systems. You should be very strict in the setup of domains and under no circumstances route traffic directly from “internal” domain to the “external” domain without passing the firewall!

And at all times, remember I did not recommend to do this, I only told you it is possible!

Best of luck and remember, when things look bleak, there’s always WireShark! :)

This post will assume you have sufficient skills in both IBM DataPower Gateways (DataPower) and IBM WebSphere Transformation Extender (WTX) to preform advanced tasks…

Getting that “Input valid but unknown data found” or a “One or more inputs was invalid” from a WTX map in DataPower can be oh-so frustrating as the WTX trace file can’t be used.

Quite often when this happens you will find that your map runs just fine in your local Design Studio but fails on DataPower with one of the above dreaded faults.

The first thing to do is of course to double-, and triple-check that you are in fact using the SAME data when testing on DataPower as you have loaded in Design Studio!

Remember to include ALL input cards and use the same data for all. After you have triple-checked this run the map again in Design Studio to make sure it runs through there with a “Map completed successfully”.

One common mistake is also that you in fact get a “One or more outputs was invalid” and in that case your map settings are messed up so go and check your output card.

To get the data that is actually received by the map in DataPower you can create a “base64 output”.

Just build a really simple “just-text” map with a Type Tree that has a Text item and add that as both input and output to the map. Then add the rule as:

=TEXTTOBASE64(TextBlob_In)

This will get the whole input and base64 encode it for you as the output.

Build the map for DataPower (.dpa), upload it to the DataPower instance and just replace the map reference in your processing policy (or routing file) with the base64 map instead of the non-working one.  Then run the message flow again through DataPower…

Grab the output from wherever you get it, MQ queue, HTTP Response, sFTP or wherever…

Your output will look like garbage but just bear with me…

Base64 output can look something like this:

Now fire up an advanced text editor like the awesome Notepad++ and paste your data into a new document.

After you have pasted the data in there, highlight the whole text ([Ctrl] + A) and chose the menu, [Plugins]->[MIME tools]->[Base64 Decode]:

The text sample on the previous page will give you:

Now make sure you save the data in the appropriate encoding and for DataPower this would normally be “UTF-8 without BOM”:

If the blue dot indicates something other than “Encode in UTF-8 without BOM” make sure you select “Convert to UTF-8 without BOM” before you are saving the document!

With this newly saved file, run the original map in Design Studio as you now have the exact data fed through the failing map in DataPower.

In normal circumstances the map should now also fail locally and you can turn on Map Trace to locate the error, fix it and build a new DPA and deploy to DataPower which should then run fine.

If the map still runs fine locally with the base64 grabbed data then it is most likely some encoding problem in the DataPower flow or the DPA on DataPower does not match the map in your Design Studio.

Make sure to rebuild the DPA and upload it to the DataPower instance again. If you are running a cluster of DataPower instances, make sure the same DPA exists on all instances!

If it is still not working after that it might be some Design Studio flaw. If possible try and re-build the DPA in another Design Studio instance.

You can also try and clean the WTX project in Design Studio (from the Project menu) and rebuild the map.

In worst case, create a whole new Workspace for WTX, copy over the Type Trees (but not the MMS file) and then go and Export the MMS from your original Workspace by right-clicking the MMS and chose [Export]->[Map]. That will give you a XML file on your disk. Now go into your new Workspace again and right-click in “Map Files” chose to [Import]->[Map from XML].

Once you have the map, build it for DataPower again and upload the DPA and try it out.

If it is still not working then, open a PMR with IBM…

Written by Anders Wasén

Enfo Zystems, September 2015

IBM MQ Appliance

• The scalability and security of IBM MQ V8
  • Integrates seamlessly into MQ networks and clusters
  • Familiar administration model for administrators with MQ skills
• The convenience, fast time-to-value and low total cost of ownership of an appliance
• Ideal for use as a messaging hub running queue managers accessed by clients, or to extend MQ connectivity to a remote location
• Fixed hardware specification allows IBM to simplify and tune the firmware
• Simplified ownership
  • Self-contained: avoids dependencies on other resources/teams
  • Licensing: Simpler than calculating licensing costs (e.g. by PVU)
  • Security: Easier to assess for security compliance audit
• Built using the latest DataPower appliance hardware and OS
• Firmware includes the MQ V8 product and capabilities
  • Participates in MQ networks or clusters
  • Existing MQ applications connect as clients, with no code changes
• Built-in High Availability
  • Per queue manager monitoring and automatic restart/failover
  • Without external dependencies (shared file systems or shared disks)

http://www-03.ibm.com/software/products/en/mq-appliance-m2000

With more and more companies expanding their business and dividing enterprises into different domains and locations, along with a growing need for up-to-date processes and information flows, the complexity of exchanging business-to-business (B2B) information is increasing.

In the pre-internet and early internet era B2B often consisted of exchanging EDI messages with very few business partners. Looking at today’s business needs, regardless of the label, small-, midsize- or large-company, it often includes a variety of external partners, communication types and messages. Many companies do not realize the width of their traffic that would classify as B2B from a “modern” standpoint.

With many established partners, subsidiaries or offices in other geographical regions B2B is often viewed as something like an internal process with an added protocol to be able to exchange the messages between different networks.

The above sentence summarizes the most commonly known definition for a B2B scenario; the exchange of data between isolated networks by two identifiable parties!

Not said that the “parties” must be different companies, it might be different departments, separate geographical areas, etc. “Identifiable” is another rather wide term as the identification of a party could be either a standardized addressing like, EDI identifier, DUNS or similar or a more technical term such as IP address or a dedicated directory in a FTP exchange scenario.

Regardless of which identifier is used (most commonly a combination of many) a B2B gateway must be able to identify the sending and receiving party.

Another key concept of a B2B gateway is to offer a routing capability for back-end systems like an ESB, ERP, or any other receiving system. The routing capability normally takes the information about the sender and receiver along with information about the message and/or protocol used to make the routing decision.

Looking at the expanding need for externalizing data today companies must also consider how to be able to meet these demands.

With mobile devices and “bring-your-own-device” policies a whole new era of communications are evolving, the API-era…

Mobile API’s are but one of three common types, Web-API’s and Business-API’s are the two other types. Web-API’s typically serves various web-portals or application servers while Business API’s is about publishing “business information”, e.g. master data.

A sample of the three working together might be if there is a customer repository in the internal systems and we want to serve our business with one common set of master-data. We would then build a business-API that would publish the customer address for example, then we would build a Mobil-API that the customers Mobile App can utilize and another Web-API so the customer also can see the address if logging in through a web browser.

The benefit of using API Management to handle this is that we only need to handle one set of data but then we can publish that same data in three separate ways, without having to write different code for them. We will also be able to handle security and user management in API Management as well as look at statistics and utilization of the API’s.

In this white paper we will not focus on API’s but an important note is that DataPower is capable of handling API’s as well and there is an available add-on called API Management for DataPower that will handle of your API requirements.

To be a bit crude, one could say that DataPower is “B2B in a box”…

DataPower with the B2B module is more than that though; it is a complete solution that will cover most of the B2B needs even for the most demanding of companies.

The DataPower simplifies, helps secure and accelerates your B2B trading partner connectivity.

As DataPower is based upon the IBM’s Gateways series hardware it is delivered as a “box”, or to use IBM’s terminology an “appliance”. DataPower can also be purchased as a “virtual appliance”, it will provide the exact same functions and even looks identical from a user perspective but then runs in a hypervisor environment, e.g. VMware ESX.

The base model for DataPower is called “IBM DataPower Gateways” which adds security and gateway capabilities to your network. Adding the module “Integration” it will add integration and an ESB capabilities. The B2B module in turn is based on the “Integration module” which means that all the functionality included in “Integration” is also found in the “B2B” version.

With the B2B module added you will get trading partner profile management, B2B transaction viewing capabilities and industry standards-based B2B messaging protocols to the already robust integration capabilities of the core appliance. These three added key capabilities are at the heart of the B2B module.

The only connections needed for any DataPower appliance is power (through a regular power cord) and a network cable. The initial setup for the network interface is done through a local USB connection and after that all configuration is normally done through the web interface. There is a Command Line Interface (CLI) and also scripting capabilities if needed.

To learn more of the basics on DataPower, please view the Red Book “DataPower Architectural Design Patterns” (http://www.redbooks.ibm.com/redbooks/pdfs/sg247620.pdf).

IBM DataPower Gateways with the B2B module is a purpose-built hardware B2B-enabled ESB.

It is designed for simplified deployment and hardened security with the ability to quickly transform data between a wide variety of formats, including XML, industry standards and custom formats. DataPower offers a built-in IBM WebSphere Transformation Extender (WTX) runtime as well as XSLT for flexible and high-performing transformations.

The device provides core B2B functions, including AS2 and AS3 messaging, partner profile administration, routing of electronic data interchange (EDI), XML and binary payloads, auto archiving and purging of B2B transactions and B2B transaction viewing capabilities.

A few core features for the B2B functionality is:

• Easily manage and connect to trading partners using industry standards
• Extend integration beyond the enterprise with a securely deployed B2B Gateway in the demilitarized zone (DMZ)
• Improve the performance and scalability of B2B interfaces
• Govern B2B integration points through consolidated trading partner management

The ESB functions include routing, bridging, transformation and event handling. It provides a reliable, performance-oriented solution to many integration challenges. Because it is not limited to handling just XML the DataPower fits perfectly with IT organizations that need to benefit from the connectivity of SOA deployments but must also deal with managing a combination of multiple proprietary, industry, company-specific and existing data formats.

The device is a true drop-in B2B integration point for such environments, reducing the time and cost of integrations and speeding the time to market for services.

For accelerated, security-rich integration capabilities, DataPower provides transport mediation, routing and transformations among binary, text and XML message formats.

Visual tools can be used to describe data formats, create mappings between different formats and define message flows. With native connectivity to IBM DB2 and IBM System z technology, the device offers a solution for a secure XML enablement of existing systems and mainframe connectivity.

The WebSphere DataPower SOA appliance portfolio has a long-standing history of support for key and advanced standards, including WS-Security, WS-Policy, WS-Reliable Messaging, SOAP, Web Services Distributed Management (WSDM), WS-I Profiles, WS-Addressing, eXtensible Access Control Markup Language (XACML), Security Assertion Markup Language (SAML), Secure Socket Layer (SSL) and proprietary Single Sign-on (SSO) tokens.

DataPower integrates with a variety of registry and repository, security, identity and service management software. Coupled with access-control software, such as IBM Tivoli Access Manager, the device enforces fine-grained access controls.

In many cases, when security is first discussed with the customer, they think of securing their data and possibly their connection. When it comes to deploying a B2B solution, we also need to take into consideration how to deploy the software in a manner that does not violate any existing network security policies that the customer has in place.

The four areas of security and their definitions that apply to B2B are:

• Deployment Security means the placement of hardware within an existing network with access to the Internet. This type includes database servers, file shares, message queue servers and integration servers.
• Connection Security means establishing a secure connection between trading participants over a Secure Socket Layer (SSL/TLS) connection (NB! Only TLS is enabled by default in DataPower but legacy SSL support exists).
• Document Security encompasses signing and encrypting the message prior to sending it to the trading partner.
• Access Control means providing access to data and configuration information inside the B2B application.

To protect B2B applications from unauthorized access, networking and firewall protection must be established. Firewalls work in conjunction with proxy servers, providing the ability to filter protocols, addresses, communication ports and IP packets. The security model that can be used is the establishment of a demilitarized zone (DMZ). The DMZ must be configured to restrict only a minimum set of communication ports for it to process requests.

DataPower is a DMZ-deployable appliance and requires a minimum amount of access through the inner firewall. Any sensitive payload data persisted to the Appliance is not accessible by partners and is encrypted on the hard drive.

Document security is normally accomplished through digital certificates, which provide an online identification credential for specific document exchanges, for example, AS1, AS2, AS3 or custom document-level encryption requirements. As part of document exchange, digital signatures can be calculated on the electronic document using public key cryptography. Through this process the digital signature is tied to the document being signed, as well as to the signer, and cannot be reproduced.

DataPower uses a role-based approach for access control. Users log in by providing their partner name, user id and password. The login determines individual access privileges. DataPower browser interface, which is used for administering functions, operates over a TLS connection (https).

To learn more and to see what DataPower can do for you and your company contact Enfo Zystems today!

With more and more companies expanding their business and dividing enterprises into different domains and locations, along with a growing need for up-to-date processes and information flows, the complexity of exchanging business-to-business (B2B) information is increasing.

In the pre-internet and early internet era B2B often consisted of exchanging EDI messages with very few business partners. Looking at today’s business needs, regardless of the label, small-, midsize- or large-company, it often includes a variety of external partners, communication types and messages. Many companies do not realize the width of their traffic that would classify as B2B from a “modern” standpoint.

With many established partners, subsidiaries or offices in other geographical regions B2B is often viewed as something like an internal process with an added protocol to be able to exchange the messages between different networks.

The above sentence summarizes the most commonly known definition for a B2B scenario; the exchange of data between isolated networks by two identifiable parties!

Not said that the “parties” must be different companies, it might be different departments, separate geographical areas, etc. “Identifiable” is another rather wide term as the identification of a party could be either a standardized addressing like, EDI identifier, DUNS or similar or a more technical term such as IP address or a dedicated directory in a FTP exchange scenario.

Regardless of which identifier is used (most commonly a combination of many) a B2B gateway must be able to identify the sending and receiving party.

Another key concept of a B2B gateway is to offer a routing capability for back-end systems like an ESB, ERP, or any other receiving system. The routing capability normally takes the information about the sender and receiver along with information about the message and/or protocol used to make the routing decision.

Looking at the expanding need for externalizing data today companies must also consider how to be able to meet these demands.

With mobile devices and “bring-your-own-device” policies a whole new era of communications are evolving, the API-era…

Mobile API’s are but one of three common types, Web-API’s and Business-API’s are the two other types. Web-API’s typically serves various web-portals or application servers while Business API’s is about publishing “business information”, e.g. master data.

A sample of the three working together might be if there is a customer repository in the internal systems and we want to serve our business with one common set of master-data. We would then build a business-API that would publish the customer address for example, then we would build a Mobil-API that the customers Mobile App can utilize and another Web-API so the customer also can see the address if logging in through a web browser.

The benefit of using API Management to handle this is that we only need to handle one set of data but then we can publish that same data in three separate ways, without having to write different code for them. We will also be able to handle security and user management in API Management as well as look at statistics and utilization of the API’s.

In this white paper we will not focus on API’s but an important note is that DataPower is capable of handling API’s as well and there is an available add-on called API Management for DataPower that will handle of your API requirements.

To be a bit crude, one could say that DataPower is “B2B in a box”…

DataPower with the B2B module is more than that though; it is a complete solution that will cover most of the B2B needs even for the most demanding of companies.

The DataPower simplifies, helps secure and accelerates your B2B trading partner connectivity.

As DataPower is based upon the IBM’s Gateways series hardware it is delivered as a “box”, or to use IBM’s terminology an “appliance”. DataPower can also be purchased as a “virtual appliance”, it will provide the exact same functions and even looks identical from a user perspective but then runs in a hypervisor environment, e.g. VMware ESX.

The base model for DataPower is called “IBM DataPower Gateways” which adds security and gateway capabilities to your network. Adding the module “Integration” it will add integration and an ESB capabilities. The B2B module in turn is based on the “Integration module” which means that all the functionality included in “Integration” is also found in the “B2B” version.

With the B2B module added you will get trading partner profile management, B2B transaction viewing capabilities and industry standards-based B2B messaging protocols to the already robust integration capabilities of the core appliance. These three added key capabilities are at the heart of the B2B module.

The only connections needed for any DataPower appliance is power (through a regular power cord) and a network cable. The initial setup for the network interface is done through a local USB connection and after that all configuration is normally done through the web interface. There is a Command Line Interface (CLI) and also scripting capabilities if needed.

To learn more of the basics on DataPower, please view the Red Book “DataPower Architectural Design Patterns” (http://www.redbooks.ibm.com/redbooks/pdfs/sg247620.pdf).

IBM DataPower Gateways with the B2B module is a purpose-built hardware B2B-enabled ESB.

It is designed for simplified deployment and hardened security with the ability to quickly transform data between a wide variety of formats, including XML, industry standards and custom formats. DataPower offers a built-in IBM WebSphere Transformation Extender (WTX) runtime as well as XSLT for flexible and high-performing transformations.

The device provides core B2B functions, including AS2 and AS3 messaging, partner profile administration, routing of electronic data interchange (EDI), XML and binary payloads, auto archiving and purging of B2B transactions and B2B transaction viewing capabilities.

A few core features for the B2B functionality is:

• Easily manage and connect to trading partners using industry standards
• Extend integration beyond the enterprise with a securely deployed B2B Gateway in the demilitarized zone (DMZ)
• Improve the performance and scalability of B2B interfaces
• Govern B2B integration points through consolidated trading partner management

The ESB functions include routing, bridging, transformation and event handling. It provides a reliable, performance-oriented solution to many integration challenges. Because it is not limited to handling just XML the DataPower fits perfectly with IT organizations that need to benefit from the connectivity of SOA deployments but must also deal with managing a combination of multiple proprietary, industry, company-specific and existing data formats.

The device is a true drop-in B2B integration point for such environments, reducing the time and cost of integrations and speeding the time to market for services.

For accelerated, security-rich integration capabilities, DataPower provides transport mediation, routing and transformations among binary, text and XML message formats.

Visual tools can be used to describe data formats, create mappings between different formats and define message flows. With native connectivity to IBM DB2 and IBM System z technology, the device offers a solution for a secure XML enablement of existing systems and mainframe connectivity.

The WebSphere DataPower SOA appliance portfolio has a long-standing history of support for key and advanced standards, including WS-Security, WS-Policy, WS-Reliable Messaging, SOAP, Web Services Distributed Management (WSDM), WS-I Profiles, WS-Addressing, eXtensible Access Control Markup Language (XACML), Security Assertion Markup Language (SAML), Secure Socket Layer (SSL) and proprietary Single Sign-on (SSO) tokens.

DataPower integrates with a variety of registry and repository, security, identity and service management software. Coupled with access-control software, such as IBM Tivoli Access Manager, the device enforces fine-grained access controls.

In many cases, when security is first discussed with the customer, they think of securing their data and possibly their connection. When it comes to deploying a B2B solution, we also need to take into consideration how to deploy the software in a manner that does not violate any existing network security policies that the customer has in place.

The four areas of security and their definitions that apply to B2B are:

• Deployment Security means the placement of hardware within an existing network with access to the Internet. This type includes database servers, file shares, message queue servers and integration servers.
• Connection Security means establishing a secure connection between trading participants over a Secure Socket Layer (SSL/TLS) connection (NB! Only TLS is enabled by default in DataPower but legacy SSL support exists).
• Document Security encompasses signing and encrypting the message prior to sending it to the trading partner.
• Access Control means providing access to data and configuration information inside the B2B application.

To protect B2B applications from unauthorized access, networking and firewall protection must be established. Firewalls work in conjunction with proxy servers, providing the ability to filter protocols, addresses, communication ports and IP packets. The security model that can be used is the establishment of a demilitarized zone (DMZ). The DMZ must be configured to restrict only a minimum set of communication ports for it to process requests.

DataPower is a DMZ-deployable appliance and requires a minimum amount of access through the inner firewall. Any sensitive payload data persisted to the Appliance is not accessible by partners and is encrypted on the hard drive.

Document security is normally accomplished through digital certificates, which provide an online identification credential for specific document exchanges, for example, AS1, AS2, AS3 or custom document-level encryption requirements. As part of document exchange, digital signatures can be calculated on the electronic document using public key cryptography. Through this process the digital signature is tied to the document being signed, as well as to the signer, and cannot be reproduced.

DataPower uses a role-based approach for access control. Users log in by providing their partner name, user id and password. The login determines individual access privileges. DataPower browser interface, which is used for administering functions, operates over a TLS connection (https).

To learn more and to see what DataPower can do for you and your company contact Enfo Zystems today!

Please note that this is a very “minimum” configuration and setup, although good enough to put into production but you should of course consider backup, fail-over, testing and of course documentation as well.

I would however like you to note that this is absolutely doable and there is nothing “crazy” or strange, the tools are just this good and state-of-the-art.

Tools needed:

• Knife or scissors (that tape on the box is really though; especially for weak IT technicians)
• Screwdriver
• USB-to-serial converter (if your laptop doesn’t have a 9-pin serial port; and if it does it’s probably time for an upgrade)
• IBM DataPower Appliance XB62 (or XB60) (Firmware 3.8.2 or above)
• A computer with the following installed:

• Putty (the Open Source SSH client)
• A Web-browser
• WebSphere Transformation Extender Design Studio (8.3 or above)

• Coffee machine

So, let’s get the clock started and myself down to the server-room!

The first 10 minutes or so I will spend unboxing the IBM DataPower XB62 appliance. If you are wondering, yes, that is included in the five hours!

Just to let you know how much of a nerd I am; I always get a severely raised pulse just opening up that DataPower box and pulling out that appliance; new shiny and full of that tremendous power… The geek-o-meter couldn’t get any higher than that! 

Another 10 minutes into this project I have the appliance in the rack and powered up. It’s quite heavy despite its small size (only 2U high) so I do recommend having a second pair of hands available!

It is generally better to run down to the server room yourself than having the network-techies doing it for you. Handing a DataPower appliance to a network technician is just begging for delays… Once they realize what kind of hardware they have gotten their hands on they will spend days planning IP stack routing tables, ARP cache’s, default routes and all those other very confusing terms they use when they want to sound busy

Next up is the initialization of the XB62. That is a fairly easy task if you know the parameters needed, such as IP address, DNS server and have decided a good and strong password prior to firing up the initialization wizard.

To run the wizard I hook my computer running Putty (the SSH client) up to the Serial port on the front of the appliance using a USB-to-serial converter.

Putty will start showing some scrambled text and after the device has booted the wizard will run. After typing in all the details I restart the XB62 to make sure the new details will stick so that I don’t have to run back down again…

I always test the appliance using the configured Ethernet port through a small network hub so that I know the IP and net-mask is fine. Before running the connection test I ran the CLI command to start the WebGUI of the appliance so that I can see it when running hooked up to the box directly.

It is also very good at this point to remember to plug the actual network cable from the rack into the Ethernet port of the XB62!

That done I can get out if that freezing server room and try to get my core-temperature back above freezing. Downing a quad-espresso on the go up the stairs normally helps a bit. (Well, yes, even though I am an IT geek of the worst kind I do take the stairs and not the elevator…).

Back at my desk I fire up my FireFox browser and open the WebGUI for the XB62 running on the default port 9090 to make sure that it works over the network.

When I have gotten this far I can forget about the DataPower box for a while. I will then start developing the WebSphere Transformation Extender (WTX) map to transform the data from EDIFACT to XML.

The message of choice for my project is an EDIFACT D.93A ORDERS message which I will transform into ebXML Order.

.

I have been working within the Integration and B2B (Business-To-Business) scope for some years now. First with IBM WebSphere Transformation Extender (WTX, former Mercator) on to using IBM WebSphere Partner Gateway (WPG) and now focusing more on IBM DataPower and the XB60/62 in particular.

My current position allows me to do loads of interesting stuff, both within integration in general but also in transformation and routing from an architectural standpoint. This has included a lot of fun stuff like learning SOA and WebServices, hardware virtualization on IBM Power platform, HA (High Availability) clustering, performance reviews and various assignments for designing and planning both new platforms and integration/message flows.

My background is in systems development, way back using Visual Basic and various databases, but later much web development, Java, scripting, Delphi, and much more... I still enjoy developing and am happy when I get the chance to create some small component in Java or some scripting in Perl, XSLT or shell script while working on some larger solution...

I have been all over the IT space, with one common factor, Technology!
From developer and DBA to pre-sales and then IT Architect to finally focus on B2B and Integration...

Take care!

Regards,
Anders