Transition to RBAC After Upgrade

With the introduction of Role-Based Access Control (RBAC), the system includes a predefined set of roles designed to ease the transition from the legacy permissions model. These roles are automatically mapped from the previous configuration to help retain basic access structures and reduce disruption during the upgrade.

While the superadmin role is fixed and cannot be modified or removed, all other predefined roles—such as admin, operator, session viewer, safes admin, and auditor—can be modified or extended as needed. This flexibility allows organizations to gradually align the access model with their internal security policies.

Warning

• After upgrading, administrators should review and customize the predefined roles to ensure they meet the specific requirements of their organization. Adjusting these roles is essential to take full advantage of the control and granularity offered by RBAC.

• When upgrading the system to a capabilities-based version, it is necessary to map all objects for which users had capabilities / grants.

• The automatic mapping of legacy roles is a one-time compatibility step performed only during the upgrade from a version without RBAC. These predefined roles are not intended to replicate previous permissions one-to-one, but rather to provide a starting point for adaptation.

• Once a predefined role is modified or deleted, the change is permanent—there is no built-in mechanism to restore its original default state. However, if you need to revert to the original configuration, please contact Fudo Enterprise support for assistance.

Understanding Privileges and Capabilities

Read

The *-read privilege grants visibility into a specific tab of the interface, and consequently, into all objects of that type in the system—not just those for which the user has capabilities. This privilege provides view-only access and does not permit editing, deletion, or any other actions.

Example:

A user assigned the user-read privilege can open the Users tab and view the full list of user accounts in the system, including those they did not create and do not have capabilities for. However, they cannot modify, block, or delete any of these users unless they also have the corresponding capabilities or additional privileges.

Create

Privileges with the *-create suffix allows users to create new objects of a given type. For example, user-create enables the creation of a new users. When an object is created, the system automatically grants the creator all available capabilities for that specific object. This means the creator can fully manage the object without needing additional privileges.

Example:

If an administrator has the user-create privilege and creates a new user, they automatically receive the following capabilities for that user:

• modifying the user’s settings,

• blocking or unblocking the user,

• deleting the user.

In this scenario, the administrator does not require separate privileges such as user-block or user-delete—the capabilities granted at creation time are sufficient.

Delete

Granting a role a privilege from the *-delete group (e.g., server-delete) allows that role to delete any object of the specified type—regardless of whether the user created it. In the user interface, access to the relevant tab and object may still be required to perform the deletion, but via the API, any object can be deleted if the *-delete privilege is present. In many cases, the *-read privilege is not required for such actions via API.

Warning

This creates a potential security concern: assigning *-delete may unintentionally elevate a role’s access level beyond what was originally intended. Recommendations:

• Prefer assigning *-create privileges when the role should only manage objects it has created.

• Use *-delete privileges only for roles that are intended to have global control over all objects of a given type.

When migrating from version 5.5, review role permissions carefully to avoid unintentionally increasing their effective privileges.

Predefined Roles as a Starting Point

The system includes a set of predefined roles designed to support backward compatibility and legacy access structures following the introduction of Role-Based Access Control (RBAC):

• Superadmin - Has unrestricted access to all system features and settings. This role can create custom roles with any available access rights.

• Operator – Grants similar permissions to the legacy operator role prior to the introduction of RBAC. This role is automatically mapped based on the previous configuration. Selected example privileges:

  • Can view the list of sessions and their details, but only for sessions linked to objects for which the operator has appropriate permissions.

  • Can play archived and live sessions, limited to sessions associated with accessible objects.

  • Cannot create new objects.

  • Can block only those objects for which they have assigned capabilities.

  • Sees only the objects for which they have capabilities in all lists, but can preview all roles and groups.

  • The operator role now includes the listener-read privilege by default. Due to RBAC changes, operators currently see all listeners, even those not explicitly granted.

  • Can preview password changers, verifiers, and password policies.

  • Can preview remote applications.

  • Cannot preview policies, and regular expressions.

  • Can manage and view notifications for users to whom they have capabilities.

  • Can see the Admin Panel footer.

  • Cannot share sessions for joining or delete sessions.

  • Can view and vote in awaiting, active, and archived requests associated with objects they have access to (requesting user, account, safe, server/pool).

  • Can generate reports from the Sessions tab.

  • Can manage report subscriptions.

  • Can manually add a subscription for the System Report, but only for objects they have capabilities to (users cannot see reports generated for other users).

  • Now has access to the Authentication tab. This change enables administrators to view and assign external authentication methods.

  • Now has access to the External password repositories tab to assign external password repositories to accounts.

  • Now has access to the Cluster tab to send sessions to other nodes.

  • Does not have access to other subtabs under the Settings tab.

• Admin - Grants similar permissions as the legacy admin role prior to the introduction of RBAC. This role is automatically mapped based on the previous configuration. Selected example privileges:

  • Has access to the Dashboard and its widgets, according to related capabilities.

  • Can create new objects such as users, groups, servers, accounts, pools, and safes. The creator is automatically granted full permissions to the objects they create.

  • Can manage users, groups, servers, accounts, pools, and safes for which they have assigned capabilities.

  • Cannot create listeners.

  • Can create users and preview their assigned roles, but cannot assign roles to users (role-modify privilege is needed).

  • Can manage and view notifications for users to whom they have capabilities.

  • Can see the Admin Panel footer and access the User Menu in the upper-right corner.

  • Can view and play sessions linked to accessible objects, manage retention, delete sessions within access scope, use all features covered by the session-modify privilege (Sessions Tab Permissions), and perform actions such as encoding, sharing, commenting, terminating, exporting, and joining.

  • Can view and vote in awaiting, active, and archived requests associated with objects they have access to (requesting user, account, safe, server/pool).

  • Can create and manage password changers, verifiers, and password policies.

  • Can create and manage remote applications.

  • Can create and manage policies, and can only preview regular expressions.

  • Can generate reports from the Sessions tab.

  • Can manage report subscriptions.

  • Can manually add a subscription for the System Report, but only for objects they have capabilities to (users cannot see reports generated for other users).

  • Now has access to the Authentication tab. This change enables administrators to view and assign external authentication methods.

  • Now has access to the External password repositories tab to assign external password repositories to accounts.

  • Now has access to the Cluster tab to send sessions to other nodes.

  • Does not have access to other subtabs under the Settings tab.

• Session Viewer - Grants similar permissions as the legacy session viewer role prior to the introduction of RBAC. This role is automatically mapped based on the previous configuration. Selected example privileges:

  • Can view the list of sessions and their details, limited to sessions associated with objects for which they have permissions.

  • Can play archived and live sessions, limited to sessions associated with accessible objects (see also Sessions Tab Permissions).

  • Can join, terminate, comment on, and encode sessions, provided they have access to the related objects.

  • Can access the Admin Panel footer.

  • Cannot modify session-related configuration (e.g., retention, encoding settings, etc.).

  • Can access the Files tab and download available session-related files, limited to sessions they are permitted to view.

• Safes Admin - Provides similar permissions as the admin role, except for access to password modifiers and password policies. Additionally, this role does not have access to the Cluster configuration or widget. Selected example privileges:

  • A newly created user with this role may not see any objects unless they are explicitly granted capabilities to existing ones.

  • Has access to the Dashboard and its widgets, depending on assigned capabilities.

  • Can create new objects such as users, groups, servers, accounts, pools, and safes. Upon creation, full permissions are granted to the creator for those objects.

  • Can preview all roles, groups, users, and accounts.

  • Can manage users, groups, servers, accounts, pools, and safes for which they have capabilities.

  • Cannot create listeners.

  • Can create users and preview their assigned roles, but cannot assign roles to users (role-modify privilege is needed).

  • Can view and manage notifications for users to whom they have capabilities.

  • Can see the Admin Panel footer and access the User Menu in the upper-right corner.

  • Can view and play sessions linked to accessible objects, manage retention, delete sessions within access scope, use all features covered by the session-modify privilege (Sessions Tab Permissions), and perform actions such as encoding, sharing, commenting, terminating, exporting, and joining.

  • Can view and vote in awaiting, active, and archived requests associated with objects they have access to (requesting user, account, safe, server/pool).

  • Can preview password changers, verifiers, and password policies.

  • Can create and manage remote applications.

  • Can preview policies, and regular expressions.

  • Can generate reports from the Sessions tab.

  • Can manage report subscriptions.

  • Can manually subscribe to the System Report, but access will be limited to objects they have capabilities for (users cannot view reports generated for others).

  • Now has access to the Authentication tab to assign external authentication methods to users.

  • Now has access to the External password repositories tab to assign external password repositories to accounts.

  • Now has access to the Cluster tab to send sessions to other nodes.

  • Does not have access to other subtabs under the Settings tab.

• Auditor - A read-only role with visibility into all areas of the system. Similar to the superadmin role in scope, but without permission to edit existing objects or create new ones.

Note that some exceptions apply, and the mapping may not reflect a one-to-one correspondence in all cases. Selected examples include:

• After the upgrade, an admin who has a capability assigned to an object will automatically gain full permissions for that object.

• Since listeners are considered a global and network-level configuration, after upgrading to version 5.6, admin users no longer have permissions to create them.

• The admin, safes admin and operator roles now includes the extauth-read privilege by default to be able to see and assign external authentication to users.

• The admin, safes admin and operator roles now includes the passvn-read privilege by default to be able to see and assign external password repositories to accounts.

• he admin, safes admin and operator roles now includes the cluster-read privilege by default to be able to send sessions to other nodes.

• The operator role now includes the listener-read privilege by default. However, due to RBAC changes, operators can currently view all listeners, not just those explicitly granted.

• Listener access model change - users now either have access to all listeners or to none. Granting access to individual listeners is no longer possible.

• can add manually subscription for this type of report but it will be limited to objects they have capabilities to.

• have access to following dashboard widgets: concurrent sessions, suspicious sessions, concurrent session chart, ‘Active users’ and ‘Account alerts’ widgets

• can now access the Download > Files tab and download files listed there. This permission is required for the correct display of SFTP/SCP sessions.

• The session viewer role now includes access to additional interface elements, including new tabs and the ability to add the Active Users dashlet from the Dashlet marketplace. This reflects expanded privileges defined in the updated access control matrix.

Note

• The superadmin role is protected and cannot be modified or deleted. This includes:

  • Editing its privileges or capabilities,

  • Renaming or deactivating the role,

  • Removing the role entirely.

• This restriction ensures that the system always retains at least one role with unrestricted access to all administrative features.

• The system enforces that at least one user must always be assigned to the superadmin role.

Warning

• The predefined user role has been removed from the system. After upgrading to version 5.6, any users who previously had this role assigned will no longer have any role.

• The predefined role service has been removed from the system.

  • Before the upgrade, customers who previously had multiple users assigned to the service role must remove all but one of them.

  • SNMP settings previously configured for that user will be transferred to the System tab and applied globally.

Related topics:

• Role-Based Access Control (RBAC)

• Groups (RBAC)

• Users