sfGuard and Implementing Security in Symfony…
Creating web-based applications using Symfony is extremely simple. This is something I stated last month in my post Symfony : Who Needs a Development Team?
Over the last 2 months I have created all modules that enable alpha release level functionality and at the moment I am attempting to secure the system.
This is where the true mental arithmetic begins. Creating the modules and UI for them in Smyfony is easy. Securing them is a different matter altogether. Security is one of the most difficult aspects of the appliciation to design. Getting it wrong can result in major issues.
Luckily, Symfony has an active community that will help as and where they can - which is great when learning how to get the best out of a framework. This same community has provided many plugins for a vast array of uses and this adds extra value to the use of Symfony. One plugin that initially caught my eye was sfGuard. Here is the sfGuard description :
The sfGuardPlugin is a symfony plugin that provides authentication and authorization features above the standard security feature of symfony.It gives you the model (user, group and permission objects) and the modules (backend and frontend) to secure your symfony application in a minute in a configurable plugin.
After installing the plugin via the instructions here I quickly discovered that it secures at system level. System level security is great for applications that have very generic user groups - but most applications aren’t like this.
I need item level security. This allows me to specify specifically what a user can and cannot Create, Edit, View or Delete. If I have a multi-site blogging system and an Editor is assigned to each site (much as an Editor is assigned to one magazine or newspaper) - Having a system level securitiy implementation means that groups are created like this :
- Editor
- Journalist
- Proof Reader
Having 3 sites means I should have 3 editors - one for each site. Giving each Editor the “Editor” privilege doesnt prevent them carrying out “Editor” functionality within each others site. This is one area where sfGuard falls short.
In creating a secure solution I am in half a mind whether to extend the sfGuard plugin to meet my needs or create an inhouse solution of my own. Extending the plugin or creating an inhouse solution means the alpha release date has to be put back. Also - extending a plugin is a bad idea as it means that any extension to in, in its current version, could be made redundant if a new version of the plugin is released.
Decisions, decisions…
on November 12th, 2007 at 1:03 am
[...] sfGuard and Implementing Security in Symfony… [...]
on November 27th, 2007 at 10:29 am
Really good and really interesting post. I expect (and other readers maybe :)) new useful posts from you!
Good luck and successes in blogging!
on November 27th, 2007 at 9:19 pm
Thanks for dropping in WildKid!
I am glad you found the post interesting. If you want me to cover any topics - just let me know…
on November 27th, 2007 at 10:27 pm
Hi,
It would be very appreciated if you can say smth about sfPropelActAsNestedSetPlugin. I’m banging my head against the wall on this issue. Thank you and keep up the good work.
on November 28th, 2007 at 2:56 am
I encountered same fate on symfony… and made decision. That is to extend sfGuard, having not enough time to code security module for the system and at the same time cant wait for the possible extension of this plug in. Which made my project not qualified for any update on the said plug in. Mine consists of multiple application sitting on a single symfony project. And my requirement is to have application/module/record level security. I extend the sfGuardPermission, sfGuardUser, and sfGuardGroup, add sfGuardApplication and sfGuardAppModule module. Now every user can have group and/or user level permission (sfGuardPermission). Permission is defined as add, edit, delete, view access (flags) to a module on each application…
sneak in to my project… http://demo.8layertech.com:88 , admin/8layer
on November 28th, 2007 at 9:55 pm
Hi pangkalizer!
I like what you are doing there. You have really capitalised on the admin generator’s functionality. Have you created all that yourself or are you in a team?
How much development time have you put into it?
I am really interested in what other developers/companies use symfony for.
I have adopted a different approach to managing the user credentials. I’ll make a posting about it when I get the time.
on November 28th, 2007 at 10:00 pm
@StefanM …
What issues are you having with sfPropelActAsNestedSetPlugin?
I havent used it before but from what I read here
… It seems like a handy plugin.
In what context are you using it?
on November 29th, 2007 at 12:06 am
actually theres two of us developing the system… the other one is a freelancer… while im the lead programmer. we started this internal project last july which aims to be productized and bundle to a Nitix server. Our progress was kinda slow for couple of months though one coz of some other client projects.
yes that’s the admin generator which i also made some modifications… it was good template for customizing your own generator.
on December 10th, 2007 at 4:07 am
you might find this thread interesting…
http://www.symfony-project.org/forum/index.php/m/41272/#msg_41272
on January 17th, 2008 at 5:54 pm
pangkalizer> hi, what about providing your changes to sfGuardPlugin as contribution to the plugin or at leaast as a unofficial patch? I think there are more people who need more complex securing their applications (as me
and have same dilema as mcnicholl… thx
on January 17th, 2008 at 7:33 pm
Yeah - thats an excellent Idea.
Trouble is - the lines of “I am being paid to do this” and “open source in the enterprise” are not ones that are crossed often.
I’ll write a post about this sometime - but essentially firms are of the rightfully selfish mindset of “I am not giving away what I have just paid for”…
Have you ever tried to push your company to release their product as open source?
on November 5th, 2008 at 9:43 am
[...] Symfony, security, plugins Visit site [...]