Roles & Permissions in Altostrat SDX

Altostrat SDX uses a flexible Role-Based Access Control (RBAC) system to manage user capabilities. Permissions (also referred to as Scopes) define the ability to perform specific actions (like viewing billing info or deleting a site), while Roles group these permissions together. Roles are then assigned to users within the context of a specific Team, determining what each user can do within that team’s resources.

Key Concepts

  • Permissions (Scopes): Fine-grained strings representing specific actions, typically in the format resource:action (e.g., site:view, billing:update, api:create). These scopes directly control access to API endpoints and influence what is visible or actionable in the user interface.
  • Roles: Collections of permissions. Assigning a role to a user grants them all the permissions contained within that role for the team they are assigned to.
  • System Roles: Predefined roles with common permission sets provided by Altostrat SDX (e.g., Owner, Administrator, potentially a read-only or member role). System roles usually cannot be deleted or fundamentally altered.
  • Custom Roles: Roles you create and manage within your team, allowing you to tailor access precisely by selecting specific permissions.
  • Team Context: Role assignments are specific to a Team. A user might be an Administrator in one team but only have view permissions in another.

Permission Scope Reference

Permissions grant access to specific functionalities. Here is a breakdown of common permission scopes grouped by area, based on available API actions:

Note: For a definitive list of all available permission scopes, refer to the List Available Scopes API endpoint. Specific scope requirements are also detailed in the documentation for each API endpoint.

Creating a Role

Follow these steps to create a custom role within your currently active team:

1

Navigate to Roles & Permissions

In the Altostrat SDX Dashboard, go to Settings → Roles & Permissions. You will see a list of existing system and custom roles for your current team.

Roles & Permissions main view listing existing roles.

2

Start Creating a New Role

Click the + Add button. A form will appear to define the new role. Enter a descriptive name (e.g., “NOC Level 1”, “Billing Manager”) that clearly indicates the role’s purpose.

Entering the name for the new custom role.

3

Assign Permissions (Scopes)

Scroll through the list of available permissions, grouped by category. Select the checkboxes corresponding to the scopes (e.g., site:view, billing:update) you want to grant to this role.

Selecting specific permission scopes like 'site:view' and 'billing:view'.

4

Save the Role

Once you have selected all the desired permissions, click the Save button. The new custom role will be created and appear in the list, ready to be assigned to users within the team. (This typically corresponds to a POST /team_roles API call).

The newly created role saved and appearing in the list.

Editing a Role

You can modify the name and assigned permissions of custom roles. System roles typically cannot be edited.

1

Select the Role to Edit

Navigate to Settings → Roles & Permissions. Find the custom role you wish to modify in the list and click on its name or an associated ‘Edit’ icon.

Clicking on the 'NOC Ops' role to edit its permissions.

2

Modify Name or Permissions

In the role editing form, you can change the role’s name and adjust the assigned permissions (scopes) by selecting or deselecting the checkboxes.

Adding the 'site:action' scope and removing 'team:delete' scope from the role.

3

Save Changes

Click the Update or Save button to apply your modifications. All users currently assigned this role within the team will inherit the updated set of permissions. (This corresponds to a PUT /team_roles/ API call). Users might need to refresh their session (e.g., log out and back in) for changes to take full effect.

Saving the updated role permissions.

Deleting a Role

You can only delete custom roles. Deleting a role cannot be undone.

Deleting a custom role will immediately revoke all its associated permissions from any users currently assigned that role within the team. Ensure users have alternative roles if continued access is needed. You generally cannot delete a role if it is currently assigned to any users within the team.

1

Locate the Custom Role

Go to Settings → Roles & Permissions. Find the custom role you want to remove from the list. System roles will typically not have a delete option.

Identifying the custom role 'Temporary Access' to be deleted.

Locating the delete icon (trash can or menu) next to the custom role.

2

Confirm Deletion

Click the delete icon (e.g., trash can or via a menu) associated with the role. A confirmation prompt will appear. Carefully review the impact and confirm the deletion. (This corresponds to a DELETE /team_roles/ API call).

The delete option might be hidden off-screen on smaller displays or if the role has many permissions listed horizontally. You may need to scroll horizontally to find it.

Clicking the delete icon and confirming the removal of the role.

Assigning Roles to Users

Roles are assigned to users within the Team Members management section.

  1. Navigate to Team Settings -> Members.
  2. Select the user whose roles you want to manage within the current team.
  3. Assign one or more available roles (system or custom) to the user.
  4. Save the changes.

(See User Management for details on assigning roles to team members).

Best Practices

  • Use System Roles First: Leverage predefined roles like Administrator or Member for common access patterns before creating custom ones.
  • Principle of Least Privilege: Grant only the necessary permissions (scopes) required for a user to perform their job function within a team. Avoid overly broad roles.
  • Create Task-Specific Custom Roles: Define roles based on responsibilities (e.g., “Billing Viewer,” “Site Operator,” “Security Auditor”) rather than individual users.
  • Regular Audits: Periodically review role definitions and user assignments to ensure they are still appropriate and align with current responsibilities and security policies.
  • Document Custom Roles: Clearly document the purpose and intended permissions of each custom role you create for your team’s reference.