Is there a simple generic implementation of rule based access control?

Question

I'm implementing the access control of an intranet site. Which would be easy, if the company didn't have 200+ employees and custom permissions for almost every one. It's madness, I know, but I can't change it.

So, I tried to find a generic implementation which would meet my needs, but couldn't find it, so I went to do it myself. In the end, I came up with a fairly generic solution which got me thinking: someone must have done it before!

I called it STOP (Subject Task Object Permission) Access Control. I have the following relation:

.-------.     .-----------.     .-------.
| users |1---*| STOPRules |*---1| tasks |
`-------'     '-----------'     '-------'

A STOP Rule has the following attributes

STOPRule {
    Subject;
    Task;
    ObjectType;
    Permission;
    Relation;
}

The object relation can be: owner, creator, revisor, etc. This field isn't required, to support generic tasks. When it's there, the relation between the current user and the object instance is calculated by a delegate. The current relation is then compared with the required relation on the rule to allow or deny the access.

Let me know if I wasn't clear enough.

Two questions arise:

1. Is there an open source implementation like this one?

2. Do you see any problems I would encounter following this path?

EDIT: I went ahead and actually started to implement this model. The first problem was I needed the relation between the subject and the object to support any use case. Now, I can store the following rule:

John (subject) can (permission) edit (task) an order (object) IF he is the creator (relation) of the order.

Please, can you guys provide a REALISTIC use case that couldn't be expressed using this model?

Answer 1

John created an order and wants to let Bob view it.

Answer 2

What about actually having one table with grouped permissions by certain roles and use another table for extended permissions that would override general ones. If it is the case of let only John access something, why also mention that each other person cannot? Like for the last example you provided in the comment above: do there is a table with permissions. A record looks like: 1645 edit_some_field. Then group_permissions looks like: 1645 everyone false and the final exception table would be 1645 (Jane Doe's ID) true.

If, let's say there are 50 people who have access to edit this field, then you just add another group in the group table like: 89 editors_of_field_X, put the people's IDs into a table group_members like 89 (John Smith's ID) true. And then on the final step you can override those with single person's permissions as I mentioned above. So in conclusion you would have 3-layer scheme. Everyone-group-person. And the deeper you go the higher importance that role has. For example if everyone is not allowed, but the group you are in is allowed, then you can edit something.

Moreover if you aren't permitted with an access on the third - person - level, then again, you became an exception in the group. This way you will be able to reuse groups for later, only adding minor changes.