Rob Graham - PHP Developer

Introduction

There are a number of security managers around for PHP so you may be wondering why I chose to write another but if you read my blog about security and permissions you'll have a good idea. To recap breifly though it was written because all the existing security managers, that I could find anyway, worked fine for simple permission models but failed when the model became more complex. You could not, for example, handle very well the ability to grant a user the permission to add users but restrict them to only adding within the same group they belong to.

The security manager will look very familiar to you if you have a Java background as it is based on a subsection of the java.security package with the addition of a Restrictor interface. This restrictor is what allows you to grant something like a 'user permission' but limit what that permission allows you to do, like for example only allowing users to be added to the same group as the user performing the action. I will go into more detail on these restrictors later in the manual, but first I will explain the basic principle of how the permissions work.

Permissions

Everything in the security manager is based around permissions, you grant permissions in a particular security role and you check for a permission before you perform some security sensitive action. Each permission is a PHP class in its own right and must be a subclass of the abstract class "Permission", which looks like this...

If we take a look at the constructor we can see that there are two arguments, $name and $actions. The first argument, $name, can be used to identify something in particular e.g. an absolute path to a file for the File permission or a type of user in a User permission and the second argument $actions is an array of strings describing what actions that permission implies, like $name they can be anything you like e.g. 'add', 'delete', 'login', 'update', 'load' etc. When granting a permission you can use wildcards, the wildcard character is an asterix (*) and can be used in both $name and $actions allthough it must still be in an array for $actions. If a permission is granted with wildcards for both the $name and $actions parameters then any permission checks of the same type will suceed, e.g. if you grant the User permission with wildcards and the manager performs a check for the User permission with the name parameter as 'admin' and the actions as 'update' then it will pass the check.

Creating your own permissions

As we have already discussed to create your own permission you must extend the Permission class which resides in the file security/class.Permission.php, all permissions you create however must go in security/permission or any subfolder to as many levels as you like.

This security manager has only been partially used in the CPDcast.com project I worked on and there are only 3 permissions so far, but I shall go through them and show you how it's possible to create more.

Here is the current layout of the permissions:

security/class.Permission.php [abstract base class]
security/permission/user/classs.UserPermission.php [UserPermission]
security/permission/report/class.ReportPermission.php [ReportPermission]
security/permission/podcast/class.PodcastPermission.php[PodcastPermission]

Each new permission you create must extend the base Permission class and be in its own file named in the format 'class.[class name].php'

Lets say we have an ecommerce system and there is a need for a security role in the system that allows users to manage items in the inventory, to allow this we will create an 'ItemPermission' class that we will place in the file 'security/permission/item/class.ItemPermission.php', the code is shown below.

As you can see to create a basic permission is very simple, if you want to make a more complex permission like one that when granted will also imply several other permissions then you could do this by overriding the 'implies' method which we will cover in more detail later.