goauthentik
Feature Request: Allow multiple parent groups
Is your feature request related to a problem? Please describe. Our current SSO directory structure is a bit unusual - we're not working with a tree of groups, but rather a DAG of groups. This makes management in many cases much, much easier, as you can re-use groups of people as members of other groups much easier. Think of central groups, that should be included in many other groups. I'm not aware of any Identity solutions that support this natively: Neither AWS SSO (our current solution, does not even support any nested groups), Keycloak (only tree-like structures with multiple child-references) or authentik (only tree-like structures with single parent-reference) support this.
If authentik would support group structures that resemble DAGs, it would be a stand out feature that allows much more flexibility in organizing your directory.
Describe the solution you'd like The simplest solution would be to allow multiple parents on a single group. A solution that would be more easy to navigate is to instead allow multiple children on a group, without the restriction of a group having at most one parent (compare Keycloak).
Describe alternatives you've considered Our current solution to this (while still on AWS SSO) is to manage this DAG externally and render it out to simple groups without hierarchy. We want to get away from this. Another option would be to directly assign central groups to bindings where required, but this would take away many of the comforts that you get from nested groups. In our special case, nested groups would become almost useless in that case.
Additional context https://goauthentik.io/docs/user-group/group#hierarchy https://www.keycloak.org/docs/latest/server_admin/#proc-managing-groups_server_administration_guide
Just looking for this as well. Similar setup, but thinking more about Roles for staff. Here is a basic example
Groups Linked to Apps
- grafana_ro
- grafana_rw
- git_ro
- git_rw
- vault_ro
- vault_rw
Roles
- role_it
- role_dev
I would to setup the following relationship. That way when I onboard a new user I just need to put them in Group/Role that is the position. Down the road if I add new app (newapp_ro, newapp_rw) I just need to add those to the role_* and people currently in the role are granted permission.
role_it
- grafana_rw
- git_ro
- vault_rw
role_dev
- grafana_ro
- git_rw
- vault_ro
I very much support those ideas! I'm desperate for an easier group/role management, that would make our onboarding/enrollment process much more convenient.
+1 for this. Coming from FreeIPA, this is the only feature I'm currently missing.
+1 as for me as well! It would make it so much easier to edit and maintain premissions in bluk. As there been any work around or progress on this so far?
This is not something we're currently considering due to the challenges in saving the data in a format where querying would still be performant enough.
I'm not too fussed about losing the LDAP group structure in Keycloak, although Keycloak itself supports nested groups. If performance is a concern, can't group membership be cached? I assume I'm missing something obvious.
And if we can’t cache it, wouldn’t it be possible to “compute” group rights only on update?
for example:
- basic : has access to resources
A, andB - extended : is a child of
basicand has access toC.
Then any change to basic would result to updates for basic, extended, and any groups extending them.
Then updating it would cost a bit of time since you have to recurse. But after that you wouldn’t have to cache at all right? Or am I saying something completely stupid and outrageous?
For me this is a very important feature. Coming from Active Directory, I honestly considered it so fundamental that the possibility this was not supported did not even cross my mind. In its current state, I do not see how Authentik can be used to manage large userbases with hundreds of different jobs, if every user has to be assigned to multiple groups by hand.
The application_role -> job_role mapping for groups is very prevalent in many orgs I have seen. Example: grafana_editor has as member backend_developer and frontend_developer. postgresql_editor has as members backend_developer.
This makes it very straightforward to both map actual application permissions to groups as well as users to permissions.
The current solution would be to define this mapping in terraform. Basically maintain a list of group memberships for "backend_developers", "frontend_developers", etc. If this can be done as a pre-processing step in an external tool, it should also be possible to do within Authentik natively. Maybe call it a groupSet instead of a group.
I would also like this, as already in my head the order of inherence for groups doesn't klick or make much sense. For me a CHILD inherences the properties of a parent, not a parent the properties like members from the child. From a natural understanding, if I would add members to a group "parent" and set in group "child" the "parent" group as a parent and attach the "child" group to a application, the members of the "parent" group have access to the application.
But currently it feels inverted and not intuitive to have parents inherent from their children. I have just 9 Users but that already feels like a hassle for 8 applications.
Consider using Entitlements
This may be a good compromise, as you can bind entitlements to groups in a many-to-many relationship. The two pain points with them are that they are application specific, so you have to create duplicate entitlements (such as login or admin) for your applications, and that the user interface is not ideal right now (you cannot see what entitlements a group/user could receive) - but that one is fixable.
Just labelling to prevent closing automatically, doesn't mean we'll implement it.
