Een werkomgeving is alleen één product als hij één voordeur heeft. Hoe Authentik één account bij zeven producten aanmeldt, wat identiteit voor meerdere klanten tegelijk werkelijk vraagt, en waarom de inlogdienst paranoia van mailniveau krijgt.
Een werkomgeving is alleen één product als hij één voordeur heeft. Mail, agenda, bestanden, chat, video, facturatie: begroet elk daarvan je team met een eigen wachtwoord, dan heb je geen werkomgeving gekocht, maar zeven gereedschappen en een spreadsheet met inloggegevens. Identiteit is dus de pijler waar al het andere aan hangt, en het is degene waar we het meest van keuze zijn gewisseld. Deel 4 van de reeks.
Elk product in onze verzameling bouwstenen heeft zijn eigen idee van wat een gebruiker is. De mailserver wil een gebruikersadministratie om tegen te controleren. De chatserver wil verteld worden wie bij welke organisatie hoort. De bestandsserver maakt accounts aan bij eerste gebruik. Het vergaderproduct wil een inlogtoken. Geen van hen is samen met de andere ontworpen, en het is onze taak ze te laten voelen alsof dat wel zo is.
Het antwoord is één identiteitsprovider waar al het andere naar verwijst. We hebben eerst twee andere systemen geprobeerd, ze lang genoeg gedraaid om de muren te vinden, en zijn uitgekomen op Authentik, dat het product sindsdien draagt. Het spreekt de twee talen die we nodig hebben: OIDC, het moderne protocol voor eenmalig aanmelden dat de webapplicaties gebruiken, en LDAP, het administratieprotocol dat de mailserver verwacht. Één systeem, één set accounts, twee dialecten.
Wat je team ervaart: één account per persoon, één wachtwoord, één plek om tweefactor in te stellen, en de webapplicaties melden je aan via dezelfde sessie. Meld je 's ochtends één keer aan en chat, vergaderingen en het dashboard gaan gewoon open. Voor mailprogramma's op de desktop, die IMAP spreken in plaats van browsersessies, kan iedereen app-wachtwoorden aanmaken: losse, intrekbare sleutels per apparaat, te beheren vanuit het dashboard, zodat een verloren laptop nooit betekent dat je je echte wachtwoord moet veranderen.
Een identiteitsprovider installeren is een middag. Hem veilig veel bedrijven tegelijk laten bedienen is het eigenlijke ingenieurswerk. Elke klant bij email.eu is een geïsoleerde huurder: jouw mensen, jouw groepen, jouw inlog, onzichtbaar voor elke andere huurder. Chat is het duidelijkste voorbeeld: elke klant krijgt een aparte omgeving met eigen geschiedenis en eigen leden, en elke omgeving vertrouwt precies de aanmeldingen van de accounts van díe klant, en van niemand anders.
Het andere dat we vroeg hebben geleerd is identiteitsconfiguratie als code behandelen. Uitnodigingsstromen, wachtwoordherstel, huisstijl, de verbindingen tussen applicaties en de administratie: het staat allemaal beschreven in blauwdrukken in versiebeheer en wordt uitgerold als elke andere wijziging, in plaats van in een beheerscherm aan elkaar geklikt. Aan elkaar geklikte configuratie is hoe je eindigt met een inlogsysteem dat niemand kan herbouwen of doorgronden. Het onze kan uit de repository gereconstrueerd worden, en wijzigingen eraan worden beoordeeld zoals codewijzigingen.
Een werkomgeving waar je niet in kunt is offline, wat de mailwachtrij ook zegt. De inlogdienst is dus naar dezelfde maatstaf gebouwd als het mailcluster. De identiteitsprovider draait met twee replica's. De databasemachinerie eronder is zo verdeeld dat geen enkele onderhoudsgebeurtenis beide kopieën kan raken, en de clusterplanner krijgt expliciet te horen welke paren nooit samen offline mogen, zodat bij routineonderhoud van onze cloudleverancier alles zijn quorum houdt en niemand iets merkt. Het gedrag bij opnieuw proberen is zo afgestemd dat een korte databaseonderbreking een hobbeltje blijft in plaats van te escaleren.
Upgrades krijgen dezelfde paranoia. Na elke wijziging aan de identiteitsprovider lopen we de hele ceremonie langs: aanmelden, afmelden, herstel, uitnodiging, want "de upgrade is gelukt" en "inloggen werkt" zijn verschillende beweringen, en maar één daarvan komt in een uitrollogboek terecht.
Je ziet identiteit zelden op een functievergelijkingspagina, en het bepaalt meer van je dagelijkse ervaring dan de meeste regels die er wel op staan. Het is het verschil tussen een nieuwe collega in één stap of in zeven aansluiten, tussen de toegang van een vertrokken medewerker op één plek intrekken of door beheerschermen jagen, tussen een verloren telefoon die een ongemak is en een die een incident is. Beoordeel je een werkomgeving, de onze inbegrepen, vraag dan waar de accounts wonen en wat er gebeurt als dat systeem een slechte dag heeft. Wij hebben ons antwoord opgeschreven.
Hierna deel 5: de infrastructuur onder dit alles, en waarom we hem zo saai hebben ontworpen als we konden.