Adobe Campaign Classic - Storing credentials for external api calls | Community
Skip to main content
Ken_Qrious
Ken_Qrious
Level 4
July 29, 2021
Solved

Adobe Campaign Classic - Storing credentials for external api calls

  • July 29, 2021
  • 3 replies
  • 2665 views

We are setting up work flow to call an external json api and the api call requires a secret to be passed.  What is the best way to store the secret in a secure manner in adobe campaign so that it can be retrieved in a technical work flow?  

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by Krishnanunni

    Hi @ken_qrious ,

     

    You may store the credentials on SFTP as a text file encrypted using GPG. During workflow execution, decrypt the file and use it to call API. At the end of workflow, delete the decrypted file. This will prevent the direct exposure of credentials. But anyone knowing the file location might be able to execute a decryption.

    Otherwise you can set the credential in advanced tab of JavaScript activity and then restrict the access to the workflow. But administrators might be able to modify the permission.

    3 replies

    Darren_Bowers
    Darren_Bowers
    Level 9
    July 29, 2021

    Hi @ken_qrious

    Each instance has its own encryption key that is unique to its instance (i.e. values encrypted on one instance cannot be decrypted on another) - this is used to encrypt things like external account passwords, but since the decryption routine is available via the API, anyone who can see the encrypted value can decrypt these "secrets" in a workflow using decryptString(). So its technically no more than security via obfuscation if your user model allows some users to have administrator access.

    You can use cryptString() and decryptString() if you want to store the value in a schema or Option variable, but if anyone recognises these they can just try decryptString() on it to see if that is what you encrypted it with.

    You could create your own encryption / decryption routine using JS, but you need to store the private/decryption key somewhere that is accessible to the user running the workflow, hence making it insecure. You can put the workflow in user restricted folders accessible to some users and hide the key in there. Use that restricted user to run the workflow and post the results into another schema.

    You could create a schema that is restricted to a special user that stores the encrypted passwords, but anyone with administrator rights could also see this.

    I've never found a truly secure way to store and retrieve secrets that cant be compromised by bad internal actors, but are always keen to hear how other have solved for this.

    Cheers

    Darren

     

      Ken_Qrious
      Ken_QriousAuthor
      Level 4
      July 29, 2021
      Thanks for the useful information. Nice to have a few options to consider.
      Krishnanunni
      KrishnanunniAccepted solution
      Level 4
      July 29, 2021

      Hi @ken_qrious ,

       

      You may store the credentials on SFTP as a text file encrypted using GPG. During workflow execution, decrypt the file and use it to call API. At the end of workflow, delete the decrypted file. This will prevent the direct exposure of credentials. But anyone knowing the file location might be able to execute a decryption.

      Otherwise you can set the credential in advanced tab of JavaScript activity and then restrict the access to the workflow. But administrators might be able to modify the permission.

        Ken_Qrious
        Ken_QriousAuthor
        Level 4
        July 29, 2021
        Thanks. I'll investigate the options you have mentioned.
        CedricRey
        CedricRey
        Level 5
        July 29, 2021

        Hi,

        As @darren_bowers  said, anyone with admin access could read the password, but we could say that anyone with admin password could read anything in any system ? If the operator is able to read / access your custom encryption library, he could get the password. I think this is not a specific AC issue, but a global problem : the information access must be controled anywhere.

         

        On my side, I usually use an xtk:externalAccount for this purpose. I set an 'HTTP' account type, and I store the password in the password field, the endpoint in the url field etc.

        Because it's the main purpose of an external account : store the access informations, and it's easily configurable on each environement.

        Then, in your code, you have to request (queryDef) the xtk:externalAccount to get the id (queryDef  > select @id> where > condition > expr="@name like 'CustomAccountName'), and when you have the id, you can load the informations : NLWS.xtkExternalAccount.load( id ). With the "decryptString" function, as provided by Daren, you are able to get the stored password (and if you execute this in a workflow, forget the warning about the use of decryptPassword instead of decryptString, beceause decryptPassword is not available in the workflow execution context.....)

         

        Cédric

          Terms & ConditionsAccessibility statement

          Loading footer...