Global rules for API

Question

I am Developing a backend of an web application, I want to create something like global rules for user authorization for example:

user() has edit to org() if user.id == org.owner

this means every user can edit every organization if they have the ownership of it, Is there any good way to implement this to our webapp API?

I've tried ABAC but not satisfied our need, also I am not even sure this is the good path, But we want our authorization system to be scalable.

Answer 1

Some years ago you could have tackled this challenge by either writing all of the authZ logic yourself or by utilizing the tools that did a combination of authentication and authorization.

Today, however, there are more than a couple of solutions that tackle the authZ realm. In terms of scalability and ease of use (among some other things) I strongly recommend checking out the cerbos.dev. It's an open source tool that does pretty much what you're looking for - authZ at scale, and enables you to make policies such as the one you described (and much more complex ones too).

Depending on your stack, the installation details might slightly differ, so I strongly recommend checking the quickstart manual.

But as per the policy you're trying to define, what you'll end up needing is something like this:

---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"

  resource: organization
  rules: 
  - actions: ["edit"]
    effect: EFFECT_ALLOW
    roles:
    - user
    condition:
      match:
        expr: request.resource.attr.owner == request.principal.id

The above represents an example of a yaml file that defines a Cerbos resource policy (resource in your case is an organization for which you want to create a policy rule).

And all your codebase would have to do is trigger an API call (via a proper SDK or directly) of a CheckResources endpoint, documented here - for which all you MUST provide are 3 things: a resource (the organization in question), an action (edit in your question example), and a principal object (the user which is trying to edit the org).

P.S. It all lives on your end (self hosted solution), so no need to worry about your users' data going to someone else’s servers or security challenges like such.