Configuring an IAM solution (Keycloak)

This guide walks through configuring a minimal Keycloak setup to efficiently manage users, roles, and apps. Keycloak is an open-source Identity and Access Management (IAM) solution that secures apps and services with little to no coding.

Prerequisites

Before you begin, ensure you have the following:

Keycloak installed
Administrative access to the Keycloak server
Basic understanding of IAM concepts

Recommended Keycloak version: 22.xNote for Keycloak 26+: If using Keycloak version 26 or above, additional email configuration is required in the realm settings to prevent bad request errors when creating users. See the realm configuration section for details.

Recommended Keycloak setup

To configure a minimal required Keycloak setup, this guide covers the following steps:

Create a new realm

Define available roles and realm-level roles assigned to new users.

Create new users

Add clients

Configure the client authentication, valid redirect URIs, and enable the necessary flows.

Add mappers

Add service accounts

Set up admin, task management, process engine, scheduler, integration designer, runtime manager, organization manager, email gateway, and license service accounts.

Before starting, if you need further information or a broader understanding of Keycloak, refer to the official Keycloak documentation:

Keycloak documentation

Creating a new realm

The guided setup flow via the Organization Manager creates both the user realm and the service accounts realm automatically. You only need to follow this section if you are configuring Keycloak manually, or if you need to customize realm settings beyond the defaults.

A realm is a space where you manage objects, including users, apps, roles, and groups. Creating a new realm is the first step in setting up Keycloak manually. Follow the steps below to create a new realm in Keycloak:

Create realm

In the top left corner dropdown menu, click Manage realms then click Create realm.

If you are logged in to the master realm, this dropdown menu lists all the realms created.

Enter realm details

Set the Realm name to your organization ID and click Create. This is the UUID provided by FlowX during organization registration — the same value you configure as the ORGANIZATION_ID parameter on the backend services. A friendly name such as the organization code can go in the Display name field under Realm settings → General.

The Realm name must be identical to the organization ID provided by FlowX. FlowX resolves the organization from the token issuer URI (<auth-server>/realms/<organization-id>), and the org_id token claim carries the same value. If the realm name differs from the organization ID, user tokens will not match any organization and authentication fails.

Configure realm settings

Tokens → Access Token Lifespan: Set to 30 Minutes (recommended).

Access token lifespan setting in realm configuration

Login → Email settings: Configure email authentication settings.

For Keycloak versions 26 and above: You must configure the email settings in the Login tab to avoid bad request errors when creating users in FlowX Designer. Make sure to enable Email as username and Login with email toggles as shown in the realm settings.

Verify your realm is created correctly: navigate to the realm selector dropdown in Keycloak and confirm your new realm appears in the list.

Creating new users

Creating new users is a fundamental part of managing access within Keycloak. Follow these steps to create a new user in a realm and generate a temporary password:

Navigate to users

In the left menu bar, click Users to open the user list page.

Add a new user

Click Create new user.Fill in the user details and set Email Verified to Yes.

Set temporary password

Save the user, go to the Credentials tab, and set a temporary password. Ensure the Temporary checkbox is checked.

Setting temporary password in Keycloak Credentials tab

Verify the user is created: navigate to Users and confirm the new user appears in the list with Email Verified set to Yes.

Password policy

FlowX.AI enforces the following password policy for all user accounts:

Rule	Requirement
Minimum length	8 characters
Maximum length	64 characters
Uppercase	At least one uppercase letter
Lowercase	At least one lowercase letter
Number	At least one digit
Special character	At least one of `!@#$%^&*()_+-`
Additional	Cannot match the user’s email address

Configure your Keycloak realm password policy to match these requirements. In Keycloak, go to Authentication → Policies → Password Policy and add the corresponding policy rules.

Adding clients

A client represents an application instance that is associated with a specific realm.

Adding an OAuth 2.0 client

Add a client named flowx-platform-authenticate, used for login, logout, and refresh token operations by web and mobile apps.

Navigate to Clients

Click Clients in the top left menu, then click Create client.

Keycloak Clients page with Create client button

Configure general settings

In the General Settings tab configure the following properties:

Set a client ID to {your-client-name}-authenticate.
Set the Client type to OpenID Connect.

Client general settings with Client ID and Client type

Configure capability config

Now click Next and configure the Capability config details:

Enable Direct Access Grants.
Enable Implicit Flow Enabled.

Capability config with Direct Access Grants and Implicit Flow enabled

Set valid redirect URIs

Click Next and configure Login settings:

Set Valid redirect URIs, specifying a valid URI pattern that a browser can redirect to after a successful login or logout, simple wildcards are allowed.

Self-hosted: The Organization Manager can populate Keycloak redirect URIs for you. If you leave FLOWX_DEFAULT_SECURITY_REALM_ALLOWEDREDIRECTURIS empty, the allowed list is derived from FLOWX_DEFAULT_DESIGNER_HOMEURI and FLOWX_DEFAULT_RUNTIME_HOMEURI with a /* suffix. See Organization Manager setup — Self-hosted URL configuration.

Configure additional settings

After creating the client, scroll down in the Settings tab and configure additional settings - Logout Settings:

Front Channel Logout: Toggle OFF.
Backchannel Logout Session Required: Toggle OFF.

Logout settings with Front Channel Logout and Backchannel toggled OFF

Add mappers

Add mappers to {your-client-name}-authenticate client.

For instructions on adding mappers and understanding which mappers to add to your clients, refer to the section on Adding Protocol Mappers.

Example configuration for microservices

FlowX services validate incoming tokens using JWT public key validation. The shared security library (application-security-client.yaml) handles most configuration automatically.

security:
  type: jwt-public-key                                # JWT public key validation
  oauth2:
    base-server-url: https://keycloak.example.com      # Base URL of the Keycloak server
    sa-realm: 00000002-0002-4002-8002-000000000002      # Service accounts realm name (fixed UUID convention) — must match the Realm name field in Keycloak

# Organization manager is a required dependency for all services
flowx:
  lib:
    security:
      services:
        organization-manager:
          base-url: http://organization-manager:80

Configuration Key	Value/Example	Description
`security.type`	`jwt-public-key`	Validates tokens using JWT public key (no introspection endpoint needed).
`security.oauth2.base-server-url`	`https://keycloak.example.com`	Base URL of the Keycloak server.
`security.oauth2.sa-realm`	`00000002-0002-4002-8002-000000000002`	Fixed-UUID name of the service accounts realm — must match the Realm name field in Keycloak (not the Display name).
`flowx.lib.security.services.organization-manager.base-url`	`http://organization-manager:80`	Organization manager URL (required dependency for all services).

Adding protocol mappers

Protocol mappers in Keycloak allow you to transform tokens and documents, enabling actions such as mapping user data into protocol claims and modifying requests between clients and the authentication server. This provides greater customization and control over the information contained in tokens and exchanged during authentication processes.

To enhance your clients’ functionality, add the following common mappers:

Group Membership mapper (realm-groups)
- Maps user groups to the authorization token.
User Attribute mapper (business filter mapper)
- Maps custom attributes, for example, mapping the businessFilters list, to the token claim.
User Realm role (realm-roles)
- Maps a user’s realm role to a token claim.

The mappers should be configured to be included in the token introspection response. Previously, mappers were primarily added to the /userinfo endpoint, but modern Keycloak versions support adding them to token introspection, which is the recommended approach for better security and performance.

By incorporating these mappers, you can further customize and enrich the information contained within your tokens, ensuring they carry the necessary data for your applications.

Group membership mapper

Steps to add a Group Membership mapper:

Navigate to Clients

From the Keycloak admin console, go to Clients and select your desired client.

Select Client Scopes

In the client settings, click on Client Scopes.Select the dedicated client scope: {your-client-name}-authenticate-dedicated to open its settings.

Select client scope

Make sure the Mappers tab is selected within the dedicated client scope.

Add a New Mapper

Click Add Mapper. From the list of available mappers, choose Group Membership.

Add Group Membership mapper from predefined list

Provide mapper details

Name: Enter a descriptive name for the mapper to easily identify its purpose, for example realm-groups.Token Claim Name: Set the token claim name, typically as groups, for including group information in the token.Add to ID Token: Toggle OFF.Add to token introspection: Toggle ON.

This group membership mapper includes the user’s group information in the token for authorization purposes.

User attribute mapper

To include custom attributes such as business filters in the token claim, follow these steps to add a user attribute mapper:

Navigate to Client Scopes

From the Keycloak admin console, go to Clients and select your desired client.Click on Client Scopes and choose {your-client-name}-authenticate-dedicated to open its settings.Ensure the Mappers tab is selected.

Client scopes Mappers tab for attribute mapper

Add a New Mapper

Click Add mapper. From the list of available mappers, select User Attribute.

Provide mapper details

Mapper Type: Select User Attribute.
Name: Enter a descriptive name for the mapper, such as “Business Filters Mapper”.
User Attribute: Enter businessFilter.
Token Claim Name: Enter attributes.businessFilters.
Add to access token: Toggle ON.
Add to token introspection: Toggle ON (recommended).
Multivalued: Toggle ON.
Aggregate attribute values: Toggle ON.

This user attribute mapper includes the custom attribute “businessFilters” in the token claim under the name “attributes.businessFilters”, making business filter information available within your app. For more information about business filters, refer to the following section:

Business filters

Runtime groups attribute mapper

The runtime authorization service reads each user’s FlowX end-user group memberships from the attributes.runtimeGroups claim on the access token, matching every value against the names of end-user groups defined in FlowX by exact string comparison.

No attributes.runtimeGroups mapper ships in the realm template. The flowx-platform-authenticate client ships with mappers for realm roles, business filters, and the designer-user flag, but none for runtime groups. Add one only when group membership is maintained outside FlowX — as native Keycloak groups, or in a federated identity provider. When an admin assigns users to end-user groups directly in the Designer, the membership is stored in FlowX and needs no token claim.

Migration-created default group renamed in 5.9.2. The end-user group that the 5.1.x upgrade migration creates for former FLOWX_ROLE holders is named Users Group as of 5.9.2 — on 5.9.0 and 5.9.1 it was created as User, and upgrading to 5.9.2 or later renames it. If a mapper or external IDP claim emits the old name User, the value no longer matches any group and affected users lose solution access on their next sign-in, with no error logged. Update the emitted group name to Users Group (or to the group’s current name, if you have renamed it since). Groups created by your own admins are not renamed.

There are two ways to populate the claim, depending on where you maintain membership. Use one for a given group source, not both.

From native Keycloak groups

Use this when your end users are organized into Keycloak groups in the FlowX realm (for example, users imported into the realm and managed there). A Group Membership mapper emits the user’s group names directly as attributes.runtimeGroups.

Navigate to Client Scopes

From the Keycloak admin console, go to Clients and select flowx-platform-authenticate. Click Client Scopes and choose flowx-platform-authenticate-dedicated. Open the Mappers tab.

Add a New Mapper

Click Add mapper. From the list of available mappers, select Group Membership.

Provide mapper details

Mapper Type: Select Group Membership.
Name: Enter a descriptive name, such as “Runtime Groups Mapper”.
Token Claim Name: Enter attributes.runtimeGroups.
Full group path: Toggle OFF. The claim then carries plain group names (for example someGroup) instead of paths (/someGroup), so they match FlowX end-user group names.
Add to ID token: Toggle OFF.
Add to access token: Toggle ON.
Add to token introspection: Toggle ON.

A Keycloak group name only grants access if an end-user group with the same name exists in FlowX. Names in the claim that don’t match a FlowX end-user group are ignored.

From a federated identity provider

Use this when an external IDP supplies group membership through federation. The external IDP federation mapper writes the source claim into the flowxIdPGroups user attribute; a User Attribute mapper then promotes that attribute onto the access token as attributes.runtimeGroups.

Navigate to Client Scopes

From the Keycloak admin console, go to Clients and select flowx-platform-authenticate. Click Client Scopes and choose flowx-platform-authenticate-dedicated. Open the Mappers tab.

Add a New Mapper

Click Add mapper. From the list of available mappers, select User Attribute.

Provide mapper details

Mapper Type: Select User Attribute.
Name: Enter a descriptive name, such as “Runtime Groups Mapper”.
User Attribute: Enter flowxIdPGroups.
Token Claim Name: Enter attributes.runtimeGroups.
Add to access token: Toggle ON.
Add to token introspection: Toggle ON (recommended).
Multivalued: Toggle ON.
Aggregate attribute values: Toggle ON.

The values that appear in attributes.runtimeGroups must match the names of end-user groups defined in FlowX. Federated logins populate flowxIdPGroups automatically through the external IDP federation mapper below.

User attribute schema must accept flowxIdPGroups. This attribute is FlowX-internal and is not part of the realm’s declared user profile. The realm’s unmanaged attributes policy under Realm settings → User profile must be set to Enabled (the Keycloak default), otherwise the IDP mapper silently drops the value and attributes.runtimeGroups arrives empty. The same applies to businessFilter and designerUser. If your security posture requires unmanaged attributes to be disabled, declare flowxIdPGroups, businessFilter, and designerUser explicitly in the user profile with admin-only edit permissions.

Data hygiene at the source. Group identifiers are matched against FlowX end-user group names by exact string comparison, so trailing whitespace, mixed casing, or stray punctuation in the source IDP’s user record will silently break authorization. The designerUser attribute is stored on the user record as the string "true" or "false"; the client mapper handles the conversion to a JSON boolean at token emission via the Claim JSON Type setting.

Designer user attribute

The designerUser user attribute is a boolean that flags whether a user has Designer access to the project. The flowx-platform-authenticate client exposes it on the access token as attributes.designerUser; the runtime authorization service reads the claim to skip role checks for designers running their own projects. In FlowX-managed Keycloak deployments the attribute is set automatically at organization provisioning, and the mapper ships with the standard client setup. Add the mapper manually only when you operate Keycloak yourself.

Navigate to Client Scopes

From the Keycloak admin console, go to Clients and select flowx-platform-authenticate. Click Client Scopes and choose flowx-platform-authenticate-dedicated. Open the Mappers tab.

Add a New Mapper

Click Add mapper. From the list of available mappers, select User Attribute.

Provide mapper details

Mapper Type: Select User Attribute.
Name: Enter a descriptive name, such as “Designer User Mapper”.
User Attribute: Enter designerUser.
Token Claim Name: Enter attributes.designerUser.
Add to access token: Toggle ON.
Add to token introspection: Toggle ON (recommended).
Multivalued: Toggle OFF.
Claim JSON Type: Select boolean.

External IDP federation mapper

This mapper reads the source IDP’s group claim and writes the value into the FlowX-side flowxIdPGroups user attribute. The Runtime groups attribute mapper above then promotes that user attribute onto the FlowX access token as attributes.runtimeGroups.

Open the federated IDP entry

From the Keycloak admin console, go to Identity providers and open the entry for the federated IDP. Click the Mappers tab.

Add a New Mapper

Click Add mapper. From the Mapper Type list, select Attribute Importer (Keycloak’s oidc-user-attribute-idp-mapper; some versions label it OpenID Connect Attribute to User Attribute).

Provide mapper details

Name: Enter a descriptive name, such as “Source groups to flowxIdPGroups”.
Sync Mode Override: Select Force so subsequent logins re-import the value and pick up source-side group changes.
Claim: Enter the name of the source IDP claim that carries the user’s group memberships. The exact name depends on the source IDP — for example, FlowX-to-FlowX federation typically uses groupsList; Entra ID typically uses the groups claim or a custom extension; AD FS uses whatever the source-side claim emitter is configured to send.
User Attribute: Enter flowxIdPGroups.

Same recipe for business filters. If the organization uses business filters, configure a second Attribute Importer mapper that reads the source IDP’s business-filter claim and writes it into the businessFilter user attribute. The User attribute mapper section above then exposes it on the token as attributes.businessFilters.

Source-side claim shaping. Most external IDPs do not emit a single multivalued claim that maps 1:1 to FlowX end-user group names. You typically need a chained mapper on the source IDP side, or on the federated IDP entry, to construct the multivalued array before this mapper imports it. See Source IDP claim emission below for the customer-side recipe.

Source IDP claim emission

The Attribute Importer mapper above reads a single claim from the source IDP’s token and writes it into flowxIdPGroups. The customer’s IDP is responsible for producing that claim. The contract is:

Claim name: customer-choice. The Attribute Importer’s Claim field absorbs the difference — pick whatever the source IDP already emits (groups, memberOf, roles, a vendor-specific path).
Claim type: multivalued string. Each value is a group identifier that must match an end-user group name in FlowX.
Token destinations: the source IDP must add the claim to the access token (Keycloak’s broker reads it from there). Adding it to the ID token and userinfo as well is harmless and recommended.

If the customer maintains group data across multiple user attributes — for example, some users have a groups array and others have a single-value role attribute — they can configure two protocol mappers on the source IDP, both targeting the same outgoing claim name with Aggregate attribute values toggled ON. Keycloak unions the values into one array before emitting the claim. The same trick works for business filters.

Verify the claim before configuring the importer. Decode a sample access token issued by the source IDP (the Evaluate tab on the source-side client is the quickest way) and confirm the group claim is present with the expected name and values. Trailing whitespace, accidental nesting, or single-value strings (instead of arrays) are the most common reasons the FlowX-side Attribute Importer appears to do nothing.

User realm role mapper

To add a roles mapper to the {your-client-name}-authenticate client, so roles will be available in the OAuth user info response, follow these steps:

Navigate to Client Scopes

Add a New Mapper

Click Add Mapper. From the list of available mappers, select User Realm Role.

User Realm Role mapper in predefined list

Provide mapper details

Name: Enter a descriptive name for the mapper, such as “Roles Mapper”.
Mapper Type: Select User Realm Role.
Token Claim Name: Enter roles.
Add to ID Token: Toggle OFF.
Add to access token: Toggle OFF.
Add to token introspection: Toggle ON.

This roles mapper includes the user’s assigned realm roles in the OAuth user info response under the claim name “roles”.

You can repeat these steps to add multiple roles mappers if you need to include multiple realm roles in the token claim.

Legacy realm roles. Realms created from older FlowX realm exports may contain role families such as ROLE_ADMIN_MANAGE_*, ROLE_TASK_MANAGER_*, or ROLE_CMS_*, sometimes already assigned to users. FlowX services assign no built-in meaning to these roles — Designer and platform access is governed by workspace and organization roles plus permissions (see the roles & permissions matrix). Realm roles are only evaluated where your own configuration references them, such as swimlane access rules or business filters. Realms provisioned by current FlowX versions no longer include these legacy roles.

Creating a basic client scope

To ensure consistent token configuration across all clients, you should create a default client scope named “basic” with predefined mappers.

Navigate to Client Scopes

From the Keycloak admin console, go to Client Scopes in the left menu.Click Create client scope.

Configure client scope settings

Name: Enter basic.
Type: Select Default.
Protocol: Select OpenID Connect.
Display on consent screen: Toggle OFF.
Include in token scope: Toggle ON.

Click Save.

Add predefined mappers

In the newly created basic client scope, navigate to the Mappers tab.Add the following predefined mappers:

sub mapper:
- Click Add mapper → From predefined mappers
- Select sub
- Click Add
auth_time mapper:
- Click Add mapper → From predefined mappers
- Select auth_time
- Click Add

Assign to All Clients

After creating the basic client scope, assign it to all your clients:

Navigate to Clients in the left menu
For each client (e.g., flowx-platform-authenticate and all service accounts):
- Open the client settings
- Go to the Client Scopes tab
- Click Add client scope
- Select basic from the list
- Choose Default as the assignment type
- Click Add

The basic client scope ensures that all clients have consistent token claims for subject identification (sub) and authentication time (auth_time), which are essential for proper token validation and session management.

Examples

To request a login token:

curl --location --request POST 'http://localhost:8080/realms/flowx/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'username=admin@flowx.ai' \
--data-urlencode 'password=password' \
--data-urlencode 'client_id={your-client-name}-authenticate'

Refresh token

To refresh an existing token:

curl --location --request POST 'http://localhost:8080/realms/flowx/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=refresh_token' \
--data-urlencode 'client_id={your-client-name}-authenticate' \
--data-urlencode 'refresh_token=ACCESS_TOKEN'

User info

To retrieve user information:

curl --location --request GET 'localhost:8080/realms/flowx/protocol/openid-connect/userinfo' \
--header 'Authorization: Bearer ACCESS_TOKEN' \

Adding service accounts

What is a service account?A service account grants direct access to the Keycloak API for a specific component. Each client can have a built-in service account that allows it to obtain an access token.To use this feature you must turn on Client authentication (access type) for your client. When you do this, the Service Accounts Enabled switch will appear.

Realm architecture

FlowX uses three Keycloak realms that separate Keycloak administration, user authentication, and service-to-service communication:

Realm	Name	Purpose	Which services touch it
Master realm	`master` (Keycloak built-in)	Keycloak’s built-in administration realm. FlowX uses admin credentials here briefly during initial provisioning to create the realms below; the master realm itself is not used as a FlowX-managed realm at runtime.	`authorization-system` (and `data-sync` during the runtime-authorization migration) — only when `SECURITY_KEYCLOAKADMINENABLED=true`. No other service ever touches it.
User realm	The organization ID — the UUID provided by FlowX during organization registration (e.g., `00000001-0001-4001-8001-000000000001` for the default organization)	Main FlowX realm where end users live: users, roles, groups, and the `flowx-platform-authenticate` client.	Frontend apps and end-user authentication flows. Backend services also reach this realm to fetch the public JWKS keys used to validate inbound tokens issued by it. Almost every service is configured with its URL.
Service accounts realm	`00000002-0002-4002-8002-000000000002` (fixed)	Holds the backend service-account clients (e.g., `flowx-admin-sa`, `flowx-process-engine-sa`). Managed and isolated from the user realm.	Every backend service — they obtain access tokens here via `security.oauth2.sa-realm`.

This separation improves security isolation — service accounts cannot access user tokens, user realm changes do not affect service-to-service authentication, and the master realm stays restricted to administrative use. Where to create each client:

User-facing clients (flowx-platform-authenticate) go in the user realm
All service account clients (flowx-*-sa) go in the service accounts realm
No FlowX clients are created in the master realm — it only holds Keycloak’s built-in admin-cli

Both realms are created automatically by the guided setup flow on fresh installations, and by Liquibase migrations on upgrades — the existing user realm is renamed to the organization ID and the service accounts are moved out into the new SA realm. For the full upgrade flow, see the Authentication & IAM migration guide.If your deployment does not grant Keycloak admin credentials to FlowX services, you must create the service accounts realm and move the service account clients manually. See Manual Keycloak configuration below.

Authorization system master realm configuration By default, the authorization-system service accesses the Keycloak master realm to manage realms and run migrations. This is controlled by SECURITY_KEYCLOAKADMINENABLED (default true). Configure the following properties on the authorization-system service only:

Environment Variable	Description	Default Value
`SECURITY_KEYCLOAKADMINENABLED`	Whether FlowX has Keycloak admin access and manages realms. Set to `false` to skip FlowX-managed realm administration; the `SECURITY_MASTERREALM_*` variables are then not required.	`true`
`SECURITY_MASTERREALM_ADMIN_CLIENTID`	Master realm admin client ID	`admin-cli`
`SECURITY_MASTERREALM_NAME`	Master realm name	`master`
`SECURITY_MASTERREALM_ADMIN_USERNAME`	Keycloak admin username	-
`SECURITY_MASTERREALM_ADMIN_PASSWORD`	Keycloak admin password	-

The admin user supplied here must hold the Admin role on the master realm with permission to create realms — at first boot, the authorization-system service creates the user realm and the service-accounts realm, along with the clients, users, and service accounts within them.

These credentials grant full Keycloak administrative access. Store them securely using your secrets management solution (e.g., Vault, Kubernetes secrets). Never commit them to version control.

Admin service account

The admin service account is used by the admin microservice to connect with Keycloak, enabling user and group management features within the FlowX.AI Designer. Steps to add an Admin service account:

Create the Client

Navigate to Clients and select Create client.Enter a Client ID for your new client.

Configure capability config

Enable Client authentication (access type).
Disable Standard flow.
Disable Direct access grants.
Enable Service accounts roles.

Service account capability config with Client authentication and Service accounts roles enabled

Configure additional settings

After creating the client, scroll down in the Settings tab and configure additional settings - Logout Settings:

Backchannel Logout Session Required: Toggle OFF.
Front Channel Logout: Toggle OFF.

Logout settings toggled OFF for service account

Configure service account roles

In the newly created client, navigate to the Service accounts roles tab.

Important: The admin service account no longer requires client roles from realm-management. If you have existing roles assigned, remove them to follow the updated security model.

The admin service account is now configured to work without specific client roles. Authentication and authorization will be managed through the service account token itself.

The admin service account does not require mappers or specific client roles. Authentication is handled through the service account token itself.

Task Management service account

The task management service account facilitates process initiation and enables the use of the task management plugin (requiring the FLOWX_ROLE and role mapper).

Starting with 5.9.0, the Task Management plugin no longer reads user data from Keycloak; task operations resolve users through FlowX runtime authorization. The service account no longer needs any realm-management client roles.

Steps to Add a Task Management service account:

Create the Service Account

Follow steps 1-3 as in the Admin Service account configuration: Admin service account.

Add a realm roles mapper

In the newly created task management plugin service account, select Client Scopes:Click on {your-client-name}-service-account to open its settings.

Ensure the Mappers tab is selected within the dedicated client scope.

Click Add mapper. From the list of available mappers, select User Realm Role.

Adding User Realm Role mapper to task management SA

Configure the mapper

Name: Enter a descriptive name for the mapper to easily identify its purpose, for example realm-roles.Token Claim Name: Set it to roles.Disable Add to ID token.

Realm roles mapper configuration for task management SA

Click Save.

Add the service account realm role

Assign the FLOWX_ROLE service account realm role (used to grant permissions for starting processes).

The FLOWX_ROLE realm role is used to grant permissions for starting processes in the FlowX.AI Designer platform.

Process engine service account

The process engine requires a service account for service-to-service authentication and authorization.

This service account is also needed to be able to use Start Catch Event node.

Create the Client

Follow steps 1-3 as in the Admin Service Account Configuration: Admin service account.

Configure service account roles

In the newly created client, navigate to the Service accounts roles tab.The process engine service account does not require client roles from realm-management. Authentication and authorization are managed through the service account token and the SA_FLOWX realm role.

Add a realm roles mapper

In the newly created process engine service account, select Client Scopes.Click on {your-client-name}-service-account to open its settings.Ensure the Mappers tab is selected within the dedicated client scope.Click Add mapper. From the list of available mappers, select User Realm Role.Configure the mapper:

Name: Enter realm-roles
Token Claim Name: Set it to roles
Add to ID token: Toggle OFF
Add to token introspection: Toggle ON

Adding realm roles mapper to process engine SA

Scheduler service account

This service account is used for Start Timer Event node. The registered timers in the scheduler require sending a process start message to Kafka. Authentication is also necessary for this operation.

The configuration is similar to the process engine service account:

Create the Client

Follow steps 1-3 as in the Admin Service Account Configuration: Admin service account.

Configure service account roles

In the newly created client, navigate to the Service accounts roles tab.The scheduler service account does not require client roles from realm-management. Authentication and authorization are managed through the service account token and the SA_FLOWX realm role.

Add a realm roles mapper

Add a realm-roles mapper (as shown in the example for process-engine service account):In the scheduler service account, select Client Scopes.Click on {your-client-name}-service-account to open its settings.Ensure the Mappers tab is selected within the dedicated client scope.Click Add mapper. From the list of available mappers, select User Realm Role.Configure the mapper:

Name: Enter realm-roles
Token Claim Name: Set it to roles
Add to ID token: Toggle OFF
Add to token introspection: Toggle ON

Integration Designer service account

The Integration Designer service account is used by the integration designer microservice to interact securely with Keycloak, enabling it to manage various integrations within the FlowX.AI platform. Steps to set up an Integration Designer service account:

Create the Client

In Keycloak, navigate to Clients and select Create client.
Enter a Client ID for your new client (e.g., flowx-integration-designer-sa).

Configure client capabilities

Enable Client authentication under access type.
Enable Service accounts roles to allow the account to manage integrations.

Integration Designer SA capability config

Save the Client Configuration

Skip the Login settings page.
Click Save to apply the configuration.

Assign service account client roles

In the newly created client, navigate to the Service accounts roles tab.Click Assign role and in the Filter field, select Filter by clients.Assign only the view-users role from realm-management:

Remove any other roles if they are assigned. The integration designer service account should only have the view-users client role.

Authorization System service account

The Authorization System service account is used for managing user authentication and authorization operations, including user management, realm configuration, and access control within the FlowX.AI platform. Steps to set up an Authorization System service account:

Create the Client

Navigate to Clients and select Create client.Enter a Client ID for your new client (e.g., flowx-authorization-system-sa).

Configure capability config

Enable Client authentication (access type).
Disable Standard flow.
Disable Direct access grants.
Enable Service accounts roles.

Configure additional settings

After creating the client, scroll down in the Settings tab and configure additional settings - Logout Settings:

Backchannel Logout Session Required: Toggle OFF.
Front Channel Logout: Toggle OFF.

Assign service account client roles

In the newly created client, navigate to the Service accounts roles tab.Click Assign role and in the Filter field, select Filter by clients.Assign the following service account client roles from realm-management:

view-users
query-users
manage-users
manage-realm

These roles are essential for the Authorization System service account to perform user and realm management operations within Keycloak.

Runtime manager service account

The runtime manager service account is used by both Application Manager and Runtime Manager services to connect with Keycloak and perform export/import operations for builds, application versions, or other resource-specific tasks. Steps to add a Runtime manager service account:

Create the Client

Navigate to Clients and select Create client.Enter a Client ID for your new client.

Configure capability config

Enable Client authentication (access type).
Disable Standard flow.
Disable Direct access grants.
Enable Service accounts roles.

Configure additional settings

After creating the client, scroll down in the Settings tab and configure additional settings - Logout Settings:

Backchannel Logout Session Required: Toggle OFF.
Front Channel Logout: Toggle OFF.

Configure service account roles

In the newly created client, navigate to the Service accounts roles tab.

Important: The runtime manager service account no longer requires specific realm roles. If you have existing roles assigned (such as ROLE_TASK_MANAGER_HOOKS_ADMIN, ROLE_ADMIN_MANAGE_PROCESS_ADMIN, etc.), remove them to follow the updated security model.

The runtime manager service account is now configured to work without specific realm roles. Authentication and authorization for export/import operations will be managed through the service account token itself.

Organization manager service account

The organization manager service account is used by the organization manager microservice to handle organization and workspace management within the FlowX.AI platform.

Create the Client

Follow steps 1-3 as in the Admin Service Account Configuration: Admin service account.Enter a Client ID of flowx-organization-manager-sa.

Configure service account roles

In the newly created client, navigate to the Service accounts roles tab.The organization manager service account does not require specific client roles from realm-management. Authentication and authorization are managed through the service account token and the SA_FLOWX realm role.

Email gateway service account

The email gateway service account is used by the email gateway microservice to manage email sending and receiving operations within the FlowX.AI platform.

Create the Client

Follow steps 1-3 as in the Admin Service Account Configuration: Admin service account.Enter a Client ID of flowx-email-gateway-sa.

The email gateway service account does not require client roles from realm-management. Authentication and authorization are managed through the service account token and the SA_FLOWX realm role.

License service account

The license service account is used by the license microservice to manage license validation and enforcement within the FlowX.AI platform.

Create the Client

Follow steps 1-3 as in the Admin Service Account Configuration: Admin service account.Enter a Client ID of flowx-license-sa.

The license service account does not require client roles from realm-management. Authentication and authorization are managed through the service account token and the SA_FLOWX realm role.

Configuring SA_FLOWX realm role

The SA_FLOWX role is a realm-level role that should be assigned to all service accounts to ensure proper authentication and authorization across the FlowX.AI platform.

Create the SA_FLOWX role in the service accounts realm (00000002-0002-4002-8002-000000000002), since that is where all service account clients reside.

Create the SA_FLOWX Realm Role

In the Keycloak admin console, navigate to the service accounts realm (00000002-0002-4002-8002-000000000002).
Go to Realm roles in the left menu.
Click Create role.
Enter SA_FLOWX as the Role name.
Add a description: “Service account role for FlowX.AI platform services”.
Click Save.

Assign SA_FLOWX to service accounts

For each service account listed below, assign the SA_FLOWX realm role:

flowx-process-engine-sa
flowx-admin-sa
flowx-runtime-manager-sa
flowx-integration-designer-sa
flowx-scheduler-core-sa
flowx-authorization-system-sa
flowx-task-management-plugin-sa
flowx-organization-manager-sa
flowx-email-gateway-sa
flowx-license-sa
flowx-webhook-gateway-sa
flowx-file-gateway-sa
flowx-ai-gateway-sa

To assign the role to each service account:

Navigate to Clients and select the service account client.
Go to the Service accounts roles tab.
Click Assign role.
In the Filter field, select Filter by realm roles.
Find and select SA_FLOWX from the list.
Click Assign.

Assigning SA_FLOWX realm role to a service account

Verify role assignment

After assigning the role to all service accounts, verify that each service account has the SA_FLOWX role listed in its Service accounts roles tab.

The SA_FLOWX role ensures consistent authentication and authorization behavior across all FlowX.AI platform services. Make sure all service accounts have this role assigned for proper system operation.

Email (SMTP) configuration

Required for self-hosted deploymentsOn self-hosted deployments, SMTP must be configured by the client directly in Keycloak. This is required for password reset flows and user invitation emails sent from FlowX Designer.

To configure email delivery:

Navigate to email settings

In Keycloak, go to your organization realm, then Realm settings → Email.

Configure SMTP connection details

Fill in your SMTP server details:

Field	Description
Host	SMTP server hostname (e.g., `smtp.example.com`)
Port	SMTP port (typically `587` for TLS or `465` for SSL)
From	Sender email address (e.g., `noreply@example.com`)
Enable SSL / Enable StartTLS	Toggle ON based on your mail server requirements
Authentication	Toggle ON if your SMTP server requires credentials
Username / Password	SMTP authentication credentials

Test the connection

Use the Test connection button in Keycloak to verify emails can be sent.

Without SMTP configured, the following features will not work:

Password reset — users cannot reset their passwords via email
User invitations — inviting new users from FlowX Designer will fail

Manual Keycloak configuration

If FlowX services do not have Keycloak admin access, perform the following steps manually in the Keycloak Admin Console:

The user realm’s Realm name must be identical to your organization ID — the UUID provided by FlowX during organization registration (the same value set as ORGANIZATION_ID on the backend services). Only the Display name is free-form (e.g., the organization code). See Creating a new realm.

Create the service accounts realm

Log in to the Keycloak Admin Console.
Click Create realm.
Set the Realm name to 00000002-0002-4002-8002-000000000002.
Set the Display name to Flowx Administration Realm.
Click Create.

Configure the realm settings:

Login tab: Enable Email as username and Login with email
Authentication → Policies → Password Policy: Add uppercase, digit, special character, and minimum length (8) rules

Move service account clients to the SA realm

For each service account client listed in Adding service accounts, create the client in the service accounts realm (not the user realm):

Service accounts realm clients list with flowx-*-sa clients

In the SA realm, go to Clients → Create client.
Enter the Client ID (e.g., flowx-admin-sa).
Enable Client authentication and Service accounts roles. Disable Standard flow and Direct access grants.
Configure Logout Settings: Toggle OFF both Backchannel Logout and Front Channel Logout.
Assign the SA_FLOWX realm role (create it first in the SA realm if it does not exist).

Create the anonymous service account

The flowx-anonymous-sa client is used by FlowX backend services for inter-service calls on anonymous (unauthenticated) runtime flows (see the full list of consuming services in the v5.9 deployment guidelines). It is intentionally scoped to a separate, lower-privilege realm role so a leaked token cannot exercise authenticated paths.

In the SA realm, create a new realm role named SA_FLOWX_ANONYMOUS. Do not reuse SA_FLOWX.
Go to Clients → Create client.
Enter the Client ID flowx-anonymous-sa.
Enable Client authentication and Service accounts roles. Disable Standard flow and Direct access grants.
Configure Logout Settings: Toggle OFF both Backchannel Logout and Front Channel Logout.
Assign only the SA_FLOWX_ANONYMOUS realm role to this client’s service account. Do not assign SA_FLOWX.

Do not assign SA_FLOWX to flowx-anonymous-sa. The whole point of this client is to keep the anonymous-flow blast radius narrow — if the token leaks, the attacker can only invoke paths reachable to an anonymous internet visitor on processes or UI flows that explicitly opted into the Anonymous runtime role. Granting SA_FLOWX removes that boundary.

After creating the client, take the generated client secret and configure it on every consuming service via SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_ANONYMOUSIDENTITY_CLIENTSECRET. The same secret must be set on all of them. See Anonymous service account: shared client secret in the v5.9 deployment guidelines for the full list of services and the matching Liquibase parameter.

Configure the org_id protocol mapper

In the user realm, ensure the flowx-platform-authenticate client has a protocol mapper that adds the org_id claim to access tokens:

Go to Clients → flowx-platform-authenticate → Client scopes → dedicated scope.
Add mapper → By configuration → Hardcoded claim.
Set Name to org_id, Token Claim Name to org_id, Claim value to the organization ID provided by FlowX (which is also the user realm name), and Claim JSON Type to String.
Enable Add to access token and Add to token introspection.

Remove service accounts from user realm

After creating the service account clients in the SA realm, delete the old service account clients from the user realm. Keep only user-facing clients (flowx-platform-authenticate) in the user realm.

If you skip manual configuration, service-to-service authentication will fail. All FlowX backend services expect service accounts to exist in the realm identified by security.oauth2.sa-realm (00000002-0002-4002-8002-000000000002).

Troubleshooting

Bad request error when creating users in FlowX Designer

Keycloak 26+ only: You must configure email settings in the Login tab of realm settings. Toggle ON both Email as username and Login with email. Without this configuration, user creation requests from FlowX Designer fail with a bad request error.

Realm name conflict

Ensure the realm name is unique within your Keycloak instance. Duplicate realm names cause creation failures.

Service account authentication fails

Verify the following:

The service account client has Client authentication enabled and Service accounts roles toggled ON.
The SA_FLOWX realm role is assigned to the service account.
The client secret in your deployment matches the secret in Keycloak (Clients → select client → Credentials tab).
security.oauth2.sa-realm is set to 00000002-0002-4002-8002-000000000002 and the service account client exists in the SA realm (not the user realm).

Token missing groups, roles, or business filters

Check that the required protocol mappers are configured on the correct client scope:

Group Membership mapper with Add to token introspection toggled ON.
User Realm Role mapper with Add to token introspection toggled ON.
User Attribute mapper for business filters with Multivalued and Aggregate attribute values toggled ON.
The org_id protocol mapper is configured on the flowx-platform-authenticate client in the user realm.

JWT validation fails

Verify security.type is set to jwt-public-key.
Ensure security.oauth2.sa-realm is set to 00000002-0002-4002-8002-000000000002.
Verify that flowx.lib.security.services.organization-manager.base-url is set and the organization-manager service is reachable.

Summary

By following these steps, you have a minimal Keycloak setup to manage users, roles, and apps efficiently. Your Keycloak setup should include:

A user realm (named with the organization ID provided by FlowX) containing the flowx-platform-authenticate client, protocol mappers, users, roles, and groups
A service accounts realm (00000002-0002-4002-8002-000000000002) containing all flowx-*-sa service account clients with the SA_FLOWX realm role
SMTP configured in the user realm for password reset and user invitations (required for self-hosted deployments)
JWT public key validation (security.type: jwt-public-key) on all services
Master realm credentials configured on the authorization-system service

For more detailed configurations and advanced features, refer to the official Keycloak documentation.

Access Management overview

User roles, groups, and access control

Business filters

Data-level access control using business filters

Keycloak documentation

Official Keycloak documentation

​Prerequisites

​Recommended Keycloak setup

Keycloak documentation

​Creating a new realm

​Creating new users

​Password policy

​Adding clients

​Adding an OAuth 2.0 client

​Example configuration for microservices

​Adding protocol mappers

​Group membership mapper

​User attribute mapper

Business filters

​Runtime groups attribute mapper

​From native Keycloak groups

​From a federated identity provider

​Designer user attribute

​External IDP federation mapper

​Source IDP claim emission

​User realm role mapper

​Creating a basic client scope

​Examples

​Login

​Refresh token

​User info

​Adding service accounts

​Realm architecture

​Admin service account

​Task Management service account

​Process engine service account

​Scheduler service account

​Integration Designer service account

​Authorization System service account

​Runtime manager service account

​Organization manager service account

​Email gateway service account

​License service account

​Configuring SA_FLOWX realm role

​Email (SMTP) configuration

​Manual Keycloak configuration

​Troubleshooting

​Summary

​Related resources

Access Management overview

Business filters

Keycloak documentation

Prerequisites

Recommended Keycloak setup

Creating a new realm

Creating new users

Password policy

Adding clients

Adding an OAuth 2.0 client

Example configuration for microservices

Adding protocol mappers

Group membership mapper

User attribute mapper

Runtime groups attribute mapper

From native Keycloak groups

From a federated identity provider

Designer user attribute

External IDP federation mapper

Source IDP claim emission

User realm role mapper

Creating a basic client scope

Examples

Login

Refresh token

User info

Adding service accounts

Realm architecture

Admin service account

Task Management service account

Process engine service account

Scheduler service account

Integration Designer service account

Authorization System service account

Runtime manager service account

Organization manager service account

Email gateway service account

License service account

Configuring SA_FLOWX realm role

Email (SMTP) configuration

Manual Keycloak configuration

Troubleshooting

Summary

Related resources