Designing a Role-Based Access Model for 1C-Bitrix
Designing a Role-Based Access Model for 1C-Bitrix
A typical scenario: a client comes in with a request like "we need managers to be unable to delete products, and editors should only see their own sections." In Bitrix, this is handled through the permissions system — modular, multi-layered, and frankly not the most intuitive. Without proper design, roles get patched together manually, and contradictions emerge: a user belongs to two groups with conflicting permissions, and figuring out why a button isn't showing up becomes a half-day investigation.
How the Permission System Works in 1C-Bitrix
The platform operates on three access levels:
User groups — the basic unit. Permissions are assigned to a group, not an individual user. A user can belong to multiple groups; final permissions are calculated as the maximum across all groups.
Module permissions — each module (iblock, catalog, sale, crm, im, etc.) has its own permission registry. For example, the iblock module defines iblock_read, iblock_edit, iblock_admin. These are not global constants — each module defines its own.
Object-level permissions — info blocks, sections, and elements can have granular restrictions set via CIBlock::SetPermission() or through the "Access Settings" interface on a specific info block.
Additionally, D7 components and the REST API use a separate mechanism — Bitrix\Main\Access — based on rules (AccessRule), providers (AccessProvider), and subjects (AccessSubject). If the project makes heavy use of D7, permissions must be designed with this layer in mind.
The Design Process
The work starts not with Bitrix, but with an analysis of the client's business processes. The goal is to understand: who creates content, who moderates, who publishes, who only views, and who handles technical administration. These are five actor types that in real projects get mixed together in the most unexpected combinations.
In practice, role model development goes through the following stages:
-
Audit of existing groups. On live projects, you often find 15–20 groups, half of which are outdated experiments. Start with an inventory:
b_group,b_user_group— look at who belongs where and whether there is any logic at all. -
Access matrix. Build a "role × resource" table. Rows are functional roles (catalog content manager, order manager, SEO specialist, technical administrator). Columns are modules and objects. Cells are the access level (none / read / edit / administer).
-
Mapping to Bitrix groups. Determine whether a 1:1 mapping is needed or whether one business role is covered by multiple technical groups. Sometimes it is more efficient to create a "base" group with common permissions and "specialized" groups with additional ones.
-
Configuring info block permissions. Critical for large catalogs: permissions are set separately for read, write, and full access — and can be inherited hierarchically through sections via
CIBlockSection. -
Permission testing. Create test users for each role and manually verify edge-case scenarios: can a manager export a price list, can an SEO specialist see the "SEO" tab on elements but not the "Prices" tab.
Case Study: Access Segmentation in a Wholesale Online Store
The project was a B2B catalog with roles: warehouse operator, sales manager, regional director, content manager, and technical administrator. In total: 5 roles, 3 info blocks (products, news, banners), and the catalog, sale, iblock modules.
The problem during initial setup: sales managers accidentally gained the ability to edit prices — through the "Employees" group, which had been granted catalog_admin "temporarily" and was never cleaned up. This was discovered three weeks later when one manager changed the price on a high-volume item.
The solution: rebuilt the groups from scratch. Adopted the principle of "least necessary privileges": each group gets exactly what it needs for its work, and nothing more. For the catalog, permissions were split: catalog_read for warehouse staff, iblock_edit restricted to the products info block for content managers, full catalog_admin only for the technical administrator. Info block permissions were assigned explicitly via CIBlock::SetPermission(), removing inheritance from module-level settings.
Result: 5 groups instead of 17, a documented access matrix that the client's technical director — not just the developer — can understand.
Enterprise Project Considerations
On projects using 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 through 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 required for the specific integration. Granting an integration administrator-level access is a classic mistake that only surfaces during a security incident.
Timeline and Scope of Work
Designing a role model for a project with a standard set of roles (5–8) and typical modules takes 3–7 business days: analysis, matrix creation, approval, implementation, testing, and documentation. Complex Enterprise projects with multiple sites and custom modules take 2–4 weeks.
Deliverables include: a documented access matrix, configured user groups in the system, a permission verification test report, and recommendations for maintaining the model as the team grows.