Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #7399 from ehuelsmann/cleanup/adr-repository
Add ADRs regarding using the database for authn and authz
- Loading branch information
Showing
2 changed files
with
77 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
# 0003 Use database as authentication provider | ||
|
||
Date: Unknown | ||
|
||
## Status | ||
|
||
Accepted | ||
|
||
## Context | ||
|
||
The security of password storage has been and remains a major point of | ||
concern in IT in general and with web applications in particular: | ||
passwords often used to be stored in clear text or would use other | ||
insufficiently secure storage mechanisms. | ||
|
||
LedgerSMB uses passwords in its authentication process and therefor is | ||
potentially affected by these problems too; however, we have a strong | ||
desire to falling into these traps *and* leverage other (much more | ||
heavily audited) open source solutions. | ||
|
||
## 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 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 |