I implemented something like this in a NAC company I founded (Lockdown
Networks)...
define('OP_GLOBAL_ADMIN', 10);
define('OP_ADMINISTRATOR', 20);
define('OP_OPERATOR', 30);
define('OP_EUM_OPERATOR', 39);
define('OP_READONLY', 40);
//[dv] only set the TRUE values, FALSE is implied.
// OP_GLOBAL_ADMIN && OP_ADMINISTRATOR permissions are all
TRUE by default, no $role array needed (yet).
// follow the 'P_group_action' naming convention, check for
existing keys before creating new ones.
//[dv] When you create a new P_permission,
// add it to this OP_READONLY operator role so we have a
master list to reference.
$role[OP_READONLY] = array(
'P_about_button'=> TRUE,
'P_switch_delete' => FALSE,
'P_switch_add' => FALSE,
'P_switch_test' => FALSE,
'P_switch_save' => FALSE,
'P_ops_view'=> FALSE,
'P_vlan_add'=> FALSE,
'P_vlan_check' => FALSE,
'P_vlan_save' => FALSE,
'P_vlan_test' => FALSE,
'P_device_audit'=> FALSE,
'P_device_add' => FALSE,
'P_device_save' => FALSE,
'P_device_import' => FALSE,
'P_device_delete' => FALSE,
...
$role[OP_OPERATOR] = array(
'P_about_button'=> TRUE,
'P_device_audit'=> TRUE,
'P_device_add' => TRUE,
'P_device_save' => TRUE,
'P_device_import' => TRUE,
'P_discovery_run' => TRUE,
'P_daterange_delete'=> TRUE,
...
/**
* Check the permissions of a given button to see if this operator (User) is
allowed to use it.
*
* @access public
* @paramstring $role array hash index
* @return boolean
* @author Daevid Vincent [dae...@]
* @since4.6.0.0 (Folsom)
* @version 1.2
* @date 08/01/07
*/
function checkGUIPerms($index, $user = null)
{
global $role;
if (!$user) $user = $_SESSION['user'];
//[dv] we have to call this out explicitly because the
OP_READONLY->is_admin() is true.
if ($user->type == OP_GLOBAL_ADMIN || $user->type ==
OP_ADMINISTRATOR) return true;
return (($role[$user->type][$index] == TRUE) ? TRUE : FALSE);
}
Then in each web page, just do something like this:
The more astute people will notice that this doesn't lend itself to user
defined roles as they're all hard-coded, but in our case that's all we
needed. However, it could be expanded and written/read from a database with
the same concept. Say with a table of role types (Operator, Admin, User,
Custom, etc.) and another master table of "P_*" roles and a third to 'join'
them. Pretty straight forward SQL.
The only trouble with the bitmask version Bastien mentions is that you have
to have a master bitmask map somewhere. Plus those numbers can get pretty
huge. A 255 character binary number is significant. Plus in a large
project, you can run out of space with 255 chars, the other SQL text/blob
column types are less efficient I'd think. But ultimately the concept is
the same as you're just using binary (true/false or 1/0) to determine if
someone has that particular grain of role flavored goodness.
ÐÆ5ÏÐ
"Some people, when confronted with a problem, think 'I know, I'll use
XML.'"
Now they have two problems.
> -Original Message-
> From: Bastien Koert [mailto:phps...@gmail.com]
> Sent: Monday, January 25, 2010 4:49 PM
> To: Abah Joseph
> Cc: php-db@lists.php.net
> Subject: Re: [PHP-DB] Role Based Access Control and Role
> Based Security
>
> I developed an implementation that combines roles with fine grained
> access. Each role is given a set of permissions ( the current set is
> global to the app, the next will be per application) in it, I specify
> a db field ( varchar 255) that holds a binary permission scheme. I.E.
> 10001 etc where each value is an on / off 1/0 permission
> set. This is mapped to a constant for each position so that each
> module can have a set of permissions like ADD, DELETE etc.
>
> This scheme then controls the menu / buttons to produce a workflow for
> the application.
>
> Bastien
>
> On Monday, January 25, 2010, Abah Joseph wrote:
> > Hi list, thank to the won
