Add ADRs regarding using the database for authn and authz

doc/adr/0003-use-database-for-authn.md

@@ -0,0 +1,34 @@
+# 0003 Use database as authentication provider
+
+Date: Unknown
+
+## Status
+
+Accepted
+
+## Context
+
+Password storage is a weak point in many webapps: passwords are often
+stored in clear text or obfuscated instead of truely secured (hashed).
+
+Many of these weaknesses exist because webapps reinvent the wheel and
+don't do it very well.
+
+LedgerSMB uses passwords in its authentication process and therefor needs
+to store passwords, but we do not want to invent an insecure wheel.
+
+## Decision
+
+Each user in a LedgerSMB company database will be associated with a
+PostgreSQL database role with login rights.  The webapp will pass any
+credentials received onto the database to authenticate the user.
+
+## Consequences
+
+- The webapp does not need to store any passwords itself, defering
+  this responsibility to PostgreSQL
+- Whenever PostgreSQL is upgraded to more secure storage methods,
+  the webapp automatically benefits from this upgrade
+- Security audits of PostgreSQL are immediatly inherited by our
+  project -- most likely PostgreSQL attracts more eyes than LedgerSMB
+  meaning much more thorough review than we could ever wish

doc/adr/0004-use-database-for-authz.md

@@ -0,0 +1,42 @@
+# 0004 Use database as authorization provider
+
+Date: Unknown
+
+## Status
+
+Accepted
+
+## Context
+
+Most webapps manage authorizations at the web-boundaries, at the time
+requests come in, with little to no protection on any of the other layers.
+
+At the time of this decision, access to various functionalities was controlled
+by menu-item availability.  However, no enforcement of access restrictions was
+implemented.  That is to say that once a user had knowledge of the URLs
+to trigger specefic functionality *and* the availability of a valid login
+account, any functionality could be triggered.
+
+## Decision
+
+Access rights on database and database object level (e.g. tables and views)
+will be used as an (additional) level of access control.
+
+## Consequences
+
+- Database connections cannot be made with a single, all-encompasing login
+  account; instead, accounts with authorizations specific for the current
+  user will need to be assigned exactly the intended access rights and be
+  used to log into the application
+- Fine-grained access rights need to be extended on database and database
+  object level, managing CRUD rights on tables, columns and rows
+- By consequence, Row Level Security, column grants and views will need to
+  be used to provide users with exactly the right data access (and no more
+  than that).  Views are a helpful tool to achieve this, because they run
+  as the owner, not as the session user, which allows `sudo` type privilege
+  escalation with strictly defined scope
+- These fine-grained access rights are assigned to PostgreSQL roles on a
+  per-applicative function granularity; e.g. creation/changing/deletion
+  of a new GL account each have their own role
+- These fine-grained roles are assigned to user accounts as per the first
+  bullet to determine the access rights of a single user