Single Sign-On checklist: hoe kies je de geschikte oplossing?

Steeds meer bedrijven kiezen ervoor om hun digitale serviceomgevingen, van commerce platforms tot service- en aanvraagportalen, APIs en apps, op te bouwen uit losse componenten. Dat is een voordeel voor de flexibiliteit en time-to-market, maar het betekent ook iets voor het beheer van gebruikers en rollen. Consultant Rudy van Haandel legt uit waar je rekening mee moet houden en hoe je een passende Single Sign-On (SSO) oplossing kiest.

wolk met sleutel icoon

Door de shift van monolithische systemen en platformen naar een landschap met losse, best-of-breed services, groeit de complexiteit voor eindgebruikers flink. Het laatste dat je wil, is dat gebruikers in elke service of component opnieuw moeten inloggen, een ander wachtwoord moeten bedenken en onnodig veel tijd kwijt zijn aan het gebruik van je dienst. Of dat ze de ene na de andere extra beveiliging moeten instellen met SMS tokens, QR-codes of authenticator apps. Tegelijkertijd wil je ook niet inleveren op veiligheid, compliancy en time-to-market. Bij een groeiend landschap dat is opgebouwd uit losse services speelt daarom altijd de vraag: hoe regel ik gebruikerstoegang en -authenticatie op zo’n manier dat het veilig en efficiënt is? Single Sign-On is vaak het antwoord.

Single Sign-On as a Service

Voordat je een Single Sign-On oplossing kiest, is het belangrijk om te bedenken waarom je SSO wil inzetten. Er is één doel dat ieder bedrijf zich zou moeten stellen met Identity & Access Management en Single Sign-On: eenvoud voor alle gebruikers. Niet alleen voor eindgebruikers van de shop of de services, maar ook voor ontwikkelteams, internet audit en risk officers bijvoorbeeld. Primair zet je SSO in, zodat iedere type gebruiker zijn gebruikerstaken efficiënt en eenvoudig kan uitvoeren. De betekenis van die ‘eenvoud’ voor alle verschillende gebruikers, vormt de basis van jouw SSO-oplossing. 

Om die eenvoud goed in te richten, ligt het voor de hand om Single Sign-On als aparte service op een centrale plek in te richten. Dat betekent dat er één service is die alle authenticatie, gebruikersrollen en -rechten regelt en regisseert. Identity informatie zit in die aparte service, of daarmee verbonden ‘directory’, opgeslagen en staat los van de rest van de services en componenten. Dat biedt een aantal voordelen:  

  • Ontwikkelteams hoeven geen rekening te houden met gebruikersdata en bijbehorende privacy, doordat dit in een afzonderlijke SSO-service wordt geregeld. Hierdoor ontstaat meer focus en een kortere time-to-market.
  • Gebruikersrollen, authenticatie en toegang zijn veel beter te beheersen wanneer dit op één plek wordt geregeld. Onboarding en, vaak nog complexer, offboarding van alle verschillende gebruikers is daardoor veel eenvoudiger en verloopt sneller.
  • De ambitie om flink te groeien? Door de flexibele architectuur met moderne connectoren (APIs) en techniek (o.a. Oauth, SAML en OpenID Connect) helpt technologie jouw groei te versnellen.

De SSO checklist

Er zijn natuurlijk verschillende manieren om dat keuzeproces aan te pakken. Meestal is dat ook afhankelijk vanuit welke hoek de vraag komt, uit de business of IT. Op basis van onze ervaringen met SSO-implementaties hebben we een checklist opgesteld die richting geeft aan die aanpak. Dit zijn de dingen die handig zijn om op te letten of over na te denken:

  • Authenticatieproces: In hoeverre wijkt jouw proces af van de standaard? Welke type services zitten in het landschap? Is er een Windows-inlog nodig of juist een externe ID via bijvoorbeeld Facebook of Google?
  • Authenticatie devices: Welke authenticatiemethoden zijn er nodig? Dat is afhankelijk van de services en doelgroepen die je bedient. Daarom is het handig om te kijken naar het type devices die moeten worden ondersteund, maar ook naar het type inlogs. Ga je bijvoorbeeld met two factor (2FA) en multi factor authentication (MFA) aan de slag, en welke eisen stel je aan de device?
  • Herhaalgebruik vanaf dezelfde devices: Heb je te maken met veel gebruikers in een BYOD (Bring Your Own Device)-landschap waarop logins ‘bewaard’ kunnen worden of moeten gebruikers op gedeelde hardware steeds opnieuw zichzelf kenbaar maken?
  • Digital experience: welke eisen stel je aan de gebruikerservaring? Bijvoorbeeld het gemak waarmee je flows doorloopt, hoeveelheid stappen bij onboarding, offboarding en recurring login, hoe snel moeten de systemen reageren en op welke (verschillende) manieren moet iemand kunnen inloggen?
  • Cloud, on-premise of hybrid: Wordt het landschap in de cloud gehost en worden er directe cloud services gebruikt, zoals Azure Logic Apps of bepaalde toepassingen uit de AWS Marketplace? In dat geval kun je ook kijken naar specifieke cloud-oplossingen voor SSO, zoals Azure SSO of AWS Cognito.
  • Standaard versus maatwerk: in hoeverre is het nodig of wenselijk om custom API-connectoren te ontwikkelen of zijn standaard connectoren van een IAM- of SSO-platform voldoende?
  • Controle over kosten: Hoeveel gebruikers verwacht je? Welke verwachting heb je bij de groei van het aantal gebruikers en met welke frequentie loggen zij in? Dat heeft namelijk invloed voor het afrekenmodel van de oplossing die je kiest. Heb je bijvoorbeeld een grote hoeveelheid low value users, dan wil je misschien liever betalen voor daadwerkelijk gebruik. Bijvoorbeeld het aantal inlogs of API calls of een bundel daarvan.
rudy.png
SSO in jouw organisatie

Vrijblijvend sparren of meer informatie over Single Sign-On? Rudy helpt je graag.

Neem contact op