From e3721770346c19a9ad973915083c0209cf64f94b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torsten=20L=C3=BCcke?= Date: Tue, 29 Mar 2022 18:37:21 +0200 Subject: [PATCH 1/3] =?UTF-8?q?docu:=20Readme=20vervollst=C3=A4ndigen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 64 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index c890f34..5d96a50 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,66 @@ # OTP-Login -In Vereinen ist es wichtig, Helfern für eine bestimmte Zeit CRUD-Rechte zu geben. Es ist meist nicht notwendig, dass der Helfer dazu unbedingt einen Account benötigt. - -Das genaue Vorgehen wird in der Readme bzw. per UML festgelegt. \ No newline at end of file +## Vorbemerkung + +Bei Veranstaltungen kommt es oft vor, dass Clients (Browser auf Endgeräten) zeitweilig für Zugriffe freigegeben werden müssen. Dabei ist es oft nicht möglich auf den Clients alle Sicherheitsaspekte zu beachten (meist sind es private Endgeräte). Gerade Vereine sind auf die Bereitstellung privater Möglichkeiten angewiesen. Auch ist es nicht garantiert, dass der Nutzer diese Rechte jedes Mal identisch braucht. + +Das aktuelle Vorgehen wäre es, dem Nutzer einen Account zu geben. Dabei hat man aber nur eine geringe Kontrolle des Passwortes und wie oben gesagt der Clients-Sicherheit. Je mehr Rechte der User bekommt, umso anfälliger wird der Server für absichtliches wie unabsichtliches Fehlverhalten. Ausserdem entstehen so eine Unmenge an Accounts, die nicht mehr ordentlich gewartet werden können. Das verschärft die Sicherheitsprobleme witer. + +Als weiteres Problem kommt hinzu, dass das technische Verständnis der Nutzer nicht immer perfekt ist, um auch eine Account-Sicherheit zu gewährleisten. Das Betrifft zum Beispiel: + +* aufschreiben des Passwortes +* weitergabe des Passwortes an weitere Personen + +Aus diesen Gründen ist das aktuelle Vorgehen nicht sicher genug. + +## Einfache Beschreibung + +Ganz ohne Accounts geht es nicht. Dabei gibt es nur zwei Gruppen. IT-Administratoren und Veranstaltung-Administratoren. Ein IT-Administrator kann einen Veranstaltung-Administrator Rechte geben, um Clients eine oder mehrere Rollen zu geben. Diese Client-Rechte sind Zeitlich begrenzt. Der Account eines Veranstaltung-Administrator ist nicht begrenzt. + +### IT-Administratoren + +* kann Veranstaltung-Administratoren anlegen +* hat erweitertes technisches Verständnis +* kann Clients vorzeitig entfernen + +### Veranstaltung-Administrator + +* kann Clients freischalten +* allgemeines technisches Verständnis reicht aus + +### Clients + +* es wird nur ein Browser des Endgerätes freigeschaltet +* die Freischaltung ist von vorne rein zeitlich begrenzt + +## Detaillierter Ablauf + +### Phase I + +Ein schon angemeldeter IT-Administrator meldet einen Veranstaltung-Administrator beim System an. Der Veranstaltung-Administrator bekommt die Daten für eine OTP-App und einen Benutzernamen. + +### Phase II + +Ein Veranstaltung-Administrator entscheidet sich, ein Client für eine oder mehrere Rollen freizugeben. Dazu geht er im Browser auf die Freigabe-Seite. Dort muss er folgende Daten Eingeben: + +* Name des Clients +* Rolle bzw Rollen des Clients +* Benutzername des Veranstaltung-Administrators +* gültiges OTP + +Es wird ein *JSON-Web-Token* im Browser als Cookie gespeichert. Dieser Token hat ein Verfallsdatum. + +### Phase III + +Der Nutzer des Clients möchte eine Web-API-Aktivität ausführen über die Weboberfläche ausführen. Dazu sendet die Weboberfläche per JavaScript eine Anfrage an die Web-API, bei der der *JSON-Web-Token* mitgesendet wird. +Die Web-API überprüft durch den Login-Server die Korrektheit des Tokens. Dann wird die Rolle des Clients ausgewertet und entsprechend das Ergebnis zurückgegeben. + +* HTTP-Code-2XX: Anfrage erfolgreich +* HTTP-Code-403: Die Aktion ist nicht erlaubt +* HTTP-Code-401: Der Client hat überhaupt keine *JSON-Web-Token* + +## Bekannte Probleme + +Ein Veranstaltung-Administrator wird nur durch ein OTP geschützt. Es ist **keine** Zwei-Faktor-Authentifizierung. +Dadurch wird aber auch die Sicherheit des Clients unproblematisch, da der Client nur ein OTP bekommt, dass nur eine kurze Zeit gültig ist. +Des Weiteren werden die Server nur für die Dauer der Veranstaltung laufen. \ No newline at end of file From cc50434f02a4bab65646921846b65a5313e97347 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torsten=20L=C3=BCcke?= Date: Wed, 30 Mar 2022 13:22:51 +0200 Subject: [PATCH 2/3] docu: Zur Verdeutlichung des Vorgehen UML schreiben --- resources/uml/Ablauf/Phase-I.puml | 21 +++++++++++ resources/uml/Ablauf/Phase-II.puml | 29 +++++++++++++++ .../uml/Ablauf/Phase-III-Token-auswerten.puml | 36 +++++++++++++++++++ resources/uml/Ablauf/Phase-III.puml | 28 +++++++++++++++ resources/uml/Komponenten.puml | 30 ++++++++++++++++ 5 files changed, 144 insertions(+) create mode 100644 resources/uml/Ablauf/Phase-I.puml create mode 100644 resources/uml/Ablauf/Phase-II.puml create mode 100644 resources/uml/Ablauf/Phase-III-Token-auswerten.puml create mode 100644 resources/uml/Ablauf/Phase-III.puml create mode 100644 resources/uml/Komponenten.puml diff --git a/resources/uml/Ablauf/Phase-I.puml b/resources/uml/Ablauf/Phase-I.puml new file mode 100644 index 0000000..a3652f0 --- /dev/null +++ b/resources/uml/Ablauf/Phase-I.puml @@ -0,0 +1,21 @@ +@startuml +'https://plantuml.com/sequence-diagram + +actor Veranstalter +actor IT +boundary "Auth-Website" as AuthUI +control "Auth-API" as AuthAPI +database "Auth-Datenbank" as AuthDB + +Veranstalter -> IT : anfrage Account +activate AuthUI +IT -> AuthUI : Login +IT -> AuthUI : Neuer //Veranstalter// +Veranstalter -> AuthUI : Angabe Benutzername +AuthUI -> AuthAPI : Erstellung //Veranstalter// +AuthAPI -> AuthAPI : Erstellung //OPT-Token// +AuthAPI -> AuthDB : Speicherung der Daten des //Veranstalter// +AuthUI <-- AuthAPI : OTP-Token für die //OTP-App// +Veranstalter <--AuthUI : OTP-Token für die //OTP-App// + +@enduml \ No newline at end of file diff --git a/resources/uml/Ablauf/Phase-II.puml b/resources/uml/Ablauf/Phase-II.puml new file mode 100644 index 0000000..a63729d --- /dev/null +++ b/resources/uml/Ablauf/Phase-II.puml @@ -0,0 +1,29 @@ +@startuml +'https://plantuml.com/sequence-diagram + +actor Veranstalter +actor Client +boundary "Auth-Website" as AuthUI +control "Auth-API" as AuthAPI +control "OTP-API" as OTP +database "Auth-Datenbank" as AuthDB + +Veranstalter -> Client : Anfrage mitarbeit? +Client -> AuthUI : Aufruf Webseite Login +Veranstalter -> AuthUI : Eintragung //Benutzername//-Client +Veranstalter -> AuthUI : Eintragung //Benutzername//-Veranstalter +Veranstalter -> AuthUI : Eintragung Rollen-Client +Veranstalter -> AuthUI : Eintragung gültiges //OPT// +AuthUI -> AuthAPI : Anfrage nach //Web-Token// +AuthAPI -> AuthDB : Anfrage nach Veranstalter-Daten +AuthAPI -> OTP : Prüfung OTP +return +alt OTP ist ok + AuthAPI -> AuthDB : Speichere Daten + AuthAPI -> AuthAPI : Erstelle //Web-Token// + AuthUI <-- AuthAPI : //Web-Token// + Client <-- AuthUI : //Web-Token// +else OTP ist nicht ok + AuthUI <-- AuthAPI : HTTP-Error 401 +end +@enduml \ No newline at end of file diff --git a/resources/uml/Ablauf/Phase-III-Token-auswerten.puml b/resources/uml/Ablauf/Phase-III-Token-auswerten.puml new file mode 100644 index 0000000..e07d58e --- /dev/null +++ b/resources/uml/Ablauf/Phase-III-Token-auswerten.puml @@ -0,0 +1,36 @@ +@startuml +'https://plantuml.com/activity-diagram-beta + +start +:Client möchte App-Server abfragen; +:Client sendet Token> +partition App-Server { + if (Token nicht in der Datenbank) then (Ja) + :Sende Token an Auth-Server> + partition Auth-Server { + :Überprüfe Token| + :Sende Ergebnis< + } + if (Token ist gültig) then (Ja) + :Speichere Token und Verfallsdatum + in Datenbank/ + else + :Sende HTTP-Code 401< + stop + endif + else + if (Token ist verfalle) then (Ja) + :Sende HTTP-Code 401< + stop + endif + endif + :Rolle aus Token überprüfen] + if (Rolle erlaubt Abfrage) then (Ja) + :Abfrage ausführen| + else + :Sende HTTP-Code 403< + endif +} +stop + +@enduml diff --git a/resources/uml/Ablauf/Phase-III.puml b/resources/uml/Ablauf/Phase-III.puml new file mode 100644 index 0000000..295bd67 --- /dev/null +++ b/resources/uml/Ablauf/Phase-III.puml @@ -0,0 +1,28 @@ +@startuml +'https://plantuml.com/sequence-diagram + +actor Client +boundary "App-Website" as AppUI +control "App-Rest-API" as AppAPI + +Client -> AppUI : Anfrage an Webseite +AppUI -> AppAPI : Anfrage an Webseite +Client --> AppUI : //Web-Token// +AppUI --> AppAPI : //Web-Token// +AppAPI -> AppAPI : //Web-Token// überprüfen +alt //Web-Token// ist gültig + AppAPI -> AppAPI : Client-Rolle überprüfen + alt Rolle ist gültig + AppAPI -> AppAPI : Anfrage auswerten + AppUI <-- AppAPI : + Client <-- AppUI : + else + AppUI <- AppAPI : HTTP-Code 403 + Client <- AppUI : HTTP-Code 403 + end +else + AppUI <- AppAPI : HTTP-Code 401 + Client <- AppUI : HTTP-Code 401 +end + +@enduml diff --git a/resources/uml/Komponenten.puml b/resources/uml/Komponenten.puml new file mode 100644 index 0000000..0866f50 --- /dev/null +++ b/resources/uml/Komponenten.puml @@ -0,0 +1,30 @@ +@startuml +'https://plantuml.com/component-diagram + + +node Webseite { + component UI + folder Cookies + UI <--> Cookies +} +node "App-API" { + component API + database "DB" as AppDB { + folder "Clients" as BekannteClients + } + API <--> AppDB +} +node "Auth-API" { + component "API" as AuthAPI + database "DB" as AuthDB{ + folder "Administratoren" + folder "Veranstalter" + folder "Clients" + } + AuthAPI <--> AuthDB +} + +UI <-> API +API <-> AuthAPI + +@enduml \ No newline at end of file From 1ccf0133dbe380d6e3c7867456175059a331453b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torsten=20L=C3=BCcke?= Date: Tue, 5 Apr 2022 11:23:33 +0200 Subject: [PATCH 3/3] docu: Verbessere die Lesbarkeit --- README.md | 44 ++++++++++++++++++++++++++++++++------------ 1 file changed, 32 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 5d96a50..ceeaffb 100644 --- a/README.md +++ b/README.md @@ -2,9 +2,9 @@ ## Vorbemerkung -Bei Veranstaltungen kommt es oft vor, dass Clients (Browser auf Endgeräten) zeitweilig für Zugriffe freigegeben werden müssen. Dabei ist es oft nicht möglich auf den Clients alle Sicherheitsaspekte zu beachten (meist sind es private Endgeräte). Gerade Vereine sind auf die Bereitstellung privater Möglichkeiten angewiesen. Auch ist es nicht garantiert, dass der Nutzer diese Rechte jedes Mal identisch braucht. +Bei Veranstaltungen kommt es oft vor, dass Clients (Browser auf Endgeräten) zeitweilig für Zugriffe freigegeben werden müssen. Dabei ist es oft nicht möglich, auf den Clients alle Sicherheitsaspekte zu beachten. Meist sind es private Endgeräte, da gerade Vereine auf die Bereitstellung privater Möglichkeiten angewiesen sind. Auch ist es nicht garantiert, dass der Nutzer diese Rechte jedes Mal identisch braucht. -Das aktuelle Vorgehen wäre es, dem Nutzer einen Account zu geben. Dabei hat man aber nur eine geringe Kontrolle des Passwortes und wie oben gesagt der Clients-Sicherheit. Je mehr Rechte der User bekommt, umso anfälliger wird der Server für absichtliches wie unabsichtliches Fehlverhalten. Ausserdem entstehen so eine Unmenge an Accounts, die nicht mehr ordentlich gewartet werden können. Das verschärft die Sicherheitsprobleme witer. +Das aktuelle Vorgehen ist es, dem Nutzer einen Account zu geben. Dabei hat man aber nur eine geringe Kontrolle des Passwortes und wie oben gesagt der Clients-Sicherheit. Je mehr Rechte der User bekommt, umso anfälliger wird die IT-Infrastruktur für absichtliches wie unabsichtliches Fehlverhalten. Ausserdem entstehen so eine Unmenge an Accounts, die nicht mehr ordentlich gewartet werden können. Das verschärft die Sicherheitsprobleme weiter. Als weiteres Problem kommt hinzu, dass das technische Verständnis der Nutzer nicht immer perfekt ist, um auch eine Account-Sicherheit zu gewährleisten. Das Betrifft zum Beispiel: @@ -13,17 +13,37 @@ Als weiteres Problem kommt hinzu, dass das technische Verständnis der Nutzer ni Aus diesen Gründen ist das aktuelle Vorgehen nicht sicher genug. -## Einfache Beschreibung +## Begrifflichkeiten -Ganz ohne Accounts geht es nicht. Dabei gibt es nur zwei Gruppen. IT-Administratoren und Veranstaltung-Administratoren. Ein IT-Administrator kann einen Veranstaltung-Administrator Rechte geben, um Clients eine oder mehrere Rollen zu geben. Diese Client-Rechte sind Zeitlich begrenzt. Der Account eines Veranstaltung-Administrator ist nicht begrenzt. +### OTP + +Ausgeschrieben "One-Time-Password". Ist ein nur kurze Zeit gültiges Passwort, dass meist bei der Zwei-Faktor-Authentifizierung Anwendung findet. + +[Wikipedia - Einmalkennwort](https://de.wikipedia.org/wiki/Einmalkennwort) + +### Client + +Damit ist der Browser auf dem Endgerät eines Nutzers gemeint. + +### Veranstalter + +Verantwortliche für die Veranstaltung. Dieser Personenkreis hat am besten den Überblick über mögliche Mitarbeiter bei der Veranstaltung. ### IT-Administratoren -* kann Veranstaltung-Administratoren anlegen +Die Verantwortlichen für die IT-Infrastruktur, die bei der Veranstaltung eingesetzt wird. + +## Einfache Beschreibung + +Ganz ohne Accounts geht es nicht. Dabei gibt es nur zwei Gruppen. IT-Administratoren und Veranstalter. Ein IT-Administrator kann einen Veranstalter Rechte geben, um Clients eine oder mehrere Rollen zu geben. Diese Client-Rechte sind Zeitlich begrenzt. Der Account eines Veranstalters ist nicht begrenzt. + +### IT-Administratoren + +* kann Veranstalter anlegen * hat erweitertes technisches Verständnis * kann Clients vorzeitig entfernen -### Veranstaltung-Administrator +### Veranstalter * kann Clients freischalten * allgemeines technisches Verständnis reicht aus @@ -37,22 +57,22 @@ Ganz ohne Accounts geht es nicht. Dabei gibt es nur zwei Gruppen. IT-Administrat ### Phase I -Ein schon angemeldeter IT-Administrator meldet einen Veranstaltung-Administrator beim System an. Der Veranstaltung-Administrator bekommt die Daten für eine OTP-App und einen Benutzernamen. +Ein schon angemeldeter IT-Administrator meldet einen Veranstalter beim System an. Der Veranstalter bekommt die Daten für eine OTP-App und einen Benutzernamen. ### Phase II -Ein Veranstaltung-Administrator entscheidet sich, ein Client für eine oder mehrere Rollen freizugeben. Dazu geht er im Browser auf die Freigabe-Seite. Dort muss er folgende Daten Eingeben: +Ein Veranstalter entscheidet sich, ein Client für eine oder mehrere Rollen freizugeben. Dazu geht er im Browser auf die Freigabe-Seite. Dort muss er folgende Daten Eingeben: * Name des Clients * Rolle bzw Rollen des Clients -* Benutzername des Veranstaltung-Administrators +* Benutzername des Veranstalters * gültiges OTP Es wird ein *JSON-Web-Token* im Browser als Cookie gespeichert. Dieser Token hat ein Verfallsdatum. ### Phase III -Der Nutzer des Clients möchte eine Web-API-Aktivität ausführen über die Weboberfläche ausführen. Dazu sendet die Weboberfläche per JavaScript eine Anfrage an die Web-API, bei der der *JSON-Web-Token* mitgesendet wird. +Der Nutzer des Clients möchte eine Web-API-Aktivität über die Weboberfläche ausführen. Dazu sendet die Weboberfläche per JavaScript eine Anfrage an die Web-API, bei der der *JSON-Web-Token* mitgesendet wird. Die Web-API überprüft durch den Login-Server die Korrektheit des Tokens. Dann wird die Rolle des Clients ausgewertet und entsprechend das Ergebnis zurückgegeben. * HTTP-Code-2XX: Anfrage erfolgreich @@ -61,6 +81,6 @@ Die Web-API überprüft durch den Login-Server die Korrektheit des Tokens. Dann ## Bekannte Probleme -Ein Veranstaltung-Administrator wird nur durch ein OTP geschützt. Es ist **keine** Zwei-Faktor-Authentifizierung. +Ein Veranstalter wird nur durch ein OTP geschützt. Es ist **keine** Zwei-Faktor-Authentifizierung. Dadurch wird aber auch die Sicherheit des Clients unproblematisch, da der Client nur ein OTP bekommt, dass nur eine kurze Zeit gültig ist. -Des Weiteren werden die Server nur für die Dauer der Veranstaltung laufen. \ No newline at end of file +Des Weiteren laufen die Server nur für die Dauer der Veranstaltung. Auch das entschärft die Probleme. \ No newline at end of file