Enhanced Role-Based Access Control (RBAC)

what is rbac? role based access control (rbac) is a security model used to control access to systems and resources based on a user's role within an organization instead of assigning permissions directly to individual users, permissions are grouped into roles users are then assigned one or more roles, which determine what actions they can perform and which resources they can access rbac simplifies access management by allowing administrators to define permissions once and apply them to many users through roles this approach improves security, reduces administrative overhead, and helps organizations enforce consistent access policies rbac in swimlane turbine swimlane turbine uses rbac to manage user access across the platform administrators configure roles and permissions to control what users can view and manage within the system each role contains a set of permissions that define which actions can be performed on specific resources only users with admin panel access can configure roles and permissions users without this access cannot manage rbac settings roles can then be assigned to users or groups, allowing administrators to manage access consistently across teams and environments rbac in turbine helps organizations control access to platform features and resources manage permissions across accounts and tenants align user access with operational responsibilities maintain consistent security policies across teams administrators manage rbac from the admin panel , primarily through the roles page after changing a role or permission, allow up to two minutes for the changes to take effect if a user still cannot access the expected resources, ask them to log out and log back in how rbac works in swimlane turbine turbine's access model is built on four interconnected layers layer description users individual accounts that log in and perform actions in turbine groups collections of users that share roles and record restrictions roles named sets of permissions assigned to users or groups permissions access rules that define which actions a role can perform access to a resource is granted when the following conditions are met a user belongs to a group or has a role assigned directly the group or user is linked to a role the role contains the required permission this layered model allows administrators to manage access efficiently while ensuring users only interact with resources they are authorized to use users users represent individual accounts that log in and perform actions in swimlane turbine users are managed under admin panel → users certain user properties affect access within the rbac system as per the following property description account admin grants full administrative access to the platform tenant association a user must be associated with at least one tenant and role to access tenant resources external users external swimlane users follow the same rbac rules as internal users groups groups allow administrators to manage access for multiple users at once by assigning roles to a group instead of individual users groups are managed under admin panel → groups group concepts concept description primary group a user can belong to multiple groups, but one group is designated as the primary group nested groups groups can be organized in a parent child hierarchy to reflect organizational structure roles the roles page is the central location for defining roles, assigning permissions, and managing role assignments navigate to admin panel → roles the page lists all roles configured for the account and provides options to create, edit, duplicate, and delete roles roles list the roles list displays all roles available in the account roles page fields field description name the role name selecting the name opens the role editor description a short description of the role tenants a summary of the tenants this role can access available role actions administrators can perform the following actions from the roles page action description create role create a new role and define permissions edit role modify an existing role’s details or permissions copy role duplicate an existing role to reuse its configuration delete role remove a role from the account role details selecting a role opens the role editor , where administrators configure the role definition and permissions the editor includes two tabs general permissions general tab the general tab contains basic information about the role and allows administrators to assign users or groups field description name the name of the role description optional description explaining the purpose of the role users users assigned directly to the role groups groups assigned to the role members of these groups inherit the role automatically permissions tab the permissions tab defines the access granted by the role permissions are organised into two sections account level permissions tenant level permissions account level permissions account level permissions control access to administrative resources across the entire account permission group description usage dashboards access usage dashboards such as actions, hero ai, and playbook runs tenants manage tenants within the account users manage user accounts roles create and manage rbac roles groups manage user groups account audit logs view account audit logs account level permission matrix these permissions control administrative capabilities across the entire turbine account resource create read update delete export import usage — ✓ — — — — tenants ✓ ✓ ✓ ✓ ✓ ✓ users ✓ ✓ ✓ ✓ — — roles ✓ ✓ ✓ ✓ — — groups ✓ ✓ ✓ ✓ — — account audit logs — ✓ — — — — account settings ✓ ✓ ✓ — — — admin panel — ✓ — — — — configuration manager ✓ ✓ ✓ ✓ — — content ✓ ✓ ✓ ✓ — — distribution portal ✓ ✓ ✓ ✓ — — access to the library menu is controlled by the content permission at the account level the library menu is not governed by tenant level permissions although content may be associated with specific tenants, all published content is available across the account and cannot be restricted per tenant to grant access to the library, ensure the role includes content permissions under account level permissions tenant level permissions the tenant level permissions section defines permissions within selected tenants administrators can select one or more tenants and configure access for resources within those tenants tenant resource permissions tenant level permissions control access to operational resources resource description applets manage applets within the tenant application records manage records stored in tenant applications applications create and manage applications in the tenant assets manage assets used in playbooks and applications components manage reusable components configuration manager manage configuration resources connectors manage integrations with external systems dashboards manage dashboards within the tenant tenant level permission matrix tenant access permissions control resources within a specific tenant environment permissions are configured per tenant , meaning a single role can have different permissions across multiple tenants administrators must define permissions individually for each tenant assigned to the role to simplify configuration, global permissions can be copied from one tenant to others within the same role however, resource level permissions are not shared across tenants , as resources (such as applications and assets) may differ between tenants resource create read update delete applets ✓ ✓ ✓ ✓ application records ✓ ✓ ✓ ✓ applications ✓ ✓ ✓ ✓ assets ✓ ✓ ✓ ✓ connectors ✓ ✓ ✓ ✓ dashboards ✓ ✓ ✓ ✓ events ✓ ✓ ✓ ✓ home page ✓ ✓ ✓ ✓ playbook alerts ✓ ✓ ✓ ✓ playbook and components ✓ ✓ ✓ ✓ pools ✓ ✓ ✓ ✓ remote agents ✓ ✓ ✓ ✓ reports ✓ ✓ ✓ ✓ tenant audit logs ✓ ✓ ✓ ✓ tenant settings ✓ ✓ ✓ ✓ webhooks ✓ ✓ ✓ ✓ webspaces ✓ ✓ ✓ ✓ permission actions actions description global applies the permission to all instances of the resource create allows creating new resources read allows viewing resources update allows modifying existing resources delete allows removing resources export allows exporting resource data import allows importing resources or configurations permission scope and evaluation permissions in turbine are evaluated based on scope and dependency , not a strict hierarchical model permission scope permissions can be configured at two levels scope description global grants access to all current and future resources of that type resource level grants access only to specific resources selected at the time of configuration behavior global permissions allow access to all resources , including newly created ones resource level permissions apply only to explicitly selected resources when both are configured, global permissions take precedence resource level permissions are retained but not applied when global access is enabled permission dependencies some features require access to multiple related resources users must have permissions for all required resources to fully access a feature applications and records access to resources in turbine follows dependency relationships between components applications and applets are foundational resources records, dashboards, and workspaces depend on applications and applets examples access to records requires the associated application related applets (if used) access to a dashboard may require underlying applications reports or records used in the dashboard related applets access to a workspace may require applications dashboards records applets access is not granted by a single permission alone users must have permissions for both the target resource and any underlying dependent resources when multiple users access the same record at the same time, users without users → read permission may be unable to open the record and encounter an error to avoid this, ensure the role includes users → read permission at the account level playbooks and automation automation features depend on multiple components playbooks events webhooks connectors users must have access to these resources to create, run, or manage automation workflows administration administrative functionality requires access to system level resources admin panel roles groups users users must have appropriate permissions across these resources to manage administrative settings access to a higher level or parent resource does not automatically grant access to its dependent resources for example, access to a dashboard does not grant access to the underlying reports or records all required resources must have permissions explicitly assigned group based inheritance rbac also supports inheritance through groups roles assigned to a parent group are inherited by child groups members of a parent group do not inherit roles from child groups key principle rbac in turbine follows the principle of least privilege users can only access resources when all required permissions are granted if required permissions are missing at any level or dependency, access to the feature or resource is restricted rbac best practices follow these best practices when configuring roles and permissions in swimlane turbine apply the principle of least privilege by granting users only the permissions they need to perform their tasks assign roles to groups when possible to simplify access management and onboarding reuse existing roles by duplicating them when creating new roles to maintain consistency test roles before assigning them broadly to ensure permissions behave as expected use clear and descriptive role names that reflect the responsibilities associated with the role if a user cannot access a feature or resource verify the user has the correct role assigned confirm permissions are granted for the target resource check for missing permissions on dependent resources