Proposal: Remove LDAP support #1701
Labels
No labels
Blocked
Bug
Changelog
Added
Changelog
Missing
Changelog
None
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/E2EE
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Matrix/T&S
Merge
Merge/Manual
Merge/Squash
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
11 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity#1701
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Typically, if we didn't want a feature anymore, we'd just remove it. However, knowing that some members of the community use and rely on LDAP, I'm instead opening an issue to gather some feedback to better know how to proceed.
The maintainer team has never used LDAP. Support for it is included entirely by the community, for the community, and as such, it does not get oversight from the maintainer team. This prevents several problems:
So, going forth, I (and the rest of the maintainer team) would like to propose dropping LDAP from the project. We have upcoming work for Oauth2/OIDC support, so in the future it will be possible to delegate to an external identity provider, but the advantage there is we don't need to worry about the security in the same way we do LDAP, and since Matrix is generally moving in this direction, it will be far easier to support.
Please let me know your thoughts in comments.
IMO it's worth keeping LDAP until OIDC is around, so you have some way of delegating identity. When OIDC is around LDAP can be removed, and users can migrate to OIDC.
Perhaps deprecating LDAP, but keeping it around until OIDC could be a compromise?
I think realistically that would be the plan of action, I don't think we can just drop LDAP support entirely until there's a way to delegate externally in some other form. Possibly dropping it into a non-default feature (if it isn't already) in the meantime.
My personal concern is a security one. I have no idea how LDAP works and, sort of having the project security work delegated to me, it gives me massive shivers knowing we support an authentication system that none of the maintainer team understand nor use, and are effectively relying on it just never failing in any way.
@nex wrote in #1701 (comment):
That sounds reasonable to me 👍
One possible reason I can think of (without having had that usecase yet myself) is for offboarding or similar. Because OIDC isn't federated the way LDAP is, a deactivation of a user within OIDC won't remove/disable it in matrix. Assuming there is some form of regular LDAP syncing, that would come automatically e.g. by disabling accounts that were previously in LDAP that aren't anymore.
As mentioned, I don't personally use anything like this yet, but I was planning on setting up LDAP for user synchronization with the rest of my hosted services.
Eh, once OIDC is here, I think theres too little reason to keep LDAP.
OIDC supports pull on login, however if a user doesn't have access to login then c10y would never see "oh this account is disabled" and delete/deactivate/whatever the user in its DB.
That's honestly the main usecase I can really see, so if OIDC supports logging in with the same or a better flow and stuff then I support removing LDAP.
@s1lv3r wrote in #1701 (comment):
Couldn't that be solved by SCIM? No idea how much work it would be to add, but it would allow the OIDC provider to push changes and continuwuity to react accordingly.
cc @RatCornu for their inputs
I actually want to start using LDAPS against Kanidm to see what's up, and write docs for it as well as the other External Auth methods (email and eventually OIDC). Imo it could be included with a big warning that it's not supported by the core devs, at least for now. Although I get that you may not want such different level of scrutiny in the same codebase. And if implementing OIDC means having to refactor everything and pull LDAP out for simplicity, I'd understand that eventual support drop as well.
Perhaps if LDAP could be a compile-time "community feature" that would be great, but skimming the PR I don't think it was initially implemented as such.
IMO the best course of action is:
Just my two cents, ofc.
I agree with quad and nex, as out of all 'auth providers' (open)ldap is definitely one of the worst to get right and properly secured, and migration to an OIDC provider should be (close to) trivial.
As long as there is a transition period (read: there should exist a version in which both LDAP and OIDC are possible to configure), I think this is a good idea.
I'm an LDAP user and have been since setting up the bearware.dev instance initially, and I really don't see a good reason to keep it around. We use Authentik over here, and we use it for all our other tools, and ends up confusing folks all the time since it has a different login flow. I also do very much agree that there is a security concern using it like Nex mentioned, and I think it's pretty unreasonable to expect the core developers working on the project to dedicate their time to LDAP if it's not something they use themselves or benefit from in any meaningful way. If OIDC is added, I would drop LDAP in a heartbeat.
For deleting user accounts, as an admin who works with OIDC and some other tools, I don't think it would be a big deal for deactivating accounts, since c10y already has a way to do so in the admin room. It's an extra step to off-boarding, but off-boarding is already not a simple task, and if it requires keeping LDAP or running an extra admin command, I would much prefer the admin command. I'm all for removing support of LDAP if/when OIDC is implemented.
Meow, I don't use LDAP with my current Continuwuity deployment, because is a small instance for friends and partners or those ones close. However, I work as devops engineer and I see a lot of environments where LDAP or an Active Directory is the central and only user store.
My point is not addressing this for corporate use, but for organizations in which I may involve myself. I would encourage and plan that they donated or support the project in some way, as companies really never give back (unless they are directly getting benefit from it), so I would not promote it there.
Having LDAP as option ensures a smooth process in integrating it with already-existing infraestructure. I don't have much experience as LDAP developer outside of Python and a bit of Typescript but I do have extensive one as sysadmin or some little automations because of the environments I move at. I would be okay debugging things as my things here would be in my free time whenever I get involved in an organization where is considered this could be used.
I asked in the group if there would be alternatives, and whenever OIDC is, as external server, I would be okay with that solution, as it was said in the chatroom too, is well supported behind a separated LDAP user store, and would provide me the integration I want or need (however you want to see it).
I'm switching to OIDC the day it comes out in a release but having a period where neither LDAP nor OIDC work would be very hard for me to manuever around - so much so, that I'd either run my own fork with the removal reverted or I'd not update until OIDC is in.
I'm going to go back on some of my original statements 30ish minutes ago. I would be fine removing LDAP even before OIDC is integrated. There's been a lot of talk about people interested in LDAP and OIDC, but if most of that is speculative (which it seems to be), the amount of people directly impacted by a period of time where LDAP is gone and OIDC is active would be pretty small. I personally would be fine transferring the users on my instance to normal username/password logins for that time period. It would be best to hear from other active users of LDAP, but I think being too concerned on planning to use it, or general idea of "an organization that would potentially use it" puts a lot more stress on a hypothetical future rather than a current or immediate material reality.
Hi! I'm the author of the PR that added LDAP few monthes ago. (I'm sorry for my english, it's not my mother tongue and I'm not used to write big paragraphs in it.)
I completely understand your motives to remove LDAP support : it's an old protocol that is less and less used as time pass. It's still widely used in organizations (company, universities, ...) but it doesn't seem to me (correct me if I'm wrong) that this is the first target of continuwuity. Moreover, a lot of people (at least a few people in this thread, including me) use an identity provider (Authentik, Authelia, kanidm, keycloak, ...) so switching to an alternative like Oauth2/OIDC wouldn't be an issue. However, as some people rely on it, I think the drop of LDAP cannot occur anytime before the full support of OIDC.
Now to talk a little bit more about the LDAP protocol : LDAP seems to me less secure than OIDC. Indeed, the protocol has only be planned for password, you can manage to use OTP but it's rather uncommon to see softwares that actually use that. You can read the LDAP protocol explaination at the bottom but the only thing that is really important to have in mind I think is that contrarily to OIDC, LDAP is much harder to test because it's an entirely distinct protocol that does not use HTTP (and it's not a huge protocole like DNS or SMTP with lots of librairies). That's why I don't think it's realistic to spend a lot of time creating a mock server for LDAP for this project.
That's why, even if I found the LDAP super interesting from a theoritical point of view, I think it is due to slowly die and to be replaced by better alternatives as OIDC. I think a good transition for all the people that rely on it today could be:
Now technical details on LDAP.
LDAP is a generic protocol with very few big implementations. I think the ones that are worth mentionning here are: OpenLDAP (I think the biggest one), Active Directory (Windows only) and all the generic identity managers like keycloak, authentik, kanidm, ... There are other software like lldap or 389 Directory Server but I saw them mentionned very rarily.
The protocol uses a client-server architecture on a TCP connection. In our case, continuwuity is the client and all of the software mentionned in this thread are servers. I will not explain the LDAP protocol because it's not really interesting here, but you can think of LDAP servers as a big database specialized to store (among other things) account information, in a tree-like structure (no relation table here).
If we compare it to the OIDC protocol, security-wise, I think the biggest issue with LDAP is the fact that a user authentication only relies on username/password and not on anything else that could be added. As the communication between the LDAP client and server are, usually, crypted using TLS or STARTTLS, there is no real difference between finding a security breach between a LDAP server or a OIDC provider.
That's why I think that if you're not that worried about OIDC security, you should not be that much worried about LDAP security. To sum up, the only two real differences that I see are:
ldap3that has no security breach listed, but it's undeniable that it surely is less tested and reviewed than axum.I hope this is not too indigest, do not hesitate to ask for clarification or more precisions, and thanks again for your work on continuwuity!