Assign privileges via REST api

Dear all,
how is possible to assign privileges to a user or to a group via rest api?
For instance, I would like to assing “Access the workflow application” privilege to a group, using rest api.
Is there any solution?

There is a REST API for privileges, see or the Swagger documentation.

I too was looking for this API. I see the source but when I launch the flowable/flowable-rest container from dockerhub and view the Swagger docs (/flowable-rest/docs/specfile/process/flowable.json) privilege is not there.

Similarly attempting to guess the api results in 404s:

So is the privilege API not included in the 6.4.1 container?

Hey @tstephen,

The reason why you couldn’t find it in the Swagger docs is because you were looking in the wrong ones. The PrivelegeCollectionResource is part of the IDM REST API, this means that it should be located in /flowable-rest/docs/specfile/idm/flowable.json.


Thanks Filip

A couple of observations:

  • calling /idm-api/privileges/{id}/users returns 200 rather than 201 when it creates a privilege mapping. That feels like a small bug, do you agree?
  • the privileges appear to have dynamically allocated ids, meaning that a script to assign them to users cannot be portable between environments (at least not without first looking up the id). So for example to assign ‘access-task’ on my system I do this:
    curl --user rest-admin:test \
    -H "Content-Type:application/json" -H "Accept:application/json"\
    -d '{ "userId": "kermit" }' \
    Compare this to adding the same user to a group named ‘supervisors’:
    curl --user rest-admin:test \
    -H "Content-Type:application/json" -H "Accept:application/json"\
    -d '{ "userId": "kermit" }' \
    Would you be open to fixing the ids for privileges to well-known values such as access-task?

Hey @tstephen,

Regarding your observations:

Seems like the creation of users and groups returns 201. Therefore, yes I would agree that it is a small bug.

Yes privileges have dynamically allocated IDs. Unfortunately, I can’t really say why it has been done like that. Perhaps @joram or @tijs would have more insight into that.

I don’t see why not. I would not call it fixing though, but adding new REST endpoints. Otherwise it would be a backwards incompatible change. Maybe a new POST that looks like privileges/name/{privilegeName}/users and privileges/name/{privilegeName}/groups.

Would you be interested in creating PRs for the changes?

No idea to be honest. Maybe to not have a one-column table :wink:

But given the REST endpoints that @filiphr suggests (where the lookup happens behind the scenes) that would solve it without having to break compatibility?

Thanks guys, I’ll see if I can put together a PR


Any news on this topic?

Sorry, distracted. I’ll look to get back to it in a week or so.