Special authorization logic. Where should this logic be located and how should it be architecturally organized?

Question

ASP.NET

The system has many restrictions (authorization and validation rules).
The logic related to data validation and data consistency is located in services with business logic (Example: the start date must be less than the end date, events must not overlap in time, etc.).
But there are still access restrictions that are performed not only on the basis of the user's role, but on the basis of certain calculations, the state of the data in the database.
There is a certain schedule of events and a trace. authorization logic:
- If the user is not an admin and the event has the status "Cancelled" or "In preparation", disable editing. Otherwise, allow.
- If the user is not an admin and the event was held more than a month ago, disable editing. If the user is the author of the event, then allow it.
I'm not sure what is the right way to weave user information into services with business logic for such calculations. In addition, it would be more convenient to perform these checks in the controllers in order to generate the correct error messages, rather than throwing a bunch of exceptions from the services.
It would be desirable to distinguish between responsibility (assign the task of authorization to some other services).
At the moment, these are regular services with the *PermissionResolver suffix.
Perhaps there are some proven practices for implementing such functionality?