Securing Flowable REST APIs with Keycloak: what the integration does
A team whose Flowable REST API still relies on HTTP basic authentication usually has a shared credential problem before it has a Flowable problem: every client holds a username and password, and nothing central can expire, scope or revoke access for one caller without touching the others. The supported way to change this is to make Spring Security's OAuth 2.0 resource server validate JSON Web Tokens issued by Keycloak, so the Flowable REST endpoints trust tokens from the identity provider instead of checking passwords themselves. The identity side has to be handled alongside that change, because Flowable's own identity management (IDM) engine still holds the users and groups that process tasks are assigned to. The IDM engine must either be replaced with a service that reads from Keycloak or kept in step with it, and the choice affects every task assignment and candidate group in the models.
By default, the Flowable REST API uses Spring Security basic HTTP authentication and requires every resource to be called by a user holding the rest-access-api privilege, unless flowable.rest.app.authentication-mode is set to any-user. Moving to Keycloak changes what that privilege check means. The bearer token carries the caller's identity and roles, so the team has to decide which Keycloak roles or scopes should map to rest-access-api and to the Flowable privileges used for administration, and which should map to candidate groups for task work. Until that mapping is designed, a token that authenticates successfully may still be refused by Flowable, or may be accepted with more access than intended. The team should confirm the exact authentication-mode behavior for its Flowable version against the Flowable REST API documentation before changing settings, and keep HTTPS in place, since the docs recommend it alongside any authentication method.
What you need before changing Flowable REST security
Changing the Flowable REST API from basic authentication to Keycloak tokens touches four moving parts: the Flowable and Spring Boot baseline, the Keycloak release and database, the realm and client design, and the network paths between them. Confirm each one before you write a line of security configuration, because a mismatch in any of them is hard to diagnose once tokens start failing.
Flowable and Spring Boot baseline
Confirm which Flowable release and Spring Boot line your REST application runs on before choosing the Spring Security settings. Flowable 8.0.0 requires Spring Boot 4 and has no backward compatibility for Spring Boot 3, so a 7.x application on Spring Boot 3 needs its own upgrade path first. Check the resource server dependency version against the Spring Boot line you actually deploy, not the one in an older sample.
Keycloak release and support model
Pick the Keycloak distribution and release line before building realms, because minor releases now come often and breaking changes are opt-in. Decide between community Keycloak and the Red Hat build if you need vendor support. Confirm the exact version you will run against the current Keycloak documentation and your support contract, not against a version number copied from a blog.
Database for Keycloak
Keycloak needs a supported production database, and the development file database is not an option for a shared environment. Choose from the supported list, provision it in the same region as the cluster, and agree on whether schema migration runs at startup or is applied by hand. Large deployments often prefer manual migration, so decide this before the first upgrade window.
Realm and client design
Define the realm, the Flowable API client, and the client that front ends use to obtain tokens before any configuration. Decide which Keycloak roles and groups will map to Flowable privileges and candidate groups, and keep the list short enough to review. Record the token audience and scopes the resource server will accept, so the Spring Security issuer and claim mapping match what Keycloak actually issues.
HTTPS on every endpoint
Flowable's documentation recommends combining its REST authentication with HTTPS, and bearer tokens make that requirement stricter because a captured token is directly usable. Terminate TLS for the Flowable REST application, the Keycloak issuer URL and the admin console, and confirm that certificates are trusted by every service that calls the issuer metadata endpoint. Mixed HTTP and HTTPS issuer URLs are a common source of token validation failures.
Network paths and high availability
Map every connection: clients to the Flowable REST application, the REST application to the Keycloak issuer and JWK set endpoints, and both services to their databases. Confirm firewall rules and DNS for each path in every environment. Confirm the Keycloak high availability design with the vendor documentation before planning, because the supported multi-site designs require a synchronously replicated database and their own network assumptions.
How to configure Keycloak tokens for the Flowable REST API
This sequence moves the Flowable REST API from basic authentication to Keycloak-issued tokens, so each call is checked against a realm your identity team controls and the Flowable side accepts only the access it is meant to allow.
Create the realm and client for Flowable
The identity administrator creates or selects a Keycloak realm for the Flowable applications and registers a client that represents the Flowable REST application, with the token settings your access model requires. Record the realm's issuer URI, which has the form of the Keycloak server address followed by the realm path, because the resource server needs it in the next step. Confirm the client and realm exist by fetching the realm's OpenID Connect metadata document from the browser or with curl, and check that the issuer value in the response matches what you recorded. Keycloak's server administration guide describes realm and client setup in detail.
Set the issuer URI on the resource server
The Flowable application team adds spring.security.oauth2.resourceserver.jwt.issuer-uri to the Spring configuration of the REST application, using the issuer recorded in the previous step. Spring Security then reads the metadata at that issuer, discovers the JWK set used to verify token signatures, and validates the issuer claim on each token, so the application does not need its own copy of the signing keys. Restart the application and confirm it starts without errors about the issuer. Then request the Flowable REST root with a token issued by the realm and receive a response rather than a 401.
Map token scopes to Flowable authorities
By default Spring Security maps the scope or scp claim to authorities with the SCOPE_ prefix, so a token carrying a scope named flowable-rest appears to Spring as SCOPE_flowable-rest. The platform team decides which Keycloak client scopes or roles carry Flowable access, then either adds the scope to the client or writes a JwtAuthenticationConverter that maps Keycloak realm roles to the authority names the Flowable privilege checks expect. Verify the mapping by decoding a sample token and calling a read endpoint with a user who should have access and another who should not. The two calls should return different results.
Disable or restrict basic authentication
The Flowable REST API uses basic HTTP authentication by default, so leaving it enabled means a user with a password can bypass the token flow. The security engineer removes the basic authentication filter chain for production profiles, or limits it to a named internal account used for break-glass work, and confirms that the chosen configuration matches the change record. Test by sending a request with a valid username and password to a protected resource and expecting a 401 response. Keep a separate test profile only where the team has documented why it needs basic access.
Set the Flowable authentication mode deliberately
The flowable.rest.app.authentication-mode setting controls who may call the REST API once the user is authenticated. By default, each resource requires a user with the rest-access-api privilege, while the any-user value lets any authenticated user through. The team chooses the value based on its authorization model, sets it in the application configuration, and records the reason in the configuration documentation. Check the result with two tokens, one for a user holding the privilege and one without it, and confirm that the second receives a forbidden response on a protected endpoint. The Flowable REST API documentation describes the default and the any-user option.
Confirm rejected and accepted calls end to end
The QA or security team runs a short scripted set of requests covering four cases: a valid token with the right privilege, a valid token without it, no token, and a token from an unrelated issuer or with an expired signature. Each case should produce the expected status code, and the team saves the outputs with the configuration version. Any accepted call that should have been rejected blocks the release until the mapping or mode is corrected. Keep the script in version control so it reruns after each Flowable or Keycloak upgrade.
Document the token contract for callers
The platform team writes down which realm, client and scopes callers must request, which Flowable privilege each endpoint needs, and how token lifetime and refresh are handled by client applications. Callers such as internal portals, external workers or integration services use this document to obtain tokens rather than reusing shared passwords. The step is complete when each calling service has a named client in Keycloak and a test that confirms it can reach only the endpoints it needs.
How Keycloak tokens change the Flowable REST request path
Replacing basic authentication with Keycloak tokens changes the request path in three steps: the client obtains a token from Keycloak, sends it to the Flowable REST application as a bearer token, and the REST application validates that token before any Flowable code runs. The Spring Security resource server sits in front of the Flowable REST endpoints and performs that validation. It reads the issuer from spring.security.oauth2.resourceserver.jwt.issuer-uri, discovers the JWK set from the issuer's metadata, and checks the token signature against Keycloak's published keys. Flowable itself never sees a password. Authorities come from the token's claims: by default Spring Security maps the scope or scp claim to SCOPE_ authorities, so a Keycloak client role or realm role does nothing for Flowable until you map it to the authority names Flowable checks.
The trust boundary sits between the Flowable REST application and the identity provider. Inside that boundary, the REST application trusts a token only if its signature, issuer and expiry check out. Keycloak is trusted to decide who the user is and which roles they hold. Confirm with your security team which Keycloak realm, issuer URL and signing keys the REST application will accept, and whether the REST application can reach the issuer's metadata endpoint from its network segment, since that discovery call is part of startup.
Until the token-to-privilege mapping is in place, the existing default still applies. Flowable's REST API requires an authenticated user holding the rest-access-api privilege unless flowable.rest.app.authentication-mode is set to any-user. A valid Keycloak token without that mapping can therefore authenticate and still receive a 403 on every resource. Keep basic authentication working during the cutover, test a token-bearing user against each endpoint your applications call, and do not switch the authentication mode to any-user to get past the error.
Mapping Keycloak roles and users to Flowable privileges and groups
This table compares each Keycloak source (realm roles, client roles, groups, user attributes) with the Flowable target it feeds, who should own that mapping, and how changes should be reviewed. Read it as a starting checklist: the Flowable side of each row depends on your own process models and identity service, so the team must confirm every target against the candidate groups and assignments those models actually use.
| Keycloak source | Flowable target | Mapping owner | Change review |
|---|---|---|---|
| Client role on the Flowable client (for example, rest-access-api) | Flowable REST privilege checked by Spring Security for every REST resource | Platform or IAM team that manages the Keycloak realm | Reviewed as an access change, approved by the application owner before deployment |
| Realm role granted to operators or administrators | Privileged REST access such as admin-level endpoints, if the team exposes them | Identity team, with the Flowable application owner as approver | Quarterly access review and a ticket for each grant |
| Keycloak group (for example, claims-adjusters) | Candidate group used in userTask candidateGroups in BPMN models | Business process owner for the group, with IAM maintaining membership | Changes to group names reviewed against the deployed process definitions |
| User attribute (for example, region or branch code) | Process variable or IDM user attribute used in expressions or assignment rules | Application team that defines the attribute schema | Schema change reviewed with the models that read the attribute |
| Token claim: scope or scp | Spring authorities named SCOPE_ that the resource server checks | Platform team that configures the client scopes | Any new scope tested against the REST endpoints before release |
| Keycloak user ID or username | Flowable IDM user record kept in sync through a custom IdmIdentityService | Integration team that owns the sync job | Sync logic reviewed and tested with users added, changed and disabled |
| Disabled or removed Keycloak user | Flowable user removed from candidate groups or marked inactive in IDM | Identity team, with the business owner confirming open tasks | Offboarding checklist that includes reassigning running tasks |
| Client role or group names used in models | Candidate group and privilege names referenced in BPMN, CMMN and DMN artifacts | Flowable model owners | Confirm each name against deployed models before any Keycloak rename |
Keeping the Flowable IDM engine in sync with Keycloak users
The first decision is how the Flowable IDM engine learns about users and groups at all. Flowable docs say identity management can be replaced either by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, with an LDAP identity service provided as a reference. Overriding the default implementation keeps the rest of the engine's behavior intact but ties you to its internals, so upgrades can break your code. Implementing the interface gives you a clean contract, but you must supply every lookup the engine calls, including user and group queries used for candidate assignment. The LDAP implementation is a reference to study, not a drop-in answer for Keycloak. Confirm with your team which lookups the engine calls in the version you run, and plan to test each one against Keycloak data.
Each option answers three questions differently: how users are created, how group membership is read, and how deprovisioning happens. Keycloak can be the source for these through its user federation and identity brokering features, but Flowable does not read Keycloak directly through the REST API. Your identity service must either call Keycloak's admin API, read from a synchronized copy, or rely on a scheduled or event-driven sync job that writes to the IDM tables. Before building the sync, confirm in your Keycloak realm whether users come from a federated provider such as LDAP or Active Directory, which attributes and groups are exported, and how disabled users appear to clients. Confirm also whether the group names you map from Keycloak roles match the candidate group names your BPMN models use.
Stale records matter because task routing depends on the IDM database, not on the token. A user removed or disabled in Keycloak but still present in the IDM tables can keep receiving tasks through candidate groups, while a user added to a group in Keycloak but missing in IDM will never see tasks routed to that group. Deprovisioning needs particular care, since a valid bearer token only proves identity at the API layer. Plan a reconciliation check that compares group membership between the two systems, and decide how long a removed user's open tasks are reassigned. Test the sync against a realm export of realistic size in a non-production environment before connecting it to live process instances.
Security settings to harden the Keycloak and Flowable link
Moving Flowable REST endpoints from basic authentication to Keycloak tokens shifts trust to two systems: the identity server and the resource server that validates its tokens. The cards below cover the transport, token validation, scope, lifetime, client secret and cutover settings that connect them, and what to check in each before go-live.
HTTPS on every hop
Flowable's docs recommend combining authentication with HTTPS, and that applies to three hops here: the browser or client to Keycloak, the client to the Flowable REST application, and the Flowable service to Keycloak when it fetches keys and metadata. Terminate TLS with certificates your organization manages and confirm that the issuer URL in spring.security.oauth2.resourceserver.jwt.issuer-uri uses HTTPS. Check that no internal hop falls back to plain HTTP behind a load balancer.
Issuer and audience validation
Spring Security discovers the JWK set from the issuer's metadata, but it does not by itself restrict which client a token was issued for. Confirm that the issuer value matches the realm URL exactly, including the hostname that clients actually use. Add an audience check so that a valid token issued for another Keycloak client cannot call the Flowable APIs. Test with a token from a different client in the same realm and expect a rejection.
Scope restriction per endpoint
Spring Security maps the scope or scp claim to SCOPE_ authorities by default, so the Flowable security configuration can require a specific scope for each area of the REST API. Separate read-only monitoring calls from process start, task completion and deployment calls. Keep the rest-access-api privilege in Flowable as the application-level check, so a valid scope alone does not grant access to every resource.
Short token lifetimes
Access tokens should expire quickly, and clients should obtain new ones through the standard refresh or client credentials flow rather than reusing long-lived tokens. Set the access token lifespan in the Keycloak realm and agree the value with the team that owns long-running processes, since a token that expires mid-request will fail. Confirm that revoked users or disabled clients stop working within the window you accept, because a resource server validating signatures will not see a revocation on its own.
Client secret handling
Services that call Flowable with the client credentials grant hold a Keycloak client secret. Store it in a secrets manager or Kubernetes secret, never in BPMN models, process variables, Git-managed Helm values or container images. Rotate it on a schedule you can execute, and confirm that Flowable logs and history do not capture the Authorization header or token contents when delegates or HTTP tasks make outbound calls.
Disabling basic auth after cutover
Keep basic authentication available only until token-based calls work for every client, then remove it from the Flowable REST configuration and from any service that still sends a username and password. Do not leave the default setting in place with a second path open. Inventory callers from access logs first, because a forgotten script or external worker will fail at the moment basic authentication is switched off.
Keycloak production settings
Keycloak's production guide covers the settings that the development mode hides, including hostname, HTTPS, proxy headers and a production database. Use one of the supported production databases such as PostgreSQL rather than the development file database, and confirm the hostname the realm advertises in its issuer. For clusters, Keycloak documents high availability designs that need a synchronously replicated database, so plan that before the Flowable link depends on it.
Operator update approval
If Keycloak runs on Kubernetes through the Keycloak Operator, the operator documentation strongly recommends manual approval mode for operator updates. Automatic upgrades can change Keycloak versions in the middle of a Flowable release window and break token issuance or validation. Schedule operator and Keycloak upgrades in a test cluster first, and confirm that the issuer, client definitions and realm settings still match after each change.
How to test token-based access to Flowable endpoints
What test cases should I run for valid Keycloak tokens with the right roles?
Request a token from Keycloak for a test user who holds the role mapped to the Flowable privilege you expect, then call a representative set of REST endpoints with it and confirm each returns the expected status. Repeat with users who hold no mapped role and confirm they receive a forbidden response rather than data. Cover at least one read endpoint, one task completion and one process start, because each checks a different privilege. Record the token claims used so a failing case can be traced to the claim mapping rather than guessed at.
How do I test that expired tokens are rejected by Flowable?
Issue a short-lived token in a test realm, wait until it expires, and send it to a Flowable endpoint. The resource server should return an unauthorized response and the request should not reach the engine. Also test a token that was valid when issued but whose signing key has been rotated out of the JWK set, because clock skew and key rotation are common causes of intermittent failures. Confirm the behavior in the same Spring Security configuration you plan to ship, since the resource server settings determine how the issuer and keys are discovered.
How do I check that tokens for the wrong audience are refused?
Create a client in Keycloak that is not intended for Flowable, obtain a token for it and send that token to the Flowable REST API. Your Spring Security configuration should reject it if you validate the audience claim, which you must add explicitly if your setup does not already do so. Also confirm that a token issued for Flowable is rejected by another service in your estate where it should not be accepted. Treat a successful call with a wrong-audience token as a blocking defect, not a configuration note.
What should happen when a user has a valid token but lacks Flowable privileges?
The request should be authenticated but refused by Flowable's authorization checks. Test users who have a valid Keycloak login but are missing the privilege required for each endpoint group, such as process start, task query or admin-only operations. Check both the HTTP response and the absence of changes in the database, for example no new process instance or completed task. Compare the result against the privilege assigned in IDM so you know whether the gap comes from the Keycloak role mapping or from the IDM group membership.
How do I test a user deleted in Keycloak who still exists in the Flowable IDM?
Disable or delete a test user in Keycloak, then request a token for that user and confirm no new token is issued. Next, test whether any token issued before the deletion still works until it expires, and document that window. Finally, check the IDM record: the user may still appear as a candidate for tasks or in group queries even though authentication fails. Your sync process should flag or deactivate such users, and the test should show whether that process ran. The exact behavior depends on your implementation of the IDM identity service, so confirm it in your own environment.
Which metrics and monitoring checks should we run after cutover?
Watch authentication failures and forbidden responses on the Flowable REST endpoints, grouped by status code and client, because a sudden rise often points to a broken role mapping or an issuer change. Track token validation errors in the application logs, and alert on keys that fail to load from the issuer's JWK set. Monitor the Flowable actuator endpoint at /actuator/flowable for process health, and compare task and process volume before and after cutover. Also check Keycloak's own metrics for login failures and token issuance, and confirm your sync job runs on schedule and reports users it cannot match.
Can our own team run these token tests without a partner?
Yes, if your team has experience with Spring Security resource servers, Keycloak realms and the Flowable REST API. The work is mostly scripted API calls with test users, which an internal platform or QA team can build. A partner is more useful when the role mapping is complex or the IDM sync is custom, because the test design then depends on decisions made during implementation. Ask any provider to deliver the test cases as versioned scripts you can rerun, so the checks remain available after the engagement ends.
What drives the cost and effort of this testing?
The main drivers are the number of endpoint groups and roles to cover, how many Keycloak clients and realms are involved, and how much custom IDM synchronization must be exercised. Test environment setup, including a Keycloak instance and test identities that match production shape, is a one-time effort, while rerunning the suite after upgrades or role changes recurs. Ask for the test matrix, the environments it runs in, who maintains the scripts and what evidence you receive at the end, so you can compare quotes against the same written scope.
Common failures when Flowable rejects Keycloak tokens
This table lists the failures teams most often hit when Flowable REST endpoints reject Keycloak tokens, with the likely cause, the fix and what to check in logs and configuration. Work through the rows in order, since an issuer or audience mismatch hides the authority and visibility problems behind it.
| Failure | Likely cause and fix | What to check |
|---|---|---|
| 401 responses on every call | The token issuer does not match spring.security.oauth2.resourceserver.jwt.issuer-uri, often because the gateway, hostname or realm path differs from what Keycloak writes into the token. Set the issuer URI to the exact iss value the token carries. | Decode a token and compare its iss claim with the configured issuer and the realm metadata URL |
| 401 with a valid-looking token | The resource server cannot reach the issuer metadata or JWK set from inside the cluster, so signature checks fail. Make the internal network path to the realm endpoints reachable from the Flowable pods or hosts. | Startup and request logs for JWK fetch errors, outbound DNS and TLS trust for the Keycloak certificate |
| 403 with a valid token | The token carries no SCOPE_ authorities or role authorities that Flowable's security config expects. Spring maps the scope or scp claim to SCOPE_ by default, so add a mapper or converter that turns Keycloak realm or client roles into the authorities your rules check. | Authorities printed for the principal, the scope or scp claim, and the security expression used for each Flowable path |
| Tasks missing from task lists | Flowable filters tasks by assignee and candidate groups from the IDM engine, not from the token. Keycloak groups or roles that were never synced into IDM groups produce empty candidate lists even when the call succeeds. | Candidate groups on the task, group membership in IDM for the user, and whether the sync job ran after the user last changed groups |
| Expected user not found by the engine | The Keycloak user exists but has not been created or updated in the IDM engine, so user and group lookups return nothing. Run the sync on login or on a schedule and confirm the user ID matches the token subject or preferred username claim you map. | Whether the IDM user record exists, the ID value compared with the sub or username claim, and sync job logs |
| Intermittent 401 right after token issue | Clock skew between Keycloak and the Flowable host makes tokens look not yet valid or already expired. Synchronize both hosts with NTP and check that token lifetimes are not shorter than the skew you observe. | Time on both hosts, nbf and exp values in a decoded token, and clock sync status on each node |
| Basic auth clients still get through or fail | Scripts, monitoring probes or older integrations still send HTTP basic credentials, which Flowable accepts by default unless its authentication mode is tightened. Inventory these callers, move them to bearer tokens and then restrict the basic auth path. | Access logs for Authorization headers starting with Basic, the value of flowable.rest.app.authentication-mode and the callers listed in your inventory |
| Token accepted but actions denied | The token is valid, but the user lacks the rest-access-api privilege that Flowable requires by default for REST resources. Grant the privilege through the IDM mapping for the role or group that the Keycloak user holds. | Privileges assigned to the IDM user, the Keycloak role names mapped to them and the HTTP status returned for each resource |
| Failures after a Keycloak upgrade | Changes to token claims, client scopes or default mappers in a new Keycloak release can silently remove the claims Flowable depends on. Compare decoded tokens before and after the upgrade and check the release notes for changes. | Claim set in tokens from the old and new versions, client scope and mapper configuration, and the Keycloak release notes for your version |
What does it cost and take to secure Flowable with Keycloak?
What drives the cost of securing Flowable REST APIs with Keycloak?
The main drivers are how many REST endpoints and calling clients need tokens, how complex the role model is, and how much custom identity sync logic you need. Each Flowable client, such as a front end, an external worker or a back-end service, needs its own token flow and authorization rules. A small set of endpoints with a flat role model is far less work than dozens of clients mapping Keycloak roles and groups onto Flowable privileges and candidate groups. Ask any provider to break the quote down by these three drivers so you can see where the effort sits.
What is one-time work and what recurs after go-live?
One-time work covers the Spring Security resource server configuration, the Keycloak realm and client setup, the role and group mapping design, the identity sync build and the test plan. Recurring work covers Keycloak upgrades, Flowable upgrades, monitoring, realm changes as new processes or roles appear, and periodic review of who holds which privileges. Keycloak publishes four minor releases a year and says breaking changes in a minor release are opt-in, so plan a standing upgrade slot rather than treating the work as finished at launch. Confirm the upgrade effort and support terms in the written scope.
How does high availability design for Keycloak change the effort?
Keycloak documents three high availability architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1 that used a separate Infinispan cluster per site. Both supported multi-site designs need a synchronously replicated database, which is often the largest infrastructure decision. Choosing a single cluster is usually less work than a multi-site design, but the database replication requirement applies to both. Ask for the HA architecture to be named in the scope before pricing starts, because it changes the infrastructure, testing and runbook work.
What should we ask for in a fixed-scope quote for this work?
Ask for a written scope that lists the Flowable REST endpoints and clients in scope, the Keycloak realms, clients and roles to be configured, the Spring Boot and Spring Security versions targeted, and the identity sync rules. Ask which HA architecture is assumed, which database engine Keycloak will use, and whether the Keycloak Operator or another install method is in scope. Ask for the test scope, the handover documents, what happens if the scope changes, and which upgrade work is included. Fixed-scope agreements are signed before work starts, so these details should be settled in writing.
What must our team provide before the engagement starts?
Your team needs to provide access to the Flowable and Keycloak environments, a current inventory of REST endpoints and calling applications, the role and group model that exists today, and the source of truth for users, such as an HR system or directory. You also need named owners for identity decisions, a decision on the Keycloak database and hosting, and access to the test environments. Without a documented role model and a clear user source, the mapping and sync design will stall. Confirm these inputs against your own environment before the scope is signed.
Can an internal team secure Flowable with Keycloak without outside help?
An internal team with Spring Security, Keycloak and Flowable experience can do much of this work, and the Flowable docs describe the identity service extension points and the REST authentication defaults. The harder parts are usually the role model design, the identity sync logic and a test plan that covers every endpoint and client. Teams that have not run Keycloak in high availability or upgraded Flowable across a major version often find those areas take longer than expected. Assess your team's skills in those areas before deciding, and consider a partner for the parts you lack.
How much testing does this work need, and what does it cover?
Testing should cover every REST endpoint and every calling client, including positive and negative token cases, expired or missing tokens, and users with too few or too many privileges. It should also check that Flowable candidate group and task assignment behave correctly for each mapped role, and that identity sync creates, updates and disables users as designed. Testing scope grows with the number of endpoints, clients and roles, so ask the provider to list the test cases and the environments they run in. Verification also needs to be repeated after every Keycloak or Flowable upgrade.
Does this work support audit or certification requirements?
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Access records, token configuration, role mappings and sync logs can serve as evidence for access control requirements, and auditors will test whether those records are complete and current. Independent auditors and certification bodies make the final determination. Ask your auditor which evidence they expect for access control before the design is locked.
Where to confirm configuration details
Before you change any property, confirm its exact name against the Flowable version you run, because the REST and identity settings in this section depend on how the engine was built. Start with the Flowable REST API documentation, which describes the Spring Security basic authentication you are replacing, the rest-access-api privilege and the flowable.rest.app.authentication-mode setting. Read it alongside the Flowable identity management docs, which explain how the IDM engine can be replaced through IdmIdentityService. Those two pages decide whether your Keycloak roles can reach the engine at all and where user and group data comes from, so treat them as the reference for your design review.
For the token side, use the Spring Security OAuth 2.0 resource server guide for JWT validation. Confirm the property spring.security.oauth2.resourceserver.jwt.issuer-uri, the way your Spring Boot version maps the scope or scp claim, and whether you need a custom converter to turn Keycloak realm or client roles into the authorities your Flowable privileges expect. Spring Boot major versions change these details, so check the guide that matches your Spring Security release. On the Keycloak side, the Keycloak server administration guide covers realms, clients, roles and token claims, and the Keycloak production configuration guide covers hostname, TLS and proxy settings that the issuer URL depends on. Ask your Keycloak operator which of these settings are fixed by your deployment template.
Record what you confirmed in a short configuration baseline, with the Flowable release, Spring Boot version, Keycloak release and the exact property names, and review it whenever either product is upgraded. Ask your vendor or partner to show the same names in your own build, not only in the documentation, since a mismatch usually surfaces as a silent authorization failure rather than a startup error.
How DeployOpen scopes and delivers Flowable and Keycloak security
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Securing Flowable REST APIs with Keycloak, we start with a written scope covering your Keycloak realm, your Flowable deployment and the role and group mapping between them, then build and test the change in your environment before handover.
How we scope
- We inventory which Flowable REST endpoints, clients and automation rely on basic authentication today.
- We agree in writing which Keycloak realm, clients, roles and groups map to Flowable privileges and candidate groups.
- We confirm your Keycloak hosting model, database and high availability requirements before any build work starts.
How we build
- We configure the Spring Security resource server settings for your Flowable application in your own repositories.
- We implement the IDM identity service so Keycloak users and groups stay in step with the Flowable identity tables.
- We test token validation, privilege checks and candidate group routing against representative user accounts before release.
How we hand over
- We document the realm configuration, claim mappings, configuration keys and the sync logic so your team can maintain them.
- We provide a runbook covering token lifetimes, key rotation, and what to check when a user or group change does not reach Flowable.
- We walk your engineers through the test cases so they can repeat them after future Keycloak or Flowable upgrades.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, covering changes to Keycloak or Flowable releases.
- You receive a written quote that follows from the agreed scope, since DeployOpen does not publish a price list.
