Setting up Groups & Authorizations

Development
1

Hi everyone

When building Camunda 7 - based applications, we ‘always’ had the issue that groups & authorizations couldn’t be configured but had to be set up either via admin ui or programmatically. (This was an issue for us because we had different stages where we deployed the applications, onboarding new devs with their own db schema should be as simple as possible)

Am I correct in assuming that Operaton at the moment also doesn’t support setting up groups & authorizations via configuration?
Are there any plans to offer a configuration mechanism to set up groups & authorizations?
Do you see the need to implement such a feature or should this be left to the users of Operaton?

2

We provide the very same feature set as Camunda for now. That is, when using defaults, groups & authorizations are managed via the admin UI or REST API.

A natural choice of course is using our Keycloak plugin to manager users & groups in Keycloak. That is not completely out-of-the-box, but integratable with low effort.

The SPI IdentityService allows you to implement custom identity management.

It is not clear to me what exactly means configuration mechanism. This would have to be designed. There are no concrete plans yet. When the requirements and the wide demand are clear then it could be an option to add. We need a wider range of users defining specific requirements.

3

Regarding Keycloak (and i also think this or another form of oauth2 integration is probably the right way to use a process engine in a prod environment):

In my understanding, Keycloak manages the groups, but does not / should not manage the permissions of a group, right?

In past projects, we configured the authorizations of groups similar to:

camunda:
  group-setup:
    enabled: true
    groups:
      - group-id: Readers
        authorizations:
          - name: APPLICATION
            type: Allow
            permissions:
              - ACCESS
            resources: "*"
          - ...

On application startup:

  • if group-setup.enabled = false, nothing happens, the existing groups and there authorizations are left as they are
  • otherwise
    • every configured but missing group is created
    • the authorizations of existing groups are modified if necessary to reflect the configuration

Benefits of such an approach (in contrast of configuring the authorizations via ui or api):

  • When deploying an application to a new stage, the database is automatically set up with ‘valid’ groups
  • When resetting the database on a test-stage (usually, we don’t do that on prd:-), it takes just a restart of the application & the groups are set up again correctly
  • When a new developer joins the team and starts the app for the first time on his own db schema, …
  • Of course this could also be achieved with a liquibase script or something similar, but then the one creating the liquibase script needs to have in-depth knowledge of the database schema (and any change of the schema will break the script)
1 Like
4

Hi @Christian,

I think this is a nice idea and a very clean solution. As @kthoms already said, we have to spend our resources well and might not be able to add this to the engine in the next time, but this might be a nice thing for a Process Engine plugin. Staging groups and permissions through different environments really is not configurable right now. If you have already done something like this, would you be open to provide this as an Open Source solution? This doesn’t have to be a donation to Operaton, it could be hosted by any individual or organization.

I’d be able to give you some pointers on how to implement a process engine plugin, but would not be able to implement one by myself right now due to time constraints

5

Hi @javahippie

Sorry for the late reply. There’s just too much work right now - but I’m sure that’s true for all of us :slight_smile:

Yes, I would be interested in building this feature. I’ve no issues with contributing to Operaton as I really like the idea of having a fully fledged Open Source process engine available for future projects.

I’ve never implemented a process engine plugin. I’m aware of the camunda 7 documentation / example projects. Do you have additional info in mind?

6

The Camunda 7 docs are still valid, and you could learn from other C7 plugins. It is just package names that change.
Maybe you could use an AI agent to craft a plugin skeleton? I did not try this so far, but wanted to test this in the near future.

7

Hi @Christian,

I created a process engine plugin for the excercise of it some time ago. It is an interface you implement, and it lets you access the engine instance

This is an example, where I added the ability to put user task data into an elasticsearch instance, but the blueprint is the same for most plugins:

If you’d like to pair program over this, I’d be very open to do this

8

Hi @javahippie

Thx for the hint, I’ve found the AdministratorAuthorizationPlugin - looks like I could use that plugin as a basis.

My current understanding of the codebase isn’t great yet. It looks like I have to do the following things:

  • write the Plugin
  • extend ProcessEngineConfiguration
  • extend ProcessEngineConfigurationImp
  • for the different runtime environments extend the configuration mechanism
    (e.g. OperatonBpmPropertiesfor spring boot)

More or less right?

Thx for the offer regarding pair programming. First I need to get a better understanding & invest some time (hopefully i can do that next week), then I’ll be happy to get back to you.

@kthoms : Yep, the AI is getting quite powerful

9

Why does it have to be an engine plugin? Setting up permissions is an administrative action IMO and can (and even should) be accompished prior starting the application itself (like setting up the DB).

One could create an application that consumes a configuration similar to the described above. It could be started when permissions should be changed, no need to restart the application for this.

Setting up permissions via GUI is surely a no go.