> I followed most of the article that you wrote on your site and the
> document that you published about Authorize_bv, but there is a couple of
> things that I do not get.
>
> Firstly, the data model that you provided with the article does not seem
> to allow/disallow certain permissions directly to the user. What I mean
> is that lets say the user belongs to a "moderator" role, that has "read"
> access to "all_pages", how would you take read access away from this
> user without making modifications to the role "moderator"? I see you use
> something similar to this in the PDF document of Authorize_bv, but I
> fail to see how it will fit in the current data model.
>
Yes, Authorize_bv did this on the 'user' level, which means each user would have personal privileges assigned to them. Even though it seems at first more flexible it is not efficient and requires more database entries. That is when I moved to the role based approach. Rather than assign privileges to each user, you now assign the privileges to a 'role' and then each user is assigned a role. This makes it a lot more flexible to modify and administer. (i.e. instead of changing each users priviliges, which could run in the thousands..., you now only need to change one role definition.)

The way to achieve your aim using the role based approach is to create a new role called 'moderator_read_disabled' and give it an importance greater than the 'moderator' role. You could then define the new role as 'read'action 'disabled' on 'all_pages'.
You then assign this new role to the users (i.e. moderators) you want. Since it has a higher importance than the standard 'moderator' it will take precedence, but only for the 'read' action that affects the 'all_pages' domain. The other moderator privileges will work as normal.

> How would you handle groups of users? Lets say we have 10 users in a
> department, and these 10 must have access to "moderator". Is there some
> functionality to allow me to put these 10 in a group and then assign the
> "moderator" role only to the group?
>
This would be easy to implement. All you would need to do is instead of assigning roles to individual users you would assign roles to 'groups'. If you look at the first image on this thread you will see the second table from the top is called 'rbac_users_has_roles'. Instead of storing user_ids you would store group_ids and just change the field and table names accordingly.

You would also need 2 more tables to define your groups and another to keep the many-to-many relationship between the users and the groups. However if these tables already exist in your system the rbac_bv class can easily be integrated into it.

This would only require minor changes to the API, namely changing a few field names and table names in the SQL queiries.

> I would like to see what your final product looks like as I am also
> doing some research in this area. I also went through LiveUser, but to
> be quite honest, it looks a bit dodgy and heavy. I like your version
> more, but I am just curious about the above questions.
>
I hope these explanations help. Please feel free to ask more questions.
In reality there isn't much to a role based access control system. Once the database design is done all you are really doing is querying the database to find out if a user can peform a certain action on a given object.