hostsharing/hs.hsadmin.ng
6
0
Fork 0
Code Pull Requests 2 Activity

TODO tracking

Browse Source
This commit is contained in:
Michael Hoennig 2022-07-31 15:16:49 +02:00
parent 53d3d68021
commit 5d4fb85383
7 changed files with 132 additions and 192 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
Glossary.md
View File

@ -1,18 +0,0 @@
# hsadminNg Glossary
### Business Object
Represents an object from the
### Tenant
The RBAC
### RBAC
abbreviation for *Role Based Access Control*
### Role Based Access Control (RBAC)
A system to control access to business objects by defining users, roles, and permissions.
For more information see

BIN
TODO-progress.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.3 KiB

82
TODO.md Normal file
View File

@ -0,0 +1,82 @@
## TODO
This document is just for tracking the initial development project and thus only in German.
### Kommunikative Aufwände
| ID | Beschreibung | Budget | Aufwand | Leistung |
|:----|:------------------------------------------------------------|--------:|--------:|---------:|
| PRE | Vorbesprechungen bis inkl. KickOff-Meeting | 8 | 4 | 4 |
| PRJ | Zweiwöchige Projektbesprechungen | 12 | 2 | 2 |
| RET | Vierwöchige Retrospektiven (optional) | 6 | | |
| TRA | Einarbeitung von Mitarbeitern des Auftraggebers (Training) | 12 | | |
| E2E | Unterstützung beim Aufbau der E2E-System-Integrations-Tests | 40 | | |
| MIG | Unterstützung bei der Datenmigration | 16 | | |
| INS | Unterstützung ei der Inbetriebnahme / Einführung | 16 | | |
| APP | Abnahme (Approval) | 4 | | |
| SUP | Unterstützung nach der Abnahme (Support) | 12 | | |
| | | | | |
### Allgemeine Leistungen
| ID | Beschreibung | Budget | Aufwand | Leistung |
|:----|:-----------------------------------------------------------|---------:|--------:|---------:|
| DEV | Aufbau der Entwicklungsumgebung (bis inkl. Unit-Tests) | 16 | | |
| ATN | Entwurf des Authorisierungs-Systems | 40 | 100 | 36 |
| ATZ | Auswahl und Implementierung des Authentifizierungs-Systems | 20 | | |
| ITS | Aufbau einer Umgebung für Integrationstests (*1) | 4 | 4 | 20 |
| ATS | Aufbau einer Umgebung für Akzeptanzteste (*1) | 16 | 3 | 4 |
| PIP | Aufbau einer Build- und Testpipeline | 20 | | |
| ARC | Aufbau einer Architekturkontrolle | 8 | | |
| | | | | |
(*1: ITS+ATS sind aufgesplittet aus TST mit 20 geplanten Stunden entstanden)
### Leistungen bezogen auf fachliche Objekte
| ID | fachliches Objekt | Persona | Ops | Budget | Aufwand | Leistung |
|:----|:-----------------------|:---------------|:------------|-------:|--------:|---------:|
| ROL | Rollen | Hostmaster | Scrulojtx | 26 | 10 | 5 |
| USR | LDAP-User | Hostmaster | Scrufojtex | 29 | 10 | 5 |
| USR | LDAP-User | LDAP-User | rufojex | 20 | 10 | |
| GRP | Gruppen | Hostmaster | scrulojtx | 26 | | |
| CBD | Customer Base | Sachbearbeiter | scruojia | 20 | | |
| CBD | Customer Base | Kunde | sr | 5 | | |
| MSV | Managed Virtual Server | Hostmaster | crudfoj | 20 | | |
| MSV | Managed Virtual Server | Owner | rulojt | 15 | | |
| MWS | Managed Webspace | Hostmaster | crudfojte | 26 | | |
| MWS | Managed Webspace | Owner | rulojte | 18 | | |
| MWS | Managed Websppace | Admin | rulojte | 6 | | |
| ACC | Unix-Account | Owner | crudfojte | 26 | | |
| ACC | Unix-Account | Admin | ruloje | 15 | | |
| DOM | Domain | Owner | (crudfojte) | 9 | | |
| DOM | Domain | Admin | (rle) | 3 | | |
| EMA | E-Mail-Address | Owner | (crudfojte) | 9 | | |
| MAL | E-Mail-Alias | Owner | - | 0 | | |
| DBP | Database Postgres | Owner | (crudlojte) | 9 | | |
| DBP | Database Postgres | Admin | (rle) | 3 | | |
| DUP | Database-User Postgres | Admin | (crudlojte) | 9 | | |
| DUP | Database-User Postgres | Admin | - | 0 | | |
| DBM | Database MariaDB | Owner | - | 0 | | |
| DBM | Database MariaDB | Admin | - | 0 | | |
| DUM | Database-User MariaDB | Admin | - | 0 | | |
| DUM | Database-User MariaDB | Admin | - | 9 | | |
| | | | | | | |
### Wöchentlicher Status
![hsadmin-ng Projektfortschritt](TODO-progress.png)
In der folgenden Tabelle sind Aufwand und Leistung akkumulierte Werte.
<!-- generated todo-progress begin: -->
| Datum | Budget | Aufwand | Leistung | Restschuld |
|------------|-------:|--------:|---------:|-----------:|
| 2022-07-17 | 553 | 44 | 0 | 553 |
| 2022-07-24 | 553 | 8 | 0 | 553 |
| 2022-07-31 | 553 | 143 | 76 | 477 |
<!-- generated todo-progress end. -->

160
adr/2022-07-18.row-level-security-mechanism.md
View File

@ -1,160 +0,0 @@
# Use VIEWs with JOIN into Permission-Assignments for Row-Level-Security
**Status:**
- [x] proposed by Michael Hönnig
- [ ] accepted by (Participants)
- [ ] rejected by (Participants)
- [ ] superseded by (superseding ADR)
## Context and Problem Statement
We need to decide how to apply the access rules defined in our RBAC system to the visibility of table rows for the accessing user.
The core problem here is, that in our RBAC system, determining the permissions of the accessing user has to consider a hierarchy of roles.
### Technical Background
The session variable `hsadminng.currentUser` contains the accessing (domain-level) user, which is unrelated to the PostgreSQL user).
Given is a stored function `isPermissionGrantedToSubject` which detects if the accessing user has a given permission (e.g. 'view').
Given is also a stored function `queryAllPermissionsOfSubjectId` which returns the flattened view to all permissions assigned to the given accessing user.
In the following code snippets `customer` is just an example domain table.
## Considered Options
* Perform Visibility-Checks programmatically in the Backend
* Add Visibility-Checks in the Backend
* POLICY with ENABLE ROW LEVEL SECURITY
* VIEW-RULE with ON SELECT DO INSTEAD
* VIEW with JOIN into Flattened Permissions
### Perform Visibility-Checks programmatically in the Backend
In this solution, the database ignores row level visibility and returns all rows which match a given query. Afterwards, the result is filtered programmatically with Java-code in the backend.
#### Advantages
Very flexible access, programmatic, rules could be implemented.
The role-hierarchy and permissions for currently logged-in users user could be cached in the backend.
The access logic can be tested in pure Java unit tests.
At least regarding this aspect, an in-memory database could be used for integration testing; though the recursive Role-evaluation uses PostgreSQL features anyway.
#### Disadvantages
It's inefficient when initial query is not very restrictive, e.g. as on overview pages in a frontend, which often show all accessible objects, large parts or even whole database tables need to be transferred from the database to the backend.
It's error-prone and security leaks can happen too easily, because after every query the access rights for all participating joins have to be considered.
### Add Visibility-Checks in the Backend
In this solution again, the database ignores row level visibility and returns all rows which match a given query. And the backend adds filter conditions to each query sent to the database.
#### Advantages
At least regarding this aspect, an in-memory database could be used for integration testing.
#### Disadvantages
It's error-prone and security leaks can happen too easily, because for every query the access rights for all participating joins have to be considered.
### POLICY with ENABLE ROW LEVEL SECURITY
For restricted DB-users, which are used by the backend, access to rows is filtered using a policy:
SET SESSION AUTHORIZATION DEFAULT;
CREATE ROLE restricted;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO restricted;
ALTER TABLE customer ENABLE ROW LEVEL SECURITY;
CREATE POLICY customer_policy ON customer
FOR SELECT
TO restricted
USING (
isPermissionGrantedToSubject(findPermissionId('customer', id, 'view'), currentUserId())
);
SET SESSION AUTHORIZATION restricted;
SET hsadminng.currentUser TO 'alex@example.com';
SELECT * from customer; -- will only return visible rows
#### Advantages
Using POLICY together with ENABLE ROW LEVEL SECURITY is the PostgreSQL native mechanism to control access to data on the role level. Therefore, it looked like an obvious and elegant solution.
Every access at from the backend is under access control at the database level.
### Disadvantages
Unfortunately security mechanisms in PostgreSQL prevent the query optimizer to work well beyond ownership barriers (session user vs. table owner) and a SELECT from a table with 1 million objects needed over 30 seconds with our hierarchical RBAC policy.
We are bound to PostgreSQL, including integration tests and testing the RBAC system itself.
### VIEW-RULE with ON SELECT DO INSTEAD
SET SESSION SESSION AUTHORIZATION DEFAULT;
CREATE VIEW cust_view AS
SELECT * FROM customer;
CREATE OR REPLACE RULE "_RETURN" AS
ON SELECT TO cust_view
DO INSTEAD
SELECT * FROM customer WHERE isPermissionGrantedToSubject(findPermissionId('customer', id, 'view'), currentUserId());
SET SESSION AUTHORIZATION restricted;
SET hsadminng.currentUser TO 'alex@example.com';
SELECT * from customer; -- will only return visible rows
#### Advantages
Every access at from the backend is under access control at the database level.
Also using ON UPDATE etc., original tables could be completely hidden from the backend, and thus improved security.
### Disadvantages
Unfortunately security mechanisms in PostgreSQL prevent the query optimizer to work well beyond ownership barriers (session user vs. table owner) and a SELECT from a table with 1 million objects needed over 30 seconds with our hierarchical RBAC policy.
We are bound to PostgreSQL, including integration tests and testing the RBAC system itself.
An extra view needed for every table.
### VIEW with JOIN into flattened permissions
We do not access the tables directly from the backend, but via views which join the flattened permissions
SET SESSION SESSION AUTHORIZATION DEFAULT;
CREATE OR REPLACE VIEW cust_view AS
SELECT c.id, c.reference, c.prefix
FROM customer AS c
JOIN queryAllPermissionsOfSubjectId(currentUserId()) AS p
ON p.tableName='customer' AND p.rowId=c.id AND p.op='view';
GRANT ALL PRIVILEGES ON cust_view TO restricted;
SET SESSION SESSION AUTHORIZATION restricted;
SET hsadminng.currentUser TO 'alex@example.com';
SELECT * from cust_view; -- will only return visible rows
Alternatively the JOIN could also be applied in a "ON SELECT DO INSTEAD"-RULE, if there is any advantage for later features.
#### Advantages
Every access at from the backend is under access control at the database level.
No special PostgreSQL features needed; though the recursive Role-evaluation uses PostgreSQL features anyway.
Very fast, on my laptop a SELECT * FROM a table with 1 million rows just took about 50ms.
Also using ON UPDATE etc., original tables could be completely hidden from the backend, and thus improved security.
### Disadvantages
An extra view needed for every table.
## Decision Outcome
We chose the option **"VIEW with JOIN into flattened permissions"** because it supports the best combination of performance and security with almost no disadvantge.

19
doc/test-concept.md
View File

@ -11,22 +11,11 @@
### General Issues ### General Issues
The following test concept uses the terms "double" and "mock" (maybe in inflected form like "mocking" or "mocked"), "whitebox-test" and "blackbox-tests" which I would like to define first. The following test concept uses terms like "double" and "mock" (maybe in inflected form like "mocking" or "mocked"), "whitebox-test" and "blackbox-tests" and "test-fixture".
Please look up their definition in the [glossary](glossary.md)
#### Test-Doubles, Dummies, Fakes, Mocks, Spies and Stubs
A "double" is a general term for something which replaces a real implementation of a dependency of the unit under test.
This can be a "dummy", a "fake", a "mock", a "spy" or a "stub".
Often the term "mock" is used in a generic way, because typical mocking libraries like *Mockito* can also be used as dummies or spies and can replace fakes.
A fake would be a double without using any library, but rather a manual fake implementation of a dependency.
Where our APIs should be designed in a way that it's possible, using a mocking library like *Mockito* often leads to shorter test code. Where our APIs should be designed in a way that it's possible, using a mocking library like *Mockito* often leads to shorter test code.
#### Whitebox- and Blackbox-Tests
A whitebox-test knows and considers the internals of an implementation, e.g. it knows which dependencies it needs and can test special, implementation-dependent cases.
A blackbox-test does not know and not consider such internals of an implementation, it just tests externally observable behaviour.
### Kinds of Tests ### Kinds of Tests
@ -35,7 +24,9 @@ Depending on the concrete aspects which we want to test, we are using different
#### Unit-Tests #### Unit-Tests
In this project a *Unit* for *UnitTests* can be a single method (function), a class or even a group of classes which express a common concept. In this project a *Unit* for *UnitTests* can be a single method (function), a class or even a group of classes which express a common concept.
The unit are whitebox-tests and count into test-code-coverage.
The unit are technically whitebox-tests and count into test-code-coverage.
But the whitebox-knowledge should only be used for the text-fixture.
Unit-Test in this project are implemented with *JUnit Jupiter*, *Mockito* and *AssertJ*. Unit-Test in this project are implemented with *JUnit Jupiter*, *Mockito* and *AssertJ*.

22
tools/todo-progress Executable file
View File

@ -0,0 +1,22 @@
#!/bin/bash
declare -a required=(gnuplot sponge)
for cmd in "${required[@]}"; do
command -v $cmd >/dev/null 2>&1 || { echo >&2 "Required '$cmd' not installed => aborting."; exit 1; }
done
let budget=`grep '^| ... |' <TODO.md | rev | cut -d'|' -f4 | rev | grep -o '[[:digit:]]*' | total`
let effort=`grep '^| ... |' <TODO.md | rev | cut -d'|' -f3 | rev | grep -o '[[:digit:]]*' | total`
let output=`grep '^| ... |' <TODO.md | rev | cut -d'|' -f2 | rev | grep -o '[[:digit:]]*' | total`
let remainder=$(expr $budget - $output)
echo '<!-- generated todo-progress begin: -->' >.todo-progress.md
sed -e '1,/todo-progress begin:/d' -e '/todo-progress end./,$d' TODO.md >>.todo-progress.md
echo "| $(date --iso-8601) | $(printf "%6d" $budget) | $(printf "%7d" $effort) | $(printf "%8d" $output) | $(printf "%10d" $remainder) |" >>.todo-progress.md
echo '<!-- generated todo-progress end. -->' >>.todo-progress.md
uniq <.todo-progress.md | sponge .todo-progress.md
sed -i -e '/todo-progress begin:/,/todo-progress end./!b' -e '/todo-progress end./!d;r .todo-progress.md' -e 'd' TODO.md
sed -e's/^|//' <.todo-progress.md | tr '|' ';' | grep -v '|---' >.todo-progress.csv
gnuplot tools/todo-progress.gnuplot
rm .todo-progress.md .todo-progress.csv

23
tools/todo-progress.gnuplot Normal file
View File

@ -0,0 +1,23 @@
set xdata time # x-axis values are time (date) values
set timefmt "%Y-%m-%d" # date value format
set datafile separator ";" # CSV column separator is semicolon
set key autotitle columnhead # first data line contains column titles
set format x "%y-%m-%d" # display date format
set xrange ["2022-07-11":"2022-10-31"] # x-axis value-range
set yrange [0:600] # y-axis value-range
set key inside # graph legend style
set xtics rotate by -45 # rotate dates on x-axis 45deg for cleaner display
set title 'hsadmin-ng Projektfortschritt' # graph title
set terminal png # output format
set term png size 920, 640 # output canvas size
set output 'TODO-progress.png' # output file name
plot '.todo-progress.csv' using 1:2 with linespoints linetype rgb "black" linewidth 2, \
'' using 1:3 with linespoints linetype rgb "red" linewidth 2, \
'' using 1:4 with linespoints linetype rgb "green" linewidth 2, \
'' using 1:5 with linespoints linetype rgb "blue" linewidth 2