Module permission vs role permissions in silex - symfony

Question

I'm quite confused about the ACL in symfony/silex and how I can make them work for me.
I've been thinking about a solution based on modules -> actions. However, reading about ACL, everything seems to be based on roles, which is to broad for the implementation I'm trying to achieve.
I will have users, and all users do belong to a role (admins, users, etc...). However, the role is more of a guideline of what you can do (as it sets the default permissions a user with that role starts with) that an actual set of actions a user can perform. The actions, are really based on the modules the system has and the permissions that are actually granted to any of the users to read, add, update of delete and any other verb outside of those.
So for example:
ROLE #1: Is an Admin
can read users
can post users
can put users
can delete users
ROLE #2: Admin
can read users
can post users
cannot put users
cannot delete users
Since I'm planning to have several diferente modules (users, payments, products, etc..), and each admin can have privileges granted or revoked, they will not fit the ROLE_ADMIN, ROLE_SUPER_ADMIN, ROLE_USER type of roles.
I was thinking something on the lines of ROLE_VIEW_USERS, ROLE_ADD_USERS, ROLE_EDIT_USERS and that a User will probably have 100 of those little roles and have voters for each controller that will decide if you can perform certain action.
Does this make sense?

Answer 1

You are confusing ACL and roles. They both have to do with permissions but they approach and function differently from one another.
Roles aren't inherently tied to a specific resource. On the other hand, ACL is, and that link is persisted. Users can be tied to resources (or appear to be so) through the use of voters.
https://symfony.com/doc/current/security/voters.html#creating-the-custom-voter
User-specific ACL, e.g. where a user has specific access defined PER resource, you'll need quite a bit more stuff.
Take a look at the SF cookbook:
https://symfony.com/doc/current/cookbook/security/acl.html
https://symfony.com/doc/current/cookbook/security/acl_advanced.html
OWNER/MASTER/OPERATOR CAN
Edit
View
Delete
Create
ALL RESOURCES (This is done using ROLES)
ROLE_USER CAN
EDIT OWN
VIEW OWN
DELETE OWN
CREATE
OWN RESOURCES (This part is done with ACL or voter)
Voters are effectively creating your own ACL and therefore there is no persistent permission unless you make one explicitly (At this point I would go ACL). The use case for ACL is basically the same as the use case for a voter, and choosing one vs the other is a matter of complexity.
The built in ACL info is coming from the database, but as per SF documentation: "It can contain tens of millions [of records] without significantly impacting performance."
Extremely simple? Could use a voter.
If you don't want to maintain your own rules (voters) for resources and don't mind the complexity of the ACL, or like that permissions are persisted + cached, you could use ACL instead.
Note that the complexity of the ACL is generally the following when creating resources (although this could be put in a service):
$aclProvider = $this->get('security.acl.provider');
$objectIdentity = ObjectIdentity::fromDomainObject($resource);
$acl = $aclProvider->createAcl($objectIdentity);
$tokenStorage = $this->get('security.token_storage');
$user = $tokenStorage->getToken()->getUser();
$securityIdentity = UserSecurityIdentity::fromAccount($user);
$acl->insertObjectAce($securityIdentity, MaskBuilder::MASK_OWNER);
$aclProvider->updateAcl($acl);
For the previous scenario, you can use the ROLE_USER to make sure that the authenticated user is actually an actual user and not AUTHENTICATED_ANONYMOUSLY and the voter or ACL to make sure they can only edit their own resource, and override this if their ROLE is ROLE_ADMIN. (Assuming users are given ROLE_USER once they sign up)
Example in security.yml
# This could be done via #Secure(roles="ROLE_USER")
access_control:
- { path: ^/my/api/endpoint, role: IS_USER, requires_channel: https }
- { path: ^/my/admin/api/endpoint, role: IS_ADMIN, requires_channel: https }
Example in controller::action
// check for edit access
if (
false === $authorizationChecker->isGranted('EDIT', $resource) &&
false === $this->get('security.context')->isGranted('ROLE_ADMIN')
) {
throw new AccessDeniedException();
}
Here is another QA in StackOverflow that also provides some examples:
Symfony 2 ACL and Role Hierarchy
You can also use annotations for this stuff:
https://symfony.com/doc/current/best_practices/security.html#authorization-i-e-denying-access (It shows how one works vs the other).
Let me know if any part of this requires further explanation.
Thank you.