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

[Erik Huelsmann <..hidden..>]

Hi David,


> 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.

Even though the above paragraph doesn't really say why you *need* that
level of openness on your servers, I think the true solution to a
black box accounting system is what (I think) Adam said he's doing for
some of his software: rent the software running on a VPS dedicated to
your company.


> 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.)

True. Unless you use separate PostgreSQL clusters for these
conflicting purposes.

> 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.

Neither will it be a problem if you do your testing on a separate
PostgreSQL cluster, which can be easily blown away after testing:
pg_dropcluster <clustername>.


> 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. :()

Not that "what others do is best", but the xTuple Postbooks solution
takes roughly the same approach as LSMB 1.3 is going: PostgreSQL as a
development/hosting environment with appropriate wrapper tools on top
(that's how I regard the cgi scripts accessing the database). In their
case, that includes much more 'heavy' desktop application.

It'd be a shame to see you go looking for another solution instead of
staying with LSMB. However, other than that you regard the current
decisions as unfortunate, I haven't seen any reasons why the current
scheme is the badest move in all of LSMB's history.

Because of the number of CVEs with vulnerabilities for webapps with
login requirement, I think it's rather hard to create a well working
webapp with login capabilities. To me the solution to hand off the
login process to another (much more experienced and tested) party
seems like a reasonable way to mitigate risks. Now, I'm open to other
lines of reasoning and other technical requirements, but since this is
accounting data, I sure would like to avoid any chances for
unauthorized access.


Bye,


Erik.