--- title: Enable Enhanced RBAC on the Turbine Platform (On-Prem) slug: enable-enhanced-rbac-on-the-turbine-platform-on-prem docTags: createdAt: 2026-09-23T04:11:04.203Z --- Enable Enhanced RBAC on a Turbine Platform installed with the Turbine Platform Installer (TPI), version 26.4 or later. A Super Admin user (`isSuperAdmin` is `true`) turns the flags on. Account Admin users on the same account assign roles and groups. An Account Admin cannot change these flags. Product behavior after the switch is described in [Enhanced Role-Based Access Control (RBAC)](https://docs.swimlane.com/90kk-role-based-access-control-rbac). Cloud customers request the switch through Support. See [Move from Legacy RBAC to Enhanced RBAC](https://docs.swimlane.com/move-from-legacy-rbac-to-enhanced-rbac). This page is the on-premises self-serve procedure. ## Choose Your Path | **Goal** | **Where to go** | | -------------------------------------------------- | ------------------------------------------------------------- | | Run the first-time migration | [Run the First-Time Migration](docId:425J7-_Bk_kFvBUqMinUD) | | Roll back to legacy RBAC | [Roll Back to Legacy RBAC](docId:425J7-_Bk_kFvBUqMinUD) | | Turn Enhanced RBAC back on without a new migration | [Turn Enhanced RBAC Back On](docId:425J7-_Bk_kFvBUqMinUD) | | Re-migrate after legacy role changes | [Re-Migrate and Switch On Again](docId:425J7-_Bk_kFvBUqMinUD) | | See what each flag does | [Quick Flag Map](docId:425J7-_Bk_kFvBUqMinUD) | :::hint{type="info"} For a first-time switch, enable `EnhancedRbacDataMigration` only. Do not turn on `EnhancedRbac` yourself. After a successful migration, the platform turns `EnhancedRbac` on automatically. ::: :::hint{type="warning"} Do not enable `EnhancedRbacDataMigration` more than once without a pause. Wait until the migration job succeeds. Several enable attempts in a row can cause migration failures. ::: :::hint{type="warning"} Users with no permissions cannot log in after Enhanced RBAC is on. Before you start, confirm each user who must log in has a role. See [Who Can Log In After the Switch](docId:425J7-_Bk_kFvBUqMinUD). ::: Migration copies legacy roles, groups, and users into the Identity database (`TurbineIdentity`). It assigns Super Admin users to the seeded **Super Admin** role and Account Admin users to the seeded **Account Admin** role. ## Before Migration Take a [platform snapshot](https://docs.swimlane.com/turbine-installer/turbine-platform-installer-guide) before you start. ### Log In as Super Admin and Collect the Account ID ```shell curl -sS -X POST "https:///tenant/api/users/login" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -d '{"userName":"","password":""}' ``` From the response, copy `token`. Confirm `userAccountAccessModels.isSuperAdmin` is `true` and `userAccountAccessModels.isSwimlaneUser` is `true`. `userAccountAccessModels.accountId` is the Swimlane Account ID (`SWIMLANE_ACCOUNT_ID`). Use it in the requests below. ## Run the First-Time Migration Enable only `EnhancedRbacDataMigration`. The PUT publishes a feature-flag-enabled event. The `identity-rbac-migration` service copies legacy roles, groups, users, and permissions into the Identity database (`TurbineIdentity`). It also assigns Super Admin and Account Admin users to the seeded Identity roles. On success, it enables `EnhancedRbac` automatically. For what each flag does, see [Quick Flag Map](docId:425J7-_Bk_kFvBUqMinUD). ```shell curl -sS -X PUT \ "https:///tenant/api/feature-flag//EnhancedRbacDataMigration?enabled=true" \ -H "Authorization: Bearer " \ -H "Accept: application/json" ``` Watch the migration pod: ```shell export NS=default kubectl -n $NS logs -l app=identity-rbac-migration --tail=200 -f ``` Success looks like: - `RBAC Consumer received feature flag event: EnhancedRbacDataMigration for account: ` - `Starting RBAC migration` / `Successfully completed RBAC migration` - `Enabling the 'EnhancedRbac' feature flag on ` Failure looks like `RBAC migration failed` or `Starting cleanup process`. On failure, the migration process deletes partial Identity data for that account. `EnhancedRbac` must stay off. Do not retry until you have those logs. Confirm both account-level flags are `true`: ```shell curl -sS "https:///tenant/api/feature-flag/" \ -H "Authorization: Bearer " \ -H "Accept: application/json" ``` Then: 1. Log in again as Super Admin, so the **Super Admin** role is in the session. 2. Log in as a user with the **Account Admin** role. 3. Log in as a non-admin user. Access should match what those users had in legacy RBAC. Users with no role cannot log in. Users whose only role has no permissions, on an account that was already on Enhanced RBAC, cannot log in. See [Who Can Log In After the Switch](docId:425J7-_Bk_kFvBUqMinUD). ## Who Can Log In After the Switch Legacy RBAC and Enhanced RBAC treat users with no access differently. **Legacy RBAC.** A user with no role can still log in. They can change only their own user profile. They cannot use the rest of the product. **Enhanced RBAC.** A user with no permissions cannot log in. Permissions come from **roles**. A user can have a role assigned directly, or through a **group** that has the role. To log in, the user needs at least one account-level permission, from a role assigned to the user or to one of the user's groups. See [Enhanced Role-Based Access Control (RBAC)](https://docs.swimlane.com/90kk-role-based-access-control-rbac). **Account still on legacy RBAC.** A role with no permissions is enough to log in. Migration [recreates existing roles](https://docs.swimlane.com/move-from-legacy-rbac-to-enhanced-rbac) in Enhanced RBAC. It also adds the account-level read permissions that legacy granted silently, including **Users → Read** and **Groups → Read**. Those permissions are enough to log in after the switch. **Account already on Enhanced RBAC.** If no role grants at least one permission: 1. On the Roles page, select **Create Role**. 2. Grant at least one permission. A role with no permissions does not allow login. An account-level permission (for example **Users → Read**) is enough. You do not need to grant tenant permissions for the user to log in. ## Roll Back to Legacy RBAC Turn Enhanced RBAC off for the Swimlane Account (`SWIMLANE_ACCOUNT_ID`). :::hint{type="warning"} Disabling `EnhancedRbac` returns that account to the legacy RBAC role configuration from before migration. Changes made on the Enhanced RBAC **Roles** page are not copied back. Leave `EnhancedRbacDataMigration` on unless you plan to re-migrate later. ::: ### Disable Enhanced RBAC with the API Use this path when a Super Admin can still call the API. ```shell curl -sS -X PUT \ "https:///tenant/api/feature-flag//EnhancedRbac?enabled=false" \ -H "Authorization: Bearer " \ -H "Accept: application/json" ``` Confirm `EnhancedRbac` is `false`. Log in again and confirm the legacy RBAC Roles page. ### Disable Enhanced RBAC in the Database Use this path when the API is blocked and users are locked out. Use the same `$NS` as in [Run the First-Time Migration](docId:425J7-_Bk_kFvBUqMinUD). Update the account-level row in `SwimlaneTenant`. Do not update the global row (`"AccountId" IS NULL`). ```shell kubectl -n $NS exec -it postgresql-0 -- bash su postgres psql \c SwimlaneTenant ``` Inspect the flags. The Swimlane Account row has a null `"TenantId"` and the account ID in `"AccountId"`: ```sql SELECT "Id", "Name", "AccountId", "TenantId", "Enabled", "IsDisabled" FROM public."FeatureFlags" WHERE "Name" IN ('EnhancedRbac', 'EnhancedRbacDataMigration') ORDER BY "Name", "AccountId" NULLS FIRST; ``` Disable `EnhancedRbac` for `SWIMLANE_ACCOUNT_ID`. ```sql UPDATE public."FeatureFlags" SET "Enabled" = false, "ModifiedDateTime" = now(), "IsDisabled" = false WHERE "Name" = 'EnhancedRbac' AND "AccountId" = ''::uuid AND "TenantId" IS NULL; SELECT "Name", "AccountId", "Enabled" FROM public."FeatureFlags" WHERE "Name" = 'EnhancedRbac' AND "AccountId" = ''::uuid AND "TenantId" IS NULL; ``` A direct SQL update does not clear the in-memory flag cache. Wait up to **two minutes**, or restart the services that read the flag: ```shell kubectl -n $NS rollout restart deployment swimlane-tenant swimlane-api identity-api ``` Then confirm that users can log in and that the legacy RBAC Roles page is back. :::hint{type="info"} Do not enable `EnhancedRbacDataMigration` with SQL. That write does not publish the event, so migration will not start. ::: ## Re-Enable Enhanced RBAC The choice is the same as in [Move from Legacy RBAC to Enhanced RBAC](https://docs.swimlane.com/move-from-legacy-rbac-to-enhanced-rbac). Use `SWIMLANE_ACCOUNT_ID`. ### Turn Enhanced RBAC Back On Use this when you rolled back by turning `EnhancedRbac` off and you do not need to copy later legacy role changes into Enhanced RBAC. `EnhancedRbacDataMigration` should already be `true`. Enable only the runtime flag: ```shell curl -sS -X PUT \ "https:///tenant/api/feature-flag//EnhancedRbac?enabled=true" \ -H "Authorization: Bearer " \ -H "Accept: application/json" ``` :::hint{type="info"} This does not run migration again. Users get the Enhanced RBAC configuration that existed when Enhanced RBAC was switched off. Legacy RBAC role edits made while the account was on legacy RBAC are ignored. ::: ### Re-Migrate and Switch On Again Use this when legacy roles changed after rollback and you want Identity rebuilt from current legacy data. 1. If `EnhancedRbac` is still on, turn it off. Use [Disable Enhanced RBAC with the API](docId:425J7-_Bk_kFvBUqMinUD) or [Disable Enhanced RBAC in the Database](docId:425J7-_Bk_kFvBUqMinUD). 2. Stay on legacy RBAC during re-migration. 3. Turn `EnhancedRbacDataMigration` off. 4. Turn `EnhancedRbacDataMigration` on. Migration starts when the flag changes from false to true. ```shell curl -sS -X PUT \ "https:///tenant/api/feature-flag//EnhancedRbacDataMigration?enabled=false" \ -H "Authorization: Bearer " \ -H "Accept: application/json" curl -sS -X PUT \ "https:///tenant/api/feature-flag//EnhancedRbacDataMigration?enabled=true" \ -H "Authorization: Bearer " \ -H "Accept: application/json" ``` 5. Watch `identity-rbac-migration` logs the same way as for first-time enablement. On success, `EnhancedRbac` is turned on again. Re-migration updates roles by legacy ID and refreshes role permissions. A rare mismatch can appear when all of the following are true: - The account was migrated once. - The account was returned to legacy RBAC. - A role from the first migration was deleted. - A new role was created with the same name. If that happens, fix or recreate the affected role after migration. If re-migration fails, the migration process deletes Identity data for that account. `EnhancedRbac` must stay off. Fix the error, then repeat the off-to-on toggle of `EnhancedRbacDataMigration`. ## Quick Flag Map | **Flag** | **Scope** | **What It Does** | **How to Set** | | --------------------------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | `EnhancedRbacDataMigration` | Account (`SWIMLANE_ACCOUNT_ID`) | Starts or restarts Identity migration. Does not switch the UI or enforcement by itself. On the Swimlane Account, also assigns Super Admin and Account Admin users to the seeded Identity roles. | API PUT `enabled=true`. The flag must change from false to true. SQL does not start migration. | | `EnhancedRbac` | Account (`SWIMLANE_ACCOUNT_ID`) | Switches enforcement and the **Roles** page to Enhanced RBAC. The platform enables this flag after a successful migration. | First time: do not set this flag. Rollback: PUT or SQL `enabled=false`. Re-enable without a re-migration: PUT `enabled=true`. |