Configuring the Secrets Module

The EFT Secrets module allows you to specify a storage location for passwords, authentication tokens, passphrases, and other security artifacts in use by the Site so that security and trust can be centralized. (Requires CCM.)

• The Azure Key Vault (AKV) functionality does not support proxies, so EFT must have direct access to Azure OR the server must reside in Azure.

• See the procedure below for what to do when a key or password changes in the AKV.

• EFT Secrets Primer (Knowledgebase)

The Secrets module can store EFT passwords or other secrets it uses:

EFT Secrets	SQLite SiteConfig.<guid>.db location
AWS Connection Profile	ConnectionProfile table - Settings cell
Azure Connection Profile	ConnectionProfile table - Settings cell
Folder Monitor Override	EventRules table - Trigger cell
Event Rule passwords	EventRules table - Statements cell
SSH Key	SSHKey table - Password cell
SSL Certificate	Site table - Connections cell
ODBC Parameters	Site table - General cell
PGP key	Site table - Security cell
AS2	Client table - AS2 Outbound cell
Webservice	EventRules table - Statements cell
Proxy passwords	EventRules table - Statements cell
Override VFS credentials	Site table - General cell

You can specify:

• Store secrets in Azure Key Vault (AKV) via authentication token

• Store secrets in Azure Key Vault (AKV) via Managed Identities

The Secrets module includes "hooks" into Azure Key Vault storage. When a secret is needed, EFT will request it from storage. When EFT is NOT hooked into a third-party secure vault, it will use it's default security key to protect its Secrets module. An Azure secure token will be requested on startup and will be updated 5 minutes before it expires. When the Secrets module storage is changed, EFT gets secrets from current storage and saves them into new storage.

To configure the Secrets module

Before performing this procedure, refer to Configuring Azure Key Vault Support for EFT to create the Client ID and Client Secret.

1. In the administration interface, connect to EFT and click the Server tab.

2. On the Server tab, click the Site, Settings Template, or user that you want to configure.

3. In the right pane, click the Security tab.

4. In the Data Security area, next to Secrets module, click Configure. The Secrets Module Configuration dialog box appears.



5. Select the Enable backup storage check box to backup secret storage. The backup options appear.

6. In the Backup area, click the Type drop-down list and select an option:

• Store secrets in Azure Key Vault (AKV) via authentication token

• Provide the Key Vault URL, Client ID, and Client Secret used to access the Azure Key Vault.

• Store secrets in Azure Key Vault (AKV) via Managed Identities

• Provide the Key Vault URL

7. The Write secrets to backup in addition to primary check box is selected by default. Clear the check box if you do not want to write secrets to backup or if the backup vault is kept in sync by a third party, such as Azure's vault backup. If the check box is not selected, EFT will not write to backup, but will attempt to read from the backup if the primary is unavailable, which may fail if the vaults are not kept in sync by the third party.

8. Click Test to ensure EFT can access the vault and that your Azure credentials are correct.

• If you receive a Connected failed error message, verify your connection string, logon credentials, and that access to the Vault has been granted (if using managed identities).

9. Click Proxy to define a proxy server, if needed. (The Proxy applies to both the primary and the backup.)

10. Click OK to save the configuration, then click Apply on the Security tab.

What happens if the password/key in Azure is changed?

If you click Test and are presented with a connection failed error after it has been previously been connecting, it is likely that your Client Secret has expired.  

DO NOT DELETE THE OLD SECRET UNTIL AFTER YOU CREATE A NEW ONE, AS SHOWN BELOW.

To allow EFT to connect to the key vault, EFT needs to be configured in the Azure Key Vault under “App registration.” This is where the Client ID and Client Secret are generated. The secret is based off a client secret that will provide a value that is used in EFT. Azure’s App registration allows the client secret to expire in 1 or 2 years or never. An Azure administrator can create a new Client Secret as needed. If you have configured your secret to expire, set yourself a reminder to update the secret before it expires—EFT will not report an error that the AKV connection is failing.

The steps below are required to ensure EFT can connect to Azure AKV without issues when the client certificate is updated. The following procedure assumes that the App registration has already been created.

If the Client Secret has expired or been updated

1. Within Azure’s Active Directory settings, click App registrations.

2. Click the EFT created registration app.

3. Click Certificates & Secrets.

4. Create a new client secret. (Note: Do not delete the old Client Secret until EFT connects to the new one!)

5. Save the new client secret value. (Copy it since it will be used in EFT.)

6. Login to the EFT administration interface.

7. On the Site > Security tab, next to Secrets Module, click Config.

8. Paste the new Client Secret (the value from step 5 above ) into the Client Secret field.

9. Click Test to confirm the connection is successful.

10. Restart EFT and ensure you can still connect.

11. If connection was successful, delete the old Client Secret in Azure.

The following COM API property and enums are provided:

SecretsModuleType

• SecretsModuleType_LocalPasswordsStorage,

• SecretsModuleType_AzureKeyVault,

• SecretsModuleType_AzureKeyVaultManagedIdentities

The ICISiteInterface provides the following read-and-write properties:

• SecretsModuleType

• SecretsModuleURL

• SecretsModuleClientID

• SecretsModuleClientSecret

(Refer to the COM API documentation for more information.)