I hope this is the correct SE site for this kind of question.

My team is currently developing an application which IMO needs access control beyond RBAC. Users can have access rights to entities based on several factors e.g. the administrator of a company is implicitly granted admin access to subsidiaries.

To allow abstraction from this complex, domain specific access control logic on the resource level we are planning to put a service in place which will simplify this to (subject,object,permission) queries.

My first question is: Do you think this is a valid approach or would you place more domain-specific checks inside the resource/controller layer of the application?

Assuming that we do put the abstraction layer in place the second part of my question is as follows: Should we store all the implicit and explicit access rights in the access control for quick retrieval or rather have the system calculate implicit/derived permissions on the fly?

If we do the computation during write/update and only store explicit permissions we can then use some standard implementation like Shiro to handle the checks. If we do the computation on retrieval we will have to basically code everything our self.

On one hand I'm a bit reluctant to do a lot of computation for each request. But I'm way more afraid of having stale access rights (either false positive when forgetting to delete implicit grants or false negative when forgetting to update on change in corporation structure).

So where do you recommend to put the domain knowledge?

  • By calculate implicit/derived permissions on the fly I guess you mean calculating the access right implicitly during the business logic execution. As part of the business logic. Right? Opposed to the idea of precalculate the rights for a quick resolution in run time.
    – Laiv
    Commented May 14, 2019 at 11:01
  • @Laiv Exactly. This part of domain knowledge would have to be put into the AccessControlService anyway and either be used once per update or during every query. And somehow the "once per update" approach feels error prone. Commented May 14, 2019 at 11:05
  • Do you expect the access control rules to change frequently? Are you afraid of these changes to happen when users are executing operations? On the other hand, does performance matters to you?
    – Laiv
    Commented May 14, 2019 at 11:34
  • The rules will get more elaborate over time and we will have a mix of implicit and explicit permissions. Also a change in company hierarchy or a reassignment might need to wide change of access rights for some person. Commented May 14, 2019 at 11:40

2 Answers 2


Your idea to use a service to hide the access control complexities is entirely valid. Doing it otherwise risks that the complex logic gets spread around and possibly duplicated and at the same time you would be violating the Single Responsibility Principle for the controllers.

With regard to where to put the domain knowledge of the access control, I am of the school that having a couple of hammers in your toolbox does not make nails the ideal way for fastening stuff bar none.
Standard components are good if they fit within your requirements, but if there is friction or a gap, then you should either adjust your requirements or create a custom solution.

In this case, that most likely means creating a custom solution (which could be derived from something that already exists; no need to do everything from the ground up). This component should be designed such that it is easiest to get the right behavior. And only after it has been proven to work and proven to have performance issues should you look into ways to make it more efficient.


You need externalized authorization also known as attribute based access control (). Attribute-Based Access Control (ABAC) is actually what you are looking for. In ABAC you write policies that state what can and cannot happen. and are the two ways you can write policies. The good thing about this approach is that you can always change the policies without rewriting your API.

I posted a lengthier response on StackOverflow, which might help you.

You can also read more on XACML and ABAC here:

You will need to deploy an interceptor (policy enforcement point) in front of the JAX-RS service you want to protect.

  • We opted to use an annotation syntax similar to the one in Apache Shiro (like company:create:id1:employees) combined with a request interceptor and an application specific AC service to resolve the access control checks. That way we can now either annotate a REST endpoint with an @Allowed annotation containing the constraint with patterns matching the path variables or directly query the service in case further detail (e.g. from the message body or query params) are needed. If coding the resolver becomes to cumbersome we might switch to an external solution. Commented May 31, 2019 at 7:57
  • Sounds like you're on the right path! Commented May 31, 2019 at 11:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.