Add user-specified groups to the LDAP server

[jimcavoli]

The Cloudron LDAP server already presents a memberOf overlay in its user records, including cn=users,ou=groups,dc=cloudron and maybe cn=admins,ou=groups,dc=cloudron depending on the user's role on the Cloudron side.

The memberOf property would return CNs for all groups, both Cloudron-internal and user-added of which the record is a member. Ideally, the groups tree should be searchable as well and would return all the user-added groups..

This feature would allow for automatic mapping of users to groups/roles/permissions in a growing number of Cloudron applications, as well as simplifying the ongoing management thereof for administrators.

[nebulon]

This comes up again and again. As you correctly mention, the memberOf is set for users. This is however not ideal so far, but was only replacing the Cloudron specific isAdmin property we used to set. I think @mehdi remembers that.

Please note that what is put in the memberOf is actually a role, not a group membership. Although not all roles like owner and usermanager are set here but only admin or user.

Now for the groups as such, we initially had the groups correctly exposed via LDAP but we found pretty quickly that groups, used in Cloudron for access control mostly, usually do not map well with groups and their meaning within apps. Furthermore the meaning of what groups are between different apps often gets confusing. So we decided against exposing the group membership to the apps, since we didn't see much value but mostly confusion. To add to this, changing group membership within Cloudron hardly ever gets correctly propagated within apps, which may even then produce security implications if not well understood by the admin.

[girish]

I think we made a mistake exposing this "meta" LDAP admins group initially. IMO, it's a great feature is Cloudron admins and app admins can be in sync but the issue is that most apps don't support group sync and thus the admin status goes out of sync as well.

I think what might be great is something a little different:

• When creating a group, we have a flag whether it is a LDAP group as well. This is only needed because I don't know how apps behave when groups come and go. Like if I shared with LDAP group in nextcloud and the group is deleted in Cloudron, not sure what happens.

• Leave it to the user to maintain mapping and not automate group mapping setup in the package. This is the key part. By putting responsibility on the user, they need to have an understanding of the limitations. When we automated admins, we took the responsibility and couldn't keep up the promise.

This feature will help things like osTicket which relies on LDAP groups to setup agents and other roles.

[jimcavoli]

I totally understand the caveats, and this discussion is just what I was hoping to get to with the ask. I think that it being the user's responsibility to configure group mappings if they want to use that feature is a very reasonable approach that strikes the right balance of maintainability and functionality. It's worth noting to people that it's an advanced thing you should only be working on if you know what you're doing and that it's not something that Cloudron can or should support beyond basic information about how the LDAP server side works.

A lot of this varies app-to-app, and frankly, I think it's appropriate to leave the nuances of the choices a user might make about how those apps behave to said user. Some apps are super powerful here, like Metabase, which can basically automate all of the role/group assignments for you if configured right, ranging all the way back to EspoCRM, which is basically non-existent in its support for group mappings besides basic login filters, which is already better handled by Cloudron anyway, and plenty of others like osTicket that are somewhere in between.

I think good points have been raised about the security concerns and sync issues, and it's worth making it clear where the line is on what's provided vs. what's possible. Furthermore, as packages update into the future and more support for group mappings is added, it would be unreasonable imo to expect Cloudron packages to anticipate everyone's preferences/needs. Patterns of use will vary hugely based on how the systems are deployed and by whom. The points above all sounds like you've gotten a pretty clear idea over the years of this one coming up about how to equalize the flexibility and clarify the boundaries for expectations with such a feature, all of which sound exceedingly reasonable, whether groups are implicitly all LDAP or explicitly configured in or not (minor detail to my mind).

[jdaviescoates]

Even if we could just get LDAP groups working with Nextcloud that'd be a big win imho given how many of us use Nextcloud (I think I'm correct in assuming it's the 2nd most popular app on Cloudron?)