[FEATURE IDEA] Multi-client integrations within same workflow

[topher-lo]

Is your feature request related to a problem? Please describe. I want to use multiple instances (i.e. different inputs / credentials) of the same type of integration (e.g. list SIEM alerts) in a workflow.

Example: real world example would be that I am an M365 customer, and I acquire another business that is also an M365 customer. We are very likely not going to be able to transition all mailboxes and users off of that environment on day 1, but if I'm using a workflow where on a certain type of alert I want to reset a user's password and then contact them, how would I interact with both M365 environments in the same workflow since all users won't exist in one or the other?

Originally posted by @mattdurant in https://github.com/TracecatHQ/tracecat/issues/268#issuecomment-2251099046

[topher-lo]

Additional comment from Discord:

We have another use-case where we suspend M365 users. Easy enough to do if you're a single tenant, but we are an MSSP - so we'd feed in the organization ID/name as well as the username and that would automatically then choose which set of client_id's, client_secret's etc. to use. Basically a dictionary that maps a set of keys to another.

Is there a native feature-set or integration that does this or something close? Otherwise we could probably build our custom integration that has a basic python dictionary just built in. Just means changes would need to be made on the back-end each time, or we could pull data from some DB etc.

i.e. 'Oh that's customer X, so we need to use key X and access M365 env X', or 'Customer Y to key Y to M365 env Y'

My thoughts

• Secrets should be separable via both workspaces / teams (with row-level security aka multi-tenancy) and via tags within the same workspace (NOT row-level security but useful for the above use-case).
• Tagging provides some level of segregation of secrets at runtime but this isn't necessarily "secure by design"
• For unambiguous segregation between clients, users should still rely on workspaces (and just duplicate workflows).

Medium term ideas

• We can eventually build out a command and control tower for playbooks / workflows. So MSSPs can deploy, update, and delete playbooks across multiple clients where clients are separated by workspaces / teams (row level security).
• ^this will have workflow duplication, but it'll be the more secure option over just a hash map AKA tagging within one shared workspace / workflow