Enige tijd geleden schreef ik over de Heilige Graal in identity management: het beheren van toegang tot apps en data door de HR-afdeling via Okta, gebaseerd op functieprofielen en andere kenmerken. Dit heeft als grote voordeel dat het tijd bespaart voor zowel HR als IT, miscommunicatie voorkomt en toegang tot data en apps verleent op basis van rollen die zijn vastgelegd in het HR-functiehuis. Precies zoals de ISO27001-auditor het graag ziet! En laten we niet vergeten welke onvergetelijke indruk je achterlaat bij nieuwe medewerkers die alles hebben wat ze nodig hebben op hun eerste dag in je bedrijf.

Deze week werken we dit HR-as-a-master concept uit in de praktijk met een Okta- en een HiBob-omgeving. We koppelen Okta en HiBob op twee manieren:

Wanneer Okta en HiBob zijn gekoppeld, stellen we nog enkele instellingen in voor een soepel onboarding-proces en een goede start voor het verdere gebruik van de Okta-accounts.

Provisioning

Provisioning betekent dat informatie over medewerkers vanuit HiBob wordt gedeeld met Okta, die er een account mee aanmaakt en het profiel invult. Okta maakt vervolgens gebruik van deze informatie om profielen in achterliggende applicaties aan te vullen. Op deze manier wordt "master data" uit het HR-systeem automatisch gebruikt om bijvoorbeeld informatie over collega's te delen in Slack, Teams, Box, enzovoort.

Het moment waarop dit gebeurt is relevant. Medewerkers tekenen hun contract lang voordat ze daadwerkelijk starten in de organisatie. HiBob zorgt ervoor dat op het moment dat de nieuwe medewerker wordt vastgelegd in HiBob er al direct een account in Okta wordt aangemaakt. Er kan niet worden ingelogd op het account tot de dag dat het contract ingaat, maar aanwezigheid in Okta stelt eventuele applicatiebeheerders van achterliggende applicaties in staat om de gebruiker al goed te onboarden. Okta zal immers het account al doorsturen naar achterliggende systemen, zodat een beheerder, indien nodig, de juiste rechten kan toewijzen en licenties kan koppelen, voor zover dat nodig is en niet automatisch gebeurt.

Op de eerste werkdag van de medewerker stuurt HiBob een signaal naar Okta dat het contract actief wordt. Dit signaal geeft Okta het teken om de activeringsmail naar het persoonlijke e-mailadres te sturen. Met deze activeringsmail kan de gebruiker zijn account activeren en krijgt zo toegang tot het persoonlijke dashboard met alle applicaties, inclusief het nieuwe zakelijke e-mailadres.

Een naadloze integratie tussen contractgegevens en praktische toegang tot data en apps is van groot belang. Het is inefficiënt en amateuristisch als een nieuwe medewerker op de eerste werkdag moet wachten op toegang. Het is uiteraard ook onaanvaardbaar om toegang te geven voordat het contract ingaat. De integratie tussen HR en IT is hier de oplossing.

Bij offboarding dit dit gevoeliger. Dienstverbanden kunnen om allerlei redenen worden beëindigd. Sommige zijn planbaar en met goede redenen. Maar het komt ook voor dat het vertrek van een medewerker niet gepland kan worden en vaak zijn de omstandigheden dusdanig dat zekerheid over afgesloten toegang cruciaal is.

HiBob en Okta doen dit op dezelfde waterdichte manier. Zodra een medewerker in HiBob door een HR-medewerker wordt beëindigd, wordt onmiddellijk het signaal naar Okta gestuurd om het account te deactiveren. De medewerker kan niet meer inloggen en wordt direct uitgelogd uit alle geïntegreerde applicaties met behulp van Okta's 'Universal Logout'.

HiBob integraties zijn te vinden in HiBob onder "Instellingen" en "Integraties". Kies vervolgens de categorie "Provisioning" en klik op "Verbinden" bij de Okta integratie.

Ik heb ervoor gekozen om de integratie te doen op basis van de REST API. Op een later moment zal ik de blog bijwerken om ook te beschrijven hoe provisioning op basis van SCIM werkt. Het voordeel van gebruik van de REST API is de realtime synchronisatie tussen status van de medewerker en het account. Bovendien bespaart gebruikt van de REST API de Okta add-on voor provisioning, hoewel die idealiter natuurlijk wel nodig is voor provisioning van de achterliggende applicaties.

Om met de API te kunnen verbinden heb je alleen de Okta basis-url nodig en een API token die je aanmaakt in Okta onder Security → API → Tokens. Doe dat voor live situaties wel onder een Okta service account welke geen SuperAdmin is.

Ik koos ervoor, zoals hierboven beschreven om het Okta account direct aan te maken zodra de medewerker s vastgelegd in HiBob. Hieronder zie je wat andere mogelijkheden zijn:

HiBob heeft goed uitgepakt in de ontwikkeling van deze koppeling, want naast een standaard set attributen die naar Okta wordt gestuurd, kan ik ook attributen toevoegen en verwijderen in de uitwisseling met Okta. ik vond dat nodig omdat ik het persoonlijke emailadres waarop HR met de medewerkers heeft gecorrespondeerd ook in Okta wil hebben. Okta kan dan dat adres gebruikken om de eerste activeringsemail te versturen.

Je ziet ook in de schermafdruk hierboven dat ik de HiBob Company id naar Okta stuur. Dat doe ik om HiBob gebruikers in Okta te kunnen herkennen in een “rule” om daar vervolgens een groep mee te vullen. Die groep gebruik ik dan vervolgens om de applicatie HiBob vanaf het Okta dashboard beschikbaar te maken middels Single Sign-on.

Single Sign-on

Single sign-on zorgt ervoor dat er een enkele, uniforme ervaring ontstaat in het gebruik van Okta, HibBob en alle andere gekoppelde apps. HiBob ondersteunt het inloggen vanaf de app met Okta (SP initiated login) en vanaf het Okta dashboard (IdP initiated login).