On Mon, Apr 7, 2014 at 8:12 AM, herman vierendeels <
[email protected]> wrote:
> Certificate-based single-factor authentication.
>
> I have a remote postgres server with self-signed server certificate.
> I have self-signed client certificate.
>
> With psql , i can login with certificate.
> I wondered if we could achieve the same in ledgersmb
>
Certificates are not transitory authentication measures, so if you do this
you would have to trust the web server regarding authentication. This is
possible but it means that supporting password authentication and
certificate authentication on the same instance would be somewhat difficult.
The simplest way to do this would be to let the web server check the
validity of the certificate, then in Perl grab data from the certificate
and log in in PostgreSQL. This could be with trust auth or with a set
password for a user which can set role to the login role. Either way you
have some significant security considerations to think about.
For two-factor authentication this is less of a concern.
It could be done today. It is mostly a question of looking at
implementation and how best to balance the considerations. This is not
overall an insurmountable problem, but I would feel more comfortable with a
real customer in front of me to help make the tradeoff decisions.
For two-factor authentication this is actually pretty trivial to do at
present.
Best wishes,
Chris Travers
>
> Best wishes,
> Herman
>
> 2014-04-06 11:54 GMT+02:00 Chris Travers <[email protected]>:
> >
> >
> >
> > On Sun, Apr 6, 2014 at 1:36 AM, herman vierendeels
> > <[email protected]> wrote:
> >>
> >> talking about authentication ,
> >>
> >> could we also think about certificate authentication ?
> >
> >
> > Can you clarify? Certificate-based single-factor authentication? Or
> > certificates as one of two factors?
> >>
> >>
> >> 2014-04-05 14:55 GMT+02:00 Erik Huelsmann <[email protected]>:
> >> > Hi Chris,
> >> >
> >> > Looking at the auth code currently in login.pm and LedgerSMB.pm as
> well
> >> > as
> >> > the exceptions in lsmb-request.pl, I'm coming to the conclusion that
> >> > LedgerSMB.pm has been coded based on the assumption that every request
> >> > needs
> >> > to be authenticated against the database and that if authentication
> >> > fails,
> >> > an auth popup should be returned.
> >> >
> >> > However, as it turns out, this situation causes problems when the
> >> > database
> >> > doesn't actually exist, or when the application "only" wants to
> >> > authenticate, but not generate a full request series (such as the
> >> > login.pl:authenticate() function).
> >> >
> >> > I'm thinking we can resolve the issue we're seeing now by:
> >> >
> >> > * Stopping to connect to the database in LedgerSMB.pm:new()
> >> >
> >> > And instead:
> >> >
> >> > * Factor out the database connection logic
> >> > * Factor out session initialization logic (the part which is based on
> >> > the
> >> > DB connection)
> >> > * Introduce a mechanism whereby a module (e.g. login.pm) can signal
> >> > one or more of its actions doesn't want a preconnected database
> >> > handle
> >> > * Make database connection and session initialization explicit parts
> of
> >> > lsmb-request,
> >> > if the module doesn't disallow it
> >> >
> >> > This way, we can remove any implicit auto-connection to the database
> >> > from
> >> > all lower level calls.
> >> >
> >> > What about it?
> >> >
> >> > --
> >> > Bye,
> >> >
> >> > Erik.
> >> >
> >> > http://efficito.com -- Hosted accounting and ERP.
> >> > Robust and Flexible. No vendor lock-in.
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Ledger-smb-devel mailing list
> >> > [email protected]
> >> > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Ledger-smb-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> >
> >
> >
> >
> > --
> > Best Wishes,
> > Chris Travers
> >
> > Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
> > lock-in.
> > http://www.efficito.com/learn_more
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Ledger-smb-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> >
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Ledger-smb-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
