Set up LDAP authn for nc.tpn

All LDAP users should have a NC account.

Can this be done using the "LDAP User and group backend" application?

Trac:
Parent Ticket: #32519 (moved)

added component::internal services/service - nextcloud owner::nextcloud-admin@torproject.org parent::32519 priority::medium severity::normal status::new type::defect labels

https://docs.nextcloud.com/server/17/admin_manual/configuration_user/user_auth_ldap.html

we don't usually allow apps to connect directly to the LDAP server. what we do is we sync the user list into the app, and then the app works standalone. i don't exactly know how it works,

in gitlab, for example, users have different passwords (but the same username) than in LDAP, and that's on purpose: that way a compromise in gitlab doesn't affect gitlab.

i don't know how this could be done in LDAP. the module you refer to seems to do "traditionnal" LDAP sync, which requires the same user/password, as far as i can tell.

we might need to implement our own thing if we want to stick with user policy, possibly with https://docs.nextcloud.com/server/17/admin_manual/configuration_user/instruction_set_for_users.html

which seems kind of a pain in the bottom. ;)

more research definitely seem necessary here.

From micah in irc:

so as I see it the options are: 1. tor nc admins manage accounts through the entire lifecycle (creation, delete, etc.) 2. some kind of LDAP integration, either through a connection, or a regular dump of the data 3. sone kind of tokenized single sign-on system that will delegate authentication 4. adding some 3rd party app to nextcloud that enables users to register themselves, and restricts that registration to only people who have torproject.org emails https://apps.nextcloud.com/apps/registration

I think we should go with the option 1. and the tor nc admins manage accounts. We create accounts when people need it and remove accouns when people leave the organization.

i'm okay with going manual for now, because i don't want this to block. but it's going to be an issue with onboarding/offboarding. we already have a lot of tools and steps to go through to get people in and out, and this will matters worse, so I'd like us to find a solution in the long term.

i think i would prefer straight out LDAP integration to nothing at all, actually. but there are security implications there, and it's more work, so maybe if we're going to work on this at all, we would try to make a sync work instead?

Trac:
Cc: N/A to anarcat

Trac:
Cc: anarcat to anarcat, micah

we decided not to block on this, so unlink from parent.

the goal here is to make sure that accesses get created and revoked when we add and removed people from LDAP. but we're not comfortable enabling the current LDAP support system as it gives too much access to our LDAP server. we don't have time to evaluate all the implications of that and possible alternatives.

Trac:
Parent: #32267 (moved) to N/A

note this is a wider problem than just nextcloud, i opened #32519 (moved) to cover for the other cases.

Trac:
Parent: N/A to #32519 (moved)

i just had the idea that we could leverage the "basic http auth" system for authentication here.

the idea would be that ud-ldap would populate a "htaccess/htpasswd" kind of file and Nextcloud would tap into that. It seems there's support for configuring nextcloud to authenticate against "environment variables" which we could leverage for this purpose:

https://docs.nextcloud.com/server/11/admin_manual/configuration_server/sso_configuration.html#configuring-environment-based-authentication

The advantage of this approach is that it could possibly work for ALL web apps. We would reuse the webPassword field in LDAP and reuse it everywhere... It could be used for GitLab as well, for example...

Otherwise I don't think it's worth treating NC as a special snowflake. If we don't take the above approach, we should just hook it up directly into LDAP and accept that it might have problems if LDAP is down.

mentioned in issue #32519 (moved)

mentioned in issue tpo/tpa/team#32519 (closed)