Role-based access control

Along with the ACL security system, administrators can use the role-based security system to control user access to all of the resources in PortaBilling. Access control lies in configuring a role and assigning this role to a user. This ensures that
the user can access only those resources they are authorized to see or use.

The role-based security system is accessible from the new web GUI and exists in parallel with the ACL one. Administrators can use both security systems to control user access to application resources.

Default roles are supplied with PortaBilling – or administrators can create new roles to fit your company needs.

A role can be one of the following types:

• Account – to be assigned to accounts

• CC Staff – to be assigned to customer care support employees

• Customer – to be assigned to retail/reseller customers

• Distributor – to be assigned to distributors

• Representative – to be assigned to representatives

• Reseller – to be assigned to resellers

• Admin – to be assigned to users of the admin interface

• Vendor – to be assigned to your vendors

For now, the Admin, Account and Customer role types are available. Support for other role types will be implemented in subsequent releases.

Roles are presented on the web interface as a resource tree wherein root nodes reflect entities in PortaBilling (i.e. customer, account, product, etc.). Second-level nodes reflect entity parameter panels. For example, for a customer entity, it can be
the Personal information panel, Invoices and taxation panel, etc.

For each node within the tree, the administrator assigns permissions to define whether an entity or its parameters are available for the user and which actions the user can perform on them. The role’s resource tree has a hierarchical structure, that
is, lower-level nodes inherit permissions that have been assigned to higher-level nodes.

If the administrator needs to hide a certain item on an entity parameter panel (e.g., the BCC field on the Address info panel), they can switch to the Advanced mode. In this mode, the role’s resource tree displays a
list of items for each entity parameter panel. The administrator then sets the required permission for the corresponding item.

The administrator uses roles to control access to the self-care page for customers/account owners. The administrator can log into a customer self-care page on behalf of the customer, for example, to help with the cloud PBX configuration. If the customer
has a custom role assigned to them, the administrator can choose whether to log in with either the custom or the default role.

The administrator can assign one of the following permissions in the role’s resource tree:

• Restrict – this means that users cannot access the specified resource.

• Read – this permits users to view the specified resource.

• Modify – this permits users to view, update, create and delete the specified resource.

When a user attempts to perform a specific action with a resource (for example, update customer information), PortaBilling checks whether the user has permission for this action. If permission is granted for this action, the user may proceed. Otherwise,
the action is not permitted.

The role-based and ACL security systems operate in parallel in the following way.

ACLs are accessible in both systems. In the role-based security system, administrators can assign users both roles and ACLs. However, administrators cannot see or modify ACL details.

Roles are only accessible in the role-based security system. In the ACL security system, administrators can neither see/modify role details nor assign roles to users.

What happens if there is an inconsistency? For example, one administrator assigns ACL1 (or a role) to a user in the role-based security system and another administrator assigns ACL2 to this same user in the ACL system? In this case, whatever the last changes are, are the changes that will go into effect.

When the user logs in to the new web GUI the system checks their role permissions. When the user accesses the old web interface, his ACL permissions are checked before the user is granted access to the system.

The same logic is in place when operating with the system via the API. The components that were already moved to the new web GUI are covered by role permissions. This means that when an API user sends a request to retrieve a customer list or edit a
product, the system checks the user’s role permissions before executing the request. If the user wishes to modify the component that is still in the old web interface, the system checks the user’s ACL permissions.

During a system update, users with system default ACLs are automatically assigned roles to access the new web GUI. Corresponding roles are created for users with custom ACLs, though an administrator must assign them to users. The corresponding custom
roles for customer/account self-care pages are created and assigned automatically.