Very, very weird behaviours in Flowable

Flowable Engine
1

Flowable 6.5.0.
Access mode: direct [1]
Database: mariadb 10

I abandoned tries with Flowable a few months ago following very weirds behaviours which I describe afterwards.
Sincerely speaking, it’s banging your head against the walls.
To summarize, only admin account works correctly when it works.
Consequently, the software cannot be put in users’ hands this way.

The details.

  1. It’s always possible to connect to -idm portal even for non-admin accounts as soon as they are allowed (through privileges) to connect to -idm.

For other modules (-modeler, -task, -admin) to be reachable, points (2) and sometimes (3) are needed.

  1. Admin password needs to be specified in the docker-compose.yml file.
    - FLOWABLE_COMMON_APP_IDM-ADMIN_USER=admin
    - FLOWABLE_COMMON_APP_IDM-ADMIN_PASSWORD=< password > [2]

    And, thereafter, ONLY admin can access modeler, tasks and admin modules.
    Even if other accounts are allowed through privileges to manage these modules, it’s a never-ending loop back to the login page.

  2. And sometimes it doesn’t work anymore: impossible, even for the admin to connect, except (1), always, on the -idm portal. For what reason ? Don’t know.

In this case, something amongst:

- FLOWABLE.REST.APP.ADMIN.USER-ID=rest-admin
- FLOWABLE.REST.APP.ADMIN.PASSWORD=< password >
- FLOWABLE.REST.APP.ADMIN.PASSWORD=test
- FLOWABLE.REST.APP.ADMIN.FIRST-NAME=Rest
- FLOWABLE.REST.APP.ADMIN.LAST-NAME=Admin

or, maybe, some of the
- FLOWABLE_ADMIN_APP_SERVER-CONFIG_APP_* variables

need to be activated to unblock the situation.
Once unblocked, only
- FLOWABLE_COMMON_APP_IDM-ADMIN_USER=admin
- FLOWABLE_COMMON_APP_IDM-ADMIN_PASSWORD=< password >
is needed.
Please note that before the unblocking, no module is working at all (but -idm of course).

  1. Moreover, in order to work admin password has to be in clear in a configuration file (docker-compose.yml). Very unsecure.

BTW, passwords are also in clear in the database. Another unsecure feature.

Can someone explains why such quirky behaviours exist in this product?

Despite that, it’s an amazing product that has the big advantage of gathering everything in the same location: engine, designing, management and administration.

Thank you,
db

[1] Initially Flowable was behind a nginx but, in order to tell pb apart, it’s now direct.
[2] The admin password is no more the orginal one.

–

2

Hey.

I’ve had some problems with LDAP, however managed to solve it in this thread: LDAP authentication malfunctioning with valid credentials

Also, you could store the admin password in an environment variable, and then reference it in the compose file. For example, I use the ${REDACTED} and works fine, just make sure you know who has the VM access and who could possibly read the password.

Regards.

3

Thank you fiki574 for the solution.
And, a I’m thinking about switching on a LDAP directory.

But that was not my major problem.
The major problem is that only admin can use this software: other accounts aren’t able to go farther than the -idm portal (loop back to login screen).
Another problem is that the behaviour doesn’t seem to be very stable: sometimes, for a reason I wasn’t able to find, even admin cannot log any more (except to -idm).

My questions:
Are you sure it’s
FLOWABLE_COMMON_APP_IDM _ ADMIN …
or is it
FLOWABLE_COMMON_APP_IDM - ADMIN … ?

Because my config was unblocked with a - and not a _.

I’m going to check with your config and will reply in another post if needed.

Have a nice day,

db

4

I checked:
- FLOWABLE_COMMON_APP_IDM_ADMIN_USER=admin
- FLOWABLE_COMMON_APP_IDM_ADMIN_PASSWORD=< password >
- FLOWABLE_IDM_APP_ADMIN_USER_ID=admin
- FLOWABLE_IDM_APP_ADMIN_PASSWORD=< same password as before >
- FLOWABLE_IDM_APP_ADMIN_FIRST_NAME= < my first name >
- FLOWABLE_IDM_APP_ADMIN_LAST_NAME= < my name >

Same behaviour: admin can use any module, other accounts can only use IDM module. For other modules they are taken back to the logon portal :frowning:

What database are you using?

db

5

PostgreSQL.

Try this:

  • FLOWABLE_COMMON_APP_IDM_ADMIN_USER=your actual domain user
  • FLOWABLE_COMMON_APP_IDM_ADMIN_PASSWORD=your actual domain password
  • FLOWABLE_IDM_APP_ADMIN_USER_ID=your actual domain user
  • FLOWABLE_IDM_APP_ADMIN_PASSWORD=your actual domain password
  • FLOWABLE_IDM_APP_ADMIN_EMAIL=your actual domain email
  • FLOWABLE_IDM_APP_ADMIN_FIRST_NAME=your actual domain first name
  • FLOWABLE_IDM_APP_ADMIN_LAST_NAME=your actual domain last name

This data must match the data from your LDAP/AD in 1:1 ratio. Everything must be exact. Do not use the “admin” user if you don’t have it in your LDAP/AD instance at all.

After I supplied these to the docker-compose.yml file, everything started to work. Have in mind you might have some LDAP query errors, so that could be another cause of the malfunctioning.

6

Ok but from now on I’ve NOT used a LDAP directory server. The IAM database is in mariadb.
One step at a time.

Do you want to say that Flowable access controls can only work with a directory?

db