Search This Blog

Tuesday, April 19, 2016

Encrypting and Decrypting FDMEE Passwords for Scripts

I have been working with FDM Classic and FDMEE for some time now and when working with passwords it gets interesting.  There are multiple options for adding layers of password protection for FDM/FDMEE scripts.
  1. Hardcoded passwords (definitely causes exposure)
  2. Custom encryption/decryption script/compile program
  3. Leveraging a password vault with API calls 
  4. System environment variables 
  5. ODI encryption and decryption process
  6. Leverage FDMEE's Encryption and decryption process
  7. etc...
Note: All of the options above are only as strong as you can secure the scripts from unauthorized access to the scripts or encryption\decryption code.  The key is to limit access and build in layers of security for process. 

In the past I would build a custom script to perform the encryption/decryption when needed, which works great but requires maintenance.  I read a great FDMEE Encryption Blog by Francisco Amores, where he leverages ODI to perform the encryption and decryption process. He broke down the process leveraging ODI and a custom script to retrieve the encrypted passwords from the ODI/FDMEE repository.  

The option that I like to use leverages the FDMEE Encryption/Decryption process outlined within the FDMEE Admin guide.  

Step 1: Create Encrypted Password Text File

Follow the instruction in the admin guide to create a encrypted password text file in the FDMEE password directory, which is defined within FDMEE system setting. 


If we look within the EncryptPassword.bat file we will notice a call to three different .jar files. 
  1. aif-batch.jar
  2. epm_j2se.jar
  3. registry-api.jar

The import jar file is the registry-api.jar which contains the encrypt and decrypt process the FDMEE uses when running the EncryptPassword.bat from the command line or FDMEE batch jobs that require a password.

The trick is to leverage the jar file in our custom FDMEE scripts when needing to access a SQL database or other secure process that requires a password. 

Step 2: Import the registry-api.jar Encryption process

Create a jython script and load the registry-api.jar for access to the encryption process.

#Import the encryption process
import com.hyperion.hit.registry.Encrypter as Encrypter

Step 3: Get the Encrypted password from UserName file

import os
#get the password file
uid = "BReynolds"
uid_filename= uid + ".fdmee"
strFile = "//<ServerName>/FDMEE_DATA/PASSWORD/" + uid_filename
#get the encrypted password
if os.path.exists(strFile) and os.path.isdir(strFile) == False:
 #can put conditions around the file that is opened
 p = open(strFile,'r');
 enc =;

In order to leverage the code multiple times we can pass variables to complete the uid_filename so that different processes can set the uid variable. In this example it is very simplistic for example purpose, but can be more dynamic based on FDMEE location attributes. 

Step 4: Decrypt Password for use

#decrypt the encrypted password
dbPass = Encrypter.decryptString(enc)
fdmAPI.showCustomMessage("Encrypted Password: " + str(enc) + " Decrypted Password: "  + str(dbPass))

Once we decrypt the password using Encrypter.decryptString, it can be read into a variable or called directly into the password input parameter.

I hope this helps everyone out there create a better way to handle passwords in scripts.  All feedback is always welcomed.


  1. Is any way to encrypt the db login password in actual jython script

    conn = sql.DriverManager.getConnection("jdbc:sqlserver://TESTDEV\NI1:1433;databaseName=DEV_FDMEE;user=test_dev;password=2020TSTuser;");

    .Please provide me with the sample script or is there any other suitable method for encrypting the password.Both dblink and base64 encode did not work

    1. If you use the encryptpassword.bat, you will then have an encrypted password stored in a flat file on the password directory specified in FDMEE system settings. The process at that point is to decrypt it when you make your db connection call.

    2. This comment has been removed by the author.