Hi guys,
I am trying to implement a 4 eyes principle using the revoke authorization method, but I am stuck.
When I try to add authorization everything runs as if nothing bad happened, but when I check for the result the permissions are not set.
Here are two samples one is working properly and the second is not working.
var auth = execution.getProcessEngineServices().getAuthorizationService().createNewAuthorization(1); // with type 1 - which is for allowing it is working
var permissions = Java.type('org.camunda.bpm.engine.authorization.Permissions');
auth.addPermission(permissions.ALL);
auth.addPermission(permissions.READ);
auth.setResourceId("32d40275-1b1c-11e9-801e-625718bb85a0");
auth.setUserId("lhofer");
auth.setResourceType(7);
execution.getProcessEngineServices().getAuthorizationService().saveAuthorization(auth);
var auth = execution.getProcessEngineServices().getAuthorizationService().createNewAuthorization(2); // with type 2 - which is for revoking it is not working
var permissions = Java.type('org.camunda.bpm.engine.authorization.Permissions');
auth.addPermission(permissions.ALL);
auth.addPermission(permissions.READ);
auth.setResourceId("32d40275-1b1c-11e9-801e-625718bb85a0");
auth.setUserId("lhofer");
auth.setResourceType(7);
execution.getProcessEngineServices().getAuthorizationService().saveAuthorization(auth);
There is also sample bpmn diagram for easy reproduction. (testAuthorization.bpmn (4.4 KB))
Here is what happen in admin:
Any help would be appreciated.
Thanks
Lukas
Hi Lukas,
For revoke authorizations the API works the other way around, i.e. you create the authorization and then call #removePermission instead of addPermission to actually revoke a permission. It’s not intuitive, but it is what it is 
That said, we discourage using revoke authorizations as the engine takes a significant performance hit when enforcing them on large datasets. See https://docs.camunda.org/manual/7.10/user-guide/process-engine/authorization-service/#performance-of-checking-revoke-authorizations and https://docs.camunda.org/manual/7.10/user-guide/process-engine/authorization-service/#check-revoke-authorizations for details.
Cheers,
Thorben
1 Like
Hi Thorben,
thanks for your reply.
Just to be clear, are you saying that it is not a good idea to use the “DENY” authorization for limiting users of the same team from access to some task when you need a 4 eyes principle?
Is there any good way how can I implement it using authorizations please?
And is there a way how can I set up the same authorization for “DENY” in engine as I can do it with rest API?
Thanks alot.
Lukas
Hi Lukas,
Can you quickly define what you understand as four eyes principle please? That makes it easier to answer your questions.
You mean creating DENY authorizations via Java API? Java and REST API are equally powerful, i.e. the REST API only delegates to the Java API.
Cheers,
Thorben
Hi Thorben,
sure I can.
Let’s say I have a team_one where are 3 users, user1, user2 and user3, and I also have two tasks which are both assigned to team_one. But these two tasks are the same and the function of the second task is to provide the check over the work that has been done on the first task. The check cannot be done by the user user who has been working on the first task.
So when the user1 claims the first task which is assigned to the team_one and he completes the task I want to prevent him from claiming the second task. The second task should be visible only to the user2 and user3.
I wanted to achieve this by creating a task listener which would create a “DENY” permission on the second task for the user who completed the first task. And I wanted to create this DENY permission using the task listener, not using the rest API.
Here is a picture if the text is not clear enough.
Best regards,
Lukas
Hi Lukas,
Thanks for clarification. You can add a TaskListener to the assign event and validate the assignee of a task there. This does not prevent the task from showing up in tasklist though. If that is important, you could consider using task variables to filter out tasks that a user should not be able to see, but I’m not sure this will perform better than REVOKE authorizations.
All that said, REVOKE authorizations may also be fine in your case. I recommend to test performance of tas the task query and filter methods with the expected workload.
Cheers,
Thorben
1 Like
