Flowable SSO and identity integration guide

How Flowable SSO connects users, groups and tasks

Flowable SSO means two separate jobs, and teams that treat them as one usually end up with a setup that works in the browser but fails in task assignment or API calls. The first job is resolving users and groups so that tasks go to the right people. The IDM engine handles this through its identity service, which answers questions such as which users are candidates for a task and which groups a user belongs to. The second job is authenticating the callers of the Flowable REST API, which sits behind its own security layer that your application or Spring Security configuration controls. Most teams in this position run Flowable in a Java stack and want employees to sign in once and then see the right work in their task lists.

Identity is harder than it looks because the engine keeps its own identity tables and does not read your directory on its own. A single sign-on login at the browser or gateway proves who the user is, but it does not populate those tables or tell the engine which groups that user holds. Candidate users and groups are resolved by the identity service at the moment a task is assigned or claimed, so a person who authenticates successfully can still see no tasks if the engine cannot resolve their groups. The REST API adds a second gap: securing the web front end does nothing for calls made directly to the engine endpoints, so each path needs its own authentication and authorization decision.

The Flowable documentation describes two ways to replace the default identity management. You can override the default identity service implementation or implement the IdmIdentityService interface yourself. The documentation also provides an LDAP identity service implementation as a reference. Treat that reference as a starting point that you review and adapt to your directory schema, group structure and query patterns. The exact integration depends on your chosen identity provider and your Flowable version, so confirm with the vendor and your own tests which identity service methods your version calls and whether your provider exposes group membership in the form the implementation expects. Do not assume that a provider is supported simply because a generic LDAP or OpenID Connect option exists.

Several decisions shape the design before any code is written. Decide whether group membership is read from the provider at login, at each lookup, or from a synchronized copy, and accept the trade-off in freshness and load. Decide how nested groups are flattened into the candidate groups that BPMN user tasks use. Decide what happens to open tasks when a person leaves a group or the directory, since assigned work can outlive the access that justified it. Write a mapping table from provider groups to Flowable candidate groups and review it with the process owners. An illustrative example: a claims group in the directory maps to a candidate group named for that team, and membership changes there should be visible to the engine on the next task lookup.

Verify the integration with test accounts in each relevant group. Confirm that a task assigned to a candidate group appears for every member and disappears for someone removed from the group. Check that a user who is not in the group cannot claim the task through the API. For the REST API, test requests with expired tokens, tokens issued for another audience and requests with no token at all. Record the results, because auditors and security reviewers will ask how access to tasks is enforced and tested.

Which Flowable components carry identity

Identity in Flowable is spread across several components, each with a different owner and a different failure mode. The cards below separate the engine-level identity service from the LDAP reference implementation, the REST layer, the Spring Boot wiring and the database tables, so you can see where each user and group decision lands.

IDM engine and IdmIdentityService

The IDM engine is the part of Flowable that answers questions about users and groups for the process engines, through the IdmIdentityService interface. Process engines call it when they resolve candidate users, candidate groups and assignees for tasks. The default implementation, IdmIdentityServiceImpl, reads from Flowable's own tables, so it is the component you override when your users live in an external directory. Confirm in your version's source which methods the interface exposes and which ones the engine calls during task assignment.

IdmIdentityServiceImpl as the override point

IdmIdentityServiceImpl is the default implementation you replace or extend when identity comes from your identity provider. Replacing it means your code answers every lookup the engine makes, so gaps in your implementation show up as tasks that no one can claim or as assignments that fail silently. Decide whether you extend the default for a few methods or implement the full interface. Confirm in your version's documentation and source how the engine is configured to use your bean instead of the default.

LDAP identity service reference

Flowable provides an LDAP identity service as a reference implementation for directories such as Active Directory or OpenLDAP. It shows how to map directory users and groups onto the identity service interface, including how search filters and attribute names are configured. Treat it as a starting point rather than a finished integration: directory schemas, nested group membership and paging behavior differ between environments. Confirm in your version's source which directory features the reference handles and which you must add.

REST application and Spring Security layer

The Flowable REST application exposes engine operations over HTTP, and its authentication is handled by a Spring Security layer that sits in front of those endpoints. This layer decides who can start processes, read tasks and query history, so it is where OAuth2 or OpenID Connect integration is attached. Note that REST calls are authenticated separately from the engine's identity service, so a user can be authenticated at the HTTP layer and still have no candidate groups in the engine. Confirm the security configuration classes and the authorities they expose in your version.

Spring Boot starters and wiring

The Flowable Spring Boot starters for the engines and the REST application register the identity beans, security configuration and data sources automatically. Because auto-configuration can supply a default identity service, your custom bean must be declared so that it takes precedence, or the engine silently keeps using the built-in tables. Check which starter pulls in which beans, and confirm in your version's documentation how the override is declared and whether the REST starter adds its own security filter chain.

Identity database tables

Flowable stores its default users, groups and memberships in database tables that the engine schema creates and upgrades. Even when an external directory is the source of truth, these tables can still be read, joined or written by parts of the engine, and they must be included in backups, access reviews and schema upgrade plans. Decide whether the tables stay empty, hold a synchronized copy, or serve as the active store, and confirm the exact table names and schema changes for your version before any upgrade.

Which identity source and login model fit your Flowable setup

This table compares four ways to connect identity to Flowable: syncing users into the built-in IDM tables, replacing IdmIdentityService with a directory-backed service, building on the LDAP reference implementation, and separating REST API login from task identity. Read each row against your directory, your upgrade cadence and how much custom code your team can maintain. The main takeaway is that the cheapest option to start is often the costliest to keep correct after upgrades.

Option	When it fits	Operational cost	Risk it adds
Sync users and groups into built-in IDM tables	Directory changes are infrequent and a short delay in access changes is acceptable	Scheduled sync job to build and monitor, plus ongoing reconciliation of deleted or moved users	Stale candidate assignments if the sync fails silently, and orphaned tasks for departed users
Replace IdmIdentityService with a directory-backed service	Candidate groups must reflect the directory at the moment a task is queried	Custom Java code to maintain across Flowable upgrades, plus directory query load on every lookup	Directory outages or slow queries can stall task lists, and the interface may change between major versions
Start from the LDAP reference implementation	Your users live in LDAP or Active Directory and you want a documented starting point	Configuration and customization of the reference code, retested with each engine upgrade	Attribute mapping errors and assumptions about group structure that do not match your directory
Separate REST API authentication (OIDC or OAuth2) from task identity	Applications or services call the REST API and humans act on tasks through their own apps	Spring Security configuration, token validation and a mapping from token claims to Flowable user IDs	Mismatched user IDs between token and engine can grant or hide tasks, so claim mapping needs testing
Who owns the identity mapping	Platform team owns the directory and the Flowable team owns process models	Ownership gaps appear when group names change in the directory without a matching model update	Process models may route work to groups that no longer exist
Confirm before choosing	Ask your Flowable partner which option your engine version documents and supports	Upgrade effort depends on how far your code departs from the documented interfaces	Relying on undocumented internals can break silently on the next release

Build sequence for Flowable SSO, from directory to task inbox

This sequence takes Flowable from a directory model and identity provider claims to a verified login path where users see the tasks their groups should see. Each step ends with a check you can run before moving on, so identity problems surface in isolation rather than in end-to-end testing.

Confirm the directory model and claims
Start by writing down the directory model Flowable has to represent: users, groups, nested groups, and service accounts used by integrations. For each, record which system is the source of truth, the unique identifier Flowable will store as a user ID, and the claims your identity provider issues in tokens, such as subject, group membership and display name. Note where nested groups are flattened or excluded, because Flowable's candidate group checks only see what your identity service returns. Done when a reviewer from the identity team signs off a one-page mapping of each attribute to a Flowable field, and the open questions list is empty or assigned to an owner.
Choose the identity source
Decide where Flowable reads users and groups at runtime. Common options are a direct LDAP or Active Directory bind, a query against the identity provider's API, or a replicated copy in the application database. Each has different latency, failure behavior and audit consequences, and the choice determines what the replacement identity service must implement. Confirm with the directory owner whether a read-only bind account is permitted and which attributes it may read. Done when the chosen source, the access pattern and the bind or client identity are recorded in the design, and the security team has accepted them.
Implement and test the identity service in isolation
Flowable's docs state that identity management can be replaced by overriding the default identity service implementation or by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Build the replacement so user lookup, group lookup and group membership queries return the mapping from step one. Test these methods with unit tests that run without the Flowable engine, using a directory fixture that includes nested groups and a disabled user. Done when the tests pass for existing users, unknown users, a user in several groups, and a user whose group nests under another group, and the results match the mapping document exactly.
Map groups to candidate groups and check visibility
In each BPMN process model, decide which groups are candidate groups for user tasks and whether any tasks use candidate users instead. Keep the group identifiers identical to those returned by the identity service, since a case difference or prefix change will silently hide tasks. Deploy the model to a test environment and sign in as test users from different groups, then query the task list through the Java API or REST API. Done when each test user sees exactly the tasks their groups should see, and a user outside the group sees none of them.
Secure the REST API with Spring Security
Protect the Flowable REST endpoints with Spring Security configured either as an OAuth2 resource server that validates bearer tokens or as an OIDC client for interactive users, depending on whether the API is called by people, services or both. Configure the issuer, audience and accepted signing algorithms from your identity provider, and map token claims to Spring authorities. Confirm the Spring Boot and Spring Security versions against the Flowable release you are running, since version 8.0.0 requires Spring Boot 4. Done when a request without a token is rejected, a token with the wrong audience is rejected, and a valid token for a test user returns only the tasks visible to that user.
Wire credentials through the secrets store
Move the bind account password or the OAuth client secret out of configuration files and into your secrets store, then inject them at startup. Give the bind account read-only access to the directory scope in step one and nothing more. Confirm that rotation can happen without a code change, and that logs do not print the credential or the full bind request. Done when the application starts with the credential supplied only by the secrets store, a rotation test in a non-production environment succeeds without redeploying code, and a log scan finds no credential values.
Run end-to-end login and task claim tests
Run the full path in a production-like environment: sign in through the identity provider, call the task API, claim a task as a user in the candidate group, complete it, and confirm that a user outside the group cannot claim it. Include a test for a user removed from a group after the task was created, and a test for a disabled account with an existing session. Record each result against the test case list. Done when every login, claim, unclaim and completion case passes, the access denials are logged with the expected identity, and the test evidence is stored with the release record.

How directory groups become candidate users and tasks

Flowable does not read your directory on its own. A group from the identity provider affects a task only when a process model names that group, and the engine then decides who can see the task by consulting the identity service it was configured with. In the IDM engine, that service is the IdmIdentityService interface, which you can implement or override, and the Flowable docs point to an LDAP identity service as a reference. The first decision is therefore which component owns each part of the mapping: the feed into your identity service, the candidate attributes in the BPMN user task, or the claims in the token that the REST layer checks. Record one source of truth for each question, because mixing them is where task visibility bugs usually begin.

Each location answers a different question. The identity service answers whether a given user belongs to a given group, and task queries depend on that answer. The process model answers which group or user a task is offered to, usually through candidateGroups or candidateUsers attributes whose values must match the identifiers your identity service returns exactly. Token claims answer whether a caller may invoke a REST endpoint at all, typically through Spring Security authorities. A claim can say a user is on a team, but the engine will still list a task only if its identity service agrees. Confirm for your Flowable version and chosen identity implementation which of these the engine consults at task creation and which it consults at query time, and whether group identifiers are stored on identity links.

Nested groups are the first place the design tends to break. If your directory nests teams under departments, the identity service must decide whether membership is direct or transitive. Expanding nested membership inside the identity service keeps the process model simple, but each lookup becomes heavier and the expansion must be refreshed when the directory changes. Renames and removals depend on identifiers. If the process model or stored identity links hold a display name, a rename can orphan open work. Use the directory's stable identifier as the group key wherever possible, and decide in advance what happens to tasks whose candidate group no longer exists. They may stay unassigned until someone reroutes them, so assign an owner to that queue and confirm the behavior with your engineers.

Users who change teams create most of the operational questions. A task already assigned to a person normally stays with that person, so someone who moves to another team keeps that work unless a process step or an administrator reassigns it. Candidate tasks behave differently. Once the user leaves the group, those tasks should drop out of their list, but they may still appear if membership is cached or stored on an identity link. As an illustrative case, a claims officer moves from retail lending to a fraud team with several open tasks. Decide whether those tasks are reassigned by a script, returned to the candidate pool, or handed to a manager, and write that rule into the process design rather than leaving it to individual users.

Test this behavior before go-live, and do not limit testing to the happy path. A useful suite uses a fixed fixture directory and asserts the outcome of each case through the Java API and the REST task query. A direct group member should see a candidate task. A member of a nested subgroup should see it only if your design expands nesting. A renamed group should keep or lose access according to your key choice. A removed group should leave its open tasks in a defined state, and a user who changes teams should keep assigned work while losing candidate visibility. Run the suite on the Flowable version you will deploy, including 8.0.0 if that is your target, and on the identity implementation you chose, because group resolution details can differ between versions and implementations.

What drives the effort of Flowable SSO in your environment

This table lists the factors that most change the effort of connecting Flowable to your identity sources, with how each one raises effort and how to keep it down. Read it before scoping, because most of the cost comes from the number of identity sources, how groups map to tasks, and how many environments need their own identity setup. Effort is described qualitatively here, so ask for a fixed-scope quote based on your own counts.

Driver	Why it raises effort	How to keep it down
Number of identity sources and directories	Each directory needs its own identity service logic, attribute mapping, and test cases. Overlapping directories also need rules for which source wins when a user appears in both.	Connect one authoritative identity source. Where that is not possible, document a single precedence rule before build starts.
User and group volume	Large directories make the initial sync, paging, and caching design more involved, and they make the group lookups used for task assignment slower to test at realistic size.	Limit synced attributes to what Flowable needs, and test lookups against a representative extract rather than the full directory.
Nested group depth	Nested groups must be flattened or resolved recursively in the identity service. Each extra level adds logic to write and cases to verify, and mistakes show up as tasks landing with the wrong people.	Map Flowable to a flat set of role or team groups that the identity team maintains, and avoid resolving deep nesting inside the engine.
LDAP, cloud identity provider, or both	LDAP usually means a custom or reference identity service with bind, search, and attribute rules. A cloud identity provider adds token claims, OpenID Connect configuration, and a separate user lookup path. Using both doubles the identity logic to maintain.	Pick one path for user identity and one for API access where possible. Confirm which LDAP service implementation your version provides before assuming it fits your schema.
Process models that use candidate groups	Every candidate group or candidate user expression in a BPMN model must resolve to an identity that exists in the target directory. Many models with group-based assignments create many test paths and more places for naming mismatches.	Standardize group names across models, use a small set of candidate groups, and review assignments in each model during design.
REST clients and service accounts	Each API client needs an authentication method, scopes or roles, and least-privilege rules. Service accounts that run process actions need the same review as human users, and each new client adds security testing.	Group clients by function, reuse one service account per integration where the policy allows, and keep the client list in a register that the security team reviews.
Environments that need separate identity configuration	Development, test, staging, and production often point to different directories, client registrations, and redirect URLs. Each difference is another configuration set to build, secure, and keep in step.	Use a shared test directory with synthetic users for non-production environments, and keep environment differences limited to endpoints and secrets.
Audit and access review requirements	Auditors may ask who started, claimed, or completed a task and why a user had access. Producing that evidence requires logging identity events, linking them to process history, and building reports for periodic reviews.	Agree the evidence list before build, log identity decisions in one place, and confirm which reports Flowable's audit history supports in your version.

How Flowable SSO changes across deployment models

A single Flowable engine instance is the simplest case. It is usually embedded in one application or run as the REST application against one database, and every identity lookup from the custom IdmIdentityService implementation goes through one JVM and one connection path to the directory. Problems tend to show up as slow logins or failed lookups, which are easier to trace on a single host.

Connection pooling: One pool serves both the engine and the identity lookups. Size it against the database connection limit, and confirm the pool settings with the team that owns the database.
Directory failover: Most single-node setups have one directory endpoint. Confirm whether a standby directory exists and whether your identity service can switch to it without a restart.
OIDC issuer or LDAP endpoint: The endpoint must be reachable from the node's network segment. Test DNS resolution and firewall rules from the host itself, not from a workstation.
Secrets: Read credentials from environment variables or a restricted file on the host. Confirm file permissions, who holds the bind credential, and who rotates it.
Engine mode: Confirm whether you embed the engine or run the REST application, because that choice decides where identity configuration lives.

Before go-live, confirm with the platform team which supported database type the node uses and how the directory credential is rotated.

Securing Flowable identity, tokens and directory credentials

Connecting Flowable to a directory or identity provider creates a set of credentials and trust decisions that sit outside the process models themselves. The cards below cover the identity-specific controls we check first, from how the LDAP bind account or client secret is stored to how group claims decide who sees which tasks. REST API hardening across the wider surface is covered on the security hardening page.

Store the bind account and client secret

The LDAP bind account and any OAuth2 or OpenID Connect client secret give the engine standing access to your directory or identity provider. Keep them out of process archives, application.properties files in source control and container images, and inject them at runtime from your secrets manager. Confirm who can read them, how they rotate, and that rotation does not require a code change to the IdmIdentityService implementation.

Validate issuer, audience and signatures

Any REST call that carries a bearer token should be rejected unless the token's signature verifies against the trusted keys, the issuer matches your identity provider, and the audience names this Flowable deployment. Test each check with a token from a different issuer, a token meant for another API, and a token with an altered payload. Confirm that the key set is fetched from the provider's configured endpoint and cached with a sensible refresh behavior.

Scope service account roles to least privilege

Automated callers, such as integration services or scheduled jobs, usually need a narrow set of REST operations, not administrative rights over the engine. Map each service account to only the process definitions, task operations and history reads it needs, and keep a separate account for operators. Review these mappings whenever a new process is deployed, because the default Spring Security configuration may grant broader access than the integration requires.

Do not trust client-supplied identity values

User and group identifiers sent in request bodies, query strings or custom headers can be forged unless the server derives them from the validated token or the directory. Assignee, candidate user and candidate group values in task operations should come from the authenticated principal or from server-side lookups. Test by submitting a task completion as a user who is not a candidate and by sending a group name the caller does not belong to.

Limit which group claims grant task visibility

Many identity providers emit group claims that include application groups, mailing lists and administrative groups. If every claim becomes a candidate group, users may see tasks meant for other teams. Agree a filter that maps only designated claim values to Flowable candidate groups, and document the mapping. Review it with the process owners before go-live and after any directory reorganization.

Set session and token lifetimes deliberately

Token lifetime, refresh behavior and idle session timeout determine how long a stolen or abandoned credential remains useful against task lists and process data. Agree maximum lifetimes with your identity team, confirm how the Flowable REST layer and any front end handle expiry, and test that expired tokens are refused mid-task. Revocation timing matters too: a removed employee should lose task access within a window your security team has approved.

Audit identity and access changes

Two kinds of change need a trail: changes to users and groups in the directory that Flowable reads, and changes to Flowable's own identity data, such as memberships or the mapping rules above. Confirm which events your deployment records, where they are stored, who can read them, and how long they are retained. Ask your auditors which evidence they expect before you finalize the design, because the engine's history tables alone may not answer their questions.

Verifying Flowable SSO works and fails safely

A Flowable SSO integration is not finished when users can sign in. You need evidence that task visibility and process start rights are granted only to the right people and withdrawn when they should be. Build a short test set that covers five cases: a user in a directory group sees and can claim that group's tasks; a user removed from that group loses visibility; an expired token and a token issued for another audience are both rejected at the REST API; a directory outage produces a clear error instead of access; and a disabled account cannot start a process. For each test, name the identity service, the group-to-candidate mapping and the endpoint it exercises, so a failure points to one component.

Run the group tests against a copy of the production directory schema or a dedicated test directory that keeps the same group nesting, attribute names and membership rules. Synthetic users in a flat test directory can pass while real membership lookups fail, especially when groups are nested or membership is resolved through a second attribute. Ask your directory team to confirm which attribute carries group membership, whether nested groups are expanded, and how long a removal takes to reach the identity lookups or any cache the engine uses. The removal test should wait for the propagation window you confirmed, not an arbitrary pause.

For the token tests, use tokens issued by your identity provider rather than hand-built JWTs, and check both the REST layer and the engine path. Confirm that the resource server validates signature, issuer, expiry and audience, and that a correctly signed token with the wrong audience is refused. For the outage test, block access to the directory in the test environment and repeat the same calls. The expected result is an error that identifies an authentication or directory failure, with no task list, no claim and no process start. A fallback to cached identities or anonymous access is a failure, even if the request returns successfully. Confirm how your chosen identity service and your own code handle lookup errors, since Flowable's identity behavior depends on that implementation.

For the disabled account test, disable a test user in the directory, wait for the confirmed propagation window, and then attempt to start a process definition and to claim a task. Both attempts should be refused. Check whether the refused attempts appear in audit or engine history under your configuration. Also confirm how long an existing session or previously issued token keeps working after an account is disabled, and whether that period matches your access policy.

Record every result as evidence. Keep the test identifier, date, environment, tester, configuration or build version, expected outcome, actual outcome, and log excerpts or screenshots. Map each test to the access control it supports, so reviewers see that removals, expired tokens and disabled accounts were exercised, not only documented. Rerun the full set after any identity service change, Spring Security upgrade, Flowable version change or directory schema change. This evidence supports your access review, but an independent auditor decides whether it satisfies a given control.

What to monitor, back up and document after go-live

This table lists the operational checks, backups and records a team needs once Flowable identity integration is live. Each row names what to watch or maintain, and the last column shows where teams usually miss it. Treat it as a go-live checklist, because identity signals and identity configuration need named owners, and an engine database backup alone does not cover them.

Area	What to do	Where it usually goes wrong
Directory connection health	Alert on repeated bind or connection failures to LDAP or the identity provider, and on group lookups that return empty.	A directory outage can look like users with no groups, which empties task lists silently.
Failed logins and token validation errors	Log rejected tokens by reason (expired, wrong audience, bad signature, unknown issuer) and track failed logins per client.	Clock drift or a rotated signing key can cause spikes that look like attacks.
Task assignment errors	Track tasks with no candidate user or group, and assignments to accounts that no longer exist in the directory.	Users see empty task lists with no error raised in the process.
Process signals from /actuator/flowable	Use the endpoint to watch running process activity next to identity alerts. It does not report identity metrics, so confirm what your version exposes.	Teams assume process health also shows identity problems, and it does not.
Identity configuration and identity tables	Back up the identity service configuration, claim mapping files and identity tables with the engine database, using one restore point.	Restoring the engine database alone can leave identity settings that no longer match the data.
Bind credentials and client secrets	Rotate the LDAP bind account and OAuth2 client secrets through a written procedure, then test login and directory reads.	Rotation happens at the identity provider while the Flowable deployment keeps the old secret.
Group mapping tests after upgrades	Re-run group, candidate and claim mapping tests after each Flowable or Spring upgrade, including the Spring Boot 4 change in Flowable 8.0.0.	Changes to Spring Security or Jackson defaults can alter claim parsing without a visible error.
Identity model and group owners	Document the identity model, claim mapping rules and a named owner for each group, with a review date.	Groups outlive the people who approved them, and access is never reviewed.

Questions about Flowable SSO, cost and effort

How much effort does Flowable SSO integration take?

The effort depends mostly on how many identity sources you connect, how your groups are modeled, and how many access paths need protection. Flowable's identity management can be replaced by implementing the IdmIdentityService interface or overriding IdmIdentityServiceImpl, so the core work is building and testing that identity layer against your directory. Teams usually also need to secure the REST API, map groups to candidate users and tasks, and test each process that depends on those assignments. Ask any provider to break the estimate into directory integration, API security, group mapping, and test cycles, and to state which of those they assume you will supply.

What drives the cost of Flowable SSO and identity integration?

Cost follows the number of moving parts that must be understood and tested. The largest drivers are the identity provider or directory type, the complexity of your group structure, whether you need OAuth2 or OpenID Connect for the REST API, and how many processes depend on candidate groups. Costs that are one-time include design, the identity service build, and initial testing. Recurring costs include keeping the integration working through directory changes, Flowable upgrades, and new process releases. When requesting a quote, ask which costs are one-time, which are support or retainer work, and which depend on your environment or on decisions only your team can make.

Can our in-house team set up Flowable SSO without outside help?

Yes, a team with Java, Spring Security and directory experience can build this, since Flowable is open source under Apache 2.0 and documents the identity service extension point. The harder parts are usually not the code but the decisions and the verification: how groups map to candidate users and tasks, how token claims are validated, and how the integration behaves when directory data is incomplete or changes. Teams without recent experience in these areas often underestimate testing against realistic identities and the upgrade path. A useful check is whether your team can name who owns each group decision, write test cases for every role, and rerun them after each Flowable release.

What does the client need to provide before an SSO engagement starts?

Before work begins, the client usually provides read access to the directory or identity provider in a non-production environment, a set of sample users that cover each role, and current group lists with their membership rules. A test tenant or test directory is needed so changes can be verified without touching production users. You also need a named owner who can make decisions about group mappings, access exceptions, and naming. Ask your provider for a written list of required access, accounts, and approvals, including who signs off on the identity model before build starts. Missing access is one of the most common causes of delay, so confirm each item before the scope is agreed.

Can we use the LDAP reference identity service as is?

Treat the LDAP identity service as a reference implementation, not a finished production component. Flowable's documentation provides an LDAP identity service implementation as an example of how to replace the default identity handling, but your directory schema, bind method, group attributes, and paging or referral behavior will likely differ from the example. You should expect to adapt the connection settings, attribute mapping, and group resolution, then test with your own users. Confirm each of these points against the current Flowable documentation for your version and against your directory administrator's configuration before you rely on it.

Do SSO changes need retesting after a Flowable upgrade?

Yes. Any upgrade can change how identity services are wired, how security filters behave, and which libraries are on the classpath, so SSO should be retested after every Flowable upgrade and after related framework changes. The 8.0.0 release moved to Spring Framework 7 and Spring Boot 4, dropped backward compatibility for Spring Boot 3, and made Jackson 3 the default JSON library, which can affect token handling and REST serialization. Keep a regression set that covers login, token validation, group-based task visibility, and candidate assignment for each role, and run it in a test environment before each production change.

What should a fixed-scope quote for Flowable SSO list?

A fixed-scope quote should name the systems in scope, the identity provider and directory versions, and the exact integration points, such as the identity service, REST API security, and group mapping. It should list the deliverables, including design notes, configuration, code, test cases, and a handover document, plus the environments where work will happen. Assumptions about client-supplied access, sample data, and decision owners should be written out, along with the acceptance criteria and how changes are handled. Ask whether post-go-live support, upgrade testing, and directory changes are included or priced separately, since those are the costs that most often surprise buyers.

How DeployOpen scopes, builds and hands over Flowable SSO

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and Flowable SSO and identity integration follows the same method. The work is agreed as a fixed-scope engagement in writing, with ongoing support available as a retainer once the integration is live.

How we scope

Inventory which identity source feeds Flowable, such as an LDAP directory or an external identity provider, and who owns it.
Decide whether identity comes from a replaced IdmIdentityService implementation or an LDAP-based identity service, and record the reason.
Define which groups map to candidate users, candidate groups and task assignments for each process and case model in scope.

How we build

Configure the Flowable REST API security with Spring Security and OpenID Connect or OAuth2, matching your identity provider's token format.
Implement group-to-candidate mapping and test that tasks route to the correct users in each process and case model.
Test failure paths, including expired tokens, missing group claims, directory outages and users who change group membership mid-task.

How we hand over

Deliver the written configuration, mapping tables and sequence diagrams that show how each login becomes a Flowable identity.
Provide runbooks for rotating client secrets, adding groups and troubleshooting failed logins against your environment.
Walk your platform and security teams through the test results and the list of open items before the handover is closed.

How we support

Review identity changes, such as directory schema updates or new identity provider versions, before they reach production.
Retest the REST API authentication and task routing after Flowable, Spring or identity provider upgrades.
Confirm with your team which support scope, response expectations and review cadence apply under the retainer before work begins.

Flowable SSO and identity integration