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.
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.
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?
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.
"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.
[1] https://lists.openldap.org/hyperkitty/list/openldap-technica...