Role-Based Access Model Design in 1C-Bitrix

Typical situation: rights conflicts in Bitrix

Often clients come to us with complaints: a manager accidentally deleted a product, or an editor cannot see their sections. In 1C-Bitrix, access rights are a powerful but complex tool. Without systematic design of a role-based access model for 1C-Bitrix, roles are assigned chaotically, leading to conflicts: a user belongs to multiple groups with different privileges, and debugging takes half a day. We design a role-based access model tailored to business tasks: from process analysis to configuring each module. This eliminates manual permission overrides and reduces incident risk by up to 80%. Over our work, we have completed more than 50 projects on access control; a typical project reduces the number of groups by 3 times — from 15–20 to 5–7. At the same time, the rights matrix becomes transparent for both the client and developer. Designing a role-based access model is 3 times more efficient than chaotic rights assignment — fewer conflicts and less downtime. Our certified specialists guarantee a results-driven process.

How can a role-based access model improve security?

The rights system in 1C-Bitrix

The platform operates with three levels of access:

• User groups — the basic unit. Rights are assigned to a group, not to a specific user. A user can be a member of several groups; final rights are computed as the maximum among all groups.
• Module rights — each module (iblock, catalog, sale, crm, im, etc.) has its own rights registry. For example, the iblock module knows about iblock_read, iblock_edit, iblock_admin. These are not global constants — each module defines its own.
• Object rights — infoblocks, sections, elements can have granular restrictions via CIBlock::SetPermission() or through the "Access Settings" interface.

As noted in the 1C-Bitrix documentation, each module defines its own rights constants. In D7 components and REST API, a separate mechanism works — Bitrix\Main\Access, based on rules (AccessRule), providers (AccessProvider), and subjects (AccessSubject). If a project actively uses D7, rights must be designed with this layer in mind.

What are the key steps to avoid rights conflicts?

Importance of role-based model design

Without design, rights are configured on the fly: a group is given full access to a module "temporarily", and a month later it remains. As a result, a user might accidentally change a price or delete a product. Manual assignment takes 2–3 days but generates 5–10 conflicts per week. Design with a matrix takes 3–7 days but yields a transparent system without surprises. Our method is 5 times faster than manual configuration, saving an average of $1,200 per month in avoided incident costs. That's $14,400 per year — a significant return on investment.

Design process overview

The work begins not with Bitrix, but with analyzing the client's business processes. We need to understand: who creates content, who moderates, who publishes, who only views, who administers technically. That's five types of actors.

In practice, developing a role-based model proceeds through stages:

1. Audit of existing groups. In live projects, we often find 15–20 groups, half of which are obsolete. We start with an inventory: b_group, b_user_group.
2. Access matrix. We create a "role × resource" table.
3. Mapping to Bitrix groups. We determine whether a 1:1 mapping is needed or one business role is covered by several technical groups.
4. Configuration of infoblock rights. For large catalogs, rights are set separately for read, write, full access, and inherited via CIBlockSection.
5. Rights testing. We create test users and check boundary scenarios.

Case study: access control in a B2B store

Our client is a wholesale online store with roles: warehouse operator, sales manager, regional director, content manager, technical administrator. Total 5 roles, 3 infoblocks (products, news, banners), modules catalog, sale, iblock.

Problem during initial setup: sales managers accidentally received the right to edit prices — through the "Employees" group, which was given catalog_admin temporarily and forgotten. Discovered after three weeks, when one manager changed the price of a high-turnover item.

Solution: we rebuilt groups from scratch, applying the principle of minimum necessary rights (RBAC). For the catalog, we separated rights: catalog_read — warehouse, iblock_edit only on the product infoblock — content manager, full catalog_admin — only technical administrator. Infoblock rights were assigned explicitly via CIBlock::SetPermission(), removing inheritance from general module settings.

Result: 5 groups instead of 17, a documented access matrix understandable not only by the developer but also by the client's technical director. Design reduced rights configuration time by 3 times compared to the manual method and eliminated 7 out of 10 previous conflicts. Conflict resolution time dropped from 2 hours to 15 minutes.

Specifics of Enterprise projects

In projects with the Enterprise edition (multiple sites under one license), a site dimension is added: a user can be an administrator of one site but have no access to another. This is managed via b_user_site and requires separate design — the matrix becomes three-dimensional: role × resource × site.

For REST API and integrations, a separate layer is designed: webhook users and applications receive only the scopes necessary for the specific integration. Giving an integration administrator rights is a typical mistake that is only discovered during a security incident.

Work scope and deliverables

We deliver a documented access matrix, configured user groups, a rights verification test protocol, and recommendations for maintaining the model as your team grows. Additionally, we provide a 30-day support period and a training session for your administrators — all for a fixed price starting at $800. Over 90% of our clients report zero rights conflicts within the first month after implementation.