Typically, I place authorization decisions in my server side controllers. These have been RESTful endpoints recently, but I think the same stands for MVC type architectures. For the sake of argument assume that it's role based authorisation. A protected method will be annotated or make checks and return 403s if necessary.
Now, given that authorisation is in fact a business rule - "only administrators can list X" for example, I'm thinking they should be pushed down a layer. When a controller asks the business layer to perform the operation, the service or business layer informs the controller it's not authorised.
Is this a reasonable approach? Are there disadvantages to this?
I'm loathe to have an AuthorisationService that essentially holds a bunch of static procedural coded rules to do this but maybe it makes sense to keep all access logic in one place. Is it a cross cutting concern that should be kept separate?
So I'm asking if anyone has done this and how they achieved it in a clean way or if there are any good resources I could read. I'm using Java fwiw but this is a language agnostic question.
I've checked out the related questions on here and they're very thin on the ground and answers. For example: Validation and Authorisation in Domain Models and Carrying that through a Service Layer to MVC
I'm reading the spring security docs which make some good arguments for it being a cross cutting concern, but I'm worried it's just the "spring way" and would like wider perspectives. It also ties your application to a specific framework.