Blog / News / Events

Insights

Webcast Replay: Migrating DataPower to IBM’s API Connect

iSOA Group’s CTO, Bryon Kataoka, presented during IBM’s weekly DataPower Webcast on 9/15/17. The webcast was a great success, with suggestions for follow up topics that we will work to have incorporated into future presentations.

Please see below slide deck on migrating from Datapower to API Connect using custom policies:

Webcast: Migrating DataPower to IBM’s API Connect

iSOA Group’s CTO, Bryon Kataoka, will be the featured presenter at this Friday’s IBM DataPower Weekly Webcast, hosted by IBM.

The focus of his presentation will be on the value to DataPower clients who migrate their DataPower deployment to IBM’s API Connect©.  Bryon will share the value, from a recent client migration, that enabled the client to realize more value from their DataPower deployment through improved analytics, broader use of DataPower services through API’s, and custom policies in API Connect that enable developers to access specific custom developed policies within DataPower.

This session will cover:

  • Scenarios and client motivations to migrate DataPower to API Connect.
  • How API Connect helps improve standardization of DataPower deployed services.
  • Lower cost of DataPower operational support while enabling agility of developers.

iSOA Group presentation: September 15, 2017 at 11:00AM and 2:00PM ET

IBM DataPower Weekly Webcasts

Every Friday one of our experts provides a 20 minute overview on a particular topic related to the DataPower platform. This webcast series is designed to provide brief, easily digestible content regarding DataPower functionality, emerging use cases, best practices, recent announcements, and client successes. It is an opportunity to learn how you can better leverage DataPower in your organization and discover new areas of applicability.

When: Fridays at 11am and 2pm ET

Log in Information:https://stmeetings.na.collabserv.com/stmeetings/room/join/access?id=7634-2249
Meeting password: datapower
Conference Bridge: 1-888-426-6840, Passcode: 64534212#

Security: Should You Code in Applications or Delegate to Gateways?

When you have a security Gateway, such as DataPower, should you continue to code security into applications?

Consider if this scenario fits your organization:

  • You have DataPower implemented in your trusted zone.
  • Your application teams are creating business services.
  • Your application teams are building in authentication and authorization into their software.
  • Developers are managing certificates.
  • Occasionally, certificates expire and the developer is no longer with the company.

If yes, don’t worry! this is a pretty common situation.

So, let’s point out where you can achieve some DataPower ROI:

Move authentication and authorization to DataPower

This can be done by adding a AAA action to your DataPower proxy service (Multiprotocol Gateway or WS-Proxy).  With some configuration to identify the user credentials (possibly a basic-auth header) and pointing to your IDP (i.e.,  Active Directory) with a few clicks you can have your user verified.

If you also need to verify that the user has access to your service, again, with a few clicks and some configuration of the LDAP group the user must be a member of, you can have authorization verified.

Allow DataPower to validate TLS

By configuring DataPower to handle the SSL you accomplish 5 benefits:

  1. Your certificates are managed by DataPower and therefore you will get notification of expirations 30 days in advance
  2. Certificates live in one place.
  3. The application teams don’t need to make code updates for security. Instead they can focus on business logic
  4. DataPower has a crypto chip that will process the SSL negotiation faster, thereby reducing cycles on your application servers
  5. Changes in security practices won’t impact your applications.

Allow DataPower to address future security changes

Security is only going to get tighter and tighter.  DataPower has the capabilities to perform encryptions/decryptions, create digital signatures and perform verifications.  By allowing DataPower to support the security needs of the application you are in a much better position to react to changes.

 Takeaway/Action Item
  • There are many ways to get more ROI out of your DataPower.
  • Have DataPower handle the security of the service so developers can spend time on business logic instead of security coding.
  • Reduce downtime by getting warned of expiring certificates in DataPower.
  • Separate security from business logic using DataPower so that security updates don’t impact your applications.

DataPower Gateway & Why You Want One!

Before we even get into what a DataPower Gateway is, let’s begin by discussing what a “gateway” is, how they differ and why you could potentially want another.

First, a “gateway” is simply a device that joins together two different networks. In the most common scenario, your enterprise networks with the Internet. A router is an example of a gateway device. It directs and decides where information packets are sent.

Another term to understand regards a firewall. A firewall is a filter that examines said packets, against a set of defined rules, in order to decide whether to allow the packets access.  Your security and infrastructure team go to great lengths to ensure firewalls are implemented to prevent unwanted access to your network(s).

Finally, a DataPower gateway is a hybrid implementation of the network components (the gateway + a firewall) just mentioned.  It is not meant to replace those components, but to supplement them with a specialized application layer (i.e., Layer 7) protocol.  The application layer allows your enterprise to implement specialized application services, and DataPower provides additional security that routers and firewalls do not.

So, what does a DataPower Gateway provide that the other network devices don’t do well (or at all) and why are they important to your company?

Here are a few features you can achieve through DataPower:

1.     Wire speed XML Parsing

Extensible Markup Language (XML) has been around for quite some time and is used to represent the data exchanged between multiple parties.  XML provides a tagged method to identify data elements so that you, your partners, and customers can exchange XML documents as a way to share data.

The problem with XML is not all information passed in an XML document is always needed.  To be as efficient as possible, it is a good practice to “starve” the data elements down to just that which you require.  The way of filtering these fields is called “parsing”.  Parsing in application servers is slow.  Load balancing the requests, in order to perform a task to meet a specified service level, becomes necessary when you encounter large volumes of parsing. This can lead to even larger server farms, more administration (backups, fix-packs, etc.) and increased hardware/software costs.

DataPower has a special, built-in XML parsing chipset designed to parse at the speed-of-the-wire, vastly outperforming server based parsing.  This specialized application feature is what makes DataPower stand out from the other previous mentioned devices.

If you are already using multiple servers to load balance parsing of XML traffic, you should consider routing those transaction through DataPower and apply your parsing on the “wire”. If you could reduce the effort spent on supporting the server farm, while simultaneously reducing your costs, what are you waiting for? It’s faster to ride in a car than ride a bicycle.

2.     Authentication/Authorization and token switching

Gateways primarily reside on the edge of the network.  That is an optimal location to perform authentication and authorization.  Not only does DataPower integrate with many authentication/authorization servers, but it can also switch the authentication tokens to another format (i.e., basic authentication to Kerberos).  Being that DataPower is standards-based, it works with pretty much any authentication mechanism.  If your authentication/authorization server is not available out-of-the-box, you can also accomplish the integration using a custom stylesheet.  This feature makes DataPower a powerful gateway addition.

3.     Advanced Security Implementation

DataPower provides enhanced security to implementations, such as Layer 7.  For instance, DataPower has a built-in, specialized ability to encrypt and decrypt at the speed-of-the-wire, meaning you can apply encryption to the XML payload.  You have the ability to sign with digital certificates, as well as verify signatures from other partners’ payload.  Plus, DataPower can also perform 2-factor authentication using a variety of methods.

Another very common use of DataPower is to use it to manage SSL/TLS.  Since DataPower can live in a DMZ, on the edge of the network, it’s best to establish the security there, instead of letting it pass through to your backend servers.

Finally, DataPower provides XML threat protection and SQL injection filtering that other devices or applications are incapable of performing.

There are many more security features in DataPower, but these are just a few to highlight, but remember you are merely scratching the surface.

Takeaway/Action Item

  • Take the time to investigate your DataPower implementation to see if you are taking full advantage of the features.
  • DataPower is a secure appliance. Involve your architects and security teams to ensure you are maximizing your investment.
  • If you are considering publishing API’s, you will need a powerful gateway.

Does your DataPower Implementation Support These 4 Key Features?

Is your DataPower implementation supporting your corporate security?

The right implementation will be agile, secure and efficient.  Depending on who, and how long ago, the DataPower Gateways were implemented, you might find these key features are missing.

And, don’t forget how agility in implementing your services through the Gateway allows your company to deliver products to customers quickly.  Winning business and protecting your assets will help you sleep at night.

So, does your DataPower Gateway have these key features?

Here is what you should look for:

1.     Logging information to your SIEM (eg. QRadar)

Security plays an important part in your DataPower configurations by identifying and protecting you against threats.  While DataPower finds these threats and acts appropriately to keep your company protected, it’s a best practice to configure a Log Target to output the messages to your company SIEM (Security Information and Event  Management).

2.     Repeatable Agile Framework to speed implementations

Configuring DataPower doesn’t require programming, which makes it very agile in providing capabilities in a short time.  To improve the agility even more, you can configure an Agile Framework that will allow you to build new services, faster, and adhere to standards with little fuss.   If you aren’t using a custom framework you are probably doing more work than necessary by replicating similar configurations that cause more ongoing maintenance.

3.     Utilizing DataPower’s threat protection

DataPower comes out of the box with built-in threat protection for your XML payloads.  There are additional configurable protection methods that guard against Denial of Service and SQL Injections, to name a few.  You can even add virus protection as part of your DataPower configuration.  Since these features are readily available out-of-the-box, ensure you turn them on.

4.     Wire speed transformations

Who doesn’t want the fastest processing of XML parsing?  DataPower has a built in XML Parser that will parse at “Wire speed”.  If you are using multiple servers to load balance parsing of XML traffic, you should consider routing those transactions through DataPower and apply your parser on the “Wire”.  You can reduce the effort to support the server farm, improve the speed for parsing XML messages, all while saving money (always a good thing!).

 

Takeaway & Action Items:

  • Take the time, regularly, to investigate your DataPower implementation to see if you are taking full advantage of the all features of DataPower, inlcuding new features in updates of the firmware from IBM.
  • DataPower is a secure appliance. Involve your architects and security teams to ensure you maximize  your return on you DataPower investment.
  • Consider a DataPower Advisor to review your implementation, share best practices, and assure you keep up-to-date on all of the latest DataPower features, including acting as an API Gateway.

 

Expert’s Corner: When to Use DataPower XSLT vs. Gateway Script

In April 2014, IBM introduced a new Scripting Language to customize and configure DataPower for deployment based on Javascript.  This introduced a new approach, beyond XSLT, and also opened up the ability to leverage Javascript skills common in the marketplace.

Our trusted advisors did some research on when to use XSLT vs. Gateway Script:

IBM continues to upgrade GWS (GatewayScript) with each firmware release. Initially, it lacked some of the extension functions that are provided for in the XSL functions.

They are now pretty much have caught up, with a few exceptions, primarily in the various protocols that are supported in URL-open extensions. What they have done with GWS is add a lot of JSON capabilities and security updates for JSON (JWE, JWK, JWT). GWS is more traditional programming versus XSLT’s template model. It is much easier to handle things like setting up conditionals or loops. Output messages to the log are as simple as typing: console.debug (“accessCount = %i, accessCount); You can still use a combination of XSL and GWS in a service policy. Also, you have a debugger in GWS which means now you can step through your GWS code. You can build functions in GWS, which is much easier than writing call-template or apply-templates. E.G., Var PO = producePurchaseOrder (bookOrder, booksDB). You can also execute GWS from dynamic content and run it out of the temporary folder. From a performance standpoint, GWS is a secure and optimized Javascript. It is probably a shade slower since you cannot take advantage of the XML chip on physical DataPower appliances, but many folks on virtual appliances won’t have that option anyway.

Bottom line is as follows:

  1. If you are new to XSLT and have javascript skills, go with GWS.
  2. If you have existing XSLT written and need to perform specialized scripts that are easier to do in a traditional javascript, go right ahead. Example might be some calculations or date manipulation.
  3. If you want to use more of the latest JSON capabilities, using GWS makes it easier because JSON is just javascript notations.
  4. You can also check out the store:/// folder for examples of GWS.
  5. If you are dealing with XML transformation and are familiar with XPATH, then it’s OK to use XSLT.

Expert’s Corner: Is DataPower a Firewall or a Layer 7 Protocol Proxy?

When discussing the capabilities of DataPower with colleagues, the topic of routing capabilities of the DataPower appliance often comes up.  It may seem convenient, at first, to compare it to a firewall, but it actually behaves much differently.   Keeping a clear understand of its behavior and how it handles routing of messages is important, as you determine the correct architecture and use cases for deployment.

DataPower operates almost exclusively as a non-transparent, Layer 7 protocol proxy, handling only an explicit number of protocols, such as HTTP (HTTPS) and FTP (FTPS). While it may appear that DataPower passes data, or messages, from one network segment to another, messages are actually terminated on the inbound TCP connection, introspecting message based data, and then a separate and distinct TCP connection is created from the device to a destination host.

 

Unlike Router/Firewalls, DataPower devices DO NOT route IP packets directly. They employ a high degree of interface isolation which is controlled by the configuration set in DataPower, but they will not connect two network segments for random protocols.

A protocol specific proxy service (XML Firewall, Multiprotocol Gateway, WS-Proxy, etc.) must be configured on the device in order to pass any data through said device, to a destination host.

For some supported protocol types – namely asynchronous messaging protocols such as IBM MQ Series™, IBMʼs WebSphere Messaging Engine™, or Tibcoʼs EMS™ protocol – the device does not act as a protocol proxy at all, but instead is responsible for establishing TCP level connections to support both the ingress and egress message path associated with an integration service.

Expert’s Corner: When to Use an NFS Hard vs. Soft Mount

If you are connecting your gateway to an NFS file system, there are two options for how to mount it.

  1. A soft mount, which means that the application, or gateway, connection will attempt to mount the drive and once connected, will start to process the file. If for some reason the gateway cannot reach the file system after a period set by the nfstimeout parameter, then it will receive an error. However, if the file system goes down during the transaction, the transaction will stop and there may be some data corruption.  The advantage of a soft mount is that it has minimal impact on gateway performance; a disadvantage is the potential for data corruption.
  2. A hard mount; once the gateway is connected to the file system it is more of a “hard connection”, meaning that the gateway or server will continue to attempt to reconnect if the file system is unreachable. Once reached, it will continue the transaction, assuring the integrity of the system and data. The advantage is that data integrity and messaging is assured; the disadvantage is there is a performance impact with the constant connection.

We recommend a soft mount when the data integrity is not as critical and therefore your application, or gateway, will know there was an error in the connection.  As an example – a backup that was interrupted and not completed.   We recommend a hard mount when data integrity and the need to complete a transaction is of utmost importance.

If you would like to speak with an iSOA Trusted Advisor or engage our team for assistance please email us at info@isoagroup.com, or call us at 707-773-1198

Expert’s Corner: When to Use PKIX vs. Exact Match for Certificate Validation

 

DataPower, as many other gateways, can validate certificates via different standards depending on your requirements, as well as those of the systems, partners, and clients that will need to be secure as you are exchanging information.

As an example, DataPower supports three different “validation modes”; the command to set the validation mode:

  1. cert-validation-mode legacy: This mode is maintained for backwards compatibility. This is where validation credentials contain the exact peer certificate to match, or the certificate of the immediate issuer. These might be an intermediate CA or a root CA.
  2. cert-validation-mode pkix:  The complete certificate chain is checked, from subject to root, with this validation credential for certificate validation.
  3. cert-validation-mode exact-match: The validation credentials contain the exact peer certificate to match.

Choosing which mode to standardize on may be a challenge depending on the industry and your security needs, but as a best practice, we recommend using PKIX.

When using PKIX, DataPower will verify that the client certificate is either matched exactly in the certificate list, or that a complete signer chain from the incoming cert, all the way to the root certificate authority, can be established. Since this is your primary method for verifying client identity, you should ensure that it is fully validated.

PKIX implies that you understand the signers of the clients. You need to include all the intermediates and root signer certificates. If you don’t, DataPower will reject the connection.

For more information for DataPower users, we recommend this link in the IBM Knowledge Center

If you would like to speak with an iSOA Trusted Advisor or engage our team for assistance please email us at info@isoagroup.com, or call us at 707-773-1198.

Expert’s Corner: Introducing Technical Advice from iSOA Professionals

Welcome to iSOA Group’s Expert’s Corner.

In addition to launching our new website, we are excited to announce another valuable service – the Expert’s Corner. iSOA Group’s trusted advisers are leaders in our industry and, as such, have a wealth of knowledge at their disposal. And, as the Dalai Lama said, “Share your knowledge. It is a way to achieve immortality.”  Whether you are new to IBM’s DataPower© or CA’s API Gateway©, a long time operator, or a newbie developer, we hope you will find our Expert’s Corner of interest.

Topics will range from discussing the pros and cons of NFS with DataPower, when to use Exact Match or PKIX for authentication, or some “tips and tricks” from our Gateway Consultants. Less fluff, more stuff!

If you have questions on, or suggestions for, a post, please email us at social@isoagroup.com. We are always looking to provide relevant content to our readers!