Service provider
De term service provider kan meerdere betekenissen hebben. Vaak verwijst de term naar online dienstverleners zoals managed service providers, payment service providers of internet service providers. En HelloID is een voorbeeld van een IAM service provider.
In dit kennisartikel richten we ons echter specifiek op Service Providers (SP) die met zogeheten Identity Providers (IdP) samenwerken in een trustrelaties om de authenticatie van gebruikers te centraliseren, te verbeteren en te vereenvoudigen.
Wat is een Service Provider?
In dat verband is een Service Provider een cloudapplicatie of website die de authenticatie van de gebruikers niet zelf uitvoert, maar deze delegeert naar een Identity Provider. Dat is een centraal authenticatieplatform dat hiervoor alle benodigde identificatie- en authenticatiegegevens beheert. Beide systemen moeten elkaar daarvoor vertrouwen en ze vormen daarom een zogeheten trustrelatie of vertrouwensrelatie.
Zo’n trustrelatie wordt vooral gebruikt in organisaties met veel gebruikers en meerdere cloud-toepassingen. Decentraal beheer van inloggegevens is dan ingewikkeld, tijdrovend en foutgevoelig, en dat kun je oplossen met zo’n centraal authenticatieplatform. Als bijkomend voordeel van de gebruikers kun je hiermee Single Sign-On (SSO) aanbieden. Als een gebruiker eenmaal is geauthentiseerd op verzoek van Service Provider 1, hoeft dat voor Service Provider 2 niet te worden herhaald. De gebruiker hoeft dus maar één keer in te loggen.
Wat doet een Service Provider?
Hoe werkt zo’n trustrelatie voor de Service Provider? We leggen het uit aan de hand van twee scenario’s. In het eerste beschrijven we hoe de traditionele, standalone inlogprocedure werkt. Daarna schetsen we het authenticatieproces binnen een samenwerkingsverband waarin de applicatie fungeert als Service Provider binnen zo’n trustrelatie.
Rechtstreekse authenticatie
Een gebruiker probeert toegang te krijgen tot de applicatie.
De applicatie bemerkt dat de gebruiker niet is ingelogd. Daarom wordt de gebruiker naar het inlogscherm genavigeerd.
Daar voert de gebruiker inloggegevens in zoals een gebruikersnaam en wachtwoord.
De applicatie verifieert daarmee de identiteit van de gebruiker. Bij een succesvolle authenticatie krijgt de gebruiker toegang.
Authenticatie op de IdP (applicatie fungeert als SP binnen trustrelatie)
Een gebruiker probeert toegang te krijgen tot de applicatie.
Die bemerkt dat de gebruiker niet is ingelogd en stuurt daarom in zijn rol als Service Provider een authenticatieverzoek richting de IdP.
De gebruiker wordt doorgestuurd naar de inlogpagina van de IdP. Daar voert de gebruiker inloggegevens in zoals een gebruikersnaam en wachtwoord.
De IdP verifieert hiermee de identiteit en bij een succesvolle verificatie genereert het systeem een zogeheten authenticatietoken. Dat is een versleuteld digitaal toegangsbewijs.
De gebruiker wordt terug gerouteerd naar de Service Provider, inclusief dit token.
De Service Provider valideert het token en de gebruiker krijgt toegang.
De toegang heeft dus indirect plaatsgevonden. Er is een trustrelatie tussen de Identity Provider en de Service Provider en daarom verleent de applicatie toegang op basis van het ontvangen authenticatietoken.
SSO met meerdere Service Providers
Als je Single Sign-On (SSO) hebt geïmplementeerd, hoeven gebruikers niet steeds voor iedere applicatie opnieuw in te loggen. Heeft iemand zich al geauthentiseerd met behulp van de Identity Provider voor Service Provider 1, dan kan de authenticatie voor Service Provider 2 automatisch plaatsvinden. We beschrijven hieronder het scenario.
Toegang tot Service Provider 2 met SSO
Eerder al is de authenticatie van de gebruiker voor Service Provider 1 succesvol uitgevoerd (zie vorige paragraaf).
Dezelfde gebruiker probeert vervolgens ook toegang te krijgen tot Service Provider 2.
Die detecteert dat de gebruiker niet is ingelogd en stuurt dus een authenticatieverzoek naar de IdP.
De IdP ziet dat de gebruiker al een actieve sessie heeft (met Service Provider 1). De gebruiker hoeft zich dus niet nogmaals te worden geverifieerd.
In plaats daarvan wordt direct een authenticatietoken aangemaakt dat naar Service Provider 2 wordt verstuurd.
Die valideert het token en geeft de gebruiker toegang.
De gebruiker is dus ingelogd bij Service provider 2 zonder opnieuw een authenticatiestap te doorlopen. Deze functionaliteit is overigens optioneel. Men kan er ook voor kiezen gebruikers bij ieder Service provider apart te laten inloggen. Maar zo’n trustrelatie met een centrale Identity Provider is natuurlijk bij uitstek geschikt voor SSO.
IAM koppelingen met Service Providers
Veel organisaties gebruiken dus een Identity Provider om de centrale authenticatie en Single Sign-On van hun gebruikers te verzorgen. Een veelgebruikte oplossing is bijvoorbeeld Entra ID.
Je kunt vervolgens een IAM-oplossing zoals HelloID gebruiken om dat authenticatieplatform te voorzien van de benodigde identificatie- en authenticatiegegevens (de credentials). Ook kun je aanvullende gebruikersattributen provisionen zoals iemands functie of afdeling. Tijdens de authenticatie kunnen deze gegevens worden doorgegeven richting de Service Provider die deze lokaal gebruikt om de rechten van de gebruiker te bepalen.
Met dat mechanisme kun je gebruikersrechten over het algemeen wel alleen highlevel instellen. Voor bijvoorbeeld Elektronische Patiënt Dossiers of zaaksystemen willen organisaties de rechten vaak veel fijnmaziger bepalen aan de hand van meerdere attributen en andere gegevens. Dat kan vaak alleen als je het rechtenbeheer rechtstreeks verzorgt vanuit het IAM-platform via een directe koppeling met de Service Provider. Om zulke Service Providers aan te sluiten op het IAM-platform biedt HelloID een uitgebreide set met connectoren.
Meer weten over het aansluiten van Service Providers?
Meer weten over hoe verschillende systemen met behulp van connectoren kunnen worden aangesloten op je HelloID IAM omgeving? Je vindt er meer over in onze connectoren catalogus.