How to design an access control system for an application?

Question

Access rights

Briefly at first)
Good day!
I ask for help with the design / redesign of the access control system. Or choosing a ready-made one, choosing libraries, patterns, whatever.
Now in detail)
What is an
Application with a large number of connections between data, rest api written in nodejs using the loopback.io framework . The application is already in production, but is actively developing - new models, fields, connections are added weekly.
What you want
1) Allow user actions (reading, editing) according to the following criteria:
- belonging to the current user - example: the action occurs with the event model, it has a connection with the manager from the client side (contactFromCustomerId), if it is the current user, then this action is allowed to him.
- belonging to a different model to which the current user belongs - example: the action happens to the event model, the current user has an association with a company, the event has an association with a user who has an association with a company, if the companies are the same, the action is allowed.
- fields that are affected by the action - example: a user with this role is allowed to view only a part of the fields of the event, and update one in general.
- the state of the fields of the model to which the action is addressed - for example: an event for the current user can only be edited in the new status.
- the state of the associated model fields - example: the user can only update the fields of the estimate model if the event associated with the estimate has the new status.
The criteria can be layered on top of each other, for example, the user can edit only certain fields of the estimate model and only when the event belongs to his company and is in the new status.
Criteria can and will be new.
2) Allow users to create rights themselves, enable / disable existing permissions.
3) Create permissions that control the visibility of content - for example, manager0 working in the system should see information in window A, manager1 should see the same information in window B.
What was
Considered n number of libraries where access control systems are implemented.
Read about ACL.
We decided (perhaps erroneously) that none of the implementations suits us and we will write down our own within an acceptable (just erroneously) time frame.
What is/What has already been done with it
Permissions are handled in a separate library.
Permissions are only positive. (allow to do something)
Permission meta information is stored in configs, configs are located next to the file describing the model, example:

{
  // ... ,
  "event_create": {
    "remoteMethod": [
      "create",
      "upsert"
    ],
    "httpMethod": [
      "post",
      "put",
      "patch"
    ],
    "modelName": "Event",
    "actionType": "write"
  },
  "event_read": {
    "remoteMethod": [
      "find",
      "findOne",
      "findById",
      "exists",
      "count",
      "get"
    ],
    "httpMethod": "get",
    "modelName": "Event",
    "actionType": "read"
  },
  // ...
}

Users have many roles, a role has many permissions.
For each user action, an object with a description is generated, for example:

{
  "remoteMethod": "get"
  "httpMethod": "get",
  "modelName": "Event",
  "actionType": "read"
}

The action is compared with the user's permissions, which we obtained from his roles.
A decision is made whether to prohibit the action, modify (send not all the fields of the event, but only a part), or allow.
Often the result of prohibiting / modifying a user request is to change the request filter in the database.
For example, the user requests /events , he can only see his events, the request to the database by default will be in our case { where: {} },
after access control { where: { contactFromCustomerId: "id of the current user" } }.
The current problems
are the gigantic number of permits and it is increasing.
especially due to overlapping criteria - for example, we,
in addition to statuses, we introduce types of events and want to allow / prohibit work with certain types in a certain status.
It's hard to work with so many permissions. Users don't want to fill them all.
is the overall complexity of the system. This is partly, of course, a consequence of the implementation, but thoughts often gnaw - maybe everything was poorly designed from the beginning?
- performance - due to the large number of criteria based on the data of other models, it is necessary to request a large amount of additional data
- there are doubts about the correctness of access control by changing the query in the database - on the one hand, we do not receive unnecessary data, on the other hand, requests can be very long and they turn out terrible.
The questions themselves

• Surely someone has faced similar issues. Would like to hear how you got on with it?
  
• Are we doing something wrong? What?
  
• What do you think about shamanizing the user's request?
  
• A huge number of permits - is this the norm?
  
• To group permissions for users, create a permission that includes the rest, or make a purely visual grouping for users?
  
• Maybe there is a pattern that tells how to steer access control, but I somehow missed it?
  
• Maybe even have examples?
  

I would be grateful for any help)
PS The question is big, there is a lot of context, I tried to describe everything that is needed to understand the situation. If it didn't work,
please write about it.

Answer 1

https://en.wikipedia.org/wiki/Attribute-based_acce...
https://habrahabr.ru/company/custis/blog/248649/