the web app is configured with active ldap plugin - can this really be the reason, why I cannot create Tenants via the admin gui? If yes, what is the rationale disabling multi-tenancy when ldap-based identity management is used?
this restriction is mentioned in the user guide. We didn’t implement multi-tenancy for LDAP because we had no idea how the users want to map the tenants into LDAP. So currently, you can not create or get tenants when you use the LDAP plugin.
If you have an idea for the mapping then please share it or create a pull request. I’m happy to discuss your approach.
thanks for your reply. First of all, I think you should docement the restriction in the user guide where the restriction takes place - and that is: Multi-Tenancy. Otherwise one would have to scan the entire userguide to find out if feature X is not usable because of using feature Y.
Concerning the reason for this limitiation, I don’t understand it. Possibly I am at a loss at the moment (first coffee of the day is still in my hand :-), but why does LDAP based user storage interfer with multi-tenancy? To my understanding LDAP plugin is to prevent duplicating user stores by re-using the central user store of the company. And Multi-Tenancy is to logically seperate different parties within the process engine - for my use case that would be different parties within the company.
Could you please explain a little more why the ldap usage completely disable multi-tenancy.
As far as I have TriedAndErrored it with 7.5.1-ee, none of the options is possible. As soon as you have ldap plugin in active, multi-tenancy is cut off:
1.) In the admin ui, there is no “create tenant” button visible.
2.) If you try to create a tenant via the direct link (camunda/app/admin/default/#/tenant-create), you get a:
Jun 22, 2016 9:48:08 PM org.camunda.bpm.engine.rest.exception.RestExceptionHandler toResponse
WARNUNG: org.camunda.bpm.engine.rest.exception.InvalidRequestException: Identity service implementation is read-only.
at org.camunda.bpm.engine.rest.impl.TenantRestServiceImpl.createTenant(TenantRestServiceImpl.java:80)
the use case I am currently faced with is approach no 1. of Robs mentioned alternatives.
The business case behind that is that I am still trying to find a suitable system architecture to offer camunda as an it service within the company. This offering must be aligned with a distributed application infrastructure (currently one tomcat per application, mid-term: inhouse cloud infrastructure based on pivotal cloud foundry).
I was hoping to achieve this by providing one central process engine covering the use cases ‘central cockpit’ and ‘central administration’. In addition to this central engine the decentral process applications (embedded PE) are integrated via database, meaning both central and decentral process applications are using the same database and running in ‘heterogeneous cluster mode’.
This works basically with some limitations. One limitation is that decentral process application can…
a.) …see all data within central process engine db. A no-go for workflows with sensitive data.
b.) even worse: …change / delete data of other process engine in the central database.
I cannot go live with this limitation simply because I don’t want to take responsibility for a service for which I don’t have the control. With the multi-tenancy feature I was hoping to adress this limitation by narrowing the access from the decentral process application to the central db by using them as a seperate tenant (one process engine per tenant + seperate db schemas). And since yesterday evening I know I cannot go live with 7.5.1 since there is no multi-tenancy when using ldap plugin.
To make the long story short - we really need multitenancy with ldap. I created a feature request via support ticket: SUPPORT-2453
No, it doesn’t work because tenants are a part of the identity service. If a user or group should be allowed to see the tenant’s data then the user / group must be a member of this tenant. So there is no authorization for the tenant’s data.
Note that you can still use the transparent access restriction for tenants with LDAP if you set the authenticated tenant-ids by your own. It is not required that the tenants exist in the identity service.
The other parts of multi-tenancy (except the identity service and also the admin webapp) should work with LDAP by default.
Since we also see different approaches for the LDAP integration, we are not sure about choosing one. Currently, we think of an alternative: instead of access LDAP every time, the engine could import the data from LDAP once or periodically into the camunda identity service. What do you think about this approach?
Thanks Philipp,
I presumed tenant was being treated as an identity construct. I have wondered if tenant should really be treated as a resource construct and thus users are authorised access to the tenant resource and its contained resources (process definitions, process instances etc…)
two LDAP groups (with tenantIDs embedded in the name) must be created per tenant (*Users, *Admins); it is the responsibility of the LDAP admin to populate these groups. For example: Camunda_Role_Admin_TENENTID001
on-demand, update the Identity Service User list with the *Users for each of the Tenants and for those users in *Admins group, provide full admin level authorization
for each of the users, indicate that the authentication will be performed by LDAP
when a user logs in, authenticate via LDAP but authorization of all features (except User CRUD) are done via Database Identity Service.
This way you get the LDAP SSO features (which is really the key) and all the Camunda functionality with multi-tenancy.