LDAP support #691

New issue

Open

opened 2025-02-28 01:49:43 +00:00 by RatCornu · 5 comments

RatCornu commented

2025-02-28 01:49:43 +00:00

(Migrated from github.com)

Hi!

I'm currently using synapse but the whole server is really slow, so I would like to change for conduwuit since all the features I need are here but the LDAP, which is hard requirement for me. I saw that OIDC support is planned in #209 which is great! But LDAP is still widely used nowadays and, in my point of view, has a better usage from an end-user point of vue since it would not require the client to support OIDC login (everything would be done through usual login).

To be more precise, the goal I think would be to be able to support recent implementations of the LDAP protocol, such as in lldap or in kanidm. For this, the client crate ldap3 would be very useful as everything needed is directly implemented here. The biggest part of the work would be a change in the login phase (which I could detail more if needed), and probably a change in the database.

I would be happy to help making a PR when I will have engouh free time, but I think that discuss changes beforehand is a good idea since it may change a lot of code.

Thanks for your work!

Hi! I'm currently using synapse but the whole server is really slow, so I would like to change for conduwuit since all the features I need are here but the LDAP, which is hard requirement for me. I saw that OIDC support is planned in #209 which is great! But LDAP is still widely used nowadays and, in my point of view, has a better usage from an end-user point of vue since it would not require the client to support OIDC login (everything would be done through usual login). To be more precise, the goal I think would be to be able to support recent implementations of the LDAP protocol, such as in [lldap](https://github.com/lldap/lldap) or in [kanidm](https://github.com/lldap/lldap). For this, the client crate [ldap3](https://crates.io/crates/ldap3) would be very useful as everything needed is directly implemented here. The biggest part of the work would be a change in the login phase (which I could detail more if needed), and probably a change in the database. I would be happy to help making a PR when I will have engouh free time, but I think that discuss changes beforehand is a good idea since it may change a lot of code. Thanks for your work!

girlbossceo commented

2025-02-28 02:23:20 +00:00

(Migrated from github.com)

I'm happy to accept a PR for LDAP support since it isn't really something we're going to prioritise on our end so a community contribution is expected for this similar to OIDC. Only thing I just want to know is how is this all going to work, and how will it all be implemented? What potential database changes will be needed? What might the config look like? And how is it actually going to be seamless into the standard login methods?

tcpipuk commented

2025-02-28 07:13:12 +00:00

(Migrated from github.com)

I know LDAP will probably not fall out of use for decades (as it's used so widely in corporate environments) but if you look at usage data from other FOSS projects (like Drupal) the usage is generally declining. A lot of people expect SSO now, and most SSO servers support an LDAP backend.

It would be interesting to see a PR that allows replacing the user database with LDAP, but if anyone is going to start putting effort into writing one now, I'd strongly recommend they use OIDC instead - MSC3861 is on the way to getting merged this year, so it'll be part of the Matrix spec.

I know LDAP will probably not fall out of use for decades (as it's used so widely in corporate environments) but if you look at usage data from other FOSS projects ([like Drupal](https://www.drupal.org/project/usage/ldap)) the usage is generally declining. A lot of people expect SSO now, and most SSO servers support an LDAP backend. It would be interesting to see a PR that allows replacing the user database with LDAP, but if anyone is going to start putting effort into writing one now, I'd strongly recommend they use OIDC instead - [MSC3861](https://github.com/matrix-org/matrix-spec-proposals/pull/3861) is on the way to getting merged this year, so it'll be part of the Matrix spec.

m00nwtchr commented

2025-02-28 08:18:35 +00:00

(Migrated from github.com)

LDAP isn't going to fall out of use, but Matrix is replacing user/password login with OIDC, which would make it impossible to support LDAP once complete, except for at the actual OIDC provider (e.g. Authelia uses LDAP as it's user db backend)

RatCornu commented

2025-02-28 15:22:58 +00:00

(Migrated from github.com)

For the concrete implementation, I think it will depend on how OIDC is added, but here is how I see the possible modifications:

add a new column user_origin (or any other name) in the equivalent of the user table in the DB (here if I understand the project structure correctly) to be able to indicate where the user come from (password/LDAP/OIDC/...)
the login process would then change as follow:
- if the user already has an account with a password origin, then nothing change
- if the user already has an account with a ldap origin, then the server should bind to the LDAP with parameters given in the config file and the username/password
- if the user does not have an account yet and tries to login, bind to the LDAP server with the same parameters, and if the user exists then create an account in the conduwuit DB
add around ~10 parameters to the config file to describe the connection to the LDAP server with useful parameters
disable password modification for account with ldap origin

This would allow conduwuit to act as a read-only client from the LDAP server point of vue, which is much easier than trying to deal with write operations.

Even if the usual user/password login is going to be deprecated, it's not going to be anytime soon, so I think it can still be worth it to add a LDAP provider. I still completely agree that OIDC is more important than LDAP, but I'm not competent at all in OIDC, but I could help for LDAP, that's why I make this issue. For the concrete implementation, I think it will depend on how OIDC is added, but here is how I see the possible modifications: - add a new column `user_origin` (or any other name) in the equivalent of the user table in the DB ([here](https://github.com/girlbossceo/conduwuit/blob/main/src/service/users/mod.rs#L38) if I understand the project structure correctly) to be able to indicate where the user come from (password/LDAP/OIDC/...) - the login process would then change as follow: - if the user already has an account with a `password` origin, then nothing change - if the user already has an account with a `ldap` origin, then the server should bind to the LDAP with parameters given in the config file and the username/password - if the user does not have an account yet and tries to login, bind to the LDAP server with the same parameters, and if the user exists then create an account in the conduwuit DB - add around ~10 parameters to the config file to describe the connection to the LDAP server with useful parameters - disable password modification for account with `ldap` origin This would allow conduwuit to act as a read-only client from the LDAP server point of vue, which is much easier than trying to deal with write operations.

girlbossceo commented

2025-02-28 15:52:06 +00:00

(Migrated from github.com)

Sounds simple enough, should be good to implement then.

Also, I don't think conduwuit will be deleting username:password authentication any time soon even if it is supposed to be "deprecated" for MAS/OIDC.

Sounds simple enough, should be good to implement then. Also, I don't think conduwuit will be deleting username:password authentication any time soon even if it is supposed to be "deprecated" for MAS/OIDC.

👍 3