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.
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.
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?
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.