Onze situatie
Als digitaal bureau werken wij met tal van externe services; hosting servers, Zeplin, Simplicate en Monday zijn hier voorbeelden van. Daarnaast ondersteunen verschillende tools ons in een meer interne setting. Voorbeelden hiervan zijn GitLab, Icinga, het WiFi netwerk, centrale data opslag, VPN connecties en nog veel meer. Het managen van de gebruikers op al deze platforms en tools kan behoorlijk complex worden, zeker wanneer men rekening houdt met het feit dat informatie interoperabel beschikbaar moet zijn. Wanneer een gebruiker zijn wachtwoord wil veranderen, is er een verandering vereist voor elk van deze tools. Of, wanneer een nieuwe medewerker begint, heeft deze een account nodig. Na een tijdje merkte ik dat het bijhouden van al deze veranderingen behoorlijk arbeidsintensief werd. Dus, met de intentie om het werk te verlichten, ging ik op zoek naar een oplossing waarbij de strenge eisen die wij stellen aan de veiligheid niet in gevaar zouden komen.
Stap 1: een geschikte database voor gebruikersdata
De eerste stap was het zoeken naar een centrale database welke alle gebruikersdata zou kunnen opslaan: een systeem dat voorziet in het communiceren van deze gegevens van en naar onze interne en externe tooling. Ik kwam al gauw uit bij LDAP, een standaard binnen de industrie. Vanwege deze standaard bieden veel tools een koppeling aan met LDAP. Tevens bieden GNU/Linux en MacOS (onze hosting servers en desktops), een native koppeling met LDAP. Een ander voordeel is het feit dat LDAP ondersteuning biedt voor het op maat maken van data schema’s, waardoor ik de opslag van de data kan aanpassen waar nodig.
Voordelen en nadelen van LDAP
We gebruiken LDAP niet alleen om in te loggen op onze WiFi en interne tools, het verbindt ons ook met onze servers. Dit betekent dat onze developers kunnen inloggen met centraal beheerde SSH keys en wachtwoord. Door een aantal aanvullende aanpassingen is het tevens mogelijk rechten te beheren gebaseerd op group-membership. Hierdoor kunnen we, in plaats van het toevoegen van individuele gebruikers voor een bepaalde service die zij gerechtigd zijn te gebruiken, de gehele groep toevoegen. Dit zorgt er o.a. voor dat developers toegang kunnen krijgen tot servers en GitLab.
Een nadeel van LDAP is echter wel dat de gebruikersnaam en wachtwoord worden verwerkt door de applicatie. Met name voor externe tools, is dit iets dat ik graag wil voorkomen aangezien deze tools de data op zouden kunnen slaan, waardoor het gevoeliger wordt voor hacking. Vanwege deze reden, is het besluit gemaakt om te kiezen voor OAuth2 voor externe tooling.
Een custom oplossing voor externe tools
OAuth2 is gemaakt om gebruikersinformatie te delen, en een login te valideren zonder het gebruikerswachtwoord ooit te tonen. De kans is vrij groot dat je hier al gebruik van maakt om bijvoorbeeld in te loggen bij een service met je Google account. De gebruiker wordt direct doorverwezen naar een login scherm. Dit betekende dat ik eerst een interface moest bouwen welke de data van LDAP gebruikt. Met behulp van SimpleSAML.php was dit vrij eenvoudig te creëren. Na het inloggen wordt de gebruiker teruggestuurd naar oorspronkelijke website met een speciale token die hem automatisch inlogt, terwijl er ondertussen wordt gevalideerd of dit correct is en of het vanuit een betrouwbare bron is gedaan.
