Hi,
ich habe eine Frage zur Kelvin-API:
Bei der Authorisierung gibt man etwa über eine Config-Datei den Benutzernamen und das Passwort eines Benutzers der Gruppe ucsschool-kelvin-rest-api-admins an.
Das Passwort steht in der Config-Datei im Plaintext.
Kann man das verbessern, z.B. durch Übergabe eines PW-Hashes?
LG,
Roland.
Hallo,
Name und Passwort eines Users der Gruppe ucsschool-kelvin-rest-api-admins werden nur beim Request eines Tokens benötigt. Es ist nicht nötig sie irgendwo in UCS abzuspeichern.
LG
Daniel
Hi,
im UCS will ich es ohnehin nicht abspeichern, aber am externen System, welches die API aufruft, muss ich das Passwort angeben, um den Token anzufordern.
Dieser Aufruf findet automatisiert statt - das Passwort kann also nicht interaktiv abgefragt werden.
LG,
Roland.
Für den UCS@School ID-Connector ist allerdings die Konfiguration des sendenden Systems nur mit einem plaintext-Kennwort in der json dokumentiert.
https://docs.software-univention.de/ucsschool-id-connector/example_json.html#school-authority-mapping
Wobei ich jetzt natürlich nicht sagen kann, ob sich Roland auf genau diesen Punkt bezog.
Das aufrufende System (der Client) muss seine Zugangsdaten immer irgendwo abspeichern.
Ob es ein Zertifikat oder Passwort ist, spielt dabei keine Rolle. Wenn es den Zugang erlaubt, muss es geschützt werden. Soll es nicht-interaktiv verwendet werden, muss so ein Geheimnis irgendwo im Klartext stehen. Ein Hash eines Passworts ist nicht das Passwort, und kann deswegen nicht verwendet werden.
Eine Möglichkeit das nicht zu tun ist, es verschlüsselt abzuspeichern, beim Start einmalig ein Passwort interaktiv abzufragen und es dann im Speicher zu behalten. Das ist im Prinzip das, was Festplattenverschlüsselung tut. Anekdote: Ich denke Apache bietet das für SSL-Keys an.
Grüße
Daniel
Ja, danke Dirk. Genau das meinte ich.
Das es mit dem Hash nicht geht ist klar - war ein Denkfehler von mir.
Die Idee es beim Start eines Daemons abzufragen und ihn dann bis zum nächsten Reboot laufen zu lassen ist nicht schlecht, danke.
Man könnte es auch symmetrisch verschlüsseln und die private Keys der berechtigten Clients am UCS hinterlegen.
Danke jedenfalls für die Antwort.
LG,
Roland.
Moin,
als Tool für nichtinteraktive Passworteingaben kann ich pass sehr empfehlen, das speichert Geheimnisse GPG-verschlüsselt und kann in Kombination mit einem GPG-Agent oder einem Key ohne Passphrase sehr gut in Skripten o.ä. genutzt werden.
Alternativ bietet sich zumindest auf Desktops der Keyring/libsecret an.
Lieber Gruß
Jan-Luca
Super, danke. Das klingt auch sehr vielversprechend!
Aktuell werden die Passwörter für den ID Connector leider im Klartext abgespeichert. Das ist nicht schön. Es fehlt aber tatsächlich ein Konzept, wie das im Produkt verändert werden könnte.
Mal aus Neugier: wäre es für euch / eure Kunden denkbar, dass der ID Connector, nach dem Hochfahren des UCS Servers, so lange nicht funktioniert, bis ein Admin sich interaktiv eingeloggt hat, und das Passwort für die Entschlüsselung eines Schlüsselrings eingibt?
LG
Daniel
Ich habe derzeit zwei neue Projekte, welche die Kelvin-API nutzen möchten. Bei dem einen ist sowohl der Client wie auch die UCS@School-Server in einem abgesicherten Netz - da stört das nicht.
Beim zweiten kann ich mir gut vorstellen, dass manuelles Eingreifen nach jedem Reboot denkbar ist.