• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

Authorise access to hierarchical data

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Saloon Keeper
Posts: 24210
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Listen. That's my theme music. That's how I know I'm a super hero. That, and this tiny ad told me:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic