Download the PHP package fedale/access-control-voter-bundle without Composer

Fedale RBAC Bundle

A Symfony RBAC bundle inspired by Yii2's auth manager. It mirrors a four-table model (auth_item, auth_item_child, auth_assignment, auth_rule) and maps those concepts onto native Symfony primitives. It adds a can() API for permissions alongside isGranted() for roles, a DB-driven role hierarchy, and contextual rules (service- or expression-based).

Not to be confused with fedale/access-control-bundle, which is the perimeter HTTP guard (path/host/IP firewall). This bundle is RBAC authorization (roles/permissions/hierarchy/rules) and is fully independent.

Concept mapping

The key expressiveness: you can assign a permission directly to a single user (via auth_assignment), bypassing the hierarchy — something Symfony's roles-only model does not support natively.

Architecture

• Assignment (user→item): auth_assignment, the single source of truth (see Token integration).
• Role→role hierarchy: RbacRoleHierarchy feeds isGranted(ROLE_*).
• Permissions / decision: AccessManager::can($item, $subject) walks up auth_item_child gating each node with its auth_rule. It is also exposed through DynamicVoter, so #[IsGranted('PERMISSION', subject: $obj)] and isGranted('PERMISSION', $obj) keep working.

can() accepts any item (role or permission). Recommended convention: isGranted(ROLE) for a plain role check; can(item, $subject) when you need a rule's contextual gating.

RBAC model & NIST positioning

In NIST RBAC (ANSI INCITS 359) terms the bundle covers:

• Core RBAC (L1) — users, roles, permissions; permissions acquired through roles, plus direct permission-to-user assignment (auth_assignment accepts a permission, not only a role).
• Hierarchical RBAC (L2), general — auth_item_child is an arbitrary DAG with multiple inheritance (role→role, role→permission, permission→permission), not limited to a tree.
• Beyond static RBAC — auth_rule adds contextual, object-level conditions (service- or expression-based on the $subject), an ABAC-style capability that plain RBAC lacks.

Not implemented: Separation of Duty (Constrained RBAC, L3) — mutually-exclusive roles (SSD/DSD) and role cardinality are out of scope.

Installation

Register the bundle (usually automatic with Flex):

With the Doctrine provider (default) the entities' ORM mapping is registered automatically: you don't need to add doctrine.orm.mappings entries.

Configuration

Database schema (Doctrine provider)

The four tables (FK constraints as shown):

Generate the migration with php bin/console doctrine:migrations:diff after installing the bundle.

Notes: a rule references a service_id or an expression (no serialized PHP object); timestamps are DATETIME; user_id is VARCHAR(255).

Token integration

auth_assignment is the single source of truth for user→item. For isGranted(ROLE_*) to reflect assigned roles, choose one mechanism:

Primary (recommended): User::getRoles() reads auth_assignment

The User entity implements AssignedRolesAwareInterface; the AssignedRolesUserProvider decorator injects the roles on every load/refresh (token always fresh, no session lag).

Fallback: inject_assigned_roles: true

For apps that cannot modify the User class. A listener on AuthenticationTokenCreatedEvent enriches the token (handles the standard login's PostAuthenticationToken). With stateful firewalls the injected roles stay in the session token until re-login; can() always reads fresh anyway.

Migrating from an existing user_role_assigned table

If your app already stores role assignments in its own table, migrate them into auth_assignment and drop it:

DB-driven role hierarchy

With override_role_hierarchy: true the bundle decorates security.role_hierarchy with RbacRoleHierarchy, which expands the role→role edges from auth_item_child (transitive closure). It replaces the security.yaml role_hierarchy: any static edges defined there must be mirrored in auth_item_child. Permissions do not enter the role hierarchy (they are resolved by can()).

Rules (auth_rule)

A rule attached to an item via rule_name runs during can() (node gate). Two forms, both stored in the DB:

Service rule (service_id)

auth_rule.service_id = 'App\Security\AuthorRule'. A service rule can also delegate to one of your own voters: $this->security->isGranted('MY_ATTR', $params).

Expression rule (expression)

An ExpressionLanguage string in auth_rule.expression, evaluated by ExpressionRule. Variables: user, token, subject (the $subject of can(), which may be a map), item, roles, auth_checker (for is_granted(...)). Examples:

With #[IsGranted], the attribute Expression is the condition (→ auth_rule.expression); the subject: part that uses args[...] stays in the controller attribute and produces the $subject that reaches the rule.

Usage

In Twig (when twig/twig is installed) the can() function mirrors the PHP API; native is_granted('ROLE_X') still covers plain role checks:

Your own voters coexist with DynamicVoter (which abstains on non-permission attributes); use disjoint attributes to avoid double votes.

Management (write API)

With the Doctrine provider the bundle exposes a write API to manage the graph, RbacManagerInterface. Every mutation flushes and invalidates the affected cache.

CLI equivalents (Doctrine provider):

assign/revoke use the value returned by getUserIdentifier() as user_id.

The write API invalidates the cache automatically. When you seed the tables out-of-band (SQL/fixtures), clear the bundle's cache keys explicitly (only the RBAC keys, not the whole pool; available when the cache is enabled):

Custom provider (no Doctrine)

Set provider: to anything other than doctrine and register services for the three interfaces ItemStorageInterface, AssignmentStorageInterface, RuleStorageInterface. The rest of the bundle (AccessManager, role hierarchy, voter, rule resolver) is source-agnostic. The write API and management commands are Doctrine-only; a custom provider can implement RbacManagerInterface itself.

Read-only commands

Tests