Hi,
I am mostly using REST API and the JWT token sets groups to the user.
But it protects only REST end point.

But you can recreate easily by using tasklist and admin application. Just build a Sprinboot version 2.2.1 jar with Camunda 2.2.1. You need to enable security as described in the application.yml. Create a process with two Candidate groups called Group A and Grup B. Put two User tasks I mean the box that has a bust of a human. Assign group A to task 1. Assign group B to task 2. Deploy the process. Go to User Administration and create Group A and Group B user groups. Create user 1 and give access to task list (no camunda_admin) and also assign Group A to user 1 . Assign Group B to user 2. Now login as user 1 when task is in task one and claim and complete. The user1 should be able to do that. Then after it moves to task 2, as user 1 try to claim the task. The user should not be able to claim the task, because the user is not in Role B.
But that does not seem to work. User 1 can complete any task. If I apply REST Api same issue. At least I want to make this work in REST API.
We want a non camunda_admin user to be able to access tasks only in their candidate group and then claim them only to the ones that they are permitted to via candidate groups. Otherwise what is the use of the Candidate groups?
Can you make sure the Candidate groups functionality works ?
Unfortunately I may not be allowed to share configuration files due to company policy.
We use spring boot 2.2.1 camunda 7.12.0 and camunda- camel.

Yana, I have been able to reproduce the issue with task list. Please use the attached Sample of from Camunda which I slightly modified to add GroupA to the first task.

I created two non admin users called dul and jil. The user dul has GroupA assigned. user Jil has no groups assigned. I have to give permission to tasklist and cockpit, access to all process definitions, process instances and filters to the two users so that they can meaningfully work in the task list. However, it does not mean that jill should be allowed to claim and complete the user task.

I have to make a correction about the description.

In the above I have the application property specified as:

camunda:

                  bpm:

                       authorization:

                             enabled: true

However if you do not make the property name like below, it will not enable security.

camunda.bpm:

                       authorization:

                             enabled: true

The attached zip file contain the project and try to do what I have described here. You may see the pdf file to see what authorizations I have in there.

I hope this helps you to re-create the problem.

Same issue exists if I block the REST API with a Login provider and assign the groups to the user with JWT tokens.

Hi dulshand@yahoo.com,

Thank you for the provided examples and details, they help me to have better understanding of your use case.

I have several remarks regarding the scenario:

• Please note, that in the provided pdf ( AdminScreenShots.pdf ) I found several places where the authorization is defined for the user GroupA instead of the group (e.g. Filter, Process Definition). I don't think that is a big deal to reproduce the scenario, however, please make sure to avoid such issues in the real-life scenarios.
• I tried enabling the authorization and it works both variants for me, the authorizations are respected as long as the yaml file is correctly defined.
• The general problem that I see in the example is that the non-admin users are allowed to do too much. Each user should be permitted to perform only the smallest set of required operation of their role and that should be reflected in the authorizations. Meaning, please avoid assigning */asterix as resource id to authorizations of non-admin unless it is necessary (e.g. the user must be allowed to start processes => they need to have CREATE permission for all Process instances). In the provided example ( AdminScreenShots.pdf ):
  • the user jil has ALL permissions for all Process Definitions. Reconsider if this is really necessary for the real-life. Side note: I see that creating authorizations like this are easier when building the example.
  • the non-admin users (jil and dul) have ALL permissions for all of the Filters. This is also not recommended for real-life scenarios. The tasklist operators should be allowed to access only the filters that are assigned to them (e.g. My Tasks, My Group Tasks, etc.). Also, All Tasks filters are not recommended to be in use.

I hope that helps you to adjust your configurations and authorizations and try to play around again with your scenarios, keeping in mind our recommendation.

Please let me know if you have any questions.

Best regards,
Yana

Yana, all permissions were given because tasklist cannot be accessed. and process creation was not allowed.I expected it to work witgout that. Anyways, if we run the sample application. You say that you used thd yml file. Did you use the pom.xml and other files. May be the version of Camunda you use to test is working.
I will ask others to test this.

I don't know if you tested properly. Person who has GroupA as a group should be able to compkete the task abd the person who does not have if should no be able to do it.

If your JIRA system allows uploading video recordings, I will post it here to show the problem.

Can you put a screen recording , put it in You Tube and then post tge link to show that it works.

another thing to mention is that if I put Jill in a GroupB Jill should be able to claim and complete taska in GroupB. Badically Dul and Jill are very similar but their groups are different like maker and checker. Maker should not be anle to check.
If remove some of the access from Jill Jill will not be able to access tasks in RoleB.

Hi dulshand@yahoo.com,

Thank you for your patience with this.

If I understand the scenario you have:

• User tasks that have a candidate group GroupA/maker assigned and user tasks that have a candidate group GroupB/checker assigned
• GroupA should work (claim/unclaim/complete) only that tasks that are assigned to that group (same for GroupB)
• Users of GroupA should not be able to complete tasks where GroupB is a candidate group

This can be achieved as follows:

• define the candidate groups in the process
• assign the users to the groups
• don't give explicit permission for the users or the group, they will be able to work with User tasks that have a group candidate assigned and the user is a member of that group. Because whenever a user task is created and has a candidate group assigned, an authorization will be created for that group to be able to READ and UPDATE that specific task by default. [1]

I hope that helps you to understand better how the authorizations in the process engine work and how you can use them to achieve the desired goal of your scenario.

As it seems that the issue is evolving to a consulting topic, I would recommend you either create a post in our forum or I can give you some details how to request consulting services for Camunda projects.

[1]: https://docs.camunda.org/manual/7.12/user-guide/process-engine/authorization-service/#default-task-permissions

Best regards,
Yana

I am closing the ticket due to inactivity, feel free to reopen in case of any further questions.