Fantasy: Your client has an incredibly simple, intuitive, and cohesive ACL schema in mind. Permission and group names make sense, never change, and current users perpetually encounter properly restricted behavior. While we’re at it, you’re also able to code one-handed while scuba-diving the Caymans.

The Cold Hard Truth: Permission names are inconsistent, Groups are changed and reassigned, and your poor users are left dangling somewhere between “Why can I see the administrator’s Social Security Number?” and “The ‘Donate Large Sums of Money’ page is giving me permission denied!”

I created a simple solution to this problem with a few new symfony tasks now available via csSecurityTaskExtraPlugin. In a nutshell, the plugin allows you to more easily visualize the security coverage of your application. Here are some examples below:

$ ./symfony app:security frontend

App Security

The app:route-security task compares your security.ymls to all the routes in your application

$ ./symfony app:route-security frontend

Route Security

You can also list who has access to which actions specified in security.yml with the group-security task.

 $ ./symfony app:group-security frontend

Group Security

Pass the name of an sfGuardGroup object as the second argument to narrow down your output

 $ ./symfony app:group-security frontend author

Group Security

List users who has access with the user-security task.

 $ ./symfony app:user-security frontend

User Security

Pass the username or id of an sfGuardUser object as the second argument to narrow down your output

$ ./symfony app:group-security frontend andyadministrator
OR
$ ./symfony app:group-security frontend 3

User Security

It’s fairly basic right now. The product of a few hours’ work and a desire to get something new out into the community. What other enhancements would you like to see to give you more/better control of your site’s security coverage?

csSecurityTaskExtraPlugin: Untangle Complex Security Confusion

07 Feb 2010

4 comments

  • NiKo - February 8, 2010

    Neat. What would be great would be to have some ability to script|configure full security test suites using a matrix like the one in the task output, or a yaml file, maybe a sfSecurityTester or something approaching… The idea would be then to have web security test coverage integrated with lime results.

    More fun: could be fully automated; you know the users, the groups and perms, so all user credentials; you know the required credentials configured for all controllers within an application. Iterating over all members, challenging every controller access with their credentials should be “quite easy” (well, you know what I mean here).

    Random rough thoughts, handle with care.

  • NiKo - February 8, 2010

    Just a thing, it looks that the plugin won’t introspect security from plugins modules which are enabled in an app…

  • admin - February 8, 2010

    Ahh, this is an edge case I did not consider.

    As for your suggestion about automating tests, you could even have a parsible text file a la:

    - Users of GROUP group can access MODULE / ACTION
    - Users with PERMISSION permission cannot access MODULE ACTION
    - User USERNAME can access MODULE

    And automate from there. Similar to Cucumber (http://cukes.info/) for ruby, but more specialized.

  • NiKo - February 8, 2010

    Yes, that would be a fantastic feature to have in symfony, but a little be trickier to implement.

    In a first (but somewhat consequent) step, just having to type app:test-security (or more simply test:security) to check all the configured security rules against user/credentials defined in the model *automatically* would just be amazingly useful :)

Add comment