Why Flowable IDM passwords need encoding before production
The built-in IDM tables in a Flowable engine store user passwords in plain text by default, so any engine that lets people sign in to the REST app or task lists with local users needs a decision before production. There are three ways to close the gap: configure a password encoder such as BCrypt for IDM user records, migrate existing users onto encoded credentials, or move identity out of IDM so the engine no longer holds the passwords at all. The path that fits depends on one question: where are your identities authoritative? If people are already managed in a directory or identity provider, a second copy in IDM is a liability to maintain. If the engine's users form a small, separate population, encoding and migration keep the change contained.
Replacing IDM is a supported route, and the Flowable docs describe identity management as replaceable. You can override IdmIdentityServiceImpl or implement the IdmIdentityService interface, and an LDAP identity service is provided as a reference implementation. That shifts the work from configuration to integration. Your team or a partner must map directory groups to the candidate groups and privileges that your processes and REST calls depend on, and test how authentication, group lookup and user search behave under your expected load. Read the Flowable configuration docs for the settings that apply to your engine version, and confirm the exact interface signatures against that release before you write code.
Before you choose, confirm three things in your own environment. First, list every account that can sign in to the REST app or task lists, including service accounts and any accounts left over from demos or container examples. Second, confirm your engine version and which encoder options it supports, since the material available here does not settle those details for every release. Third, decide who owns password policy and account lifecycle, because encoding protects stored credentials but does not make weak passwords strong. Ask any partner to show how the chosen path handles existing users at cutover, including users who have never signed in to the engine.
Choosing between a password encoder, migration and external identity
This table compares three ways to stop storing Flowable IDM passwords in plain text: configuring an encoder, migrating existing users, or replacing the IDM identity service with an LDAP or IdP-backed implementation. Read each row as a question to answer for your deployment, then check the operational cost in the last rows. The main takeaway is that the encoder path keeps passwords in Flowable, while the external identity path moves that responsibility out of the engine entirely.
| Decision factor | Configure a BCrypt-style encoder | Migrate existing users | Replace IDM with LDAP or IdP |
|---|---|---|---|
| What stays in the Flowable database | Hashed password values in the IDM user tables | Hashed values for migrated users, plus any plain-text values until they are re-set | User records may remain for links to tasks, but credentials are not stored there |
| Who manages passwords | Your application or Flowable admin flows, through the engine | Your team, with users prompted to reset where hashes cannot be carried over | The directory or identity provider, outside Flowable |
| Main implementation work | Set the encoder on the IDM configuration and confirm login and password change paths | Write and test a migration that hashes existing values and handles accounts that cannot be converted | Override IdmIdentityServiceImpl or implement IdmIdentityService; the docs provide an LDAP reference implementation |
| Recurring operational cost | Low, mainly keeping the encoder choice and its strength settings reviewed | One-time, but needs a cutover window and a support plan for users who must reset | Ongoing directory integration, group mapping and sync testing with the identity team |
| Effect on group and role data | None, since groups and privileges stay in Flowable | None, but confirm migrated accounts keep their group links | Group and privilege sources must be mapped from the directory, which often needs design work |
| Confirm before choosing | Which encoder your Flowable version supports and its configuration key | How many accounts use plain text and whether hashes can be generated from them | Whether your directory supports the lookups and group model your processes need |
How to configure a BCrypt encoder in Flowable IDM
This sequence moves a Flowable IDM deployment from plain-text stored passwords to a BCrypt-hashed password store, with checks that prove new and migrated credentials are no longer readable in the database.
Confirm the Flowable version and runtime setup
The team lead and the engineer who owns the Java application confirm the exact Flowable version, whether the engine is embedded in a Spring Boot application, a servlet container such as Tomcat or Jetty, or a Java SE process, and whether the REST application is in use. Configuration keys differ between these setups, so the Flowable configuration docs for that version are the reference for every name used in later steps. Exact property and class names must be confirmed against the configuration docs for the version in use before any change is made. Done when the team has a written record of the version, the runtime, the database type and the owner of the change.
Back up the IDM tables and the environment
The database administrator takes a tested backup of the database that holds the IDM tables, along with the current engine configuration and deployment artifacts, and restores it to a non-production copy to confirm it works. This gives a rollback point if the encoder change breaks sign-in for existing users. Done when the restore to a separate environment succeeds and the team can log in there with a test account that existed before the change.
Configure the password encoder in engine configuration
The engineer who maintains the engine configuration sets a BCrypt password encoder on the process engine configuration in the form the Flowable configuration docs describe for the version in use. In Spring Boot setups this is typically done through a bean or property, while embedded setups set it on the configuration object before the engine is built. The change is made in source control and reviewed by a second engineer. Done when the application starts in a test environment with the encoder active and the startup log or a diagnostic check confirms which encoder is loaded.
Change the user creation and password check path
The developer updates every code path that creates users or changes passwords so that the password is passed through the encoder before it is stored, and confirms that the sign-in check compares the submitted password against the hash. Any custom identity service, administrative script or seeding routine that writes to the IDM tables directly is found and changed or removed. Done when a code search for password writes returns only paths that use the encoder and a unit or integration test shows a created user can authenticate.
Plan the handling of existing plain-text users
The security lead and the engineer decide how existing accounts with plain-text values will be handled, since the encoder only applies to passwords written after the change unless a migration is run. Options include forcing a password reset at next sign-in, running a controlled migration script that hashes existing values, or moving identities to LDAP or an identity provider. Confirm the chosen approach against the Flowable docs for IDM and any identity service in use. Done when the decision is recorded with the owner, the affected account count from a database query, and the sign-off of the security lead.
Test sign-in with a new user
A tester creates a new user through the application path changed in step four, then signs in through the REST application or the application's own login form using the new password. The tester also confirms that a wrong password is rejected and that the same flow works after a restart of the engine. Done when the new user signs in successfully, the wrong password fails, and the result is recorded in the test report with the Flowable version and build identifier.
Verify stored values are no longer readable
The database administrator queries the IDM user table for the new test account and for any account migrated in step five, and confirms the password column holds a hashed value rather than the entered password. The check should also confirm the hash format matches what BCrypt produces and that no plain-text copy exists in logs, backups created after the change, or seed files. Done when the query output shows no readable password for any checked account and the findings are filed as evidence for the change record.
Migrating existing IDM users without locking anyone out
Start by inventorying the IDM tables before changing any configuration, because the migration plan depends on what is actually stored. Query the user table and record how many accounts exist, which ones are human users, which are service or integration accounts, and which have ever logged in. Confirm with your Flowable version and database vendor how the password column is populated for each account, since rows created by older deployments, by the REST admin tooling and by scripts may differ. Take a tested backup of the IDM tables and restore it into a non-production database before the first production change. A backup that has never been restored is not a rollback plan.
Decide per population how existing passwords will be converted. The common options are to rehash each password on the next successful login, which leaves active users untouched but keeps plain-text rows around until they sign in, or to force a reset for dormant accounts and anyone whose password may already be exposed. Rehash-on-login needs a code path that checks the stored format, verifies the submitted password against the plain value, and writes back the encoded hash only after the check succeeds. Service accounts usually cannot answer a login prompt, so assign each one an owner, rotate its credential through the same process your secrets handling uses, and record the change in a change ticket.
The most damaging failure in this transition is a table with mixed encoded and plain values, because a password verifier that expects one format will reject the other and lock users out in ways that look random. Keep a per-row marker or a format check in the verification path, and test both formats against the same engine build before cutover. Coordinate the REST admin account with the same window: confirm which account administers the REST application, that its password is changed through the encoder, and that you have a second administrator who can still sign in if the first one is affected. Write the rollback steps down, including the backup restore order and the deployment version to return to, and rehearse them once.
Security risks that remain after the encoder is set
A password encoder protects only the values stored in the IDM tables. The risks below sit around those tables: demo accounts, weak policies, copies of credentials in backups and logs, broad admin rights, exposed user operations and the libraries underneath. Each card names the check to run before the engine is exposed to users or networks.
Default demo accounts still present
Flowable's example deployments ship with a default rest-admin user, and that account is well known to anyone who has read the docs. Switching the encoder does not remove it. Confirm that every demo user is deleted or disabled in each environment, including the Docker images and the REST application you deployed, and that the seeded passwords no longer work. Check the identity tables for accounts you did not create.
Password policy not enforced
The engine stores whatever hash your application sends, so a short or reused password is still accepted if the front end allows it. Define the minimum length, complexity, lockout and rotation rules in your identity layer or the admin tooling that creates users, then test them with the REST and Java APIs. Confirm who can change passwords and whether users can set their own.
Plain-text values in backups and logs
Encoding only protects the live IDM tables. Older rows created before the change may still hold plain text until users reset their passwords, and database dumps, snapshots and debug logs can carry credentials passed through requests. Query the user tables for values that do not match the encoder format, rotate any found, and review how request logging and backup retention treat the password fields.
Admin privileges granted too broadly
Flowable separates identity administration from process work through groups and privileges, and a user with the admin rights can create, change and reset other accounts. Review membership of the admin group and every privilege that touches users, then remove standing access for people who only operate processes. Record who holds admin rights and how each grant was approved.
REST surface exposing user operations
If the REST application is reachable, its user endpoints can read, create and update identities, so an encoder does not limit who calls them. Confirm which endpoints are exposed, that they require HTTPS and an authenticated privileged caller, and that the actuator and other management paths are not public. Test each user operation with a non-admin account to confirm it is refused.
Dependency updates on Spring and Jackson
Flowable's engines run on Spring and Jackson, so vulnerabilities in those libraries reach your identity service as well. The Flowable 8.0.0 release moved to Spring Framework 7, Spring Boot 4 and Jackson 3 by default, and it dropped Spring Boot 3 compatibility, so the upgrade path is a planned change. Keep a dependency scan in the build, track the libraries your version uses, and schedule updates with regression tests for the login path.
Questions teams ask before changing Flowable identity storage
What does it cost to move Flowable passwords to a stronger encoder?
The cost comes mainly from people's time, not licenses, because Flowable open source is licensed under Apache 2.0 and the engine's identity code is part of the same project. Your team or a partner pays for analysis of how your deployment stores users, the code change to configure a password encoder, testing of login and password reset, and the migration of existing rows. Costs rise with the number of user records, the amount of custom identity code, and how many applications read the IDM tables directly. Ask any quote to separate one-time work (scoping, configuration, migration, testing) from recurring work (password policy reviews, dependency updates, and upgrades to the Flowable release line you run).
How long does scoping and implementation take?
No fixed duration applies because it depends on the path you choose and on your environment. Encoding passwords with a supported encoder in a small deployment with a single identity store is a different job from replacing the IDM engine with an LDAP or IdP integration across several applications. Scoping usually depends on how many applications authenticate against Flowable, whether any system writes to the IDM tables, and whether you have a staging copy of production data. Ask for a written scope with the deliverables and the order of work before you commit to a timeline.
What must our team provide before the work starts?
Plan to provide four things before implementation begins:
- Read access to your directory or IdP if you plan to switch identity sources, along with test accounts that cover each role
- A set of test users and a staging database that mirrors the production schema
- A backup window, plus a tested restore procedure for the Flowable database
- A named owner for the password policy, who decides length, rotation, lockout and reset rules
Without the policy owner, the engineering work tends to stall at the question of which encoder and which rules to adopt.
Can an internal team change Flowable password storage without a partner?
Yes, a team with Java and Spring skills can make this change using the Flowable documentation, provided they test it carefully. The configuration route and the identity service interface are documented, and the Spring Boot and configuration guides describe how the engine is wired. The risks lie in migrating existing credentials safely, in confirming that every login path uses the new encoder, and in keeping password reset and any custom code working. A partner is most useful when the team lacks experience with identity migrations or needs an independent review before a production change.
Does changing the password encoder affect existing users?
Yes, existing users are affected. Stored passwords in plain text cannot be converted into a hashed form without the user's cooperation, so the usual approach is to hash new or changed passwords with the new encoder and to verify old values during a transition period. Decide early whether you will force a reset for accounts that have not logged in, how you will record which encoding each row uses, and how you will handle service accounts that authenticate by password. Test each of these cases on a copy of your data before you touch production.
When should we switch Flowable to LDAP or an identity provider instead?
Consider a switch when your users already live in a directory or IdP, when joiners and leavers are managed there, or when you need single sign-on and multi-factor authentication that the IDM tables cannot provide. Flowable's documentation says identity management can be replaced by overriding the identity service or by implementing its interface, and it provides an LDAP identity service implementation as a reference. Keeping the IDM tables in use is reasonable for a small, closed set of process users, but the directory becomes the source of truth and the IDM tables should stop holding real passwords. Confirm with your identity team how group membership maps onto Flowable groups before deciding.
What should we confirm before we decide on an approach?
Confirm which Flowable release line you run and whether its identity classes match the examples in the documentation, since configuration details can change between major versions. Check which applications read or write the IDM tables, whether any reporting tool queries them, and whether the REST layer depends on them for authentication. Ask your security team which password policy and audit evidence they need, and confirm that the chosen encoder is one your security standards accept. These answers shape the scope more than any single technical choice.
How to verify the change before users depend on it
Verify the password change in a fixed order, and do not announce it to users until every step passes. Start with sign-in tests for each user type in the IDM tables: ordinary users, administrators, and any accounts that were created by scripts or imported from earlier systems. For each type, sign in with a known password through the path people actually use, whether that is the Flowable UI, a REST call or a custom application, and confirm the session works end to end, including task lists and started processes. Test a user whose password was set before the encoder change and a user whose password is set after it, because the two can behave differently during migration.
Next, confirm that the values in the IDM password column are no longer readable text. Query the table directly on a test copy and check that the stored strings have the format of the encoder you configured, rather than the plain value you typed. Then prove that rollback works. Restore a recent backup into a separate environment, apply the rollback steps you wrote before the change, and confirm that the restored engine starts and that users can sign in with the passwords they had before. Do not rely on the production database for this test. Also confirm that the REST admin account and every service account used by integrations, scheduled jobs or the async executor's dependent systems still authenticate, since a broken service credential often fails silently until a job runs.
Record the results as you go: the date, the environment, the test accounts used by type (never their passwords), the query output showing the stored format, and the restore log. Keep this as operational evidence for later compliance or audit reviews. It shows what your team tested and when, but it is not an audit result, and an independent assessor will decide what it proves. Confirm with your auditor or assessment body which records they expect and how long they must be kept, and store the evidence where your retention rules apply.
