Systematic Community

mppowe · ‎09-25-2023

Good afternoon all,

This question has vexed me for a while now. Take an HTTP connector where the authentication requires a username/password to be put in the body of a POST request. The existing connector will now allow that information to be put in the Connector, so it winds up in the action of a recipe. Another example is Workday's SOAP endpoint to return a report.

The docs say to use Environment Properties... but it's all or nothing, not just a single property that has the username/password you need. So you give people access to everything in there, or nothing.

One Workato consultant suggested using a Lookup table, but it has the same problem. Can't give access to only that one Lookup table, it's either all or nothing.

Another Workato consultant suggested making a separate project that houses the "secure" connectors or recipe steps, and then only give access to that project to the ones who need it. We were starting to set this up, but then realized that the users only get one Collaborator roles, not multiple. So it's not like you can set up a role that just gives access to the "secure" project and give that out as needed. Rather, you need a role to give a developer access to all the projects minus the secure one, then another role to give all the projects. Then if another need for secure connectors/recipes arises in a different functional area, we'd have a 2nd secure project and then need a role giving access to:

Everything except secure project 1 and 2
Everything including secure project 1, but not secure project 2
Everything including secure project 2, but not secure project 1
Everything including secure project 1 and 2

This would get more and more complicated if there were more secure projects, or other kinds of mixes or security needs.

What models have others adopted, or what do you WISH you adopted in hind-sight? 🙂

Thanks,

Mike

javier-riesco · ‎10-04-2023

Hi @mppowe , thank you for providing feedback on my response. Here are some quick comments:

The ability for a user to have multiple roles might cover situations like the ones you described. My suggestion would be to raise an enhancement request for the Workato Product team to evaluate. You can submit a new enhancement request for Workato via the "Resource Hub" under the section "Give Feedback".
In addition to the suggested approach, there are a few other things that might help:
- You can define properties within the environment or project level, including words like "key", "password", or "secret" in the name. Workato will automatically mask the value of these properties. You can then restrict user access to only "View" these properties.

Furthermore, you can mask the HTTP call step in the recipe by following the steps outlined in the data masking documentation. Additionally, you can restrict editing the recipe in higher environments, such as Production, to prevent the data masking from being disabled for that step.

Let me know your thoughts.

View solution in original post

javier-riesco · ‎10-05-2023

Thank you @mppowe for this very interesting conversation and the exchange of ideas 😀. It is of great help to understand and improve the platform among the entire community.

Systematic Community

Security best practices with passwords