[Freedombox-discuss] LDAP
On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote:
> Quoting Petter Reinholdtsen (2013-11-03 09:49:24)
> > [Lorenzo]
> >> For these reasons I think it's not necessary to put LDAP in the
> >> freedombox. Maybe I'm overlooking something (maybe some critical
> >> daemon is incompatible with SASL?). I hope what I wrote can be of
> >> help in the design, I'm curious to hear what are the other opinions
> >> on this topic.
> >
> > The reason I believe it is a good idea to have LDAP on the freedombox,
> > is that it reduces the number of user databases on the system. Some web
> > service systems, like owncloud and ejabberd, have their own user
> > databases while also supporting LDAP as their user database backend.
> > Several, or perhaps most, do not use /etc/passwd as their user database.
> > So we can either maintain several user databases specific to a lot of
> > the services we want to set up in the Freedombox, or we can maintain one
> > in LDAP and hook the services up to LDAP to use one common user database
> > instead. I prefer the latter.
>
> Ok. Makes good sense to mandate use of shared auth mechanism. Not
> convinced LDAP is the ideal for that, though.
>
> Beware that simply "supports LDAP" may not tell the full story: Some
> applications integrate with LDAP only by optional lookups of LDAP
> records, while maintaining its user data in a custom database anyway
> (i.e. not writing back to LDAP).
>
> If LDAP is used only for readonly user/group data, not for sharing other
> user data and not updated from the applications, then it might be safer
> to write a script exporting POSIX info to those applications needing a
> custom format (e.g. as a cron job or added as hooks to e.g. change of
> password.
>
> Ejabberd, specifically, _does_ support POSIX getent. That's the very
> reason I suggested to use that daemon: I have experience using it in
> production, because it fits my requirements of using that simple shared
> auth mechanism.
It would help to avoid confusing identity store with authentication or
authorization mechanisms.
> Hint for someone wanting to help: Above has to potentially low hanging
> fruits:
>
> * collect concrete data on which applications support which shared
> mechanisms for user/group management, and whether the support is
> readonly or read/write.
Read Only is the most sensible, you do not want random apps to be able
to write to an identity store, or you open up your flank for privileges
escalations.
> * document how to make prosody use getent.
the nsswitch interface (which is what you refer to with getent) is
pluggable, so LDAP would fit in quite easily, there are a number of
tools that provide plugins for all sort of identity stores.
> > In addition, we get a central and structured place to store
> > configuration for at least some of the services, but that is of less
> > importance to me.
>
> It is of *big* importance to me that we do *not* move storage from /etc
> to a database: It may seem tempting to use that approach when needing a
> setup different from what the corresponding package maintainer offers,
> but since we have *no* administrator on our systems, our setup *must* be
> supported by package maintainers.
I am not sure what this means, package maintainers normally call
adduser/addgroup or similar, how is that a problem ?
Simo.
Reply to: