Skip to main content

Atria Permissions System

Overview​

Atria controls access to features and data through a role-based access control (RBAC) system. This system regulates user access to menus and pages within the Atria UI, as well as object-level permissions like Read, Write, and Delete actions on entities such as Customers, Users, and Services.

Roles and Permissions​

Users can be granted one or more Atria Security Roles. Each role can contain multiple permissions, and roles can also include other roles, inheriting their permissions.

Service-Dependent Roles​

Each Atria Service has a set of associated roles that contain the permissions needed to manage that service within Atria. To simplify management, broader administrative roles can encompass multiple service-specific roles. These roles are dynamically enabled based on the services assigned to the customer.

For example, the following customer-level roles could exist:

  • User Administrator: Can add, update, and remove users within a customer.
  • DNS Service Administrator (tied to DNS Service): Can manage DNS records for a customer.
  • Workspace Service Administrator (tied to Workspace Service): Can manage workspace services for a customer.
  • M365 Service Administrator (tied to Microsoft 365 Service): Can manage Microsoft 365 services for a customer.

A broader role, such as Service Administrator, could include roles like "DNS Service Administrator," "Workspace Service Administrator," and "M365 Service Administrator."

In a scenario where a customer only has the DNS service enabled, a user assigned the Service Administrator role would only receive the "DNS Service Administrator" permissions. Atria will automatically exclude the "Workspace Service Administrator" and "M365 Service Administrator" permissions, as they are irrelevant for that customer.

When additional services are assigned (e.g., M365), the features associated with the M365 Service Administrator role will automatically become available to users with the Service Administrator role in that customer.

Scope of Permissions​

Atria uses a hierarchical scoping system to determine where permissions apply. Permissions can have one of three scope settings:

  1. Current Customer: Permissions apply only to the user's current customer.
  2. Sub-Customers: Permissions apply to customers created under the current customer, but not the current customer itself.
  3. Current Customer and Sub-Customers: Permissions apply to both the current customer and its sub-customers.

This system allows segregation of permissions between a reseller’s staff and the end-users of the reseller's customers. For example, service desk staff at a reseller may have administrative rights over sub-customers but would not be able to administer other users within their own organization.

Default Roles​

Atria includes default security roles that provide a baseline for typical system users.

For example:

  • The User and Service Administrator role allows a user to create and manage other users within a tenant and assign any enabled services to those users.
  • A Reseller Administrator can manage sub-customers and their assigned services.
  • The Service Provider Administrator is a special role that grants access to the administrative features of the Atria platform.

Customizing Roles​

Service Provider-level users can create and modify Atria Security Roles. As part of an implementation, roles can be configured and customized to meet the specific needs of the service provider and their customers.

Controlling Role Access​

Access to roles can be controlled at the customer level. Once roles are enabled for a customer, they can be assigned to users within that customer.

Backing Roles with Active Directory Security Groups​

Atria Roles can optionally be linked to Active Directory security groups. When this feature is enabled on a role, Atria will create a corresponding security group and associate it with the role. Any user granted that role will automatically be added to the security group.