Thanks, that's great.

I'm new to access control, and "RBAC" seems to be what I am looking for. I was wondering if you could briefly state pros or cons or limitations or recommendations of 3 designs:

1. this one
2. phpGACL (PHP Generic Access Control Lists)
3. radicore (A Role-Based Access Control (RBAC) system for PHP)

#3 has a RBAC wrapped up inside a framework, and there is a licensing issue. So I may not be able to use that one, despite any merits of the logic (although Tony appears to have a sizeable background designing these things so I hate to dismiss it outright).

Whichever one I end up with I plan to port to CodeIgniter.

Thanks for any thoughts you may have.

I am aware of both these systems, but cannot give a detailed analysis of them since I only looked at them briefly about 2 years ago .... so some things may have changed.
At the time I was looking for a RBAC framework and downloaded/installed phpGACL. I played around with it, read the documentation but (call me slow if you like ;-) I just couldn't see how to make it work for my situation. It was actually after spending some time trying to understand the intricacies of phpGACL that I decided to make RBAC_bv.

Concerning Radicore, I remember reading Tony's pages and found them interesting. A lot of his work is worth reading, even if it is just to get a different perspective on tackling a problem.

The main aim I had when making RBAC_bv was that it had to be conceptually easy to understand and still flexible.

It had to be fast and efficient and cater to simple as well as complex situations alike.

90% of web apps only need simple role based access control mechanisms to deal with a user who has just logged in, such as 'is the user a member?' or 'is the user an administrator?'
Basically we just want to determine the role of a user. (i.e. member, admin, moderator etc...). RBAC_bv can do that very quickly.

If you look at the picture of the database design on the first post of this thread you will see that the whole design follows a pyramid structure with the roles defined at the top and the finer details defined at the bottom. So in essence you can drill down the pyramid to get finer and finer permission classification for the user.

RBAC_bv allows you to query the database at any point and retrieve all the information you need with just one query.
For example, you can find out with just one query:
- all the roles assigned to a user
- all the privileges assigned to a role
- all the domains assigned to a role
- all the actions assigned to a privilege
- all the objects assidned to a domain

which means you can also determine with just one query:
- all the actions a user can perform or not perform on any object.

conversely you can also find out quickly which users have a certain role and therefore which users can perform a certain action on a given object.

The key however to all this working nicely is taking time to think through the actions and objects you will be dealing with and grouping them appropriately together.


So in summary the advantages would be:
- Easy to understand (I hope ;-)!
- Easy to extend
- Can be used as a fine grained or coarse grained RBAC framework depending on your requirements
- Efficient and fast (However I have never run tests to see how it compares in speed to the other systems... any takers?)
- BSD license


Disadvantages:
- Not polished. The main purpose of this thread is really to share an idea, a concept that others can take and improve upon. That is why all the code is released under the BSD license. So don't consider RBAC_bv unless you are willing to get your hands durty ;-)

For anyone wanting to integrate RBAC_bv into their own framework, I would be glad to help in any way I can.

Hi Ben,

Just curious if you ever happened across LiveUser (http://www.gvngroup.be/doc/LiveUser/permission_complex.php)?

phpGACL seems to have been around the longest and allegedly has had numerous users. I'm a little surprised that none of these ACLs (phpGACL, LiveUser, this one) aren't more "organized" for lack of a better word. This is not in reference to the quality or merits of the class itself, but moreso the documentation. So like you mentioned in one of your earlier posts, I guess I'm a bit too slow as well and am not sure how to use the class, that's where your concept shines to me, it is easier to grasp looking at the ERD.

Do you have an idea how to implement user management in your system? That is, how to handle controlling administration rights of users? I have a situation where I might want to ability to have "admins" or "department managers" create users or assign rights to other users. The scenario comes to mind where you want to limit what rights could be assigned, for instance you would'nt want a "department manager" to be able to create a "super administrator" etc.

Yes, I came across LiveUser when I did my original research. I just quickly read through the docs and looked at their diagrams, but didn't do too much with it since it 'looked' complicated.
Admittedly, anything new looks complicated, but for some reason it just didn't click. That is why I like 'choice' in the open source world. There are more than one ways to achieve the same end result, it is just a matter of finding the one that works for you.

True. I can't comment on the other systems but as for RBAC_bv, the key, (as I have already mentioned before) is in the database design. If you take the time to study the design and play around with it you will see that you can retrieve any piece of information you want with just one query.
All the methods I have written are mainly SQL queries with a little post processing. If you looks at the code I have written you will see what I mean.

We must think the same ;-) However I am sure to many people the ERD would be more confusing.


Yes. In actually fact you already solved the problem without realising it. (Which reminds me I should upload a pdf document that explains what I am about to say.)
The privileges defined in RBAC_bv follow the rules of the english language. I won't go into this in detail because they are discussed in the docs. But to answer your question, you would create a role called 'department manager' you would then create an action 'create' and an object 'user'. You then link the action to the object in the 'rbac_roles_has_domain_privileges'. (i.e. it is just a record that states that the role 'department manager' is allowed to 'create' a 'user' object. (As opposed to not being allowed to perform a certain action))


This is precisely what RBAC_bv is designed to do. i.e. clearly define the privileges of each user group, so they don't conflict with one another.
In your case the object 'user' would be associated with the role 'simple_user', so that once a new user was created you could assign to them the role of 'simple_user' which would be defined as the right to 'view' the 'public_pages' object. (or whatever you want really.)

I hope this helps a little.

I have uploaded the docs here. Please note that these docs were written for a precursor of RBAC_BV which was called Authorize_bv. However many of the concepts are similar. Once you have read the docs please look at the examples in the zip file (which you can find on the first post), for things to fall into place.

I haven't included this file with the others at the beginning of the thread because these are not the 'real' docs for RBAC_bv but are only meant to help you grasp the 'concept' of the database design.

Attached Images

rbac_bv.pdf (148.1 KB, 175 views)

SO is it all done?

I really can't be assed making my own ACL thingy for PHP - I tried using one of the other rolled ones but it had errors in it.

This sounds good, just not sure if the files posted in the first thread are the complete deal is all.

Thanks

I get this error in MySQL 5.0.41 when viewing the rbac_users_has_roles table. I'm not that versed in index and unique setups in a MySQL database so I'm not sure entirely why this error would pop up and what it really means in the operational structure of the system.

Can anyone explain this to me and propose a fix if needed?

-Nathan

You can delete the INDEX keyword as UNIQUE fields are automatically indexed.
I will fix the SQL when I get back (I don't have the time right now.)

Hello,

at a glance, the system you have built up seems very elegant and efficient. However, it is not clear to me if it can perform more 'item-specific' role administration. Let me try to explain what i mean.

Say you need to make a newspaper site, with dynamic categories and articles, and want be able to have both super-administrator and super-moderator role (which would be permitted to perform appropriate actions on global level), but also category administrator or category moderator, which would have same permissions as global roles, but only on local level (meaning, within a specific category). Is this rbac system designed with these capabilities, and how would they be implemented, or administered?

Thank you for the response in advance.

It appears that the zip file is corrupt again. Can you that be fixed? thanks