Alle unter einem Dach
Bisher erfolgte der Login bei uns über den selbstgewählten Benutzernamen. Das unterstützen wir für bestehende Accounts auch weiterhin auf unbestimmte Zeit. Wer sich aber nun einen neuen Asteroid anlegt, für den gilt nun die E-Mail-Adresse zusammen mit dem selbst gewählten Passwort als Login - und der neu angelegte Asteroid ist dann der erste in einer Liste von potentiell mehreren, die über den gleichen Zugang verwaltet werden. Bestehende Asteroids können in diesen neuen, E-Mail-basierten Zugang importiert werden.
Moment mal - “Asteroid”?
Apropos, um möglicher Verwirrung vorzubeugen: Wir haben unsere Nomenklatur mal ein wenig geradegezogen. In der Vergangenheit haben wir von “Uberspace” gesprochen, wenn wir einen konkreten User-Account mit einem frei gewählten Usernamen auf einem unserer Linux-Server gemeint haben. Nun, mit der Möglichkeit, mehrere dieser… Accounts… unter einem… äh… Zugang anzulegen, haben wir festgestellt, dass es wirklich verwirrend wird, von Usern, Accounts, Logins, Zugängen, etc. zu reden und den Begriff “Uberspace” irgendwie darauf zu mappen. Wir haben daraufhin beschlossen, einen bisher nur intern verwendeten Begriff nun auch in der Außenkommunikation zu verwenden: Einen eben jener User-Accounts auf unseren Linux-Systemen bezeichnen wir nun als “Asteroid”, und den E-Mail-basierten Zugang zu unserem Dashboard bezeichnen wir als “Uberspace” - oder um es in einem griffigen Satz unterzubringen: In deinem Uberspace kannst du beliebig viele Asteroids verwalten. Nebenbei ergibt unser Slogan “Hosting on Asteroids” damit nun sozusagen erstmalig wirklich Sinn. :-)
Accounts trennen - sinnvoll, aber nicht praktisch genug
Viele von euch haben nicht nur einen einzigen Asteroid bei uns, sondern gleich mehrere. Wir empfehlen dies auch schon immer, wenn nicht nur eine einzige Website oder Applikation bei uns gehostet werden soll, sondern mehrere: Klar ist es technisch möglich, sie alle in einen einzigen Asteroid zu stopfen, aber wer beispielsweise ein CMS für seine Website, einen Onlineshop und dazu noch Blog betreiben will und dafür drei verschiedene Applikationen installiert, ist vermutlich unglücklich, wenn eine Sicherheitslücke in einer der verwendeten Applikationen gleich auch noch die anderen beiden kompromittiert.
Wer mehrere Asteroids hat, der hat entsprechend viele Kombinationen von Benutzernamen und Passwörtern, und das kann… etwas unübersichtlich werden. Das betrifft auf der einen Seite die entsprechend vielen Login-Kennungen fürs Dashboard, auf der anderen Seite das Aufladen all jener Accounts. Ersteres haben wir nun grundlegend überarbeitet - und das dient wiederum als Vorbereitung dafür, dass auch Zweiteres in absehbarer Zeit realisierbar wird.
Strukturelle Veränderungen
Traditionell fragen wir bei der Registrierung den gewünschten Benutzernamen, ein Passwort sowie eine E-Mail-Adresse ab. Wir behandeln diese Angaben jetzt aber anders als vorher.
Bisher bildeten Benutzername und Passwort die Login-Kennung; die E-Mail-Adresse war eine Eigenschaft des so registrierten Asteroids. Wer fünf Asteroids wollte, musste diesen Registrierungsprozess entsprechend fünfmal durchlaufen.
Nun bildet aber die E-Mail-Adresse zusammen mit dem Passwort den Zugang zum Dashboard. Unter diesem Zugang können dann beliebig viele Asteroids verwaltet werden - der bei der Registrierung angegebene Benutzername wird schlicht automatisch der erste in dieser Liste. Werden weitere Asteroids gewünscht, werden diese künftig dann nicht mehr über die Registrierungsseite angelegt, sondern in der Asteroid-Übersicht im Dashboard, was dann den Schritt der Validierung der E-Mail-Adresse einspart - man ist ja bereits eingeloggt.
Um es als geänderte (vereinfachte) Datenbankstruktur darzustellen:
Die E-Mail-Adresse ist insofern nun keine unmittelbare Eigenschaft eines Asteroids mehr, sondern ergibt sich aus der Zugehörigkeit zu einer separaten Datenstruktur, die wir intern als “Metauser” bezeichnen, wobei wir uns bewusst dazu entschieden haben, diesen Begriff nur in unserer internen Kommunikation, aber nicht im Dashboard zu verwenden: Hier verwenden wir einfach Formulierungen wie “registriere dich mit deiner E-Mail-Adresse” oder “logge dich mit deiner E-Mail-Adresse ein”, die keiner weiteren Erklärung bedürfen sollten.
Was ist mit dem Altbestand?
Die Möglichkeit, sich mit dem Benutzernamen eines Asteroids und dem zugehörigen Passwort einzuloggen, besteht zunächst unverändert weiter - wir wollen niemandem den Zugang nehmen oder dazu antreiben, sich hier und jetzt eine neue Zugangsmöglichkeit anzulegen, nur weil wir uns gerade eben etwas Neues gedacht haben. Für Leute, die Uberspace zum ersten Mal benutzen, dürfte das neue Registrierungssystem intuitiv verständlich sein, zumal die Registrierung und dann auch der Login per E-Mail-Adresse von vielen anderen Diensten absolut gewohnt sein dürfte.
Diejenigen, die bereits Asteroids haben und einen neuen anlegen wollen, werden vielleicht erstmal etwas stolpern, wenn die Erwartungshaltung ist, dass alles so funktioniert wie immer. Das angedachte Vorgehen ist in diesem Fall:
- Sobald Bedarf an einem weiteren Asteroid besteht, wird jener über die Registrierungsseite angelegt. Dabei wird in diesem Zuge ein Metauser - sorry, das wollten wir ja nicht sagen - ein E-Mail-basierter Zugang angelegt und in diesem Zugang der eben registrierte Asteroid.
- Bestehende Asteroids können dann importiert werden. Dazu reicht es meist aus, den jeweiligen Benutzernamen anzugeben:
- Wenn der Asteroid die E-Mail-Adresse, mit der man sich gerade registriert bzw. eingeloggt hat, als Eigenschaft trägt, dann wird dieser direkt zugeordnet. Wir kennen ja bereits die E-Mail-Adresse und im Zuge der Registrierung zum E-Mail-basierten Zugang wurde diese auch bereits validiert. Das ist also ähnlich wie die “Passwort vergessen”-Funktion.
- Ist eine andere E-Mail-Adresse beim zu importierenden Asteroid hinterlegt, fragen wir im nächsten Schritt das Web-Passwort jenes Asteroids ab. Wird es korrekt angegeben, wird der Asteroid in die Account-Übersicht mit aufgenommen. Die bisher bei jenem hinterlegte Mailadresse wird dann mit der neuen überschrieben.
Nun mag es auch Menschen geben, die akut gar keinen weiteren Asteroid brauchen, aber dennoch von dem E-Mail-basierten Zugang profitieren wollen und ihre bestehenden Asteroids auf diese Weise zusammenfassen zu wollen. Hierfür gibt es nun unter dem Menüpunkt “Datenblatt” die Möglichkeit, auf den E-Mail-basierten Login umzustellen.
Warum nicht einfach automatisch alles zuordnen?
Wir hatten zwischenzeitlich auch daran gedacht, nach der Registrierung einer E-Mail-Adresse jener einfach automatisch alle Asteroids zuzuordnen, die jene E-Mail-Adresse tragen - also ohne dass dazu jeweils der Benutzername genannt werden müsste. Allerdings haben wir uns aus zwei Gründen dagegen entschieden und verlangen stattdessen einen expliziten Import: Wir sahen es als problematisch an, Leuten ganze Listen von Benutzernamen bereitzustellen, denn die Szenarien, wie Leute im realen Leben mit Asteroids arbeiten, haben sich regelmäßig als weitaus vielfältiger herausgestellt als wir uns vorstellen konnten, mit Szenarien wie “eine Agentur legt für ihre Kunden Asteroids an”, wobei einige dann eine E-Mail-Adresse der Agentur hinterlegen, andere aber eine E-Mail-Adresse des jeweiligen Kunden. Bevor wir hier durch Bereitstellung von Listen von Benutzernamen plötzlich für Überraschungen oder auch Irritationen sorgen, gehen wir lieber auf Nummer sicher und setzen voraus, dass ein Benutzername bereits bekannt sein muss, wenn er importiert werden soll. Für die Zukunft ist angedacht, auch die Aufladung - zumindest optional - über den Metauser zu regeln, so dass für 20 Accounts nicht mehr alle 20 einzeln aufgeladen werden müssen, sondern man lädt eben den Metauser auf, und alle zugeordneten Accounts bedienen sich an jenem. Hier wäre es dann fatal, wenn Dritte sich einen Asteroid auf fremde Kosten leisten, einfach in dem sie - im konventionellen Zugang per Benutzername - eine E-Mail-Adresse hinterlegen, die jemandem gehört, der ein gut gefülltes Guthabenkonto hat, und jener Person ihren Asteroid quasi “unterzuschieben”.
Wie geht’s weiter?
Zunächst einmal war uns wichtig, den E-Mail-basieren Zugang überhaupt erstmal einzuführen und zum Standard für neue Asteroids werden zu lassen. Für uns haben wir damit nun auch die Möglichkeit, Eigenschaften wie z.B. welche Sprache im Dashboard verwendet werden soll oder aus welchem Land jemand kommt (wichtig für die korrekte Umsatzsteuer-Berechnung) an einer zentralen Stelle hinterlegen zu lassen, anstatt das pro Asteroid immer wieder neu konfigurieren zu müssen.
Ein paar Dinge kommen auf jeden Fall noch sehr kurzfristig, die wir als “semi-kritisch” betrachten, die aber nicht den eigentlichen Start des Features verzögern sollten:
- die Möglichkeit, die E-Mail-Adresse auch zu ändern (sollte selbstverständlich sein)
- die Möglichkeit, Asteroids von einem Metauser an einen anderen Metauser übergeben zu können (da steht der Prozess noch nicht ganz fest)
- die Möglichkeit, Guthaben von Asteroids per Klick oder sogar automatisch bei Aufladung umverteilen zu können (einfachere Vorstufe zu zentraler Aufladung)
- die Möglichkeit, einen oder mehrere SSH-Keys in den Einstellungen hinterlegen zu können, die neue Asteroids dann automatisch hinterlegt bekommen (mehr Komfort - und wir wollen ohnehin zu mehr zur Nutzung von SSH-Keys statt Passwörtern motivieren)
Natürlich haben wir auch schon ein paar größere Ideen im Kopf, dazu gibt’s dann zu einem späteren Zeitpunkt mehr Infos.
OpenID: Ein Abschied auf Raten
Wir hatten zwar schon seit langem Support für OpenID in unserem Dashboard, so dass man beim Login mittels OpenID alle Asteroids im Überblick hatte, aber was sich einst angeschickt hatte, eine wirklich dezentrale Authentifizierung im Internet zu werden, ist über die Jahre mehr und mehr eingeschlafen; ein OpenID-Anbieter nach dem anderen hat seinen Dienst eingestellt. Das Nachfolgeprotokoll OpenID Connect wollten wir nicht wirklich implementieren; vor allem, weil es den entscheidenden Freiheitsaspekt vermissen lässt: Wir hätten uns bei allen Authentifizierungsanbietern, über die wir Logins ermöglichen wollen, erstmal selbst registrieren müssen und dafür eine Abhängigkeit eingehen müssen, die wir an dieser zentralen Stelle nicht wollten.
Dass die bisherigen OpenID-Anbieter ihre Dienste eingestellt haben, hat zu echten Problemen geführt, insbesondere für diejenigen, die ihren passwortbasierten Zugang nicht mehr kannten und die auch keine E-Mail-Adresse hinterlegt hatten (was früher optional war). Wenn nun der OpenID-Anbieter aber seinen Dienst einstellt, hatten auch wir letztlich keine Möglichkeit mehr, Leuten Zugang zu ihrem Account zu verschaffen, schlicht weil wir die Eigentumsverhältnisse nicht klären konnten. Das ist einer der Gründe, warum wir seit inzwischen geraumer Zeit die Angabe einer E-Mail-Adresse verpflichtend machen. Natürlich kann man auch den Zugriff auf eine Mailadresse verlieren, aber das ist in der Praxis eher selten - jedenfalls weitaus seltener als Leute, die bei uns im Support aufschlagen, weil ihr OpenID-Anbieter den Dienst abgekündigt hat oder sogar ohne Abkündigung eingestellt hat, was wir erst beim Debugging anhand eines abgelaufenen Zertifikats feststellen. Natürlich steht es einem frei, seinen eigenen OpenID-Service aufzusetzen (ggf. direkt auf dem eigenen Asteroid), aber das erscheint inzwischen zunehmend exotisch - und es wäre nicht das erste Mal, dass User sich selbst aus ihrem Account ausgeschlossen hätten, weil sie ihren eigenen OpenID-Service versehentlich kaputt gemacht haben.
Nach wie vor unterstützen wir auch weiterhin OpenID für den Login im Dashboard - nicht zuletzt, weil manche schlicht überhaupt keinen anderen Zugang haben. Wir haben inzwischen aber die Option gestrichen, neue OpenIDs hinterlegen zu können. Ganz ehrlich: OpenID ist tot. Sorry.
Was hat eigentlich so lange gedauert?
Zugegebenermaßen: Dass die Metauser so elend lange auf sich haben warten lassen, ist auch uns ziemlich unangenehm, immerhin stand eine Art Sammelzugang zur Verwaltung mehrerer Asteroids nicht nur bei vielen Usern schon lange auf der Wunschliste, sondern auch auf unserer eigenen, und dass OpenID hier nicht mehr die Perspektive bietet, die wir ihm einst zugeschrieben hatten, war uns längst bewusst geworden.
Einer der Hauptgründe ist, dass das Dashboard “Chefsache” ist. Was intuitiv erstmal nach besonders hoher Priorität klingt, ist hier durchaus in negativer Weise gemeint - und das sage ich selbst als eben jener Chef: Die bestehende Implementierung mittels Perl auf Basis des Catalyst-Frameworks (und allen Unkenrufen zum Trotz: sowohl Perl als auch Catalyst werden weiterhin aktiv entwickelt) ist zwar durchaus kein antiker Spaghetti-Code, sondern eine hübsche strukturierte Applikation auf Basis des Model-View-Controller-Konzepts, mit Templates und allem Schnick und Schnack, aber… es ist eben Perl, und damit von unserem Development-Team, das sich sehr auf Python eingeschossen hat, nicht trivial übernehmbar. Der ursprüngliche Plan sah vor, in absehbarer Zeit das Dashboard schlicht einmal komplett neu - mit Python/Django - zu implementieren, und in dieser Form von der Chefsache mit entsprechend niedrigem Truck Factor zu einer anständig von einem kompetenten Team gepflegten Applikation zu befördern. Das hatte zur Folge, dass lange Zeit viele Dashboard-bezogene Featurewünsche letztlich als “Das können wir ja dann im neuen Dashboard gleich sauber abbilden” zurückgestellt worden sind.
Nur: Die Zeit verstreicht erbarmungslos, und je näher das Ende der Lebenszeit von CentOS 7, auf der unsere Hostingplattform U7 basiert, rückt, desto wichtiger wurde es, dass wir unsere Development-Kapazitäten sehr bewusst auf die Entwicklung der Nachfolgeversion U8 konzentrieren. Da wir kein allzu großes Unternehmen sind, das problemlos mehrere Großprojekte gleichzeitig jonglieren kann, heißt das Schlüsselwort: Fokus. Und dieser Fokus lag dann entsprechend nicht mehr bei der Dashboard-Reimplementierung. Uns das einzugestehen, hat uns zugegebenermaßen viel Zeit und auch viel Zähneknirschen gekostet. Die Einführung des Metauser-Features im bisherigen Perl-Dashboard soll hier nun aber gewissermaßen den Startschuss dafür geben, sich doch auch wieder bewusst um unser Legacy-Dashboard zu kümmern und letztlich zukunftsgerichtete strukturelle Veränderungen nicht mehr länger zu verschieben, sondern bereits hier umzusetzen - letztlich auch im Hinblick darauf, dass eine spätere Migration auf ein ganz neues Dashboard auch davon profitieren wird, wenn Modernisierungen und damit entsprechende Umbauten von Prozessen und Datenstrukturen bereits stattgefunden haben und somit auch einen klareren Scope setzen. Insofern: Weiter geht’s!
Foto von Dieter de Vroomen auf Unsplash