Krishna Sunuwar

phpBricks saves roles, resources and permissions in database which looks following (more to come later):

Update: RBAC model has been changed. This one is new model.

Last week, I wrote blog about RBAC architecture in phpBricks (http://tinyurl.com/rbac1). Today, I am going to give little snapshots about coding implementation. As you already know, RBAC is a component, but it is special provisioned component which works with core phpBricks. There is quick option which tells whether to apply RBAC or not. If you decide to apply RBAC set code in configuration like:
define('_RBAC', 1);

When RBAC is applied, an instance of RBAC is available in controller and views, but not in model classes. RBAC is not relevant in model because models are not supposed to contain any business logic. It is very much important to understand how each function is accessed to understand how RBAC determine authenticity. Each resource (or function) is identified with set of parameters, called CMA. Suppose you want to see list of users, that means calling index method of users. For that CMA parameter looks like (‘c’=>’user’, ‘m’=>’users’, ‘a’=>’index’).

In RBAC, permissions are assigned to roles not to users. Users inherit permission from their roles. So checking permission is done with combination of provided CMA parameters and roles. There is function called isPermission which takes 5 parameters. First three are CMA, fourth is primary_key (for advance business rule), and fifth is roles. Last two are optional.

For example, if you want to check that whether current loged in user has permission to see list of users or not:


if($this->Auth->isPermission('user','users','index'))
{
// code to list users
}
else
{
// sorry permission denied.
}
This works from view and controller.

Roles of user is collected at time of login and stored in session, which is available in $_SESSION['__userroles']. So if you don’t pass roles parameter, phpBricks suppose current user. Now your turn to think how do you check permission of a users who is not loged in.

———-

This blog is intended to alpha users of phpBricks. Thank you guys, you are source of energy. Thanks for suggestion, exceptions.

Role Based Permission Control (RBAC) is widely used security module in the industry, including Oracle, Microsoft Exchange Server (some form of it). When MAC and DAC unable to address business rule, a concept of RBAC is brought into practice.  In this model, users are not assigned permission directly but acquire from their role(s). Role, which is created for job function in organization and each role are designated to perform set of operations. En employee can perform operation, which is assigned to his/her role(s). So, it is pretty straight forward.

I have implemented lightweight form of RBAC (lightweight is my personal terminology). It’s lightweight because it exactly address need of web application. RBAC itself is very huge while implementing whole features, it’s like giant elephant. In phpBricks, RBAC is included in user component. As shown in figure bellow, it consists of Users, Roles, Permissions and Resource Registry (Operations).

• Users: Subject which access application. A user can have multiple roles e.g. Forum editor and CMS editor.
• Roles: Job title which consists list of operations (job). Roles can be two type, black list or white list (allow list or deny list)
• Permission: Indicate approval to access resources.
• Resource Registry: List of operations (action, also called method) which is grouped into component and module. Method represent actual operation or function where component and module are packges. phpBricks is smart that it collect all components, modules and methods, then build registry automatically so programmer don’t need to worry about accounting all these.

How to define?

From back-end when you access RBAC, it shows matrix of roles and resources (operations). Simply you can tick on check-box to allow or deny access. One important thing to remember is that role type. By default all operations are allowed in black-list role and all operations are denied in white-list roles. So by selecting operation under black-list role, you are banning access, but in white-list you are allowing.

How it works?

Resource is always identified by three parameters i.e. component, module and actions knows as CMA (fourth is optional i.e. primary key for advance business rule). So, whenever user try perform certain operation, based on CMA phpBricks authenticates.

What next?

Checking permission on realtime basis while access request is made, can cause performance to be slow. So, I am thinking permission caching technique.

Recommended reading:

Role-Based Access Control by David F. Ferraiolo (can be found it in Amazon)

Note:

In above text, following terminology may be confused while used interchangeably.

Operation=Function=Resource=Action=Method