IDM. BPMN Groups vs Spring Security Groups


The IDM makes a one-to-one mapping between BPMN groups (a mechanism to assign potential owners to a task based on a user being a member of a certain group, to Spring Security Groups (a way of grouping the authorities a user has to make it easy to administer user authorities

It seems more natural to me that the IDM should consider BPMN Group membership as a Spring Security Authority that a user can have (the ability to claim and complete a set of tasks marked with that authority) rather than a Spring Security Group.

In particular, I would like to be able to use the current natural way of administering authorities in the IDM (such as the ability to use the resp API, to administer users of the system, etc.) by assigning them to Spring Security Groups, to also assign BPMN group memberships to a given Spring group. In particular I have found that in my applications the Spring groups map naturally one-to-one to the organization job titles and roles, but don’t map one to one to BPMN groups.

The goal of this comment is to initiate a discussion about whether other people share the thought that BPMN group membership would be better treated in the IDM and flowable as a Spring Security Authority rather than a Spring Security Group and if so whether it might make sense to change/extend the way the IDM works in this respect. In particular I am wondering what the core developers think about this and whether there would be any interest in providing such functionality as part of the open source code. I plan to work on this task, and would be happy to open source my code into flowable if it was of value to the community.

I’m not following yet fully. Can you point to the place where a security group is used?

Looking at the code, the groups get put into authorities, which are put in

Or are you talking about the non-UI use case? If so, I can see this code being there:, which does indeed do an additional mapping.

Can you maybe give an example of how you would set it up and how it all would like together?

Hi Joram.

Thank you for your comments. I am thinking of the case when flowable is integrated into a larger server application that does other things in addition to process management.

In such a system we have the concept of user (a human being, or more specifically a login credential).

We also have the concept of privilege. Each privilege controls access to a fine grained feature of the server (e.g. upload bpmn processes, modify user data, query historical data, perform backups of the databases, etc. plus privileges for features unrelated to flowable).

Each user can be individually assigned privileges, but in addition, the users can also have assigned roles (often coupled with job category, e.g. technicians, senior technicians, managers, senior managers, supervisors, senior supervisors, etc.) Many users are assigned a single role, but some have more than one. Each role has assigned privileges, and users with a role inherit that role’s privileges in addition to whichever privileges were specifically assigned to the user. Using roles in this way greatly simplifies user management, since when a new user gets started he can be assigned a role and be ready, instead of having to go privilege by privilege deciding whether that user should have it.

Then we have BPMN group. We typically control who can can perform a given activity in a process by specifying a candidate group in the activity.

The way the flowable IDM currently works, it couples BPMN groups with roles as defined above. My suggestion is that the two concepts should not be coupled. Instead, it is my opinion that belonging to a BPMN group is logically equivalent to having a privilege as defined above. In this way of thinking, users could be assigned membership to bpmn groups specifically, but roles could also be given membership into bpmn groups and users would inherit membership from the roles they have. This way there we could have roles that would have membership to multiple bpmn groups as well as roles that have nothing to do with bpmn and have no membership to any bpmn group. Let me know if this makes sense.


Have you considered using a dedicated Identity and Access Management solution.

For example, use Keycloak in combination with Flowable. Keycloak is an open source Identity and Access Management solution that supports:

  • Single Sign On (SSO)
  • OpenID Connect (OIDC), OAuth 2.0 and SAML 2.0
  • LDAP and Active Directory
  • User Federation, Identity Brokering and Social Login
  • Centralised User Management


Thank you @Robinyo. I feel keycloak is unnecessary complex for my purpose, since I am just trying to have a single server that implements a restful API. Many (but not all) of the API calls are related to flowable and process management and I would like to have fine grained control over which users can make which calls using privileges. I don’t use any webapps since my clients are not web based. As I described above I would like to have a role concept to group privileges and make user privileges easier to manage.

Thans for the thorough explanation. Am I understanding you correctly that you want to add the concept of a ‘role’ that could also be a member of a group? Is a role something that gets persisted (with foreign keys and all that to user/groups) or is it more something orthogonal to it, that gets applied when needed?

FYI: in the past, we’ve had the concept of a ‘security group’ (see, which is a group for the IDM engine, but treated differently. The current implementation however, doesn’t use that type anymore. With a security group, privileges can be attached to that group.

Thank you Joram. Yes, what I had in mind is something similar to the old security group.

In particular, I envision users having two different kinds of privileges, one kind controls access to API endpoints and webapps. The set of this type of privileges is closed. The privileges that the system knows about is fixed.

The other set of privileges is in a one-to-one relationship with bpmn groups marking whether a user belongs to a group. This set of privileges is open, one creates new privileges of this kind by creating new bpmn groups.

The concept of role that I envision is orthogonal. It is a way of grouping privileges (which could be of both kinds) so that a user that has a role “inherits” the privileges of the role.

Right. I think that indeed matches the ‘old’ security groups quite nicely. What’s your plan with this? Is this something you’d like to investigate/contribute? Or something else?

I have already started to investigate and write it for my application. Once it is in a reasonable shape I can share my conclusions and see if there is any interest in a broader contribution.