Multitenancy

[craigfowler]

An area of functionality which has been requested a few times across various mediums (issues, discussion, chat) is support for multi-tenancy.

This is a quite wide subject with numerous potential interpretations. Before it can be conclusively implemented we should answer such questions as:

• What does multi-tenancy mean to Elsa?
• What model(s) of multi-tenancy should Elsa support?
• What should be left to the consuming application?
• What will Elsa explicitly not-support?

Once we have a better understanding of the requirements, we can formulate a strategy for support and schedule appropriate enhancements.

Roundup of related issues

The following are issues which relate to requests for multi-tenancy. It should be added-to as further issues are raised/found.

• [ ] #762 - variable workflow definitions/logic per-tenant

• 140 - discussion/request for support

• [ ] #242 - another issue/story for multi-tenancy
• [ ] #221 - touches on multi-tenancy

[tomy2105]

First thing about multi-tenancy that comes into my mind is user authorization (for dashboard and designer). How else do you know which workflow belongs to which tenant?

[craigfowler]

That's an interesting point.

Elsa & authorization

I don't personally think that Elsa should get too deeply involved in auth. The main reason for that is that we can't predict every app's authentication/authorization model. I think that at absolute most what we should do is provide an extension point/hook which is something like:

public interface IGetsPermissionToEditWorkflow
{
  bool CanEditWorkflow(string workflowCorrelationId);
}

Our default impl of that class would be to hard-code a true result every time. But then a consumer of Elsa may supply their own impl via DI and add whatever logic in there that they want.

One multi-tenancy example

As it happens, "my day job customer" is using Elsa in an app which is already multi-tenant. We achieve this by:

• Using Single Sign On (happens to be Identity Server) which knows about all of the tenants
• When a user logs into the app, they may choose between the available tenants
  • We have some tricks in play which means some URLs cause the tenant to be pre-selected and hidden from the UI
  • Different "identity" users have mappings to different levels of permission in different tenants
  • So joe@example.com might be an Admin on Tenant A, might be a regular user on Tenant B and might not be allowed to access Tenant C at all
• Once login is complete, the "current tenant" for that login session is held as one of the claims within the authentication token
• Each tenant's data is stored within a different instance of the application database (literally a different connection string).
• We use a combination of that "current tenant ID" claim and an app/tenants configuration to generate a connection string
  • DI makes sure that when we get a DB connection anywhere in the app, it came from the correct tenant-specific DB
  • The connection itself is scoped per HTTP request, so everything in a single request uses one connection

Now, we've already got this implemented just fine, actually using Elsa 1.4 (we'll upgrade probably once 2.0 is ready for stable release). Elsa itself knows nothing about our users, or our multi-tenancy setup. All we needed to do (in our closed source app) was to extend the registration mechanisms for Elsa. That was partly replayed back into Elsa as open source contribs in #748 (actually some of we had done had already been done as part of Elsa 2.0!).

We are kind of lucky though in that we don't use the dashboard or designer UIs yet. The user-specific configuration/customisation of our workflow(s) is already built into the app (we used to use a different workflow product) and so we already have our own UI for doing all of that, and it already respects our own auth rules.

[tomy2105]

Thanks for the explanation of your use case. I agree Elsa should have an interface for multi-tenancy/authorization and implement true by default. But would definitely like to see this interface include "all" aspects of multi-tenancy in elsa (for example connection string fetching through that interface). Or at least ones that you described and know of (since you already did it) combined with dashboard and designer.

[craigfowler]

Exactly, I think that's a good starting point for the discussion which needs to happen. Indeed, one possible strategy to supporting multi-tenancy might just be to support all of the right extension points to do all of this stuff (part of the work we'd need to do is to identify what those are).

There's lots of possibilities available and at some point I think we're all going to have to get together and make our minds up. Right now priority no. 1 is getting Elsa 2.0 out of the door, and so we're not focussing too much on multi-tenancy. That doesn't mean we're not accepting ideas and talking points though.

[tomy2105]

So would it be possible to make a place/hook in Elsa 2.0 dashboard/designer to include custom JS code which could be fired and executed in cases where API calls fail due to the fact that they weren't authorized? And of course ability to add custom headers and or cookies to the API calls (namely authorization header one I guess).

[sfmskywalker]

We can definitely add that, it makes sense.

[ghost]

Elsa is good enough workflow engine, multi tenant should be something handled outside wrapped to Elsa and set the required DB connection to it

instead of making Elsa jack of all its better Elsa becomes just master of workflow

[tomy2105]

That depends on the how you define multi-tenancy @khan-mail-com Your approach assumes (or at least that is how I read your comment, sorry if I'm mistaken) that each tenant has its own database (so all you need to do is point Elsa to different db). However what about when you want multiple tenants inside each database?

Moreover even if they were inside same database, when (and how) would you point Elsa to different database? At each inbound HTTP request? Yes this is possible probably. But since workflow can continue on timers/schedules without inbound requests that leaves two places where it should be possible, and probably many more....

I agreee that some stuff should be left outside of Elsa (like user auth, etc....). But elsa definitely needs to be "internally" multi-tenant and have hooks for all the cases where you want to somehow "tell" it which tenant to use (either by completely switching database or by changing some internal id of a tenant when multiple tenants are inside same db).

[ghost]

Yes, multi-tenancy for separate DB, all you need to do is point to separate DB but i think HangFire services may require to configured to point each of DB to run schedules

for same DB, we need to apply the context filter with the tenant ID, which is again a top layer thing

On Tue, Nov 23, 2021 at 5:08 PM tomy2105 @.***> wrote:

That depends on the how you define multi-tenancy @khan-mail-com https://github.com/khan-mail-com Your approach assumes (or at least that is how I read your comment, sorry if I'm mistaken) that each tenant has its own database (so all you need to do is point Elsa to different db). However what about when you want multiple tenants inside each database?

Moreover even if they were inside same database, when (and how) would you point Elsa to different database? At each inbound HTTP request? Yes this is possible probably. But since workflow can continue on timers/schedules without inbound requests that leaves two places where it should be possible, and probably many more....

I agreee that some stuff should be left outside of Elsa (like user auth, etc....). But elsa definitely needs to be "internally" multi-tenant and have hooks for all the cases where you want to somehow "tell" it which tenant to use (either by completely switching database or by changing some internal id of a tenant when multiple tenants are inside same db).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elsa-workflows/elsa-core/issues/764#issuecomment-976588105, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKECRB7DBK43UJIMY5RV5CTUNON7PANCNFSM4ZHLREBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[vgb1993]

I have to support both multi-tencancy modes. This would be super usefull.

[gentledepp]

Well being able to have multi-tenancy by using a separate database for each tenant is gread. We use abp however, which also allows to keep tenants in a single database. In that case, we have a "int TenantId" property on every entity which denotes the tenant. The EF DbContext then automatically applies the filter to get only the current tenant data.

I read that for ELsa 3 the storage api is revised to make it easier for devs to create their own storage provider. Does this then also allow us to add such a "tenant filtering" mechanism?

[jspitman]

I see in the code that there is a reference to TenantId, so it looks like it has been implemented in Elsa to a certain extent for single database approaches.

It might be interesting to look at a library like FinBuckle and the patterns it uses to introduce multitenancy into .NET projects. That could provide an essential guide for opening Elsa up to multitenancy through other frameworks. Aspects of better access to DBContext in Elsa and implementation of options builders.

[sfmskywalker]

@jspitman I had not heard of FinBuckle before, will look into it. Thanks for pointing it out!

[vgb1993]

I’m not a 100% sure but I think it had some issues with Blazor. Maybe I’m wrong. Anyway we’re doing multitenancy in our new Blazor app without it and it works just fine, it’s simpler. Maybe it’s not needed. Just saying.

[Gryhyphen]

Re: MultiTenancy,

Am investigating different workflow automation tools for work. Elsa looks pretty good but part of my evaluation is looking at aspects like multitenancy and project separation, which is an area Elsa performs poorly in.

Another product I'm comparing it to is Dolphin Scheduler, which allows for both multitenancy and project separation. It is however, excessively complex and unintuitive for our intended audience (operators/tier 2), which is something that Elsa does really, REALLY, well.

Ultimately, cause elsa is .net, we can probably roll our own nodes to ensure that data for one organisation never hits an endpoint or accesses data outside of what it is allowed, and edit the dashboard to allow us to filter on orgs, but ya know, that is a pain. Or we would need to spin up multiple elsa instances (like logic apps), and put some sort of proxy service in front of it, which is still, a pain.

Definitely something I think elsa should support, but I'm biased because it would make my life easier haha.

[sfmskywalker]

Hi @Gryhyphen,

Thank you for your detailed feedback on Elsa's multi-tenancy capabilities compared to other tools like Dolphin Scheduler.

I completely understand where you're coming from. Multi-tenancy is indeed an essential feature, and we are committed to improving Elsa in this aspect. While Elsa 3 offers features like Events and the Webhooks module, and also ensures extensibility for cross-app communication via service bus messaging, I acknowledge that there might be areas where it falls short in terms of project separation and multi-tenancy.

Could you perhaps provide specific instances or features you found lacking or any suggestions for improvement? This would greatly help us refine and potentially update our roadmap to better cater to your scenarios.

Our 2024 focus is on enhancing the maturity of the Elsa engine for scalable production use, which encompasses multi-tenancy and security.

Again, I appreciate your insights and look forward to hearing more from you!

[Gryhyphen]

@sfmskywalker Sorry for not having time to respond. Work gets hectic, you know how it is. We are still rolling our own internal workflow management stuff which is a pain in the neck (one of those, designed for a specific purpose, then grew into a mess) so haven't had much luck progressing this. We have been looking more into logic apps because that is what some larger parts of our organisation are trained on, and leveraging existing resources obviously is a good linchpin to pivot and advocate for a better workflow management solution.

I have noticed that Elsa has recently added multitenancy support as part of this PR https://github.com/elsa-workflows/elsa-core/pull/5159

However, it doesn't seem to have been documented yet, and it would be hard to argue a use case in my organisation if I can't evaluate if this multitenancy functionality suits our needs.

We do document intelligence processing, so taking in human-readable documents like purchase orders, and integrating them into erps. As a multitenant app, we have multiple organisations using our services, and thus need mechanisms to restrict workflows to specific tenants at the levels of the:

• Endpoints/webhook: we don't want to be integrating data for an endpoint for the wrong organisation, so we need some mechanism for elsa to blow up and tell us "oops wrong token for this endpoint, you are probably sending data to the wrong erp"
• Project grouping: some sort of grouping mechanism that allows us to provision and section off workflows for different organisations, establish authorization boundaries and access keys per project.
• Data Nodes: Assuming that we deeply integrate elsa with our product, we might want to have direct database access for a tenant/ project. We would want a way to configure a "user" or some standardized way of permitting a project to only access data that belongs to the tenant.
• Designer: while the designer doesn't need to be multitenant (at least initially), (users of workflow automation should probably be able to view all workflows, since it will mostly be internal staff), we would want to be able to monitor the status of different projects, and filter on project workspaces, so we can investigate issues and easily manage and identify which organisations a workflow belongs to.

All I can provide is our use case that I'm evaluating for, which might help your team / inform your design. Hope this feedback helps!

[sfmskywalker]

Hi @Gryhyphen , not worries, I know exactly how it is and all the more reason for me to appreciate the time you took to share this valuable bit of feedback - thank you!

The current state of multitenancy covers some aspects, but not all:

Implemented

• Endpoints/webhooks: If a workflow is associated with a tenant, then the endpoint can only be invoked from that tenant's context. For example, through route prefix, host name and JWT from a user or application that is bound to the same tenant.
• Data Nodes: Depending on whether this is done through a custom activity, the multitenancy APIs allow for this. For example, the EF Core implementations apply tenant filters using a query filter installed in the DB context. This ensures no module needs to be aware of multitenancy before loading e.g workflow for a given tenant. Rather, it just selects all workflows by some application specific predicate, and the extra tenant ID predicate is included automatically.

Not implemented

• Project grouping: There's nothing for this yet. We are thinking of doing something with tagging and RBAC on resources, and I'll keep this use case in mind.
• Designer: Today, the designer is scoped to the tenant of the current user. We might do something where a user has access to a number of tenants / all tenants. It might help that tenants are hierarchical, where perhaps permissions could flow from parent tenant to descending tenants. Anyway, all this has yet to be designed.

Thanks again for the feedback, it's much appreciated!