Hi @Ashutosh,
The authorization details indeed need to exists within Camunda BPM. We actually decode the JWT in the authentication provider and obtain all necessary data from that object (username and groups) and create memberships on the fly if needed.
We do not implement a completely custom filter. We reused the one from the example and changed it to what we needed. Instead of checking the basic authentication details with the data in the Camunda Engine, we decode the JWT from the request and add all authentication details to the engine. We create the user if necessary and add any non-existing memberships. Finally we create a “successfull authentication” (sorry don’t remember the classname and method by heart).
The authorization details would already exist within the engine. This would be provided by the process implementation. Candidate groups, candidate users, etc are used to authorize the users in the engine. We do not implement a custom authorization service. Camunda still authorizes our calls, we only provide a custom authentication.
Hope this was somewhat clear / useful.
Kind regards,
Pieter Vincken