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)

NOTE: If the Secrets module is enabled and CCM is not registered and the EFT trial expires, EFT will default to local storage to allow EFT administrators to continue to gain access to the site.

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.)