Consider a scenario in which you offer service access based on a hierarchy of authority. i.e., a HEAD can register his subordinates. The authenticated HEAD has the previledge to read and update data from all of his subordinates. Is there an authorization standard or pattern that relates to this scenario?
Different roles may be assigned to the HEAD and subordinates, and they could be distinguished with scopes in standard OIDC. With this, we can ensure that only users with specific responsibilities have access to certain APIs and properties. But, even with the aforementioned, how can we prevent privilege escalation? i.e. Prevent a given HEAD from querying other HEADs' subordinates?
One option that springs to me is embedding the subordinate IDs within the JWT Token itself. However, I do not believe that this solution will be scalable or generic enough. i.e. if a co-HEAD is introduced and the subordinates are large in number? It also requires granular code level (Microservices level) validations, which cannot be performed at the gateway, making the system fragile.
Are there any generic, scalable patterns to handle this, ideally any standards that Identity Providers can easily support?
For standard JEE webapps, there is container-managed Role-Based Access Control. It is not hierarchical, but a given user can be assigned multiple roles, so you can - with careful attention to roles and application design - do what you want. Note that the primary security function of JEE container security is to block access to unauthorized URLs, thus denying the functions behind them, but there are methods in the JEE Request API that can also control access via explicit application logic.
For example, take roles like these:
auditor - can access URLs that allow generation and reading of reports. Cannot control the system or modify data.
clerk - can enter and maybe correct data
manager - can access URLs that determine what others can do and when
application administrator - can run maintenance functions and do other things that control the apo
system administrator - can run functions related to the purely IT side of keeping the app usable
executive - All URLs can be accepted if you have this role, so anything you can do in the webapp can be done by the executive.
This is actually more precise than a strict hierarchy and it makes it much easier to know who to blame when a function is mis-used.
On the other hand, in a larger enterprise context, you might have something like selinux, that does allow different access levels (although that's not something that's used much outside of military systems). Since most Java systems can tap intto wide-scale security environments, you might be able to establish a suitable mapping.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
Listen. That's my theme music. That's how I know I'm a super hero. That, and this tiny ad told me: