I had to change quite some things to make it work on my system.
What I would like to say at the moment is that the sql needed to be adjusted.

rbac.sql:
line 91:
id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
line 98 (I don't think this one is necessary):
CREATE INDEX id ON rbac_roles(id);
line 106/107:
roles_id INTEGER UNSIGNED NULL,

I might get to the other stuff I changed sometime soon. : )

I have seen in this thread that people look for groups, and that they dont see the privileges very clear.

its posible that you call "roles" to what are really "groups"(user groups) and that you call privileges to what could be really Roles?

A user belongs to groups, and a role i understand like a collection of actions, a possible behaviour.

Thx ben.

Yes and no. If your system is simple then you would have a one to one relationship between a "role" and a "group". However when things get complicated a "group" could be defined by more than one "role".

If it makes more sense then feel free to make a new table called "groups" (but you can't rename the roles table as group as they are different concepts).

Also if you area looking at a "user group" solution this rbac implementation might be too complex. If all you want to to know is whether a user is part of a group you would only need two database tables.

No. A role is a singularity whereas a "group" is a plural.
Let me try and explain with a soccer example. You can define a soccer team as a "group" of players belonging to the same club. Within that group you have different "roles". A striker, defender, captain, goal keeper. Each of these "roles" have various privileges. Some are the same others are different. For example the goal keeper has an extra privilege and that is he can pick the ball up with his hands if he is in his box. The captain also has extra privileges.
So you can have users that are part of the same "group" but they can also have different "roles".


I think you need to look at this rbac from the user point of view. The most important question this rbac system allows you to answer is "Is this user allowed to perform a certain action on a given object"

I believe the way you are looking at this is the "group" is defined, and you then just want to check wether a user belongs to a group. So the focus is now on the group an not the user.

A "role" is a collection of admissible or forbidden "behaviors". It links an "action" to an "object". Again in our soccer analogy, the goal keeper is allowed to "hold" [action] the "ball" [object], whereas the other players are only allowed to "kick" [action] the "ball" [object].

Hope this makes sense....

I understund it now.

Thx ben for the detailed answer.

I've followed this thread for a while as it seems to be one of the central resources on the web for a good overview of the RBAC problem - good work Ben!

I have a question for you guys though... How would you go about fine-tuning the *type* of access to an object...?

For example, say Director user Mike can override Reception user Sally's registration date. One would assume that Mike could set any date both in the past or in the future - the traditional GRANT/UPDATE/EDIT privilege. Then we have Payroll user Steve who can also modify Sally's registration date, but only for dates in the past up until (for example) one year ago. To spice things up, then we have the HR Manager user Mary who can also amend Sally's registration date, but only for dates from one month ago up until one month from now...

The point of that example is to highlight that sometimes it's not enough to authorize access to an object, but that the object itself may have further access restrictions depending on the Role, which need to be flexible - what if we wanted to change the HR Manager role so that they could only change the date from now up to exactly the 12th June 2008?

Does anyone have any ideas of how to map that into the object or indeed record those parameters in the database???

Thanks!