Authorization in a multilayer system

[humbertoc-silva]

Hi all,

Multilayer system was the best term that I think to describe my use case. I am struggling to define the best way to apply authorization to a system composed of some layers, for example:

• Presentation layer (mobile apps, web apps, etc.)
• Business rules layer (intermediate systems with very specific business rules)
• Core layer (core systems that are common to a lot of business systems and store the most valuable information)

mobile app -> business system A -> core system
mobile app -> business system B -> core system

After some analysis, I reached two different approaches:

1 - Put fine-grained authorization rules in business systems

In this case, the fine-grained authorization will be applied in business systems, that is intermediate systems. I think that in this way the rules and data will be more compliant with the domain. In contrast, the generic rules will be applied in core systems because the more granular ones were applied before. The problem is that the core systems must trust the business system and this could be a risk.

2 - Put fine-grained authorization rules in core systems

In this case, the fine-grained authorization will be applied in core systems, that possess the most valuable information, this way I have total control over the way the resources are consumed. In contrast, the generic rules will be applied in business systems. The problem is that the request must travel over all layers to find out something is not authorized, and the complexity will be elevated on the core systems because I will bring rules and data from many different contexts and domains.

At the end of the day, it is a trade-off and there is no correct response for this, but I appreciate your opinion and ideas about this case. Maybe there are alternative ways to handle authorization in a multilayer system that I really would like to know.

Thank you!

[anderseknert]

This is a great topic!

I think in general, authorization in recent years has more and more moved from the "gateway model" — where checks for identity and permissions have been performed at the outer perimeter of a system only — towards a zero trust security model, where the same checks are performed everywhere. If that can be accomplished, that would generally be preferable, I'd say. Some common hurdles preventing this model include:

• Latency budget. While querying OPA for decisions is generally fast (a few milliseconds), the total amount of requests add up, and may prove to be too expensive for the system as a whole.
• Memory requirements. If all systems need to store large amounts of permission data in-memory, the total amount of memory required for authorization could prove prohibitively expensive.

I've blogged some about potential workarounds for this in the past, and I believe some models would be interesting to look at more closely. Would appreciate hearing from others too!

[humbertoc-silva]

Hi @anderseknert,

Thank you for your contribution! I read your post and got some ideas from there, mainly from item 4 because it could deliver security and performance. I imagine that it would be possible to hash the authorization context (headers, body data, etc) in some way and put it on the OPA's signed token and the subsequent layers must validate de token and check if the context remains the same comparing the request and the token hash. For example:

Business System A:

• Invoque OPA passing the request as input
• Opa authorizes the transaction and responds with a JWT
• The JWT contains a custom claim where the value is a hash of the resources that were authorized to be consumed.
• The JWT is propagated to the next layer

Core System:

• Invoque OPA passing the request as input (this time with OPA JWT)
• OPA checks the JWT validity
• OPA calculates the hash from the request and compares it with the custom claim
• If the comparison success, the transaction is authorized

This was an example to demonstrate that we can explore the JWT custom claims to express what was authorized before.

[anderseknert]

Indeed! If performance is of outmost importance, I would probaby consider not even sending the JWT to OPA in the subsequent services, but just have those applications check for — and of course verify — the JWT coming in from the OPA in the first service. If no JWT is present, only then would OPA be consulted for a decision. While it does require more logic to be written inside of your applications, those are commonly the type of compromises one would need to take in order to meet such requirements.