Restricting user visibility to own group members (LDAP, ACL?)

Apps & App Center
, , ,
#1

Dear Community – how is it possible to make a UCS user “see” and search for only the members of their own UCS group? This is a frequently occurring scenario - for instance to separate workgroups or school classes. Example:

  • UCS group1: User11, User12
  • UCS group2: User22, User23

In all apps, 11 and 12 should see/find each other, but not 22 or 23 - and vice versa.

My primary use cases are Nextcloud and Kopano with OpenLDAP controlled by the UCS server they’re installed on – it’s be good to have a solution at least for these apps.

By creating an openldap ACL script, it’s possible to successfully limit visibility for ldapsearch, bound to a user; for example:

access to filter="univentionObjectType=users/user"
        by self break
        by set="user/gidNumber & this/gidNumber" break
        by set="user/kopano4ucsRole & [user]" none stop
        by * break

But this seems to have no effect on Nextcloud and Kopano (which might use their own logins to trawl the LDAP user directory?). All users can find each other in Nextcloud contacts and the Kopano Global Address List.

Any thoughts appreciated!

#2

Hi @ucstester20,

in Kopano such scenarios can be achieved through multi tenancy features. But for this to work there also need to be changes to the LDAP tree as users that should see each other need to be organised below e.g. a shared ou.

The UCS Kopano integration is not designed to allow multiple tenants by default, but can be extended to do so.

If you’re interested I recommend to reach out to the Kopano sales team to set up a project for you.

#3

@fbartels - thanks a lot for your suggestion. I take it Kopano makes some of its own LDAP data processing and stores the results under the hood, and when querying it doesn’t bind to the DN of the Kopano user?

“Multi-tenancy” sounds like overkill just to be able to separate groups on the same infrastructure. There’s GDPR, privacy and a lot of other good reasons - I’m less worried about specific UCS integration here, this is secondary. If you have resources to read up on that, please feel free to share.

In fact, the problem could be generalized somewhat: in UCS (and apps), it would make sense to have three types of groups:

  • public: members visible to all, including non-members (example: prom organizers)
  • semi-private: members visible only to members (example: classes)
  • private: members visible only to admins (example: students on aid)

LDAP filters or ACLs should be able to handle that - at least for small and mid-sized setups.

#4

hmm… yeah that would be one way to explain it. Another would be: essentially the GAB is not stored per user, but per installation/tenant. so the server connects to the ldap with its bind user to create it (and do other stuff).

Unfortunately the Kopano GAB does not work like that. You can either see a user in the gab, or you don’t. There is no way to specify that it should only be visible to parts of your users.

But also GDPR hardly applies here imho. After all all the users you see in in your gab are members of the same association (company, club, whatever) as you. And these other members are no strange, random people that have signed up for an account over the internet. And towards your employer you should have no hope of privacy when it comes to work related tasks/equipment.

What is a “prom organizer”?

#5

What is a “prom organizer”?

This referred to a school party (prom). The organizers of which might be publicly known students :wink:

The all-or-nothing approach to the GAL is a constraint, but I accept that currently Kopano does not offer a dedicated solution to this kind of problem - you may want to see this as a feature request from the crowd. Thanks for reading and replying.

In any case, the examples quoted were just that - examples. There are many other valid situations which could drive towards a separation of visibility:

  • companies may want to mask employees from country A from those in country B,
  • employees on special bonus plans may be masked from those not on plans,
  • line workers might be masked from managers or vice versa,
  • students of one class of a decentralized educational institution vs. students in another class elsewhere,
  • or maybe you just want to run UCS for several groups of friends and keep them separate.

It looks like the solution would be to hide all Kopano users and then to figure out what to do about Nextcloud.

#6

Ah, I was wondering if you are really speaking about american high school traditions…

Come to think of it it might actually be possible. You can instruct kopano-server to turn off the gab. But there is another form of central addressbook in Kopano. The adreslist. The content of an adresslist is defined by a search filter, so that could be your group members. I am however not sure if turning of the gab still leave the adreslist functional. I leave that for you to try out.

Your scenarios all sound a bit sketchy to me and I am wondering if there are really real world cases for these. Except for the last one. That one is imho the classic multi tenancy scenario:

Mastodon