How-To: Clear Channel Deployments History

There has been questions about how to clear unwanted versions of channel builds that exists in iWay Service Manager. By following the simple step, one can get rid of them. 

 Navigate to /etc/repository/manager/car/ and delete everything is not required. Do make sure the channel is deployed nowhere before deletion.

How-To: Use iSM to implement PGP Crypto Functionalities

By Srikanth Srinivasan

In this article, I have tried to explain, in a step-by-step fashion, on how to build a scenario that involves PGP encryption. In my view, anyone who is reading this blog is already expected to be fluent in creation of regular objects in iSM such as channels, inlets & listeners, routes & pFlows and outlets & emitters. Hence, we will not deep-dive into their nitty-gritty.

Entities Involved:

è iWay Service Manager 6.1.9;

è iWay Integration Tool;

è A tool to generate PGP keys, I am using Kleoptra;

è Text editor;

Keywords & Extensions:

.PGP [Pretty Good Privacy], iSM [iWay Service Manager], iIT [iWay Integration Tool]

Assumptions:

      èBasic knowledge on using iSM;

      è Downloaded & Installed Kleoptra [Source];

Procedure:

There are three sections in implementing this scenario.

Section-1: Create PGP Keys

Launch Kleopatra and choose File – New Certificate from the menu bar, like seen in the following image:

Upon selecting a New Certificate option from the menu, select "Create a Personal OpenPGP Key Pair"  and cofnigure the values for your keys, as seen in the screens  below:

 We will not dive into Advanced Settings for now as I do not want to complicate things at this article. However, there is no harm to try it out yourself. After configuring your key parameters, go ahead and hit "Next" then verify the detaisl to hit "Create Key", as seen in the image below.

Provide passphrase when prompted during the course of key generation which will land in screen like what is seen the following image to indicate successful end of activity.



Now that wehave successfully created a key, take a back-up copy of your key pair by choosing "Making a Backup of Your Key Pair" option from the screen seen above. The next step will prompt for a destination location, provide one and store it with ".pgp" extension.

Note: The extension ".pgp" does seem to matter as the tool seem to produce the content based on the extension. Feel free to try with other options.

For those who wonder, what is the "ASCII armor" option - it is a feature that encodes the encrypted machine-only-readable secret key into ASCII form which will look a base64 content. Feel free to try with the option checked & unchecked and open both files in a text editor to see the difference yourselves.

We now have a qualified version of secret key which will later be used for decryption of data in this article. Now, let us try & export the public key and save it with ".pgp" extension. Public key can be exported by selecting the keypair entry in Kleoptra, right-clicking on it and choosing "Export Certificates", like seen in the screen below.

Provide a destination location when prompted.

Finally, make a note of the "User-ID" [the email id is user-id here] & "Key-ID" of the secret key we just produced. Open the key and look for them as seen in the screen below:



Section-2: Create an Inbound & Outbound scenario

Alright, now lets head back to design-mode. We first create an Outbound scenario to build an encrypted data and emit then. Then we create an Inbound scenario to receive & decrypted incoming data.

Outbound:

Launch iIT and create a simple pFlow that has PGPEncrypt Agent for encryption. Supply the values for properties of PGPEncrypt  Agent accordingly. There are four sections in the agent, namely, General, Signature, Compression & Encryption.

The first section, General, lets us choose the type of output the agent should produce. That is, in encrypted machine-only-readable format or in ASCII format. We can set the Armor property to true when we transmit the data over HTTP or SOAP, as in my opinion, the receiving party will get the data as we send it, if they are in parsable format.

The second section, Signature, can used to sign the content to send it out for transmisison. We'll not use this feature in this article, feel free to try it out.

The third section, Compression, as self-explanatory can be used to compress the content of the PGP encrypted message. We'll use this here.

The fourth & the last section, Encryption, is the section we will use the public key we generated in section 1. Every encryption is regarded as a session and they can have a session key for every encryption. The agent has a provision to mention a session key for encryption. If configured with a session key, the same key should be provided in the decryption agent. My configuration of PGPEncrypt looks like this:

Create an emitter [the type of emittter should be the type of the listener in the Inbound scenario] in the pFlow, publish to the registry.  Feel free to build the pFlow according to your need. My version of the pFlow looks like this:

Create a channel and other dependant components, build and deploy the channel on a managed server.

Inbound:

Create a simple pFlow that will handle the incoming encrypted message. It can simply have a PGPDecrypt Agent and a File emitter to store the decrypted content. 

The PGPDecrypt Agent has two sections and they are Decryption & Signature Verification. 

The first section, Decryption, should be configured with the secret key we generated in section 1 along with its passphrase and a session key if the encrypted data should require one.

The second section, Signature verification, will be used to verify the signature of the content, if it was signed during packaging & encryption. We are using it here as we have not signed out content.

Create a file emitter next to it, to store the decrypted content and publish the pFlow to the registry. Feel free to build the pFlow according to your need. My version of the pFlow looks like this: 

Create a channel and other dependant components, build and deploy the channel on a managed server.

Section-3: Publish, Build, Deploy & Test our efforts

Test our efforts. Following screens are samples of an input file, a pgp secret key file and a pgp public key file.

Sample input file:

Sample PGP secret key file [un-armored]: 

Sample PGP secret key file [armored]:

Sample PGP public key file [un-armored]:  

Sample PGP public key file [armored]:

Until something interesting next time, Good luck!

How-To: Use iSM Web Services as Regular Web Services with Client Authentication

While it does seem I have taken a quite long break for yet another new blog, this time it is about a common requirement most of the iSM users seem to face. And that is, How to build a web service in iSM and make it available for third-party consumption? While it is a little lengthy process, with proper setup iSM can host web services with WS message-level authentication or with client authentication over SSL connectivity.

I’ll try and explain what to do to see what we want to as simple as I can.

Entities Involved:

è iWay Service Manager 6.1.9

è iWay Integration Tool

è Keystore Explorer for producing certificates for SSL connectivity and client authentication;

è Text editor;

 

Keywords & Extensions:

.P12/.PFX [Private key enabled Certificate], .CER/.CRT [Regular X.509 Certificate], iSM [iWay Service Manager], iIT [iWay Integration Tool], JKS [Java Key store]

 

Assumptions:

è Basic knowledge on SSL connectivity & Client Authentication over HTTP(s);

è Ability to handle Java Key store/Trust store;

è Downloaded & Installed keystore Explorer [Source];

è Firewalls blah handling;

 

Procedure:

There are six sections in implementing this scenario.

Section-1: Create a New Managed Server [with all primary regular settings such as enable logging/tracing, blah blah]

Read THIS blog to learn how to create a new managed server.

Section-2: Build Process Flow that our Web Service will use to handle the incoming message

Launch iIT and create a simple pFlow and assign “Any” as the schema at Start & End objects. Let the pFlow accept something and return something so the consumer gets a response from the web service. My version of pFlow looks like:

Publish the pFlow to the desired managed server which can be verified by navigating to iSM Web Console -> Deployments -> Management -> Services and see if your pFlow is listed there like what is seen in image.

 

 

Navigate to “iWay Explorer” tab in iIT, create a new iWay resource by clicking the highlighted icon seen in image.

 

 

Logon to the iIT with appropriate iSM logon details such as console port, SOAP port. If everything is configured as described here, a pFlow deployed in the previous step should be visible in iWay explorer's new resource as seen in the image below:

 

 

 

Now, create a iWay Business Service for this pFlow by right clicking on it and choosing Create iWay Business Service... as seen in screen below. Provide a name for the service and choose a licensing object which is useful for grouping.

 

 

 

 

By creating a new business service, it will result in creating one and listed under Services as seen in the screen below:

 



 

At this stage, we have the web service ready to accept messages inbound but without an authentication mechanism implemented yet. Before we see how we implement that, lets make a copy of WSDL by extratcing one by right clicking on the entry under Services and storing it locally for later use that will seen in a few steps.

 



Section-3: Create JKS and Key Pair

Read THIS blog to learn how to create a JKS & generate key pair entry.

Section-4: Create & Configure a SOAP listener in iSM “blue” Screen Console

Follow the screens below to find out what to do in the iWay blue screen console.

To get into the blue screen look for the build number in the top right corner of the iSM Web Console.

 

The iWay Blue Console shoudl look like what is seen in the screen below:



Choose the desired managed server from the "Available Configurations" drop down list box in the top right corner of the image above. After that, navigate to Configuration - Listeners and create a new SOAP listener.

 

A configured SOAP listener should look like what is seen in the image below:

 

To start the SOAP listener, navigate to Monitor - Configuraiton - Choose the <Managed_Server> where SOAP listener was created as seen in screen below.



 

Section-5: Create/Build/Deploy a Channel & a Process Flow for it that will consume the Web Service that we created above

Create a new channel with a process flow that has an XDWSHttpClientAgent [XDWSClientAgent also can be used, depends on how one likes to wrap the SOAP envelope around the business message]. Build & Deploy the channel on the manged server. The XDWSHttpClientAgent will look like the image when configured:

 

Section-6: Test our efforts

Test the scenario by starting up the outbound channel that emits SOAP message to iSM's SOAP listener and see the result. You can alternatively use SOAP-UI to test locally.

Isn’t that simple? Try it out! ;)

 

Notes:

For security reasons, some spots in images might had been greyed out;

Try to build your custom SOAP listener on a non-base managed server to avoid disrupting iSM's regular inernal SOAP interactions; SOAP commnication is internal method of communication between iIT & iSM Execution Engine.

Coming up next: iSM Scenario with PGP cryptography