Why the default Flowable rest-admin account must change before exposure
If your team has stood up the Flowable REST application or a Docker example, the default rest-admin account must be replaced before the service is reachable from any network beyond a single developer machine. The demo credentials are published with the examples, so anyone who can reach the login endpoint can attempt them. Treat the account as a known credential, not as a temporary convenience. The exact username and password shipped in your release must be confirmed against the documentation and the files in your deployment, because the defaults can differ between the REST app, the Docker example and the Spring Boot starters. Confirm them before you write any exposure rule.
The rest-admin account is an administrative identity inside the REST application. Whoever holds it can reach the REST endpoints that the engine exposes, and the privileges attached to that user determine how far that reach extends. Teams usually need this work at three points: a pilot that a few stakeholders can reach over a shared network, a shared development or test environment where the Docker image is left running, and the handover from a prototype to a production platform team. In each case the demo account tends to survive because nobody owns its removal. Assign that owner at the start, and record which identities, roles and privileges replace it.
This page covers the steps that close that gap: creating named administrative users, assigning the privileges those users need, applying a password policy, removing or disabling the demo account, and checking that the change holds before the instance is exposed. Authentication behavior over HTTPS and the privilege model are covered in the sibling pages on REST authentication, and password storage is covered separately. Read those alongside this page, and confirm how your chosen release handles identities before you start the change.
How to replace the rest-admin account step by step
This sequence moves a Flowable REST deployment off the default rest-admin demo account onto named administrators with the right privileges, and confirms that no old credentials remain in any environment.
Inventory every Flowable REST deployment
Your platform or infrastructure team lists each place the Flowable REST application or a Flowable Docker image runs, including development, test, staging, production and any shared lab or demo host. For each one, record the identity source it uses (the built-in IDM tables, an LDAP directory, or a custom identity service that replaces the default), the owner, and whether the instance is reachable from outside the internal network. Confirm with the engineers who built each image whether they used the example Compose file or a Helm chart, because that determines where the default user was introduced. The step is done when the list covers every running instance and every image tag in use, and each entry names its identity source. Anything missing here will keep the demo account alive after the others are fixed.
Create named administrator users
Your identity or platform administrator creates one named account per person who needs REST administration, rather than a shared admin login. Each account receives the rest-access-api privilege so it can call the REST endpoints, and the admin privilege only where that person's role needs it. If identities live in LDAP or an identity provider, create or map the users there and confirm the Flowable identity service resolves their groups and privileges, using the identity service options described in the Flowable docs. Check that each new account can sign in through the identity source you chose. The step is complete when every named user appears in the identity store with the intended privileges and a documented owner.
Set the password policy for new accounts
Before any named account is used in a shared environment, your security team sets the password requirements that apply to Flowable IDM accounts or, if an external directory holds the credentials, confirms the directory's policy applies. Generate initial passwords outside the Flowable configuration files and deliver them through your normal secure channel, not in a README or ticket. Decide how the engine stores passwords, since the IDM tables hold passwords in a form that needs its own review. Confirm the policy with the security owner. The step is done when the policy is written down, the initial passwords are not stored in any repository or deployment file, and the owner has signed off.
Verify the new accounts against the REST API
A tester calls a read-only REST endpoint with each new account over HTTPS, using basic authentication as the Flowable REST docs describe, and confirms a successful response. Then the tester calls an endpoint the account should not reach, such as an administrative operation outside its role, and confirms the request is refused. Run the same checks against each environment from step one. Record the request, the response code and the account used in your change log. The step is done when every named account succeeds on its permitted calls and fails on the others, in every environment.
Confirm the old credentials fail
Before removing anything, the tester attempts a sign-in to each instance with the demo rest-admin account and its default password, and records that the login is rejected. This check matters because a rejected login proves the account is gone or disabled, not just that the documentation has changed. If the old login still succeeds, stop and go back to step one, since that instance is outside the inventory or uses a different identity source. The step is done when every instance returns a failed login for the old credentials and the result is logged against the environment name.
Remove or disable the demo user
The platform team deletes the rest-admin user from the IDM tables or removes it from the LDAP or identity source, depending on what step one recorded, and restarts or reloads each instance so the change takes effect. If removal is not possible in a given environment, disable the account and document why. Repeat the failed-login test from the previous step after the restart. The step is done when the old account cannot authenticate anywhere in the inventory and the change is recorded in your configuration management or change record.
Search for injected credentials in deployment assets
An engineer searches every repository, deployment script, Compose file, Helm values file, CI pipeline variable list, and README that the team uses for Flowable for the old username and default password, and for any environment variable or header that sends them. Remove each occurrence, rotate any secret that was ever stored in version control, and check container image build layers if the team built custom images from the example configuration. Ask the engineers who maintain the pipelines to confirm that nothing outside the repository set, such as a shared wiki or a local laptop template, still injects the old values. The step is complete when a search of every listed location returns no matches and the search query and its date are recorded for the audit file.
Re-deploy from clean assets and confirm
Redeploy each environment from the corrected assets so no running instance depends on a previous configuration, then repeat the named-account verification and the failed-login test. Confirm that monitoring and logging do not record the old username as a successful sign-in. Ask the operations team to add an alert or log query for future logins using the old account name, so any reintroduction is detected. The step is complete when every environment passes both tests from a clean deployment, and the operations owner has accepted the alert or monitoring check in writing.
Which identity option fits each Flowable deployment
This table compares three ways to govern who can reach the Flowable REST admin functions: built-in IDM users with a replaced admin set, a custom identity service backed by LDAP or an identity provider, and the REST app behind an existing SSO gateway. Read each row for when the option fits, who carries the maintenance, and what you must confirm before exposure. The main takeaway is that every option removes the demo account, but only the first two keep identity inside Flowable's own user model.
| Option | When it fits | Who maintains it | What to confirm before go-live |
|---|---|---|---|
| Built-in IDM users with a replaced admin set | Small deployments where a handful of administrators manage Flowable directly and no central directory feeds the engine | Your platform team maintains users, groups and privileges inside the engine's IDM tables | Which privileges each admin needs, how passwords are stored, and whether the IDM password handling in your version meets your policy |
| Custom identity service backed by LDAP or an IdP | Organizations where staff identities already live in a directory and joiners or leavers should flow automatically | Your developers maintain an IdmIdentityService implementation, with the LDAP reference implementation as a starting point | How the custom service maps directory groups to Flowable privileges and how it behaves when the directory is unreachable |
| REST app behind an existing SSO gateway | Estates that already enforce sign-in at a reverse proxy or gateway and want Flowable to trust that layer | Your infrastructure or security team maintains the gateway, and the Flowable team maintains header and network trust rules | Whether the gateway strips client-supplied identity headers and whether Flowable itself stays unreachable except through the gateway |
| Built-in IDM users alone, without a gateway | Lab or isolated test environments only | Your team, with no central control | Whether the environment is truly isolated from users and networks, since basic authentication still needs HTTPS and strong credentials |
| Mixed model with directory-backed admins and a break-glass account | Regulated environments that need an emergency administrator independent of the directory | Your security team maintains the break-glass credential vault and review process | Where the break-glass secret is stored, who may use it, and how each use is logged and reviewed |
Setting a password policy for Flowable admin users
On a developer workstation or a throwaway Docker container, the engine usually listens only on localhost and holds no production data. A lighter policy is reasonable here, but the admin account should still be created on purpose rather than left at the demo credentials. Developers should use a generated password stored in their own secrets tooling, and the defaults should never be copied into a repository or a Compose file that others pull.
- Generate, don't reuse: give each developer a unique admin password instead of a shared value written in a README.
- Keep it off the network: bind the REST application to localhost or a private Docker network so the admin account is unreachable from other hosts.
- Avoid committed credentials: keep admin passwords out of
application.propertiesand Compose files that go into version control. - Reset after demos: rotate or recreate the local admin account after any training session or screen share.
Before a developer environment is cloned into a shared setting, confirm that the same credentials are not reused there.
A shared test environment is reached by several teams, sometimes over a corporate network, and often holds copies of production-like process models and sample data. It is the environment most likely to drift from the rules applied to production, so the policy should be explicit. Set a minimum length and complexity requirement that matches your organization's written standard, and require an individual account for each engineer who needs admin rights.
- Match the corporate standard: apply the same minimum length, complexity and lockout rules your organization uses for other internal systems, and confirm them with your security team.
- Individual accounts: create one admin identity per person so that deployments and privilege changes can be traced.
- Rotation on a schedule: agree a rotation interval with your policy owner, and record when each credential was last changed.
- Limit exposure: restrict REST access to the test network or a VPN, and do not publish the endpoint to the internet.
Confirm whether test data includes personal information, because that determines how strictly this environment is governed.
In production, the admin account controls deployments, process instances and identity data, so the policy should be the strictest of the three. Agree the password length, complexity, expiry and reuse rules with your organization's policy owner before go-live, and make sure the rules are enforced by the identity source that holds the credentials, not just documented. Avoid a shared admin account, since shared credentials break accountability and make a compromised password hard to attribute.
- Named admin accounts only: give each administrator a personal account, and keep break-glass credentials sealed, logged and rotated after any use.
- Length and rotation aligned to policy: set the minimum length and rotation period to the organization's written standard and document any exception with its approver.
- Separate admin from daily use: administrators should not use admin accounts for routine work, so that privileged activity can be reviewed separately.
- Access review: review who holds admin rights on a fixed cadence and remove accounts for people who have changed roles or left.
- Password storage review: the engine stores IDM passwords in a form that needs its own assessment. Read the sibling topic on encoding Flowable IDM passwords before you rely on any password policy in production.
Confirm with your auditors which evidence they will request, such as policy documents, account listings and rotation logs.
Across all environments, the policy works only if the accounts behind it are managed. Admin rights should be granted through a documented request, tied to a named owner and removed when the need ends. Where identities are held in LDAP or an identity provider, the engine's own password rules may not be the controlling ones, so the enforcement point needs to be identified during planning.
- Documented grants: record who approved each admin privilege and why it was needed.
- Owner for every account: assign each admin account a named owner who answers for it.
- Central identity source: if Flowable reads identities from LDAP or an identity provider, confirm which system enforces length, expiry and lockout.
- Removal on exit: tie admin account removal to your joiner, mover and leaver process.
- Password storage check: verify how the engine stores any passwords it holds, using the sibling topic on IDM password encoding as the guide.
Ask your identity team to confirm which system is authoritative before writing the policy into the Flowable configuration.
Security risks that remain after the default account is gone
Removing the demo rest-admin account closes one door, but the deployment around it can still expose the same engine. The cards below cover the risks that most often survive the account change: copied configuration, unencrypted transport, shared identities, exposed monitoring, leaked credentials and missing audit trails.
Demo credentials in copied config
Docker and Compose examples are often copied into internal templates and kept long after the first test run. Search your repositories, image build files and Helm values for the default user name and its password, and check that no environment file or sample compose file still provisions it. Confirm that the admin user created in the target environment is the only one with the privilege, and that every environment, including staging, is provisioned from a source that does not carry the demo account.
REST API served over plain HTTP
Basic authentication sends credentials with every request, so a REST endpoint reached over plain HTTP exposes the admin password to anyone on the path. Confirm that the Flowable REST application sits behind TLS termination at a load balancer, ingress or reverse proxy, and that HTTP is closed or redirected at every listener. Check the proxy configuration itself, not only the application, because a direct port on a container or node can bypass it.
Admin accounts shared across teams
When one rest-admin login is shared by developers, operators and support staff, nobody can tell who changed a deployment or started a process. Replace the shared login with named administrative users, each assigned only the privileges their role needs. Ask who holds the rest-access-api privilege today, and whether the owners of each named account still work on the platform.
Actuator endpoint exposing monitoring data
The Spring Boot starters expose an actuator endpoint at /actuator/flowable that reports on running processes. Monitoring data about process activity can help an attacker map workflows and their volumes, even when the REST API is locked down. Check whether the endpoint is reachable from outside the management network, whether it requires authentication, and which actuator endpoints the Spring configuration enables.
Credentials leaking into CI logs
Deployment pipelines that run REST calls to deploy process definitions often print the request, including the Authorization header, or echo variables in debug output. Review pipeline scripts for verbose curl flags, shell tracing and logged environment variables, and store the admin credentials in the pipeline secret store with masking enabled. Rotate any credential that has appeared in a build log, and confirm who can read historical logs.
No audit trail for admin actions
Deploying process definitions, creating users and changing privileges are administrative actions that must be attributable to a person. Confirm that your logging captures REST calls with the authenticated identity, and that those logs are shipped to storage outside the Flowable host. Decide who reviews them, how long they are kept, and how a change to a privilege or a deployment would be traced back to the account that made it.
What to confirm in your Flowable version and environment
The default rest-admin account is defined by the release and packaging you run, not by a single rule. Each card below is a check to close in the vendor documentation or your own test environment before you rotate credentials or expose the REST application.
Default account and privileges per release
Confirm the username, the privileges it holds and the password it ships with in the exact release you deploy. Flowable 8.0.0 was released on February 27, 2026, and the 7.x line differs in its baseline, so do not reuse notes from an older version. Record the privilege list for the account so your replacement grants no more than the default did, and keep the 8.0.0 release notes open while you check.
Startup user creation in images and starters
Determine whether the Docker image, the REST application WAR or the Spring Boot starter creates the demo user at startup, and whether it does so only when the database is empty. A configuration file in your image may recreate the account on every restart, which means rotating the password once is not enough. Test by starting a clean container against your own database and listing users before any credentials are issued.
Interaction with the IDM tables
Work out where users live: in the IDM tables of the engine or in an external identity source. If you replace IdmIdentityService with LDAP or another source, the demo account may still exist in the IDM tables and remain valid for basic authentication. Query the user table directly after deployment, and confirm which identity source the REST application actually consults for each request.
Privilege naming and assignment
Confirm how privileges are named, stored and assigned in your version, including the rest-access-api privilege and any admin-level privileges. Naming and assignment rules can differ between releases, so an assignment that works in one version may silently grant nothing in another. Use a non-production user with only the privileges you intend, then call representative endpoints to see which return access denied.
Password policy and storage behavior
Verify the password policy your version enforces, the encoding applied to stored passwords and whether a new password is hashed when you set it through the API or directly in the database. Set a test password through each path, then inspect the stored value. Confirm that the policy applies to users created by administrators as well as self-service changes.
Testing the change in CI
Add an automated check to your pipeline that starts the release you deploy, attempts sign-in with the demo username and password, and fails the build if authentication succeeds. Include a test that confirms the replacement admin can perform the administrative calls you need. Ask your team to repeat this check after each Flowable upgrade, since the default account can reappear with a new image.
Questions teams ask before changing the Flowable rest-admin account
How much effort does changing the default rest-admin account take?
The effort depends mostly on how many environments run Flowable, where identities are stored, and how much existing automation depends on the demo account. A single development container with no shared data is a small change. A platform with separate development, test, staging and production environments, each with pipelines, health checks and scripts that call the REST API with the default credentials, is a larger one. Each environment needs a new administrator, a credential rotation, a review of every client that authenticates as rest-admin, and a verification pass. Ask any partner to break the estimate down by environment and by integration rather than quoting one figure for the whole platform.
How long does the change take, and what sets the timeline?
The timeline is set by the scope you agree in writing, not by a standard duration, so confirm the schedule against your own environment before work starts. The main variables are the number of environments, whether the new administrator users are created in the Flowable identity tables or in an external identity provider, how many scripts and pipelines must be updated, and how many change windows your operations team allows. Expect the work to split into discovery, a change in a non-production environment, verification, and then production. Each stage can wait on approvals from people outside the project team.
What does the work need from our team?
The work needs three things from your side. First, an identity owner who decides how administrators are named, which privileges they receive and how passwords must be set and rotated under your password policy. Second, access to each environment, including the Flowable REST application, its database and the deployment pipeline, so changes can be tested where they will run. Third, a change window in each environment, agreed with operations, during which clients using the old credentials can be updated. Ask your team to list every system that calls the REST API today, since those are the places where the old account is most likely to be hard-coded.
Can our internal team make this change alone?
Yes, if your team has administrative access to the Flowable deployment, knows the identity configuration and can test API calls in each environment. The change itself is a configuration and data task, but the risk lies in what depends on the old account. Internal teams often miss scripts in CI jobs, monitoring checks and older Docker Compose files. A review of the environment against a checklist, plus a written rollback plan, reduces that risk whether the work is done internally or by a partner. Decide early who will own the change record and who signs off on the new privilege model.
What does a fixed-scope engagement cover for this change?
A fixed-scope engagement covers the work agreed in writing before it starts. For this topic, that usually means confirming the environments in scope, documenting the current use of the default account, defining the replacement administrators and their privileges, setting the password policy, applying the change in each environment, verifying that the old credentials no longer work and that the new accounts can perform the required calls, and handing over the documentation. The written scope should also state what is excluded, such as changes to external identity providers or rewrites of client applications, and what evidence is delivered. DeployOpen does not publish a price list, so a quote follows from that written scope.
What happens to our existing Docker examples after the change?
Docker examples that start Flowable with the default rest-admin credentials will stop authenticating once the account is changed or removed, so they need to be updated before the change reaches any shared environment. Update the example to read administrator credentials from environment variables or a secrets store, and remove any default password from the image, Compose file or README. Developers who rely on the example will need the new credentials through a secure channel. Keep a clearly labeled development profile separate from production configuration, so the demo convenience does not carry into deployed systems.
How the admin change fits the wider Flowable hardening work
Replacing the demo rest-admin account is the first step in securing a Flowable REST deployment, and the order matters. The account is the one identity that can reach the administrative surface of the REST application, so it has to be replaced with a named administrator and a strong password before the service is reachable from any network you do not fully control. Once the default credential is gone, the remaining work changes shape: you are hardening a deployment that has no known login, rather than one where anyone who reads the examples can get in. Treat this as a gate. Do not expose the endpoint to a load balancer, a test environment that others can reach, or a partner network until the default account is removed and the new privileges have been checked.
After the account change, the next decisions follow the same path. The sibling topic on REST authentication and privileges explains how callers authenticate and which privileges gate the REST endpoints, so your new admin user and any service accounts should be mapped to the smallest set of privileges they need. The topic on encoding Flowable IDM passwords covers how the password store holds credentials, which matters because your new admin password is only as protected as the storage behind it. The topic on securing Flowable expressions and the REST surface covers which endpoints to expose at all and how the actuator endpoint, documented under Spring Boot as /actuator/flowable, should be restricted. Finally, the topic on task and process authorization covers checks your application layer must make before completing tasks or starting processes, because the REST administrator role does not decide who may act on a given business task.
Confirm each of these with your own environment before you go live: the identity source you will use for administrators, whether your deployment disables the IDM engine in favor of LDAP or an identity provider, and which REST endpoints your clients actually call. Record the outcome of each sibling check in the same change record as the account change, so an auditor or security reviewer can see the sequence: default account removed, password storage confirmed, privileges reduced, surface reduced, then exposure.
How DeployOpen scopes and delivers Flowable identity hardening
DeployOpen plans and implements the change to the default rest-admin account inside your own infrastructure, from the first inventory of where the demo credentials are used to the final handover. Engagements are fixed-scope, so the written scope sets what gets changed, tested and documented before work starts.
How we scope
- Inventory every Flowable deployment, REST application and Docker example that still uses the default rest-admin user.
- Agree in writing which admin users, privileges and identity sources will replace the demo account.
- Record the password policy, network exposure rules and who approves changes before any build begins.
How we build
- Create named administrative users with the privileges each role needs, then remove or disable the default account.
- Configure the password policy and identity source in the engine, using the identity service options the Flowable docs describe.
- Test that the old credentials fail, that new accounts log in and that REST calls are refused without valid authorization.
How we hand over
- Deliver the configuration, deployment changes and a written runbook for creating, rotating and removing admin accounts.
- Document the verification steps and their results so your team can repeat them after future releases or redeployments.
- Walk your engineers and security reviewers through the change and confirm which items remain with your team.
How we support
- Offer ongoing support and upgrades as a retainer when your team wants continued help after the initial hardening.
- Re-run the credential checks when Flowable versions, Docker images or REST application settings change.
- Confirm support terms, response expectations and repeat testing scope in the quote before the retainer starts.
