Is there a simple, general rule-based access control implementation?

Question

I implement access control on an intranet site. It would be easy if the company did not have more than 200 employees and user permissions for almost everyone. This is crazy, I know, but I can't change it.

So, I tried to find a common implementation that would meet my needs, but could not find it, so I went to do it myself. In the end, I came up with a fairly general solution that made me think: someone should have done this before!

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

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

The STOP rule has the following attributes

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

An object relation can be: owner, creator, revisor, etc. This field is not required to support general tasks. When it is there, the relationship between the current user and the object instance is computed by the delegate. The current relation is then compared with the desired rule relation to allow or deny access.

Let me know if I have not been clear enough.

Two questions arise:

• Is there an open source implementation like this?

• Do you see any problems that I encountered after this path?

EDIT: I went ahead and actually started implementing this model. The first problem was that I needed a connection between the object and the object to support any use case. Now I can save the following rule:

John (topic) can (permission) change (task) (object), if he is the creator (relation) of order.

Please, can you guys use a REALISTIC use case that could not be expressed with this model?

Answer 1

Regarding the actual availability of one table with group permissions of certain roles and the use of another table for extended permissions that will override the general ones. If so, if only access to someone, why also mention that each other cannot? As in the last example given in the comment above: is there a table with permissions. The entry looks like this: 1645 edit_some_field. Then group_permissions looks like this: 1645 everyone false , and the resulting exception table will be 1645 (Jane Doe ID) true .

If, say, there are 50 people who have edit access to this field, then you simply add another group to the group table, for example: 89 editors_of_field_X , put the identifiers of people in the group_members table, as 89 (John Smith ID) true . And then in the last step you can redefine those who have permissions of one person, as I mentioned above. So, in conclusion, you will have a three-layer scheme. All-group man. And the deeper you go, the higher the significance that this role has. For example, if everything is not allowed, but the group you are in is allowed, you can edit something.

In addition, if you are not allowed third-party access, then again you become an exception in the group. This way, you can reuse groups for the subsequent addition of only minor changes.

Answer 2

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