Customizing and Extending Camunda Tasklist (Securing External Calls)
In our previous topic we managed to communicate with an external source “employee database table” from within an embedded html form.
The communication was done through a REST API call “an HTTP web request”. This REST API is unsecured so even if user is not authenticated, a successful call can be made.
This API call should fail if user is not authenticated so we need to make our service a secured service.
Securing our service can be easily done utilizing camunda built-in security filters.
There is a built-in security filter called org.camunda.bpm.webapp.impl.security.filter.EngineRequestAuthorizer. This filter authorizes requests based on the current authentication so request is authorized only if user is authenticated.
Keep in mind that this filter expects engine name as path parameter.
You can have a look at the code of this filter here.
All what we need to do to utilize this filter is to specify denied and allowed paths for our service in camunda/WEB-INF/securityFilterRules.json file as in below snippet.
(Notice: the text {engine} appears in above snippet determines the location of the required path parameter “engine”) so in our GET request (http://localhost:8080/camunda/hr-rest/default/employee/demo), “default” is the value of path parameter “engine”.
The complete securityFilterRules.json file can be found here. (Don’t forget to shutdown then start camunda)
Now, if we try to access our service while no authenticated user logged-in to camunda app then the call will fail and an unauthorized error is returned.
Okay, this time, login to camunda app using valid credentials then try to access our service. The request is authorized and result is returned successfully.
Great! we have successfully demonstrated how easily we can secure our API calls.
One question might be raised, What if our service is not deployed as part of camunda app? What if our service is deployed somewhere else? How can we securely call it?
The answer is simply to write a Java Servlet to call the service from within it then deploy the servlet as part of camunda app so you can apply to it the same things applied to our demonstrated RESTful service.
Be ready for our next topic which is “Associating business object with a process instance”.