IBM App Connect Enterprise — SOAP WS Security with Security Profile and Vault
In this article we are going to create an integration flow on the IBM App Connect Enterprise (ACE) platform that allows you to expose a SOAP-type Web Service with the authentication mechanism of WS-Security.
The credentials used to log into the SOAP Web Service will be saved within the Vault configured on the IBM App Connect Enterprise (ACE) product.
The necessary to follow this guide are:
- IBM App Connect Enterprise Toolkit
- Docker, or alternatively an installation of the IBM App Connect Enterprise product
All the source code in this article is available in the following Git repository:
IBM App Connect Enterprise
IBM App Connect Enterprise (abbreviated to IBM ACE, formerly known as IBM Integration Bus) is an IBM Integration Broker product that allows the exchange of information between different applications. The product is an Enterprise Service Bus (ESB) and is used in Service-oriented Architecture (SOA).
IBM ACE provides functionality to build solutions needed to support various integration requirements through a variety of connectors for a variety of data sources. An advantage of using IBM ACE is that the tool enables existing applications for Web services without costly rewrites of legacy applications.
The free version for product evaluation can be downloaded from the following link.
Creating and configuring an Integration Server
First, let’s create our Docker image of the IBM App Connect Enterprise product. IBM has released its official product image at the following link.
Unfortunately, the official image does not include the possibility of using the product Vault configuration, so let’s create a custom IBM ACE docker image, adding the configurations for creating the vault:
As shown above we have a Dockerfile that extends the IBM base image and then we are going to copy the bash script, which contains the configuration and creation of the vault called “ace-local-vault” and the creation of a credential with these specifications:
- Credential Name: myCredential
- Username: myUsername
- Password: myPassw0rd
If we want to insert more credentials it is sufficient to modify the “create-local-vault.sh” file and build the image.
To create the image we run the following command, in the same directory where the files are present:
docker build -t ace-server-vault --file Dockerfile .At the end we will have our Docker image with the name of “ace-server-vault”.
To run the container from our image we use the command:
docker run --name ace-server-vault \
-p 7600:7600 \
-p 7800:7800 \
--env LICENSE=accept \
--env MQSI_VAULT_KEY=ace-local-vault \
--env ACE_SERVER_NAME=ACESERVER \
ace-server-vaultIn the above command we pass the environment variable “MQSI_VAULT_KEY” with the name of our vault to make IBM ACE understand to use the vault.
From the browser by going to the administration console we will see our ACE Integration Server active.
To access the console we use the link:
Now moving to the “Credentials” tab we will see our credential created with the bash script.
Definition of Security Policy
From our Development Toolkit we create a Policy project and create:
- Policy — SecurityProfile
In the newly created Policy we set the “Type” to “security profile” and we are going to define which authentication and which credentials the flow should use to validate the username and password pair.
We create it as shown in the following image:
In the “Authentication” field we go to set “Local”, so IBM ACE will look for the specified credential “myCredential” in the system Vault.
- WS Policy Sets and Bindings
A modal window will open and we will create a new “Policy Sets” (in the example below it is called “WSSecurity_Custom”) and set the “uname_token” value as “Token Name”.
Now we create the “Policy Set Bindings”, in our example “WSSBidings_Custom” and we associate the “Policy Set” just created above, and we indicate what kind of Policy it is, in our case of type Provider as it will be enabled on a SOAPInput node.
Now our Policy project will consist of the following files:
Now we can deploy it on our Integration Server:
By accessing the administration console we will find our Policy project.
Apply Security Policy to an Application
In this example we are going to create our application to test the configuration and functioning of the WS-Security policies.
Let’s create an application (called “WSS_Test”) that will contain a WSDL that we are going to expose with a SOAPInput, the main Message Flow and a Mapping object.
The Message Flow will be composed as follows:
While our Mapping implements the service logic:
Now our application is ready and all we have to do is apply the Policies to our application.
First we need to create a BAR file, then opening it from the Toolkit we go to look for the SOAP Input node and apply the properties to the node. The string pattern for setting policies is as follows:
{PolicyProject}:PolicyNameIn our case we are going to set:
- Policy Set → {WSS_Policy}:WSSecurity_Custom
- Policy Set Bindings → {WSS_Policy}:WSSBindings_Custom
- Security Profile → {WSS_Policy}:WSS_SecurityProfile
Let’s save the BAR and deploy it on the Integration Server.
Also from the administration console it is possible to view our deployed application:
From the browser it will be possible to view the deployed WSDL:
SOAP WS-Security Test
To test our development we use the SoapUI tool, create a new SOAP Project and set the WSDL of our deployed Service:
We execute the first SOAP Request without setting up any Authentication:
As we can see from the image above, the Service responds with a SOAP Fault as it has not passed the authentication.
Now on the SoapUI project let’s go to configure the WS-Security:
Now let’s set the WSS configuration on SOAP Request:
As shown above, the Service now responds correctly, a sign that authentication was successful!
