Modeling Authorization Layer, Object Types, and Role-Based Permissions in Warrant

[vstepanyuk]

Hey Team,

I am in the process of modeling an authorization layer for our application and I find myself in need of your advice. My main objectives are effectively managing permissions for specific roles and users, accurately modeling "object types", and ensuring that permissions are assigned to roles per object in Warrant.

To paint a clearer picture: We have an object (such as an article) that is associated with a user carrying a specific role, for instance, an "Owner". We also have other users with roles like "Readers" and "Editors", each possessing distinct set of permissions. Furthermore, it's essential to mention that a user does not have a global role, but rather, a role associated with each object. Besides this, users may have individual permissions, such as create, edit, update, or delete.

My aim is to establish a mechanism whereby I could query the Warrant API to verify if a certain user (identified by their userID) is authorized to perform a specific operation (like 'create') on a particular object (identified by the object type and object id). Importantly, these permissions should be associated with the role per object in Warrant, not globally.

In addition, I'm seeking guidance on how to model "object types". What are the best practices for designing and structuring these object types in our particular context?

I would highly appreciate your guidance on structuring this request to the Warrant API using only the userID, object type, object id, and the operation the user seeks to perform. Furthermore, any insights or recommendations for modeling object types and effectively assigning permissions to roles per object in Warrant would be tremendously beneficial.

Looking forward to your invaluable insights and suggestions.

[akajla09]

Hey @vstepanyuk,

Thanks for the detailed description. If I were to summarize, I believe what you're looking for is a hybrid of fine-grained (object-level) and RBAC (role-based) access control.

First, looking at your example, here's how I'd express a basic 'article' object-type within Warrant:

"article": {
    "owner": {},
    "editor": {
        "inheritIf": "owner"
    },
    "reader": {
        "inheritIf": "editor"
    }
}

This representation defines an 'article' type with 'owner', 'editor' and 'reader' relations (or roles). The inheritIf attribute allows us to specify that any subject (user) having an 'editor' relation to an 'article' also has the 'reader' relation and any subject (user) having an 'owner' relation has both the 'editor' and 'reader' relations implicitly defined.

With this object-type defined, you can create warrants such as:

[user:1] is an [owner] of [article:x]
[user:3] is a [reader] of [article:x]

Which would yield the following checks:

Is [user:1] an [owner] of [article:x]? // true
Is [user:1] a [reader] of [article:x]? // true
Is [user:1] an [editor] of [article:x]? // true
Is [user:3] an [editor] of [article:x]? // false, user:3 is only a reader

If your checks only take user/subject, relation (role) and object into account, this object type should be enough to build out full fine-grained authz. However, it seems like you're also implying that your use-case references an additional layer of abstraction (permissions/operations) like 'create', 'update', 'edit' and 'delete'? Is it only these 4 permissions or are there more/a variable amount?

Regardless, you can add these 'operations'/'permissions' directly within the 'article' object-type as well:

"article": {
    "owner": {},
    "editor": {
        "inheritIf": "owner"
    },
    "reader": {
        "inheritIf": "editor"
    },
    "edit": {
        "inheritIf": "editor"
    },
    "update": {
        "inheritIf": "editor"
    },
    "delete" {
        "inheritIf": "owner"
    }
}

Now, with this updated object-type definition and using just the 2 warrants described above (user:1 owner of article:x, user:3 reader of article:x), you'd be able to issue the following checks as well:

Does [user:1] have [edit] on [article:x]? // true
Does [user:1] have [update] on [article:x]? // true
Does [user:1] have [delete] on [article:x]? // true
Does [user:3] have [edit] on [article:x]? // false
Does [user:3] have [update] on [article:x]? // false
Does [user:3] have [delete] on [article:x]? // false

Let me know if this makes sense for your use cases.

[vstepanyuk]

Would it be possible dynamically define permissions as object type (like built-in object type) and manage it through admin ui?

[akajla09]

Yes - you can create/manage object-types as well as add/remove permissions from your object-types (relations) dynamically via the API or dashboard.

However, editing object-types via the UI is different from the RBAC flow in the UI which has additional screens for adding/managing roles and permissions. We don't currently have a similar UI for permissions on object-types. If this is what you're looking for, I'd be curious to get your thoughts about how you'd expect that UI to work?