Best practice to embeding credentials into a workflow
Hi,
Just a general question around best practices for securely embedding credentials into a workflow. From what I understand:
- Client-side workflows expose credentials in the browser console, making them easily accessible to users.
- Server-side workflows offer better protection, as credentials aren’t visible in the console. However, users could potentially download the workflow JSON and extract credentials.
What approaches are others using to securely manage third-party credentials within your workflows? Appreciate any insights or suggestions you might have on this. Kind regards aaron
-
As far as I know, there isn't really a proper way to do this.
What I usually do is store credentials in an external file, and open that file in a server workflow. Unfortunately, the filename in the workflow can only be a hardcoded static path, so you can't use e.g. an environment variable such as %ProgramData% or %UserProfile% to store the file in a generic place.
0 -
Aaron Thorn I want to offer a slight correction to what you said about server workflows. Regular users can't download the workflow JSON for a server workflow.
The contents of a server workflow are only saved on the server itself within the Data Directory that was specified in the Post Installer.
When a server workflow is executed, the workflow is loaded from disk on the server and executed there. Only the workflow outputs and artifacts (such as logs) are exposed.
The actual content of the workflow itself is only exposed when the workflow is loaded into the on-prem installation of the Workflow Designer. You need to be the owner of the workflow to do this.
0 -
BTW: Other than the owner of the item, one can also be a member of a shared update group.
One possible design is to have the external file (or database table) store the User ID and password. The server workflow could simply query for the needed password, based on the provided user ID, but instantly use it to generate a token. The resultant token ID is passed back the client workflow.
Theoretically, one can go one step further and save the resultant token into memory (with a defined expiration) to reduce the number of times the server workflow is called.
0 -
Mike Diss-Torrance Thanks for that added detail. Yes, a shared update group can also edit the workflow and see its contents.
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
4 commentaires