elsa-core
elsa-core copied to clipboard
Multitenancy
TODO: Add support for DB connection pooling with tenants:
https://learn.microsoft.com/en-us/ef/core/performance/advanced-performance-topics?tabs=with-di%2Cexpression-api-with-constant#managing-state-in-pooled-contexts
TODO: Add support for DB connection pooling with tenants:
https://learn.microsoft.com/en-us/ef/core/performance/advanced-performance-topics?tabs=with-di%2Cexpression-api-with-constant#managing-state-in-pooled-contexts
Actually, the Store<T> utility class used internally already handles application of the current Tenant ID, rendering the custom DB context factory unnecessary. Although that would have been a more elegant solution, unfortunately the creation of a DB Context is non-async, while tenant resolution is async (for e.g. resolving the current tenant from the current user).
Feedback:
-
Add a little architectural documentation about how multi-tenancy works in terms of security on various levels.
-
Do we add tenant ID to the message properties (e.g., ASB message metadata)?
- It would be nice to have this in stage 1. Can be helpful with monitoring and troubleshooting and will enable more advanced use cases in the future.
-
Workflow definitions:
- Nice to have: list of
AuthorizedTenantson workflow definition, so that we can allow tenants to start a workflow that they don't own. They will be able to see it (read-only) and start it, but not alter it (because they are not the owner tenant). - If we think this through, we could even add authorizations to definitions, which may allow having more detailed authorizations, e.g., contributing in editing of a workflow by another tenant, and more.
- Nice to have: list of
-
What happens when we have multi-tenancy enabled, we have multiple tenants and data for these tenants, then someone disables the multi-tenancy.
- What happens technically?
- What is desired as a security safeguard to protect against wrong config and data leak? What is desired as strategy/strategies to ensure the system is secure and works in a desired business environment?
-
What happens if we have data without multi-tenancy, then we enable multi-tenancy with one or more tenants?
- What happens technically?
- What is desired as strategy/strategies to ensure the system is secure and works in a desired business environment?
Quality Gate failed
Failed conditions
5 Security Hotspots
33.5% Duplication on New Code (required ≤ 3%)
C Reliability Rating on New Code (required ≥ A)
See analysis details on SonarCloud
Catch issues before they fail your Quality Gate with our IDE extension
SonarLint
I've been testing this out as it's key to our usage of Elsa. I've added an implementation of the tenant resolver to use our current tenant resolution logic but it loses context when sending messages to the mediator. There is no context of the active user any more.
How are you planning to manage the tenant resolution on the mediator execution? Are you thinking of something along the lines of adding the TenantId to the ICommand interface and then setting the execution context using IAmbientTenantAccessor as I see the AsyncLocal there would handle this well. This would probably require AmbientTenantResolver to always be part of the resolution strategy though, not sure whether you should be able to configure it's not.
Hi @Itzalive
Thank you for trying out the feature so early and for offering your concern.
The mediator handler should have the same context as the code that fires the notification or command. If this is not the case, can you provide me with an example of a case where this context gets lost?
Converted PR to Draft mode because I'm merging in #5444. Once #5444 merges into main, I'll do another update of main into this PR.
Response to Multi-Tenancy Configuration Questions
Scenario 1: Disabling Multi-Tenancy After Being Enabled
Technical Impact:
- When multi-tenancy is disabled after being previously enabled, all records that were associated with specific tenants become invisible. This is because those records are linked to a tenant ID. Only records with a NULL tenant ID will be returned and visible in the system.
Scenario 2: Enabling Multi-Tenancy on an Existing Data System
Technical Impact:
- When multi-tenancy is enabled on a system that initially did not use it, any existing data not associated with any tenants will not be visible because these records will have a NULL tenant ID.
The mediator handler should have the same context as the code that fires the notification or command. If this is not the case, can you provide me with an example of a case where this context gets lost?
For example, the DispatchTriggerWorkflowsRequest and DispatchResumeWorkflowsRequest commands which execute on the mediator. They have a string of the bookmark/event name but no tenant awareness. If two tenants have a bookmark with the same name, they will both be fired. The mediator, as I understood it, processes ICommands which have been persisted for later execution and so when it loads an ICommand there is only the information within the ICommand to set the context.