3 ms·

Any thought about supporting SQL databases for the user backend with configurable queries? Would be awesome to be able to take an existing SQL database of users

Any thought about supporting SQL databases for the user backend with configurable queries? Would be awesome to be able to take an existing SQL database of users and use that to serve LDAP authentication queries.

Timon3 4y ago
This would be really cool! At my last job I implemented this for a simple use-case (allowing PfSense captive portal logins with credentials from a different system). It wasn't too hard thanks to ldapjs[1], but it still felt a bit hacky. Having a well-tested implementation with a couple of options could replace a lot of these special-case implementations. [1] http://ldapjs.org/ http://ldapjs.org/
mgbmtl 4y ago
According to the docs, it uses sqlite as the backend: "Currently only SQLite is supported (see launchbadge/sqlx#1225 for what blocks us from supporting more SQL backends)." although presumably it would be better to query the graphql API.
- dingleberry420 4y ago
  Right, I want to hook this up to my existing postgres/mysql database with existing schema.
nitnelave 4y ago
We're going to add support for more DBs (e.g. Postgres and MySql) in the next release, I did a lot of work on the underlying libraries to make that possible. However, mapping the tables/field names is not planned. I think it's a can of worms that I don't want to open: How do you populate the fields you don't know about but are mandatory when creating a new user/group? You could go the way of setting up a middleman service that listens to the binary queries to (e.g.) postgres and "tranlates" them by substituting the field names, but that seems complicated.
- dingleberry420 4y ago
  First of all, read only functionality would be good enough for me. Especially if it can read from a database view which could be backed by my other tables. I often deal with user databases managed by custom software which we also want to let be consumed by something that speaks ldap, and it would be great not having to synchronize stuff, instead having a single source of truth. So perhaps if it can read from a view with a schema defined by you, that would work? And perhaps for inserting/updating user/groups, you could require the database have a specific stored procedure present? Initially I was thinking about allowing templated queries, where the administrator can specify the field names. For inserts, the database will just have to provide sensible defaults or let the insert go through a stored procedure that provides such. But doing everything using views & stored procedures might be simpler?
  - nitnelave 4y ago
    I'm not a DB expert so I don't know much about stored procedures. Given that I'm trying to stay compatible with all of sqlite/mysql/postgresql, it might be difficult to rely on stored procedures horizontally. A read-only view would be possible, the schema is quite simple. If you want, you could create an issue for that! Keep in mind that the DB schema is more of an implementation detail than a public API, so I'm not going to consider an (automatically-migrated) schema change as a breaking change.
liveoneggs 4y ago
OpenLDAP back-sql allows you to map anything you can query with ODBC to ldap
- inejge 4y ago
  The problem is that back-sql is unmaintained (e.g., see [1]) and only security bugs are addressed. [1] https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/message/4BKHDYOSSTC2K3YPUMZFF4IIE7TWNSVS/ https://lists.openldap.org/hyperkitty/list/openldap-technica...

Timon3 4y ago

This would be really cool! At my last job I implemented this for a simple use-case (allowing PfSense captive portal logins with credentials from a different system). It wasn't too hard thanks to ldapjs[1], but it still felt a bit hacky. Having a well-tested implementation with a couple of options could replace a lot of these special-case implementations. [1] http://ldapjs.org/ http://ldapjs.org/

mgbmtl 4y ago

According to the docs, it uses sqlite as the backend: "Currently only SQLite is supported (see launchbadge/sqlx#1225 for what blocks us from supporting more SQL backends)." although presumably it would be better to query the graphql API.

dingleberry420 4y ago
Right, I want to hook this up to my existing postgres/mysql database with existing schema.

nitnelave 4y ago

We're going to add support for more DBs (e.g. Postgres and MySql) in the next release, I did a lot of work on the underlying libraries to make that possible. However, mapping the tables/field names is not planned. I think it's a can of worms that I don't want to open: How do you populate the fields you don't know about but are mandatory when creating a new user/group? You could go the way of setting up a middleman service that listens to the binary queries to (e.g.) postgres and "tranlates" them by substituting the field names, but that seems complicated.

dingleberry420 4y ago
First of all, read only functionality would be good enough for me. Especially if it can read from a database view which could be backed by my other tables. I often deal with user databases managed by custom software which we also want to let be consumed by something that speaks ldap, and it would be great not having to synchronize stuff, instead having a single source of truth. So perhaps if it can read from a view with a schema defined by you, that would work? And perhaps for inserting/updating user/groups, you could require the database have a specific stored procedure present? Initially I was thinking about allowing templated queries, where the administrator can specify the field names. For inserts, the database will just have to provide sensible defaults or let the insert go through a stored procedure that provides such. But doing everything using views & stored procedures might be simpler?
- nitnelave 4y ago
  I'm not a DB expert so I don't know much about stored procedures. Given that I'm trying to stay compatible with all of sqlite/mysql/postgresql, it might be difficult to rely on stored procedures horizontally. A read-only view would be possible, the schema is quite simple. If you want, you could create an issue for that! Keep in mind that the DB schema is more of an implementation detail than a public API, so I'm not going to consider an (automatically-migrated) schema change as a breaking change.

liveoneggs 4y ago

OpenLDAP back-sql allows you to map anything you can query with ODBC to ldap

inejge 4y ago
The problem is that back-sql is unmaintained (e.g., see [1]) and only security bugs are addressed. [1] https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/message/4BKHDYOSSTC2K3YPUMZFF4IIE7TWNSVS/ https://lists.openldap.org/hyperkitty/list/openldap-technica...