TL;DR: TOPdesk kan ook gebruikersnaam/wachtwoord-combinaties in de eigen database opslaan, waarmee gebruikers kunnen inloggen. Dit systeem kan potentieel compliancy-issues opleveren op het gebied van informatiebeveiliging.
Dit is het eerste deel over een drieluik over TOPdesk-authenticatie.
Als je TOPdesk wilt gebruiken, dan moet eerst je inloggen. Ben je succesvol ingelogd? Dan is TOPdesk overtuigd dat je bent wie je zegt dat je bent. TOPdesk kan op vier manieren je identiteit controleren (zie screenshot), zowel als behandelaar als op de SelfServicePortal. Eén van die manieren ervan, TOPdesk-authenticatie, is gewoon een raar ding, en in deze post leg ik uit waarom.
Ik zie TOPdesk-authenticatie als het equivalent van de reservesleutels die je uitdeelt aan mensen die wel om een of andere reden een sleutel van je huis moeten, maar die niet in je huis wonen. Ben je je eigen sleutel binnen vergeten? Gelukkig hebben de buren een reservesleutel, waarmee je je eigen huis in kan. De interieurverzorger (m/v) kan ook in je huis, met zijn/haar reservesleutel, om vervolgens nuttig werk te doen. En misschien heb je de achterdeursleutel van je eigen huis verstopt onder die supergeheime bloembak waar geen enkele inbreker ooit onder zou durven kijken. Supermakkelijk!
Inloggen en authenticeren
Een zichzelf respecterende organisatie vindt het belangrijk om grip te hebben op wie toegang heeft tot welke informatie, en waarom. Het is vaak Active Directory waar gebruikers en autorisaties centraal worden beheerd. Ook TOPdesk kun je aan Active Directory koppelen. Is dat ingeregeld, dan kun je in TOPdesk inloggen met de credentials van je reguliere netwerkaccount. Dit is vanuit compliancy fijn: is een account uitgeschakeld in Active Directory, bijvoorbeeld omdat de medewerker uit dienst is? Dan kan die persoon automatisch ook niet meer inloggen in TOPdesk.
Zo’n koppeling met Active Directory kan echter stuk gaan: een firewallregel kan dichtgezet of aangepast worden, een certificaat kan verlopen, het IP-adres van je domain controller kan wijzigen, etcetera. Gebeurt dit, en heb je niets anders dan je Active-directory-koppeling? Dan kan niemand meer in TOPdesk inloggen. En kun je niet meer inloggen, dan is de koppeling repareren ook niet zo eenvoudig. Het is alsof de voordeursleutel nog aan de binnenkant in het slot zit. De voordeur kan niet meer open, maar je moet toch eerst naar binnen om de sleutel te verwijderen.
I hate it when that happens…
Maar gelukkig is er nog de reservesleutel van de achterdeur onder de supergeheime bloembak. Je kunt namelijk binnen TOPdesk accountjes maken die buiten TOPdesk nergens bestaan. Zo’n accountje maken is bovendien een fluitje van een cent (*). Bij deze zogenoemde TOPdesk-accountjes zijn zowel gebruikersnaam als wachtwoord opgeslagen in de database van TOPdesk zelf. Een gebruiker kan met die gebruikersnaam/wachtwoord vervolgens inloggen in TOPdesk, buiten Active Directory om! Ligt je koppeling met Active Directory er dus uit? Dan kun je alsnog inloggen met een TOPdesk-accountje met admin-rechten. Op die manier kun je dan bijvoorbeeld een certificaat vervangen, waardoor de koppeling met het AD weer werkt.
Hetzelfde geldt voor als je inlogt via een Identity Provider via het SAML-protocol. Gebruik je bijvoorbeeld Azure Active Directory, dan kun je op allerlei manieren toegang tot TOPdesk reguleren. Zo kun je toegang tot TOPdesk dichtzetten voor gebruikers uit bepaalde landen, of gebruikers met de verkeerde hardware of met bepaalde browsers. En je kan multi-factor authentication instellen, net als allerlei password policies. Zo’n SAML-koppeling kan echter ook stuk. Maar gelukkig heb je nog je reservesleutel. Met een TOPdesk-accountje sla je al dat lastige security-beleid over en log je direct de database in. Supermakkelijk!
Dat klinkt niet zo best-practiserig…
Om de ironie een beetje expliciet te maken: een TOPdesk-account is moeilijk verenigbaar met deugdelijk Identity & Access Management. Daarnaast zijn er ook op het gebied van informatiebeveiliging een aantal vraagtekens te zetten bij TOPdesk-authenticatie. Zo verlopen TOPdesk-accountjes nooit, en worden TOPdesk-accounts ook niet gelocked na een X aantal mislukte inlogpogingen. De enige policy die je in TOPdesk in kunt stellen op TOPdesk-authenticatie 
is het minimale aantal karakters van het wachtwoord. TOPdesk mort niet wanneer je die waarde op 1 karakter zet (zie screenshot). Zet je het minimale aantal karakters op 8, dan vindt TOPdesk een wachtwoord zoals 11111111 ook turboprima.
TOPdesk-authenticatie uitschakelen dan? Dat kan natuurlijk. Je kunt gewoon het vinkje in het eerste screenshotje uitzetten en dan weet je zeker dat gebruikers via sterkere methodes authenticeren. Maar TOPdesk-accountjes zijn natuurlijk wel ergens goed voor. De eerste use case was de reservesleutel, die van pas komt wanneer je met de gewone sleutel niet naar binnen kan. Tweede use case is instellingenbeheer, het tooltje dat inmiddels op SAAS en in de nieuwste on-premise-versies van TOPdesk is uitgefaseerd. Derde use case is gewoon: mensen laten inloggen als LDAP of SAML niet beschikbaar is. Dit raad ik sowieso niet aan.
Maar de belangrijkste use case van TOPdesk-accounts is het koppelen van geautomatiseerde systemen op TOPdesk via het netwerk. Dit kun je in principe alleen maar aan de praat krijgen met een behandelaarsaccount in TOPdesk dat inlogt dmv TOPdesk-authenticatie of via LDAP.
- Met httprequests kun je geautomatiseerd kaarten aanmaken of editen. Goed voorbeeld: een melding die automatisch na 14 dagen wordt afgemeld.
- Met de TOPdesk-API kun applicaties tegen TOPdesk bouwen. Het uitbouwen van de API is een belangrijke strategie van TOPdesk (naast alle klanten naar SAAS brengen).
- Via de XML-module kun je alle tabellen en velden in de database bewerken op basis van binnenkomende XML-berichten.
Deze systemen zijn als de interieurverzorger die naar binnen moet om nuttig werk te doen in je huis. Voor een stabiele werking van deze geautomatiseerde systemen is een TOPdesk-account beter dan LDAP-authenticatie.
Vanuit compliancy-perspectief is TOPdesk-authenticatie dus enigszins twijfelachtig, omdat allerlei inzichten uit Identity & Access Management en informatiebeveiliging niet op TOPdesk-accountjes toepasbaar zijn. Maar tegelijkertijd zijn er allerlei scenario’s te bedenken waar een TOPdesk-account de beste, of zelfs de enige, mogelijkheid is om bepaalde functionaliteit mogelijk te maken. Wat dit betekent in de praktijk leg ik in een volgende post uit.
Vooruitblik
Het zou me niets verbazen als TOPdesk het concept TOPdesk-authenticatie een keer op de schop neemt. Instellingenbeheer is uitgefaseerd dus daar is het niet meer voor nodig. Ook een reservesleutel hoeft niet per se; op SAAS heb je TOPdesk-support voor noodgevallen en on-premise zou TOPdesk het speciale admin-account kunnen opwaarderen. Voor de geautomatiseerde systemen zijn er inmiddels application passwords (lees hier meer). Die zijn nu nog afhankelijk van LDAP- of TOPdesk-authenticatie, maar het lijkt mij niet onmogelijk om die afhankelijkheid los te koppelen en standalone application passwords mogelijk te maken. De grootste uitdaging lijkt mij httprequests en backward compatibility. Ik ben benieuwd welke ontwikkelingen we gaa zien in de toekomst.
* Volgende keer deel twee over TOPdesk-authenticatie: werken met TOPdesk-accounts in de praktijk.
