The version 3.1 of Strapi introduced a variety of capabilities to advanced enterprise content management capabilities. One of the most significant improvements is with the Role-Based Access Control (RBAC) feature, which is designed to help maximize operational efficiency, reduce dev team support work, safeguard against unauthorized access or configuration modifications, and make it easier to meet publication deadlines. The practice of assigning each user the precise amount of privileges to perform their jobs and nothing more is one of the most x fundamental security principles and allows opening up contribution to external users.
Strapi EE RBAC introduces the possibility to create any custom roles, up to 30 different ones on the Bronze Enterprise Edition plan, and unlimited for the Silver and Gold Enterprise Edition.
Each organization has different requirements and operational processes. Oftentimes, the predefined 3 default build-in roles won’t be specific enough. They either grant too few or too many privileges that each user needs to undertake. To resolve this problem, Strapi Enterprise Edition allows you to create custom roles that give exactly the precise privileges based on your users’ responsibilities at a more fine-grained level.
A role is a collection of permissions and operation actions that you can apply to users. Using roles makes it easier to add, remove, and adjust permissions rather than assigning permissions to users or user groups. As your user base increases in scale and complexity, roles become particularly useful.
Predefined Default Roles
Strapi Enterprise Edition supports the same predefined roles available in the Community Edition: SuperAdmin, Editor and Author. They are the most commonly used roles in most of the organizations. The permissions of these roles have been predefined and can be directly assigned to individual users or user groups.
SuperAdmin roles will have all the privileges and permissions for the entire system. Editor roles will have the Create, Read, Update, Delete, Publish privileges. Author roles will have the same privileges, but only on their own content.
One of the main goals of RBAC is to only grant contributors the access they need to do their missions and prevent them from having irrelevant access. A well-designed RBAC system also simplifies and streamlines the administration of access.
The best practices to implement custom roles is to start by considering the roles for each contributor in the publishing process in your agency, or company, or your client’s company. This way, you will mimic your organizational structure inside your Strapi Admin panel. You can then consolidate or break out roles as needed based on how people in different job functions are meant to use Strapi.
The role that will be defined should be strictly based on each contributor’s responsibilities. Reduce risk, both from malicious intent and user errors by following the principle of least privilege i.e setting up roles for the lowest level of permissions first.
The Strapi RBAC is designed to be additive: if users have several role assignments, users’ permissions will be the union of the defined privileges. The practice can facilitate management and update of roles. Overlapping roles should be considered only if the user is assigned to have several levels of permissions in the publishing process.
One of the benefits of the RBAC is to reduce administrative work. If you have many users in your organization, make sure that users can be grouped into specific roles with the same permissions to maximize efficiency.
The advanced RBAC included in Strapi Enterprise Edition allows admin to set different permissions for each field in any content types for any Create, Read, Update or Delete operation. It is recommended to add the permission status in your workflow to define the permissions during the content type creation process.
This feature will be very helpful if you need to build a Strapi application to manage a network of franchise, a partner portal or any distributed network and global communities composed of several subgroups or entities.
Large companies often require these privileges to be managed from Single Sign-On (SSO) or Active directory that controls authorization to all accounts and applications from a single service. That SSO feature is not yet available in Strapi EE. However, we’re currently working on supporting third-party authentication providers such as Okta, Azure AD, GitHub, Facebook, Google, Twitter and so on.
Learn more about Strapi Enterprise Editions