More Than 32 Roles/Permissions Symfony2 Security System?

3
votes

Everything in Symfony2 looks pretty good however there is one issue I can't seem to find a solution too. The issue is that Symfony2's security component is limited to 30-32 roles/permissions. One of my projects, a project management/issue tracker system, is going to need more than 32 permissions. There are a number of different components of the system that need to have there own set of permissions. Just because someone has create, read, update, or delete permissions to issues does not mean they have those permissions for projects, milestones, etc... Each component is going to need its own create, read, update, and delete permission not to mention component specific permissions and there is no doubt I will reach the 30-32 roles/permission limit.

I have questioned in IRC and the mailing list with no really direction of where to go. I would prefer to be able to just added this functionality on top of the existing security component (preferably through a bundle). I am not sure how I can achieve more than 30-32 roles/permissions with symfony2's security component.

I would really prefer not to have to development my own security system w/ ACL.

3
securitysymfony
But this is exactly the use case for ACL. You can start using the built-in ACL system today! It's quite easy to modify/extend as well to best suit your needs. - kgilden
I guess I forgot that the ACL does allow you to setup permissions globally (based off classes) instead of just direct objects. I will give it a try and see what happens. - ryanzec
Looks like I am going to have to role my on security bundle w/ ACL as I really want it to be stored in MongoDB and Symfony's security ACL component seems like MySQL only - ryanzec
are you sure? MongoODM is mentioned to be supported. It's written here in the grey tooltip. - kgilden

3 Answers

4
votes

as stated before in the question comments by gilden:

But this is exactly the use case for ACL. You can start using the built-in ACL system today! It's quite easy to modify/extend as well to best suit your needs.

For beginners, I think it's best to read these articles from Symfony2 official book in the following order:

  1. Security - Including info about: Authentication and Authorization, Users & Roles, Access Control in Templates & Controllers
  2. Access Control Lists (ACLs) - Including info about: Bootstrapping & configuration, Creating an ACL, an ACE, Checking Access & Cumulative Permissions
  3. Advanced ACL Concepts - Including info about: Design Concepts, Database Table Structure, Scope, Pre- & Post-Authorization Decisions, Process for Reaching Authorization Decisions

There are also some interesting question here at SO.com about Symfony2 ACLs

Good luck!

4
votes

I think you kind of misunderstood the acl system you can only create 32 kind of role, but by domain object. This is done using bitmasks operations on integers ( this explaining the '32' limitation as an integer is ... well you know the answer ).

So for example the permission to delete one object would be same - 'MASK_DELETE' - for a project a milestone or a ticket. So if you used the ProblematicAclManagerBundle you would just have to do :

$aclManager->addPermission($ticket, $userEntity, MaskBuilder::MASK_DELETE);

or

$aclManager->addPermission($projet, $userEntity, MaskBuilder::MASK_DELETE);

to give your user permission to delete $project or $ticket for instance. It also creates the acl entry for the domain object and the entry for the user if they are not already there. What I need to know though is if you can create different masks names for a class, or every class of a bundle ?

You will find a deeper explaination on acls here

0
votes

I know this is an old post, but I just wanted to share this with anyone who has a similar answer.

The key to providing a solution is in this sentence in your question:

There are a number of different components of the system that need to have there own set of permissions.

For each of these components you could create a separate voter.

  • Create a class that extends AclVoter.
  • Override the supportsClass() method to make sure the voter will only vote for classes of the component it is meant for.
  • Create your own PermissionMap containing the set of permissions the component needs.
  • Pass the PermissionMap to the AclVoter in your services configuration.
  • Tag the voter as security.voter so the AccessDecisionManager will start using it.

This should get you a long way.

I also recommend going thought the code of the ACL Component, there are a lot of features that unfortunately aren't documented.