Projekt:Heiko: Unterschied zwischen den Versionen
K (→Funktionsweise: typo fix) |
Noqqe (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| (11 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 13: | Zeile 13: | ||
Heiko ist ein Python Programm das eine interaktive Kommandozeilen Eingabe bereitstellt und via REST HTTP mit dem in Go geschriebenen Backend [[Projekt:Matomat-Service]] kommuniziert. | Heiko ist ein Python Programm das eine interaktive Kommandozeilen Eingabe bereitstellt und via REST HTTP mit dem in Go geschriebenen Backend [[Projekt:Matomat-Service]] kommuniziert. | ||
Es öffnet sich wenn man sich als User "heiko" auf dem Matomat einloggt automatisch ( | Es öffnet sich wenn man sich als User "heiko" auf dem Matomat einloggt automatisch (TTY2). | ||
== SSH Buchung == | |||
<pre> | |||
ssh heiko@matomat | |||
</pre> | |||
Pw ist das gleiche wie der User | |||
== Installation == | == Installation == | ||
Auf [[Host:matomat.intern.k4cg.org|matomat.intern.k4cg.org]] ist ein user <code>heiko</code> eingerichtet. | Auf [[Host:matomat.intern.k4cg.org|matomat.intern.k4cg.org]] ist ein user <code>heiko</code> eingerichtet. Dort liegen die Config, das Backup der alten Matomat Instanz und die <code>user_greetings</code> | ||
In der <code>/etc/passwd</code> muss die Login Shell auf <code>/ | In der <code>/etc/passwd</code> muss die Login Shell auf <code>/usr/local/bin/heiko</code> umgesetzt werden und das Passwort in <code>/etc/shadow</code> geleert sein. | ||
== Update == | == Update == | ||
<pre> | <pre> | ||
$ sudo -s | |||
# pip3 install --upgrade heiko | |||
</pre> | |||
== Setup auf TTY1 == | |||
Der Systemuser <code>heiko</code> hat in seinem Home den Source, Config und die Sounddateien vom Matomat Frontend. | |||
Details siehe [[Projekt:Heiko]] | |||
Das Commandline Matomat Interface läuft auf TTY1 | |||
<pre> | |||
# cat /etc/systemd/system/getty@tty1.service.d/override.conf | |||
[Service] | |||
Type=simple | |||
ExecStart= | |||
ExecStart=-/sbin/agetty --autologin heiko --noclear %I 38400 linux | |||
</pre> | </pre> | ||
== RFID Login == | |||
Leute wollen sich am Matomat mit RFID anmelden, weil war schon immer so. | |||
Wir haben 1 Reader und mehrere Karten | |||
=== Aus dem matomat-service === | |||
> What about RFID/NFC chip based “login” | |||
> | |||
> | |||
> This functionality has to be implemented by the client. The client would have to offer a eneroll functionality during which the user enters her credentials. Then a very high token validity time is chosen by the client application (months?) and a login operation - resulting in a JWT token - is performed against the service. The received token is then stored on the RFID/NFC chip. For subsequent “logins” the client only needs to read the token from the RFID/NFC chip and use it to authenticate its calls to the service. | |||
> | |||
=== Implementierungsidee === | |||
Heiko hat eine tinydb in der daten abgelegt werden, da wir nur einen Readonly Reader haben. Im Endeffekt wird der Kartenhash mit dem JWT und dem Username zusammen in ein JSON gelegt. | |||
User -> Karte mit ID 023421337 TTY1 ist der USB Card reader und der Leser gibt sich als Keyboard aus JWT ist das Login Token fürs Backend | |||
Login: 1. User hält karte hin 2. Heiko liesst karte via TTY1 3. Heiko sieht 023421337 4. Heiko Hashed das 023421337 (mit argon2[1]) 5. Heiko schaut in tinydb[2] ob hash da iwo liegt. 6. Heiko entschlüsselt mit 023421337 das JWT Token 7. Heiko loggt den user mit JWT ein der zum hash passt 8. User kann mate buchen | |||
Registirering | |||
1. User loggt sich mit password ein | |||
2. User waehlt option X zum registrieren einer RFID karte | |||
3. Heiko sagt: leg deine Karte auf den Leser | |||
4. User tut | |||
5. Heiko liesst TTY1 aus und findet nummer 023421337 | |||
6. Heiko sagt danke und hashed die Kartennummer mit argon2 | |||
7. Heiko speichert das mit 023421337 verschlüsselte JWT in tinydb | |||
8. Zurück zum Menü | |||
Datenstruktur | |||
``` | |||
[ | |||
{ | |||
user: bernd | |||
rfid: argon2(rfid) | |||
jwt: encrypt_with_rfid(jwt) | |||
}, | |||
{ | |||
[...] | |||
}, | |||
] | |||
``` | |||
Links | |||
[1] [GitHub - P-H-C/phc-winner-argon2: The password hash Argon2, winner of PHC](https://github.com/P-H-C/phc-winner-argon2) [2] [Welcome to TinyDB! — TinyDB 3.12.2 documentation](https://tinydb.readthedocs.io/en/latest/) | |||
Aktuelle Version vom 6. Dezember 2023, 08:41 Uhr
| Projekt:Heiko | |
| Betreuer*In | noqqe |
| Jahr | 2019 |
| Läuft auf | matomat.intern.k4cg.org |
| URL | https://github.com/k4cg/heiko |
Allgemeines
Dieser Eintrag beschreibt die Funktionsweise und das Setup von Heiko auf dem Matomat Laptop
Funktionsweise
Heiko ist ein Python Programm das eine interaktive Kommandozeilen Eingabe bereitstellt und via REST HTTP mit dem in Go geschriebenen Backend Projekt:Matomat-Service kommuniziert. Es öffnet sich wenn man sich als User "heiko" auf dem Matomat einloggt automatisch (TTY2).
SSH Buchung
ssh heiko@matomat
Pw ist das gleiche wie der User
Installation
Auf matomat.intern.k4cg.org ist ein user heiko eingerichtet. Dort liegen die Config, das Backup der alten Matomat Instanz und die user_greetings
In der /etc/passwd muss die Login Shell auf /usr/local/bin/heiko umgesetzt werden und das Passwort in /etc/shadow geleert sein.
Update
$ sudo -s # pip3 install --upgrade heiko
Setup auf TTY1
Der Systemuser heiko hat in seinem Home den Source, Config und die Sounddateien vom Matomat Frontend.
Details siehe Projekt:Heiko
Das Commandline Matomat Interface läuft auf TTY1
# cat /etc/systemd/system/getty@tty1.service.d/override.conf [Service] Type=simple ExecStart= ExecStart=-/sbin/agetty --autologin heiko --noclear %I 38400 linux
RFID Login
Leute wollen sich am Matomat mit RFID anmelden, weil war schon immer so.
Wir haben 1 Reader und mehrere Karten
Aus dem matomat-service
> What about RFID/NFC chip based “login” > > > This functionality has to be implemented by the client. The client would have to offer a eneroll functionality during which the user enters her credentials. Then a very high token validity time is chosen by the client application (months?) and a login operation - resulting in a JWT token - is performed against the service. The received token is then stored on the RFID/NFC chip. For subsequent “logins” the client only needs to read the token from the RFID/NFC chip and use it to authenticate its calls to the service. >
Implementierungsidee
Heiko hat eine tinydb in der daten abgelegt werden, da wir nur einen Readonly Reader haben. Im Endeffekt wird der Kartenhash mit dem JWT und dem Username zusammen in ein JSON gelegt.
User -> Karte mit ID 023421337 TTY1 ist der USB Card reader und der Leser gibt sich als Keyboard aus JWT ist das Login Token fürs Backend
Login: 1. User hält karte hin 2. Heiko liesst karte via TTY1 3. Heiko sieht 023421337 4. Heiko Hashed das 023421337 (mit argon2[1]) 5. Heiko schaut in tinydb[2] ob hash da iwo liegt. 6. Heiko entschlüsselt mit 023421337 das JWT Token 7. Heiko loggt den user mit JWT ein der zum hash passt 8. User kann mate buchen
Registirering
1. User loggt sich mit password ein 2. User waehlt option X zum registrieren einer RFID karte 3. Heiko sagt: leg deine Karte auf den Leser 4. User tut 5. Heiko liesst TTY1 aus und findet nummer 023421337 6. Heiko sagt danke und hashed die Kartennummer mit argon2 7. Heiko speichert das mit 023421337 verschlüsselte JWT in tinydb 8. Zurück zum Menü
Datenstruktur
``` [
{
user: bernd
rfid: argon2(rfid)
jwt: encrypt_with_rfid(jwt)
},
{
[...]
},
] ```
Links
[1] [GitHub - P-H-C/phc-winner-argon2: The password hash Argon2, winner of PHC](https://github.com/P-H-C/phc-winner-argon2) [2] [Welcome to TinyDB! — TinyDB 3.12.2 documentation](https://tinydb.readthedocs.io/en/latest/)
