Best way to model per-resource/per-relation authorization

Hi all,

In our backend service, we have authenticated APIs that will perform some actions on a given entity. That entity E has different types of relations with a user (e.g. OWNER, REPRESENTER, etc). So, for example, user Alice might OWN entity E1 and REPRESENT E2, meanwhile user Bob might OWN E2.

We are trying to figure it out what is the best way to model the authorization checks for those entities, based on Auth0 roles and permissions and on those relations. Let’s say that both relations above would authorize the same action on the resource (e.g. entity:manage). We can think of two approaches:

  1. We have a single permission entity:manage, that both roles OWNER and REPRESENTER have. When a user is authenticated, we check if it has the entity:manage permission and, if yes, we check the set of all entities it has access, based on its role(s). If the user has role OWNER, we take all entities with relation owned-by with that user. Similarly if the user has role REPRESENTER.
  2. We have specific permissions tailored for those relations, like: entity:manage:owned-by and entity:manage:represented-by. An OWNER would have the former and a REPRESENTER the latter. So, upon authenticating an user, we can check the entities it has access to based solely on the permission(s) them have, not having to look for the role.

Right now, there is a high correlation between those specific permissions described on #2 and the roles that would have those permissions. We are still not sure if that would hold for the future, although we don’t have a use-case right now for different roles sharing those same, specific permissions.

Is there any obvious choice considering best design practices for such auth logic? Is there anything specifically bad in using the role at application level for narrowing the authorization of specific resources? Or, on the other hand, is there anything inherently wrong in having more specific permissions (that might, at some level, resemble the relation also being expressed in the role)?

Thanks a lot!

Hi Thiago @tcoraini

If I understood correctly your backend resource service needs to know both the role and permission to filter the right subset of data.

Ideally, the resource service should only know about permissions otherwise the benefit of the separation between permissions and roles is diminished. Both approaches in my mind are similar, so I would go for your option 2.

A more general way to solve this would be with what I call resource filters . See
Role assignment with resource filters . In this case your role would be Owner/Representer permission would be manage and filter would be some representation on how to filter the subset of resources for a Owner/Representer/other....

Hope that makes sense. Looks like we have similar use cases :slight_smile:

1 Like