Ivan
Ivan

Reputation: 789

Granular authorization for accessing database objects

What is the best architectural approach for the use case example below:

  1. Domain model contains Company, Department, and Position.
  2. Company can have multiple Departments. Department can have multiple positions.
  3. Any user can have three permission levels for every entity - "Admin", "Write" or "Read".
  4. If user has "Admin" access to Company - then he has admin access to any child entity. If the user has "Write" access to Department then any Position in the department inherits that access right.
  5. Objects must be stored in the persistent storage like relational or document db.

As far I understand OAuth scopes are not applicable for use cases above. One way is to store all data (including permissions) in relational database and query it using joins every time. Another way is to have some external system like LDAP that is going to store relations between entities and manage their permissions. Entities itself are still stored in some database.

Both of options above do not look too attractive for obvious reasons. In the first case, you end up having too many joins. In the second case, you might have a hard time managing data integrity across two systems. Also, it violates single source of truth principle.

The use case must be typical for software development, but I have not found any "best practices" advice for this use case. I will appreciate any suggestions or references to external resources.

Upvotes: 1

Views: 344

Answers (1)

David Brossard
David Brossard

Reputation: 13834

The best practice is to use externalized authorization management (EAM).

Externalized Authorization Management offers a more granular way to manage access within an organization. (Gartner)

EAM gives you:

  • attribute-based access control (ABAC) i.e. access control that uses parameters (attributes) of the user, the resource, the action, and the context rather than just defining access control in terms of roles or permissions
  • policy-based access control i.e. a set of policies that bring together attributes and define what can or cannot happen. For instance:
    • managers can view their own company profile.
    • no one can edit a company profile if it is ready-only.

In particular, ABAC provides you with an architecture which decouples the layer you want to protect (an app, data inside a database...) from the authorization logic. This means you can evolve your app independently of the authorization and vice versa. XACML is the de facto implementation for ABAC.

All your requirements end up being expressed as policies.

Upvotes: 1

Related Questions