Description

Currently, the Security component mixes authentication and authorization together. It also assumes a Role-Based Access Control (RBAC) model, forcing UserInterface::getRoles(). However, many applications:

• Do not need roles at all (e.g., policy-based, attribute-based, or ownership checks),
• Only require authorization (e.g., CRON jobs, system tasks) but not full user authentication,
• Need alternative models such as Discretionary Access Control (DAC), Mandatory Access Control (MAC), Attribute-Based Access Control (ABAC), or Risk-Based decision-making,
• Or simply handle authorization for subjects other than a typical user (e.g., microservices, batch processes, system-level services).

Proposed Change

• Create a symfony/access-control Component

  • Migrate all authorization features from symfony/security (voters, is_granted() Twig functions, role checks, etc.) into a dedicated package.
  • This new component can offer built-in RBAC, ABAC, DAC, MAC, Risk-Based policies, or custom rule sets—without forcing roles.
  • Subject-Agnostic: It should not rely on having a UserInterface at all, allowing any entity or context to be the “subject” of an authorization check.

• Deprecate getRoles() in UserInterface

  • Let developers define their own permission models or attributes. Roles can still be supported, but not required.

• Keep symfony/security Focused on Authentication

  • Firewalls, token management, and user identification remain in symfony/security.
  • symfony/access-control handles how to grant or deny actions, regardless of authentication approach or subject type.

Potential Benefits

1. Cleaner Separation of Concerns

   • Authentication/identification in one place, advanced authorization in another.

2. Flexible Access Control Models

   • Developers can choose RBAC, ABAC, DAC, MAC, risk-based checks, or any custom logic without coupling to roles.

3. Scalable for Complex Scenarios

   • Systems can implement stricter or more dynamic policies without hacking around UserInterface::getRoles().

4. Works for Authorization-Only Apps

   • Service-to-service APIs, batch processes, or microservices needing permission checks can use the access control piece alone.

5. Subject-Agnostic Design

   • Easily handle use cases where the “actor” is not a typical user but any other subject (e.g., an automated system or a machine identity).

Conclusion

By introducing a dedicated symfony/access-control component and separating it from symfony/security, Symfony would better accommodate applications that either:

• Need robust authorization without roles,
• Rely on alternative models (e.g., ABAC, DAC, MAC, Risk-Based),
• Only require authorization without full-fledged authentication, or
• Wish to treat any entity as the “subject” of access checks, not just a UserInterface.

Feedback on backward compatibility, migration strategy, and community support is greatly appreciated!

Example

No response