docu: Readme vervollständigen

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.
+## Vorbemerkung
 
-Das genaue Vorgehen wird in der Readme bzw. per UML festgelegt.
+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.