Hi,
As part of my preparations to introduce web services, I've found that many
web APIs provide two ways to authenticate: (a) a session cookie which can
be obtained by "logging in", or (b) an "API key" ; either the API key or
the session cookie is then provided with each request to the API,
authenticating the request with the session and/or user. It should be noted
that neither requests providing an API key nor those providing a session
cookie contain further credentials.
For our (API) authentication, ideally, I'd like to be able to provide both
the "api key" and the "session cookie" patterns for request authorization.
Additionally, I'd like session authentication to be available using:
- Username & password (preferably through CRAM-SHA2 or higher SHA)
* Note that in this scenario, the password validation could be anything;
even a Kerberos or LDAP server
- WebAuth / FIDO2
- OAuth2
- Client certificate
- (and more, if we come up with those)
== The Problem ==
Our current authentication setup requires plain text username and password
on the initial login and each further request. We currently use basic auth
to supply these values. In addition, we use a session cookie, but that only
serves to validate the session. Thus every request currently requires the
username, password and session cookie. The username and password are
required because those are used to set up the database connection at the
start of the request handling.
Most of the authentication systems above don't maintain a username/password
combination visible to our server. By consequence, I'm looking for ways to
eliminate the need for the username+password in the Web request. Also, if
we'd want to use "API key" type authentication, that API key would need to
hold in it (encrypted, but decryptable to the server) the username and
password in order to be able to log into the database.
Note that the previous sentence explicitly states "in the Web request":
ideally, LedgerSMB authentication can happen on two different levels -- the
web request level and the database connection level. Basically, I'd like to
start making the distinction between the web request authentication and the
database authentication in such a way that our database authorization
(access control) remains PostgreSQL-role-based (that is: doesn't change
from the current model).
== The Proposal ==
My current idea is to separate the web authentication from the database
authentication. The web application would use a generic user to set up the
database connection, switching the session authorization to the role
associated with the user, as if the user had logged in directly on the
database. Technically, this is achieved by the Pg command 'SET SESSION
AUTHORIZATION = username'. This means that once the session has been
verified (either through the API key provided or the session cookie),
authorization can be switched to the (web)authenticating user and regular
processing (as we know it today) can continue.
This solution using the session authorization is very similar to what the
Graphile (graphile.org) project uses [they use SET ROLE instead of SET
SESSION AUTHORIZATION -- there are subtle differences between their
approach and my proposal].
The solution has the benefit of supporting direct connections to the
database as they are today with all methods built into PostgreSQL, adding
into the mix a second set of authorization options better suited to a web
authentication scenario.
== The Request ==
Please comment on the above to get a good common understanding of what I'm
describing and the best possible implementation at that.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.7.8
* Upgrade Dojo dependency to 1.15.1
* Load the template from the database when printing receipts
* Prevent dead-locks in response to request from timed out session
* Add monetary formatting to payments/receipts screen and report
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.7.8/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.7.8
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.8
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.7.8
These are the sha256 checksums of the uploaded files:
59a7ad10d8da1b28f298239c93ea4ca15fd348ff5d1517253dfe6a4b51d099a4 ledgersmb-1.7.8.tar.gz
c91c4b3af21ac0ad8d6d5809678ed8e537596e15899d3142e196ac2a724f9876 ledgersmb-1.7.8.tar.gz.asc
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.6.18
* Upgrade Dojo dependency to 1.13.5 (Erik H)
* Prevent dead-locks in response to request from timed out session (Erik H)
Erik H is Erik Huelsmann
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.6.18/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.6.18
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.18
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.6.18
These are the sha256 checksums of the uploaded files:
e07f6afc54c33f30d5b914c7e28635640e5c246826f7f5054d0742c2f2214f62 ledgersmb-1.6.18.tar.gz
828c87904b13617f60f5011a97767dcf073be0534bb529363f28387c289ae51c ledgersmb-1.6.18.tar.gz.asc
Hi,
Over the past weeks, I've implemented a change in the way payments are
being recorded: batch payments are now recorded explicitly (instead of
implied) and payments entered into the invoice screen are now recorded (as
opposed that they were not recorded as payments, but "just" lines on the
invoice transaction).
The next step in my improvement plan is to use the new payment information
in Reconciliation.
To understand the problem domain, there's a bit of context to be explained:
technically, every invoice being paid in a payment causes its own line in
the Bank GL account. These lines are grouped using a payment
identification. Now that all payments are being correctly recorded in the
database, we can tap into that information to summarize the bank
reconciliation view: We can show payments as a single line.
Where we're coming from is different: we used to aggregate lines on the
Bank GL account by various fields (reference, counterparty, source
reference, date, transaction type, mostly). The method we used to use,
caused two payments by the same customer - entered without a source
reference number - to be aggregated into a single reconciliation line. On
the other hand it was impossible to post small corrections to payments
through the GL: because the aggregation takes the transaction type into
account, GL transactions and payment transactions (AR/AP) can't be
aggregated into a single reconciliation line.
I was thinking that the reconciliation could be changed to use this
business rule:
Aggregate into single reconciliation lines (so as to reconcile with a
single bank transaction):
* Payments and GL transactions on the same date with the same 'reference'
* GL lines with the same date and same 'source' (source reference number)
-- if the gl lines couldn't be merged with a payment
This business rule allows reconciliation - as single reconciliation lines -
of:
* Reconciliation of payments *with their GL corrections* as a single
payment line
* Reconciliation of payments (without GL corrections)
* Reconcilation of GL-entered lines with the same source code reference
* Reconciliation of GL-entered lines individually (when no source code
reference is entered)
Is this what we want?
It's wildly different from the criterion we currently use, where we
aggregate all lines on the bank account, into lines where the
differentiator is:
* Date
* Transaction type (ar/ap/gl)
* Reference (AR/AP: internal eca ID; GL: transaction's "Reference" field)
* Voucher number
* Source reference number (Source field of transaction line)
* Memo field content (transaction line Memo field)
Note however, that in the current situation, there isn't a concept of
"payment" in the database at the moment; transactions posted using regular
and batch payments receive the same values for Date, Transaction type,
Reference, Source reference number and optionally voucher (for bulk
payments). Concluding: the old rule mostly aligns with payments, but on a
different basis and may aggregate multiple payments into one.
When we hash out the question above, I have a follow-up question of how the
reconciliation process should work from a business process perspective.
Let's try to hash this one out first.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
The LedgerSMB development team is happy to announce yet another new
version of its open source ERP and accounting application.
This release contains the following fixes and improvements:
Changelog for 1.7.7
* Fix currency column not being available in the parts screen
For installation instructions and system requirements, see
https://github.com/ledgersmb/LedgerSMB/blob/1.7.7/README.md
The release can be downloaded from our download site at
https://download.ledgersmb.org/f/Releases/1.7.7
The release can be downloaded from GitHub at
https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.7
Or pulled from Docker Hub using the command
$ docker pull ledgersmb/ledgersmb:1.7.7
These are the sha256 checksums of the uploaded files:
3509cfa379c5752206a464abc0b04c1beaff66ee7a6b2e49c338d7808de9e08b ledgersmb-1.7.7.tar.gz
b00f2b01607822d862c5ef7446c3c4e1d887204123e90d4441bec4da6e1020fb ledgersmb-1.7.7.tar.gz.asc
