Security best practices with passwords

[mppowe]

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:

1. Everything except secure project 1 and 2
2. Everything including secure project 1, but not secure project 2
3. Everything including secure project 2, but not secure project 1
4. 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]

Hi mpow, very good questions. Please take a look at these two recent updates in the platform, Project-level properties and lookup tables, that allow users to control access to the potentially sensitive data in properties and lookup tables.

• The access is open without any limitations (no specific plan, addon or ad-hoc feature is needed).
• The project properties are located in the “Project settings” tab and can be used only for recipes in the same project. Only users who can see this project & have permission to “Project properties” can use them.
• The user can change the availability zone for lookup tables from “All projects” (default) to a specific project. After that, only the users who can see this project & have permission to “Lookup tables” can use them.
• Each project can have the “Project property” with the same name. But the Platform doesn’t allow two lookup tables with the same name.
• The user can’t set the “Home assets” project scope for lookup tables and create project-level properties there.
• Both enhancements are available via API, too.

[mppowe]

Thanks for replying @javier-riesco, I wasn't aware of those enhancements.  However, I think we still run into the same issue.  Limiting access to these passwords by project is similar to the "project-secured" option I described above in the sense that it still requires a bunch of custom roles to be created to cover every kind of wrinkle we'd want covered b/c each person can only have one role assigned.  I think the long-term answer here is the ability to assign multiple roles to each user so specific assets can easily be protected and then just that one thing given as needed, rather than creating entire new roles for every kind of permission set needed.

Or maybe there's something I'm not thinking of?  Given the scenario I described in my original post, where I have an HTTP connector with a password in the post body, and a Workday SOAP action to call a report that requires the username/password in the body.  I want to restrict access to those credentials to as few people as possible, and also know that more of these kinds of connectors will come in time.

What is Workato's recommendation in dealing with those situations?

Also would love to hear other perspectives.  Thanks!

[javier-riesco · Accepted solution]

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.

[mppowe]

@javier-riesco  thanks for the response.  Good to know about the masking in the Properties, but it still feels like a workaround.  Then developers who create the connection that requires sensitive handling need to get an admin to create the entry in the Environment properties, and if ever a change needs to happen an admin has to do it, even though these are credentials specific to a particular recipe/integration in one functional area.

In short, it seems that the current security model doesn't allow a straight-forward way to enforce the principle of least privilege.  I was going to write an enhancement request but it seems one already exists: https://ideas.workato.com/app/#/case/230911, which is the ability to assign multiple roles.

If you're reading this post and think it would be a good idea to allow multiple roles to be assigned to a user as a means of enforcing the Principle of Least Privilege, please upvote that idea.

Thanks!