Re: Authentication in 1.3 (was Re: State of Perl-based database setup utilities for LedgerSMB 1.3)

["David F. Skoll" <..hidden..>]

On Sat, 28 May 2011 21:06:44 +0200
Erik Huelsmann <..hidden..> wrote:

> You're aware that the PostgreSQL versions nowadays allow
> authentication against its own database, Kerberos,
> LDAP/ActiveDirectory and PAM out of the box?

Yep.  And none of those appeals to me.  I like LSMB to maintain its
own database of users independent of all of those other possibilities.

> What specifically goes wrong in your server management processes when
> LSMB uses PostgreSQL authentication, taking into account that 1.3
> comes preconfigured to connect through the IP interface, which is
> probably not configured as "all all trust" even in your company.

In fact it is:  We have host all all 127.0.0.1/32 trust.

The problem with using PostgreSQL authentication for LSMB is that
people who run LSMB will actually have to care about PostgreSQL.
That's a bad move.  As I wrote earlier, PostgreSQL should (as much as
possible) be a "black box" component that is installed and used with
as little configuration as possible.

Using Pg authentication makes it significantly more annoying for
non-sysadmins or non-Pg experts to administer LSMB users.  It becomes
impossible to create users via the Web interface (unless, of course,
you grant the LSMB admin user "CREATE ROLE" privilege in Pg which is,
IMO, a huge security problem.  Suddenly the Pg admin user can create
roles in PostgreSQL that may have nothing to do with the LSMB
database.)

It also makes testing annoying because when you blow away a test
database, you also have to remember to blow away any LSMB users.  If
auth info were stored in the database itself, this wouldn't be a
problem.

I urge you to make it optional to use an in-application list of users
for those who do not want to use Pg auth.  (But I suspect this is a
losing battle, so we'll need to decide whether to continue with LSMB
or look elsewhere. :()

Regards,

David.