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…

Categories: ALM, Programming, Requirements