Skip to main content

Secret / Password Encryption

There are a few cases where any account secret / user password is stored in the repository database using an encryption method that is two-way in order to restore the original password just before calling a third-party API later:

  1. When configuring metadata harvesting (Model > Import > Setup), some bridge parameters require authentication to the source technology / server (e.g. user / password of a database or a BI server)
  2. When configuring LDAP based authentication (MANAGE > Users > LDAP)
  3. When configuring Email notification (MANAGE > Email Notification)
  4. When configuring Cloud Identity (MANAGE > Cloud Identity)

Because of this requirement, TDC cannot use key-based industry standard encryption. It instead stores such user/password in the repository database (i.e. at rest) using a confidential proprietary reversible encryption algorithm based upon industry standards.

NOTE 1 : A second level of encryption can also be used during transport (i.e in motion) using 6.5 Custom integration for Secure Socket Layer (SSL) communication

  1. HTTPS for remote metadata harvesting from the main TDC Server and a remote Harvesting Agent / Server.
    See Configuring SSL to access Remote Servers
  2. LDAPS for authentication to the Enterprise Directory.
  3. When using LDAP based authentication.
    See Configuring the MM Application Server to securely connect via LDAPS to the Enterprise Directory

NOTE 2 : Alternative secret / password encryption and external storage solutions are available using Cloud Identity and Cloud Secret Vaults (such as Amazon Web Services, Microsoft Azure, or Google Cloud).
See, MANAGE > Cloud Identity

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!