I have an existing application with users, groups, roles and projects. I am now in the process of migrating our user database to keycloak, but am struggling to understand what is the best practice for keycloak authorization setup based on my scenario. These are the fundamental requirements:
A user can create one or more projects.
A user from one group can access and edit projects from other users in that same group.
A user with role admin can access and edit all existing projects.
How should I set up the resources, permissions and policies?
Is it best practice to have one resource for each project, e.g. project/{projectId}? In my case, this would lead to thousands of resources, and also the need to synchronize resources during creation and deletion of projects. But if this is the way to go, I am wondering how the policies should be structured based on my requirements. Do I need to have one group policy for each existing group, and link the policy for groupA to all the resources where owner is also part of groupA and so on? Also this would probably lead to a giant access token, as a user might have access to hundreds or even thousands of projects?
Is it better (or even possible) to have one common resource that represents all projects, and then apply a "dynamic" policy to this resource? One example of this could be to have a custom policy that compares userId from token with the userId provided as context, and then grant access depending on whether the ids match, they are part of the same group or so on. If this is possible, I could perform a request to keycloak like so: "Does {token} have access to project owned by {userId}?" when a user tries to access a project from my API. I have already tried to create a custom java SPI policy that should do this check, but I am now lost in understanding how to perform a request to keycloak with the extra userId as context. I am not even sure this is possible.
Are there any other options that would work better?