Access control in symfony, don't quite understand you?

Question

symfony

Good afternoon!
I don't quite understand security in symfony 3, access to resources is by roles and all roles are declared explicitly. But what if I want, say, to make a table of privileges in the database and bind privileges to functionality (add a user - addUser, delete a task - delTask, send out a mailing list - sedMultyEmail), and the roles themselves are not so important for the application, because the task of the system control - to provide access by privileges, and which role has some kind of privilege - this is another abstraction, and the system does not need to know about it.
Does this mean that in symfony ROLE = privilege, and each person can have several of them, or did I just not read the documentation thoughtfully enough?

Answer 1

Symfony is primarily a framework for handling HTTP requests, and therefore many components are "tailored" for this scenario by default.
Ultimately, all of Symfony Security is built around the notion of a "token" ( TokenInterface) and most of the parts of a Security component are abstract enough that quite a variety of permission sharing schemes can be assembled from them.
You need to define for yourself what "binding privilege to functionality" means in terms of application code. Do you plan to leave this separation of access rights at the level "let / do not let on a certain route" or you will call something similar in the application servicesSecurity::isAllowed()? Symfony implements the first approach by default, but nothing prevents you from organizing your own implementation of the main components. If you need an ACL (that's what "binding privileges to functionality" is called) - then this functionality has been moved to a separate ACL bundle in Symfony 4, which is most likely what you need.
Regarding the link role = privilegy - no, in the general case this is not the case. It is necessary to separate the processes of authentication (as a result of which the validity of the user is confirmed and his roles are determined) and authorization (as a result of which it is determined whether the authenticated user can access a particular resource).
If we talk about the work of Symfony Security in the context of processing an HTTP request, then authentication is performed in the process of passing the request through the so-called. firewalls, their task is to somehow determine what kind of user this is and form a token. The authorization process is built around the so-called. voters who "vote" for / against / abstained on the issue of "letting in / not letting in", there are a number of examples in the documentation . Hopefully the fact that voters can be arbitrary and have any logic of their own is pretty obvious. For example, the same ACL bundle just implements voter, which decides on access based on the ACL list (which, of course, can also be in the database), but in general this is a special case.