Hello, I am setting up Incus with OpenFGA and Keycloak for a school project. Our users and groups are managed natively inside Keycloak, and due to project constraints, we cannot use an external LDAP or Active Directory server.
In OpenFGA, our permissions are given to groups (by granting access to a group rather than individual users). However, it appears that Incus does not automatically pass OIDC group claims as contextual tuples to OpenFGA during permission checks, meaning group-based access fails.
I am aware of the existence of the openfga-sync tool for LDAP, Active Directory, and Rauthy, but since it doesn’t target native Keycloak databases, I wanted to ask how the community handles this.
How do you typically sync or manage group-based access in OpenFGA with Incus without an LDAP layer?
I don’t have any Keycloak environments left at this point which is why we only have Rauthy (upcoming IdP for IncusOS), Zitadel (current IdP for Linux Containers and Zabbly) and AD/LDAP (commonly used by customers).
The general model should work fine for the sync_groups mechanism at least, effectively adding support for providing Keycloak credentials and having it synchronize the groups with the member list from Keycloak.
The sync_roles mechanism could possibly work too but I don’t remember how that part works in Keycloak as ideally for that mode to be useful, you’d want a mechanism to store metadata as part of the Keycloak role (as Rauthy does by storing JSON data), making it possible to directly tie OpenFGA tuples to a role within the IdP itself.
Not sure what that would look like. OpenFGA is very very simple by design, it’s really just an API to ask “can X perform Y on Z” where X, Y and Z are simple single word identifiers.
So the only thing you need to integrate OIDC and OpenFGA is knowing what X (the user) is.
That’s configured through the authorization.oidc.claim setting, so you’d typically pick email or preferred_username or something, then the rest of the OpenFGA tuple is dictated by what you’re trying to access.
Incus itself doesn’t push authorization tuples into OpenFGA, all it pushes are the various objects for those tuples to refer. It’s on your (or a tool like openfga-sync) to populate the authorization tuples within OpenFGA.
Currently there’s no real enforcement of that split in responsibility, partly due to lacking restrictions on the OpenFGA side of things. But in an ideal world, you’d actually prevent Incus from being able to write authorization tuples, preventing a somewhat compromised Incus from being able to mess with the authorization entries. In larger enterprise environments, you may have separate teams in charge of identity (authentication) and access (authorization), themselves distinct from the virtualization team running the platform. Each being in charge of their own part of the story is often a good idea to provide a secure environment.
