Swap the IDM to get multi tenancy

[mattydebie]

Hey there

We would like to implement multi tenancy in our IDM. This is because the process definitions in the flowable-admin should only be visible to the right tenants.
In the screenshot below, the tenant bacmads should only be able to view definitions of bacmads and nothing else.

This is implemented on database level, but there seems to be no way of adding the tenant ids to certain admins in the flowable-idm.

We thought of 2 ways to handle this:

• Extend the exisiting idm to show the tenant
• Extend flowable to handle different RemoteIdmServices (like KeyCloak)

The second option appears to be most ideal as this would provide more flexibility for authentication.

Any help or pointers in the right direction would be greatly appreciated.

Joram already told us that extending the RemoteIdmServices will not work for SSO, but flowable uses spring security, so as an example we could look into https://github.com/vdenotaris/spring-boot-security-saml-sample

[joram]

There’s indeed two things to this:

• The user logging in would need to have the tenant information (i.e. https://github.com/flowable/flowable-engine/blob/master/modules/flowable-ui-common/src/main/java/org/flowable/ui/common/security/SecurityUtils.java would need to have a getCurrentTenantId() for example. The FlowableAppUser https://github.com/flowable/flowable-engine/blob/master/modules/flowable-ui-common/src/main/java/org/flowable/ui/common/security/FlowableAppUser.java already has a tenantId field). Once that’s in, all calls that go to the engine api’s would need to pass this tenantId to make them tenant-aware.

• “extending the RemoteIdmServices will not work for SSO”: indeed, the current setup uses a filter to check the cookie and uses the RemoteIdmService to fetch users. From a quick glance at the code, this whole Spring Security configuration would need to be swapped with something that goes against an SSO provider. Hence why I thought swapping the security config with the one from your link above would be a good starting point. Ideally this is a configurable setting such that people can switch (and ideally that would be a contribution ;-)). The end result is that a FlowableAppUser needs to be there after authentication, that’s what all the subsequent code expects.

[mattydebie]

Hey Joram,
thanks for the reply you have certainly pointed us to the right direction (we think).

The main requirement appeared to be multi-tenancy, so in stead of implementing our own SSO we tried your first alternative.

The modeler seemed to already take the tenant ID into account. When giving a user a tenant, all the models, definitions and deployments he creates, gets that tenant as well.

The admin, as showed above, was not tenant aware. So as proposed:

• I added the getCurrentTenantId() to the SecurityUtils
• I looked for one method that every *ClientResource used so that I could add the tenantId to the request.

Right now I changed the following in the org.flowable.ui.admin.rest.client.AbstractClientResource to add the tenantId to the requests:

protected Map<String, String[]> getRequestParametersWithoutServerId(HttpServletRequest request) {
        Map<String, String[]> parameterMap = request.getParameterMap();
        Map<String, String[]> resultMap = new HashMap<>();
        resultMap.putAll(parameterMap);
        resultMap.remove(SERVER_ID);
+
+        if (SecurityUtils.getCurrentTenantId() != null) {
+            resultMap.put("tenantId", new String[] { SecurityUtils.getCurrentTenantId() });
+        }
+
        return resultMap;
    }

Is this an acceptable approach?
Right now the tenant only gets added when you change the users’ tenant in the database yourself, so this is only ‘activated’ when you want it to. We can ofcourse add a feature flag as well, if requested.

Would this be accepted as a PR since some other users may like this as well. Ohterwhise we would need to provide a custom Flowable Build.

[mattydebie]

I also configured the IDM so that it’s able to edit the users’ tenant (default = null).

At the moment this is not configurable, so everyone who uses the IDM will see the Tenants from now on.
I’ll try and put in a PR tomorrow.

Changes can be (re)viewed on our fork on github.