TYPO3 technology icon

Access Control Lists in TYPO3

Introduction

TYPO3 CMS, known for its remarkable flexibility, offers extensive options for configuring access to various elements of its management panel. Proper configuration of Access Control List (ACL) is crucial not only for security but also for the efficient management of access in both small and large projects. In projects where TYPO3's panel is used by anywhere from a few to several hundred people, each individual should have access only to those parts of the system necessary for their tasks. In this article, we will analyze the system elements that access can be granted to, examine what access configuration looks like immediately after a fresh installation of TYPO3, discuss the challenges associated with managing access in the TYPO3 panel, contemplate whether there are documented best practices for ACL configuration, and consider whether there are already available solutions that could facilitate the initial ACL setup.

What kind of permissions can we set in TYPO3

TYPO3 CMS allows for very detailed specification of access to individual elements in its management panel, which can be granted to individual users or user groups. However, it's worth noting that backend user groups offer a much wider range of configuration options, and one of the best practices is to use these groups for assigning access, then assigning individual users to the existing groups.

Access can be granted to various modules of the TYPO3 backend, which are usually accessible directly from the module menu and allow for managing different types of content or settings. Another aspect to which specific permissions can be granted includes the ability to view only certain parts of the page tree (DB Mounts) and define permissions for single pages (Page Permissions) or selected paths (File Mounts) in file storages, as well as granting permissions for operations on files and directories (Fileoperation permissions).

List of permissions for the group for individual elements in its management panel

If we delve deeper into the content management area, we can see how detailed the permissions can be configured. Here, we have the ability to specify which database tables a backend user group can view or modify (Tables for listing and Tables for editing), determine which columns of specific tables the group will have access to (Excludefields, by default those fields are accessible only to Admin users - marked as ‘exclude’ in TCA), or restrict content editing to selected languages (Limit to languages).

Detailed configuration of user permissions in the content management area

As you can see, there are many options for configuring access in TYPO3, and not all of them have been mentioned here (a detailed list can be found in the table below). It’s also worth noting that in TYPO3, there are 2 special types of backend users who by default have a very broad range of permissions and don’t require detailed access to individual elements of the management panel. These are the Admin and Super User accounts. Users granted administrator status will have access to all functions of the TYPO3 backend, except for a narrow group of modules related to installation and low-level system configuration, which are exclusively dedicated to users configured as Super Users.

Access Control Option Where the configuration is stored

Modules

Access lists

Database

 

Table: be_groups
Column: groupMods
Example value: web_layout,page_preview,web_list

Table: be_users
Column: userMods
Example: web_FormFormbuilder,workspaces_admin

Dashboard widgets

Access lists

Database

 

Table: be_groups
Column: availableWidgets
Example value: t3news,docTSconfig,t3information

Allowed multi-factor authentication providers

Access lists

Database

 

Table: be_groups
Column: mfa_providers
Example value: totp,recovery-codes

Allowed multi-factor authentication providers

Access lists

Database

 

Table: be_groups
Column: mfa_providers
Example value: totp,recovery-codes

Tables for listing

Access lists

Database

 

Table: be_groups
Column: tables_select
Example value: pages,sys_category,sys_redirect

Tables for editing

Access lists

Database

 

Table: be_groups
Column: tables_modify
Example value: sys_file_collection,backend_layout,fe_users

Page types

Access lists

Database

 

Table: be_groups
Column: pagetypes_select
Example value: 1, 6, 4

Excludefields

Access lists

Database

 

Table: be_groups
Column: non_exclude_fields
Example value: pages:fe_group,pages:author,tt_content:categories,tt_content:imagecols

Explicitly allow/deny field values

Access lists

Database

 

Table: be_groups
Column: explicit_allowdeny
Example value: tt_content:CType:header,tt_content:CType:text,tt_content:list_type:indexedsearch_pi2

Limit to languages

Access lists

Database

 

Table: be_groups
Column: allowed_languages
Example value: 0, 1

Table: be_users
Column: allowed_languages
Example value: 0

Fileoperation permissions

Access lists

Database

 

Table: be_groups
Column: file_permissions
Example value: readFolder,writeFolder,readFile,writeFile

Table: be_users
Column: file_permissions
Example value: readFolder,writeFolder,readFile,writeFile

DB mounts

Mounts

Database

 

Table: be_groups
Column: db_mountpoints
Example value: 1, 3

Table: be_users
Column: db_mountpoints
Example value: 6, 3

File mounts

Mounts

Database

 

Table: be_groups
Column: file_mountpoints
Example value: 1, 2

Table: be_users
Column: file_mountpoints
Example value: 1, 2

Category Mounts

Mounts

Database

 

Table: be_groups
Column: category_perms
Example value: 1, 2

Table: be_users
Column: category_perms
Example value: 1, 2

Workspace permissions

Database

 

Table: be_groups
Column: workspace_perms
Example value: 1

Table: be_users
Column: workspace_perms
Example value: 1

Page Permissions

Database

 

Table: pages
Column: - perms_userid
- perms_groupid
- perms_user
- perms_group
- perms_everybody


Example value: 1

User TSconfig

Database

 

Table: be_groups
Column: TSconfig
Example value: permissions.file.default {
addFile = 0
readFile = 1
}



Table: be_users
Column: TSconfig
Example value: permissions.file.default {
addFile = 0
readFile = 1
}

It’s worth adding that various modules installed in TYPO3 can utilize the available functionality of defining backend users and groups to determine access to their own features. An example of such a module is Workspaces, which allows the creation of workspaces that can be accessed by individual users or user groups, and these configurations are stored in the database tables defined by the extension providing this module. Let's therefore look at where and how the Workspaces module stores information about access:

Access Option Where the configuration is stored

Owners

Database

 

Table: sys_workspace
Column: adminusers
Example value: be_users_2,be_users_1,be_groups_1

Members

Database

 

Table: sys_workspace
Column: members
Example value: be_groups_1,be_users_2
Stage: "editing"

Notification dialog settings

Database

 

Table: sys_workspace
Column: edit_notification_defaults
Example value: be_users_2,be_groups_1
Stage: "ready to publish"

Notification dialog settings

Database

 

Table: sys_workspace
Column: publish_notification_defaults
Example value: be_users_2,be_groups_1
Stage: "publishing execute"

Notification dialog settings

Database

 

Table: sys_workspace
Column: execute_notification_defaults
Example value: be_users_2,be_groups_1

Access options for workspace custom stages:

Stage access option Where the configuration is stored

Responsible persons

Database

 

Table: sys_workspace_stage
Column: responsible_persons
Example value: be_users_2,be_groups_1

Default notification recipients

Database

 

Table: sys_workspace_stage
Column: notification_defaults
Example value: be_users_2,be_groups_1

The above summary clearly shows how many options and areas need to be considered when we want to correctly configure access in the TYPO3 backend and then manage it easily. The flexibility, yet complexity, of this functionality (ACL) in TYPO3 often leads to various challenges for the person managing access, and these will be presented in the later part of the article.

Main challenges when setting up permission in the TYPO3 backend

Configuring and assigning access to the TYPO3 backend won't be a significant challenge in a small project with a limited number of editors. However, as the project grows, or from the outset if it's complex and extensive, involving dozens or hundreds of editors, configuring accurate and manageable access can become challenging.

What are the main challenges in the context of configuring ACL’s in the TYPO3 backend?

  • planning appropriate naming and description for backend user groups
  • building a suitable hierarchy (inheritance) of backend user groups for easy management
  • updating permissions when new features are introduced that editors should have access to
  • configuring file and directory access and permissions in file storages
  • configuring access and permissions for multiple sites (multisite) within a single project
  • verifying that a large number of groups and users have the appropriate permissions
  • maintaining order in backend groups and users – removing or disabling groups that defined access to functions that no longer exist

If these issues aren't properly considered at the initial stage of access configuration in extensive projects, managing and correctly configuring editor permissions can become very problematic and time-consuming. In extreme cases, this could even lead to a decision to grant certain editors administrator status to allow them to fulfill their tasks (to have appropriate access), which is very bad practice and is  not recommended.

What do we get regarding ACLs after a fresh installation of TYPO3?

Despite the existence of some general best practices for configuring backend access, TYPO3 does not impose any specific approach and leaves a lot of freedom and flexibility to developers in this matter. This is clearly evident when we launch a fresh installation of TYPO3.

During the installation of TYPO3, we don't receive any option that would allow the installation of predefined backend user groups, which could be used for quickly granting access management to newly created user accounts. In version 12, we can only choose whether to create a default page or go directly to the backend and start development work entirely from scratch. The situation is slightly different in the developmental version 13. Here, in addition to the aforementioned options, we also get a third option, which allows us to go to the backend to the module for downloading pre-configured distributions. It's worth mentioning that in version 12, this module is also available, but there is no option to navigate to it directly from the installer, which may mean that some developers are not aware of the possibility of using it.

The Official TYPO3 Introduction Package image

In the list of pre-configured distributions, which are extensions to TYPO3, we find among others The Official TYPO3 Introduction Package. It provides a fully configured site with sample pages, content elements, and a working frontend based on the Bootstrap framework. Importantly, upon its installation, we also receive three configured and ready-to-use backend groups: All users, Simple editors, and Advanced editors. This might be a good solution for those who want to familiarize themselves with the workings of TYPO3, but for more complex projects, these three groups certainly won't be sufficient, and a more advanced configuration will be necessary. 

As we can see, there is a significant area for improvement in TYPO3, such as offering the option during installation to create ready-to-use backend user groups that are defined based on best practices in ACL management.

Are there any documented best practices available?

When we look at the official TYPO3 documentation, we find several valuable tips regarding the recommended approach to configuring backend user access. However, these are rather general pieces of information scattered across various pages of the documentation, among which we find, among others:

  • most systems should have only "admin" users for the developers - not for any editor [link]
  • you should grant backend users only a minimal set of privileges, only to those functions they really need [link]
  • It is a good approach to set permissions on a group level (for example use a group such as "editors") [link]
  • consider users in the context of their roles and create backend groups that represent these roles [link]

As can be seen, these are very general pieces of information and, as mentioned earlier, the official TYPO3 documentation lacks detailed recommendations for ACL configuration based on proven solutions.

Much more information regarding ACL management in TYPO3 can be found on various blogs. One of the more well-known articles is from 2017 by Marcus Schwemer, titled TYPO3 Backend-User-Management. This article details approaches to: naming backend groups, the scope of permissions assigned to individual groups, issues of inheritance in groups, and how to approach the creation of backend user groups in the context of extensions.

Another interesting article is Creating TYPO3 Backend Usergroups Your Clients Will Love from 2020 by Desirée Lochner. The article emphasizes the importance of a well-structured backend usergroup logic that begins with a general approach and becomes more specific, adapting to the diverse needs of users.. Creating separate usergroups based on team or job functions, rather than altering individual user configurations, ensures a comprehensible and maintainable system. It also recommends documenting the usergroup logic for clarity and future reference.

Summary

In conclusion, managing Access Control Lists in TYPO3 CMS is a crucial aspect that demands careful planning and consideration. The flexibility offered by TYPO3 in configuring access aligns well with the diverse needs of projects, both small and large. However, this flexibility also brings the responsibility of creating well-structured and efficient backend user groups. While the official TYPO3 documentation provides a starting point, it lacks detailed guidelines, prompting developers to seek insights from various expert blogs and articles.

That is why we launched the ACL Improvements initiative as part of the TYPO3 budget ideas (read about it in [this article]). The first step is to gather feedback from various agencies through a prepared survey, where we ask about their experiences in this area. Stay tuned for the next part of our ACL in TYPO3 series, where we will summarize the survey results.