email.eu gebruiken als de inlog voor je eigen applicaties

Elk bedrijf draait uiteindelijk iets dat bij niemands suite hoort. Een eigen GitLab. Een projecttool. Een intern dashboard dat iemand heeft gebouwd. Een wiki die ouder is dan de huidige directie.

Elk daarvan komt met zijn eigen inlog, en vanaf die dag beheer je met de hand een klein identiteitssysteem. Iemand komt in dienst en je maakt vier accounts. Iemand vertrekt en je denkt aan drie ervan. Zes maanden later is er een account van iemand die in het voorjaar wegging, dat nog steeds kan inloggen, en niemand weet het omdat niemand keek.

Eenmalig aanmelden lost dit netjes op. Het probleem was altijd dat het kopen ervan een identiteitsleverancier betekent, een prijs per gebruiker bovenop je bestaande prijs per gebruiker, en een inkoopgesprek. Dus kleine bedrijven kopen het niet, en blijven vier inlogs met de hand beheren.

Werkomgevingen hebben al een identiteitssysteem. Het onze staat voor je open.

Wat je krijgt

Op het Business-abonnement kan een eigenaar of beheerder je eigen applicaties aanmelden voor eenmalig aanmelden, in een formulier, in ongeveer een minuut. Geen ticket bij ons, geen telefoontje, geen configuratiebestand dat wij voor je aanpassen.

Je geeft de applicatie een naam en het adres waarop hij terugkomt. Wij geven drie dingen terug die elke standaardapplicatie nodig heeft: een ontdekkings-URL, een client-id en een clientgeheim. De meeste software wil alleen de ontdekkings-URL en die twee gegevens, want die URL is een document dat al het overige beschrijft over hoe er met ons gesproken moet worden. Plak ze in de instellingen van de applicatie en je team meldt zich aan met zijn email.eu-account.

Het protocol is OpenID Connect, de moderne standaard hiervoor en wat zo goed als alles vandaag spreekt. We vragen je niet iets ongebruikelijks aan te nemen. Jouw applicatie ondersteunt dit al; hij wacht tot je drie velden invult.

Het geheim wordt één keer getoond, op het moment dat je het aanmaakt. Raakt het ooit kwijt of komt het naar buiten, dan roteer je het zelf, wat een nieuwe aanmaakt en het oude direct ongeldig maakt. Daar heb je ons niet voor nodig.

Het deel dat goed moet zijn: alleen jouw mensen

Hier is de eigenschap die dit veilig maakt om aan elke klant aan te bieden op een gedeeld identiteitssysteem, en het ding om te controleren wanneer iemand je eenmalig aanmelden voor meerdere klanten aanbiedt.

Elke applicatie die je aanmeldt wordt gebonden aan de eigen groep van jouw werkomgeving. Alleen leden van jouw werkomgeving kunnen zich erdoor aanmelden. Niet andere klanten van ons, niet iemand anders met een email.eu-identiteit, niet een vreemde die je terugkomstadres heeft gevonden. Zit iemand niet in jouw werkomgeving, dan is het antwoord nee, en die beslissing neemt het identiteitssysteem in plaats van dat de applicatie erop vertrouwt dat wij voorzichtig zijn geweest.

Die binding gebeurt automatisch als je de applicatie aanmaakt. Er is geen instelling om verkeerd te zetten, want een instelling die je verkeerd kunt zetten is een instelling die iemand verkeerd zal zetten.

De standaarden die we bewust hebben versmald

Twee dingen die we anders doen dan de standaardinstelling, beide het weten waard als je hier belang aan hecht.

Alleen de aanmeldstroom staat aan. Identiteitssystemen komen doorgaans met meerdere manieren om een token te krijgen, waaronder een paar oudere waarbij een applicatie de wachtwoorden van je gebruikers zelf verwerkt. Wij zetten de browserstroom aan en het vernieuwen van tokens, en niets anders. Jouw applicaties zien nooit een wachtwoord, want er is geen ondersteunde route waarlangs dat zou kunnen.

Terugkomstadressen zijn exact en moeten versleuteld zijn. We accepteren alleen https-adressen, en we leggen ze exact vast in plaats van als patroon. Ruime patronen op terugkomstadressen zijn een van de klassieke manieren waarop tokens ergens terechtkomen waar ze niet horen, en patroonvergelijking is het mechanisme dat dat mogelijk maakt. Streng zijn betekent hier af en toe dat je een tweede adres toevoegt in plaats van een joker, en dat is een heel kleine prijs.

Je applicaties krijgen de standaardgegevens: wie de persoon is, zijn e-mailadres, zijn naam en zijn groepslidmaatschap. Genoeg voor de applicatie om zelf te beslissen wie beheerder is, zonder dat jij een tweede lijst met mensen bijhoudt.

Wat dit niet doet

Precisie is hier op zijn plaats, want "SSO" wordt losjes gebruikt.

Wij doen authenticatie. De applicatie vraagt wie deze persoon is, wij antwoorden, de persoon meldt zich aan. Wij maken of verwijderen geen accounts binnen jouw applicatie. Heeft je tool een gebruikersrecord nodig voordat iemand hem kan gebruiken, dan maken de meeste er een aan bij de eerste aanmelding, maar dat is gedrag van de applicatie en niet van ons.

Dit is OpenID Connect, geen SAML. Moderne software spreekt het eerste. Sommige oudere bedrijfssoftware wil het tweede, en is dat jouw situatie, vraag het ons dan in plaats van het aan te nemen.

En elke aanmelding, rotatie en verwijdering komt in je auditlogboek terecht, want een applicatie het recht geven je personeel te authenticeren is precies het soort wijziging dat een vastlegging hoort achter te laten.

Waarom het inbegrepen is en niet apart verkocht

Omdat we het identiteitssysteem waarop je werkomgeving staat toch al draaien. Je mensen aanmelden bij zeven van onze eigen producten en weigeren ze aan te melden bij het achtste ding dat ze gebruiken, zou een puur commerciële grens zijn, en een doorzichtige.

Het aanbieden kost ons vrijwel niets. De waarde voor een bedrijf van twintig mensen dat nu een spreadsheet bijhoudt van wie waar een account heeft, is aanzienlijk. Dus het hoort bij Business in plaats van een apart product met een eigen prijs per gebruiker te zijn.

Wil je het tegen een specifieke applicatie testen voordat je je vastlegt, dan is dat een redelijke vraag, en we helpen je liever controleren dan dat je het achteraf ontdekt.