Single Sign-On, vaak afgekort tot SSO, koppelt een ATS aan de centrale inlogomgeving van een organisatie. Recruiters en hiring managers gebruiken daardoor hun bestaande werkaccount om het recruitmentsysteem te openen, in plaats van een apart ATS-wachtwoord. Dat maakt het gebruikersbeheer overzichtelijker en kan de toegang beter laten aansluiten op het bredere IT-beleid. SSO regelt echter alleen de manier waarop een gebruiker wordt herkend. Welke kandidaten, vacatures en instellingen iemand daarna mag zien of wijzigen, moet nog steeds afzonderlijk in het ATS worden ingericht.
Wat is SSO binnen een recruitmentlandschap?
Een ATS staat bij veel organisaties niet op zichzelf. Het systeem is gekoppeld aan andere toepassingen voor HR, planning, assessments, onboarding en rapportage. Ook identity management kan onderdeel zijn van dat landschap.
In het kennisartikel Welke ATS-koppelingen zijn essentieel voor een modern recruitmentlandschap? wordt identity management genoemd als een relevante integratie. Het doel is vooral dat medewerkers niet voor iedere zakelijke applicatie een los accountproces hoeven te doorlopen.
Bij SSO gebruikt het ATS de centrale identiteit van de organisatie als uitgangspunt. Een medewerker meldt zich aan via de vertrouwde organisatieomgeving en het ATS accepteert vervolgens dat deze identiteit centraal is gecontroleerd.
Waarom organisaties SSO aan een ATS koppelen
Recruitmentsystemen worden vaak gebruikt door meer mensen dan alleen recruiters. Ook hiring managers, HR-medewerkers, functioneel beheerders en soms tijdelijke projectleden hebben toegang nodig. Daardoor kan het aantal gebruikers snel oplopen.
Los accountbeheer per applicatie zorgt dan voor extra werk. Nieuwe medewerkers moeten worden toegevoegd, vertrekkende medewerkers moeten worden verwijderd en gewijzigde rollen moeten worden aangepast. Met SSO kan een deel van dat beheer beter aansluiten op de centrale gebruikersadministratie.
Voor gebruikers is het voordeel vooral praktisch. Zij hoeven niet opnieuw een apart wachtwoord voor het ATS te onthouden. Voor IT en functioneel beheer ontstaat meer samenhang tussen het ATS en het algemene toegangsbeleid van de organisatie.
Hoe werkt de koppeling op hoofdlijnen?
Bij een SSO-koppeling werken twee omgevingen samen. De centrale identity provider controleert de identiteit van de medewerker. Het ATS vertrouwt op die controle en geeft daarna toegang aan de juiste gebruiker.
NIST beschrijft dit als federatieve identiteit: een centrale partij bevestigt de identiteit van een gebruiker aan een andere applicatie. De applicatie hoeft daarmee niet alle stappen rond identificatie zelfstandig uit te voeren.
Voor het ATS is vooral belangrijk dat beide systemen dezelfde gebruiker eenduidig herkennen. Organisaties moeten daarom vooraf bepalen welke informatie nodig is om een medewerker aan het juiste ATS-account te koppelen.
Welke standaarden worden gebruikt?
Voor zakelijke SSO-koppelingen worden onder meer SAML en OpenID Connect gebruikt. Beide zijn bedoeld om identiteitsinformatie tussen systemen op een gestandaardiseerde manier te laten samenwerken.
De OpenID Foundation beschrijft OpenID Connect als een interoperabel authenticatieprotocol waarmee een applicatie de identiteit van een gebruiker kan verifiëren op basis van een centrale identity provider. SAML wordt al langer in veel enterprise-omgevingen gebruikt.
Voor recruitmentteams is vooral relevant dat een leverancier duidelijk kan aangeven welke standaard het ATS ondersteunt en hoe die past bij de identity-omgeving van de eigen organisatie. De term SSO alleen is daarvoor te algemeen.
SSO is niet hetzelfde als rechtenbeheer
Een veelgemaakte denkfout is dat SSO automatisch alle toegangsrechten regelt. Dat is niet zo. SSO bepaalt vooral hoe iemand wordt herkend. Het ATS bepaalt vervolgens wat die persoon mag doen.
Een recruiter kan bijvoorbeeld toegang nodig hebben tot meerdere vacatures en kandidaten, terwijl een hiring manager alleen de sollicitanten voor het eigen team hoeft te zien. Een functioneel beheerder heeft weer andere rechten.
In Hoe audit je een ATS of deze goed beveiligd is? wordt daarom geadviseerd om gebruikersrollen en rechten periodiek te controleren. SSO maakt zo’n controle niet overbodig.
SSO en multifactorauthenticatie vullen elkaar aan
Een centrale login kan worden gecombineerd met multifactorauthenticatie. Daarbij is naast de normale aanmelding een extra verificatiestap nodig. De organisatie kan zo centraal bepalen welke eisen gelden voor toegang tot zakelijke applicaties.
Het kennisartikel Hoe veilig is een ATS? noemt zowel Single Sign-On als multifactorauthenticatie als belangrijke maatregelen rond accountbeveiliging.
Het voordeel van een centrale aanpak is dat recruitment niet zelf een afwijkend inlogbeleid hoeft te onderhouden. Wel moet worden gecontroleerd of de gekozen instellingen voor het ATS aansluiten bij de gevoeligheid van kandidaat- en vacaturegegevens.
Wat gebeurt er bij indiensttreding en vertrek?
SSO wordt vooral waardevol wanneer het aansluit op het proces voor medewerkers die starten, van functie veranderen of de organisatie verlaten. Een nieuwe recruiter moet toegang kunnen krijgen zodra dat nodig is. Iemand die geen ATS-toegang meer nodig heeft, moet die ook weer verliezen.
Dat betekent niet dat historische informatie uit het ATS automatisch wordt verwijderd. Een gebruikersaccount en de acties die in het verleden aan dat account zijn gekoppeld kunnen onderdeel blijven van het dossier of de audittrail. Toegang blokkeren en gegevens verwijderen zijn dus verschillende processen.
Ook functiewijzigingen verdienen aandacht. Een medewerker kan binnen dezelfde organisatie een andere rol krijgen en daardoor meer of juist minder ATS-rechten nodig hebben.
Welke punten moet je vooraf controleren?
Neem SSO al mee bij ATS-selectie en implementatie. In Hoe implementeer je een ATS? wordt SSO genoemd als een van de integraties die tijdens inrichting en testen aandacht vragen.
Controleer in ieder geval:
- welke SSO-standaarden het ATS ondersteunt;
- of de gekozen standaard past bij de identity-omgeving van de organisatie;
- hoe nieuwe gebruikers aan een ATS-account worden gekoppeld;
- hoe wijzigingen in functies en gebruikersgroepen worden verwerkt;
- hoe ATS-rollen en rechten afzonderlijk worden beheerd;
- of multifactorauthenticatie centraal kan worden toegepast;
- wat er gebeurt wanneer een medewerker uit dienst gaat;
- wie verantwoordelijk is voor functioneel en technisch beheer.
Test met echte gebruikersrollen
Een technische test waarbij één beheerder succesvol kan inloggen is niet voldoende. Test ook met verschillende typen gebruikers. Laat bijvoorbeeld een recruiter, hiring manager en functioneel beheerder controleren of zij na het inloggen precies de juiste onderdelen van het ATS kunnen gebruiken.
Neem ook een medewerker mee die van rol verandert en een account dat geen toegang meer hoort te hebben. Daarmee controleer je niet alleen de login, maar ook de aansluiting tussen centraal gebruikersbeheer en de autorisaties in het recruitmentsysteem.
Leg de gekozen inrichting vast zodat later duidelijk blijft welke partij verantwoordelijk is voor de identiteit, welke rechten het ATS zelf bepaalt en hoe wijzigingen worden doorgevoerd.
