"camunda-admin" hard-coded with certain permissions?

Camunda 7 Topics Discussion & Questions
1

Hi,
I have tried to create a new group with the exact same permissions set in ACT_RU_AUTHORIZATION table. However, the behavior is still different from “camunda-admin”.

For example, this new group can’t migrate a process that belongs to another tenant while “camunda-admin” can. I suspect there is some hard-coded implementation for “camunda-admin”?

2

When you create admin user the admin group “camunda-admin” will be associated with that user. This group, is having full permissions to perform any operations.

3

Thanks @aravindhrs, but I think you misunderstood the problem here…

4

Camunda-admin will have access to all the tenants.

5

@aravindhrs, It’s not about camunda-admin has access to all tenants. It’s about another group with the exact same permissions as camunda-admin, but this group can’t access all tenants.

6

Did you compared the resources Authorization in the db for both groups are same?

7

Yes. That’s why I specifically mentioned the table name in the description.

8

Hi @run,

only camunda-admin is able to access all tenants (https://docs.camunda.org/manual/7.12/user-guide/process-engine/multi-tenancy/#access-all-tenants-as-administrator).

In your case you have to add the group to all tenants explicitly.

Hope this helps, Ingo

9

Hi @Ingo_Richtsmeier,
All the permissions in the tenant are granted. The ACT_RU_AUTHORIZATION is exactly the same for camunda-admin and the custom group. But they behavior differently.

10

Hi @run,

does “migrate” mean that you want to transfer process instances from tenant 1 to tenant 2?

If yes, it could be forbidden from the underlying tenant separation in the engine. It is restrictive that no tenant could ever see data from another tenant.

If you want to check further details in the code, you can start checking the tests (there are many) here: https://github.com/camunda/camunda-bpm-platform/tree/master/engine/src/test/java/org/camunda/bpm/engine/test/api/multitenancy. They are easier to read when you clone the repo and import them into your IDE.

Hope this helps, Ingo

11

Hi @Ingo_Richtsmeier,
“migrate” does not mean migrate from tenant 1 to tenant 2. It’s migrating to the same tenant.

Let’s say

  • A user “abc” belong to tenant “T1”.
  • A process definition of two versions belong to tenant “null” (no specific tenant)
  • A process instance “P1” belong to tenant “T2”.

Now

  • If “abc” has a group membership “camunda-admin”, the API call is able to migrate process instance “P1”
  • If “abc” has a group membership of “migrater” (this group has the exact permission settings as camunda-admin), the same API call will fail.
12

Hi @run,

in your setup user “abc” has no access to tenant “T2”, as it belongs to tenant “T1”.

If you add “abc” to tenant “T2” as well, the user should be able to migrate process instances.

Hope this helps, Ingo

13

The strange thing is, if I don’t change the tenant membership but simply adding “abc” to “camunda-admin” group, the migration would be successful.
But if I adding “abc” to another group, which has exact the same permissions as “camunda-admin”, the migration would fail again.