[Freedombox-discuss] LDAP

[Simo]

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.