BPM, Workflow, and Case

 View Only

Encrypting credentials in IBM Business Automation Workflow - part 1

By Jens Engelke posted Fri December 18, 2020 05:25 AM

  

With IBM Business Automation Workflow, you can automate workflows that involve human workers and connect to backend IT systems. Depending on the integration technology you choose, you can provide credentials to authenticate system-to-system invocation to these backend systems. Business Automation Workflow uses various approaches for persisting these credentials that are explained in the following sections.

Authentication aliases

Some server definitions can refer to an authentication alias - a configuration construct in WebSphere Application Server. This has many advantages, in particular:
  • Credentials can be isolated for each environment. If you have staged environments such as development, test, and production environment, credentials do not need to be transported between those environments (the prod credential is not entered in a dev system)
  • The authentication alias is independent from the business application versioning. Many snapshots can point to the same alias. Changing the password in the alias is immediately effective for all snapshots.
  • Authentication alias data is persisted in WebSphere Application Server's configuration files using customizable encoding or encryption: https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tsec_securepwds.html 
This option is referred to as "invocation credential".

Selecting auth alias vs. userid/password

Database persistence

Other server definitions persist credentials in the Workflow database either encoded using WebSphere's customizable password encoding or AES encryption. For example, credentials for accessing a remote document management system via CMIS are persisted in the database. When you define an "Enterprise Content Management" server, you can check the "Always use this connection information" checkbox. This will connect to the remote server using credentials specified in the same editor - no matter which end user is active in Business Automation Workflow. Leaving this checkbox unchecked allows you to propagate end user identity.

CMIS server credentials

The "User ID" and "Password" specified here are persisted in the database. They can even be included when you move your app from dev through test and staging to prod:

Server variable per environment type

By looking at database content, we can find that all this connection information is serialized in a URL and stored in an environment variable as follows:
https://my.server:9443/fncmis?repository=docs&connectionUserId=tw_admin&password=ytGJGE86i%2FT3SVw0ULid0Q%3D%3D%3AE%2B%2FAKkW6Z4syYexAVyiKcg%3D%3D&credentialEnforced=true
Obviously, the password is encrypted, which is good. 
We can create a snapshot of this process app, export it in .twx format, and import it into another instance of IBM Business Automation Workflow Center. Or we can use online or offline deploy to install the snapshot in a Workflow Server. Inspecting the export file closely, we will find the exact same URL representation of our ECM server connection information.
In each of these cases, a connection to the Enterprise Content Management System will succeed, that is, somehow the target system was able to read, decrypt, and use the encrypted password - which is convenient, but of course concerning from a security perspective.
This can only be possible when both, the source system and the target system were both using the same key. In fact, the key used in this scenario has been hard coded for many releases and is still used as the default key for backwards compatibility. 

Advanced Database Persistence with Configurable Encryption

With IBM Business Automation Workflow 20.0.0.2, we can do better than that.
With IBM Business Automation Workflow 20.0.0.2, the encryption key for credentials persisted in the database is configurable. See Configuring a key for credential encryption in the knowledge center.
You can set a new key by updating the server configuration with your own keyphrase, which will be used to derive the effective key.

Setting encryption key passphrase

After applying this configuration, all encryption and decryption will use the configured key.  Of course, this configuration does not change anything in your database or in .twx files that you may have exported in the past. 
While import of .twx will still work, the encrypted credential is no longer understood. You can use Process Admin Console to set the same value again.
The same holds for existing process apps in runtime Workflow Servers. You need to set a new password for in all "affected" snapshots.

Setting credentials in Process Admin Console

In case you actually "transport" credentials with process apps between Workflow Center environments or as part of install packages, you can set the same keyphrase in all your "related" systems to allow seamless exchange.


#BusinessAutomationWorkflow(BAW)
#whatsnew

Permalink