Web application security model?

Question

Kohana

Once again, I wanted to compose something that would be flexible on the one hand, and relatively simple and not cumbersome on the other. I looked at ACL mechanisms and the like for a long time, and came up with this:
make inherited security descriptors for each site object. Well, i.e. the descriptor itself is just a set of "user/group -> privileges". The whole snag is in inheritance and efficient storage and use.
Well, i.e. Let's take an example, a forum: we have sections, there are topics and there are posts. It is worth noting that these are 3 different entities and it is impossible to directly inherit privileges over the forum on the post: it is clear that if I have the right to edit the forum, then I have the right to edit the post, but vice versa is not true in the general case. Then the question arises - from what to inherit the rights to entities of different types that have not yet been created?
The advantages here, I believe, are obvious, because all sorts of features like pre-moderation (remove the read flag for users) or topic curator (add a specific user with elevated privileges for a specific topic) do not require finishing at all, but are simply possible by design.
Cons actually in the mechanism of inheritance and effective use of descriptors: from whom to inherit newly created entities? From the point of view of efficiency - how to make selections based on descriptors, well, so as not to pull out extra data from the database with subsequent additional processing by the engine.
I plan to implement it on Kohana3.
Has anyone seen implementations of such things? Under the subject or just separately. If there is an alternative comparable in flexibility, please tell me where to dig?

Answer 1

It's a bit confusing, but I hope I got the point right.
Speaking in the context of KO3, then IMHO, its Auth module is fully expanding in the described direction.
There, the user is assigned roles. Then the user group with the login role can be assigned certain rights in each model.

Answer 2

Usually, it’s like this: User
groups - for them, basic security settings
Users - individual settings delegated from groups, a user can be in several groups
Action tree - hierarchical crap, from the root to the branches, their checkboxes are safe. New branch - inheritance from the root, etc.
You can do it quickly using recursion and caching.

Answer 3

It is possible to try to hang up akl on routes, IMHO. I have ACL, not at the record level, but at the access level to the route + action, and the binding goes to the set of groups in which the user is a member. There are 3 default groups, Admins, Authorized Users, Anonymous Users. Then there is a f-I that receives a route as an input, and a list of groups, and gives out whether there is access or not. In general, hang up the rights to the group and nothing more. if you hang both on the group and personally on the user, a lot of hemorrhoids. And such functionality, where the user personally needs something unique to prohibit, is extremely rare. And if he appears, make a group for him, and bring him there.