Configuring permissions securely

✖
Copy to clipboard

Permissions allow you to control access to the particular sections of the Xperience administration interface by users. To learn how the whole system works, continue through the following sections:

The rule of thumb here is to assign the least privileges possible. You should only grant permissions to users who really need to perform the particular actions.

User types

Xperience has two basic user interfaces:

  • Live site – front end for site visitors.
  • Administration – interface for managing the system and editing content, separated into applications.

Xperience divides users on the following levels:

  • Public user – can see live unsecured resources (pages, images …) on the live site. Represents a site visitor who has not signed in. Has privilege level None.
  • Authenticated user – a signed in user. May see secured resources on the live site (depending on assigned roles). Has privilege level None.
  • Editor – has access to the administration interface for assigned sites. Permissions are determined by assigned roles.
  • Administrator – has access to the administration interface for all sites within the system. Administrators can can manage all objects of all sites, but cannot use applications that are restricted to global administrators (typically those that affect the entire system, for example Sites) or perform certain restricted actions.
  • Global administrator –has unrestricted access to all functionality in the system.

Public users, Administrators and Global administrators have permissions determined by their privilege level. The other two types, authenticated users and Editors, are more flexible and their permissions are determined by their roles.

Users who want to access the administration interface must have at least the Editor privilege level. Moreover, they need to have assigned roles with permissions configured according to these users’ needs.

Public users (users with the None privilege level) can access only the Live site.

Impersonation

Administrators can sign in to the system as other users. This allows them to view the user interface from the given user’s perspective. To impersonate other users, edit a user in the Users application and click Log in as this user.

Due to security reasons, only users with the Administrators or Global administrator privilege level can use impersonation. Additionally, it is not possible to impersonate other administrators.

See also: Impersonating a different user

Permissions and UI elements

Permissions for the whole system can be managed in one place in the administration interface in the Permission application. They are role based – you cannot assign specific permissions to users directly, you always need to assign the user to a role and then give the role certain permission(s). There are two types of permissions:

  • Functional (permissions)– permission check is done after the user performs an action. If the action is not permitted, an error message is shown in the interface.
  • Visual (UI elements) – permission check is done during the page rendering. If a certain action is not available, the corresponding action button/link is not rendered and the user doesn’t see it in the interface.

There are two standard permissions – read and modify (manage). Also, many modules have their own specific set of permissions for better granularity or for better handling of special scenarios. For example, the Users module has the special permission “Manage user roles” which allows a given role to add or remove a user from/to a role.

To allow roles to modify pages and other parts of the system, you need to assign them both the read and manage permissions.

If you assign only the manage permission to a role, then this role will not be allowed to view the specified pages.

Be careful when assigning permissions, as some permissions can have other security implications. For example, you should assign the Manage user roles permission (from the Users module) only to a role with properly instructed users.

Roles

Each user can belong to any number of roles, their relationship is N:M. The roles are related N:1 to sites, every role belongs to a certain site.

You can learn how to manage roles in the Role management topic.

Memberships

Memberships group existing roles together, forming another security layer. Memberships are intended to be used mainly in the E-commerce solution.

See also: Membership management

Access control lists (ACL)

Every page has its own access control list (ACL). In this list you can specify which roles or users are permitted to read, modify, create, delete or destroy (delete permanently) the current page or its child pages.

See also: Page-level permissions (ACLs)

Special permissions

The special permissions include Edit SQL code and Edit SQL queries. These permissions can influence the possibility of privilege elevation attack. Find more information in Special security permissions.