Wanneer ik iemand hoor zeggen dat ze een app hebben "gemoderniseerd", betekent dit meestal dat ze SAML of OIDC hebben ingeschakeld.
SsodoetMaar hier is wat me zorgen maakt: te veel teams stoppen daar. ze implementeren SSO en gaan ervan uit dat het harde deel voorbij is.
Waarom “we gemoderniseerd” niet altijd betekent wat je denkt
Wanneer mensen me vertellen dat hun app is gemoderniseerd, vraag ik me wat dat echt betekent. In veel gevallen betekent het gewoon dat de app nu SSO ondersteunt. Het gebruikt nog steeds dezelfde interne sessielogica. Autorisatie is nog steeds diep gecodeerd in de app. Het is nog steeds broos - alleen met een betere inlogpagina.
Wat hier gebeurt, is vaker dan de meesten toegeven: we moderniseren de voordeur en laten de rest van het huis ongewijzigd.
En dat is een probleem, want identiteit gaat niet alleen over inloggen, het gaat om wat er daarna gebeurt.
Wat moderne authenticatie eigenlijk levert
Moderne auth-protocollen zoals SAML en OIDC zijn ontworpen om echte uitdagingen op te lossen - voornamelijk login en federatie.
Dat is echte vooruitgang.En ja, SSO door middel van deze protocollen verbetert de veiligheidspositie.Maar laten we gemak niet verwarren met volledigheid.
Protocollen zijn vooruitgang - maar ze zijn niet de eindlijn
Je krijgt minder wachtwoorden, minder wrijving en een meer consistente gebruikerservaring.Wat ze niet bieden zijn de andere kritieke controles die we vertrouwden op met Web Access Management (WAM) -systemen: gecentraliseerde sessiebeheersing, autorisatiehandhaving, directory-integratie en consistente beleidsbeheer.
WAM-systemen waren niet perfect, maar ze gaven ons een consistente besturingslaag over toepassingen.Toen we ze verwijderden zonder die laag te vervangen, verloren we iets essentieels - en ik heb de gevolgen uit de eerste hand gezien.
De app is niet modern als identiteit nog steeds hardcoded is
Ik heb apps gezien die op het oppervlak glanzend lijken, maar nog steeds vertrouwen op fragiele, ontwikkelaarspecifieke identiteiten die achter de schermen plunderen.
Sommige teams gebruiken nog steeds verouderde sessiebibliotheken. Anderen coderen toegangsregels op een manier die audit een nachtmerrie maakt.
Waar dingen uit elkaar vallen: sessiebeheer
Een van de grootste identiteitsblindspots in gemoderniseerde omgevingen is sessiebeheer.
Met WAM werd het sessiegedrag – timeouts, verlengingen, intrekkingen – op één plek verwerkt. U kunt een beleidswijziging toepassen en weten dat het van kracht zou zijn in de hele onderneming.
Ik heb met teams gewerkt met Spring, Node.js, Rails – en zelfs binnen één framework is er geen garantie voor consistentie.
Het niet kunnen handhaven van consistente sessie timeouts is een enorm risico als ze geen sessies kunnen herroepen wanneer er iets verdachts gebeurt.
De kosten van gedecentraliseerde sessie logica
Wanneer het patchen van sessiebibliotheken weken of maanden duurt, of niemand weet waar onbeperkte timeouts zijn gedefinieerd, wordt beveiliging op zijn best reactief.
Dit is niet theoretisch.Ik heb gezien dat bedrijven moeite hebben om gewoon te volgen hoe hun sessiebehandeling zelfs werkt.Het is stamkennis geworden, diep verborgen in appcode.
Dat is niet duurzaam – vooral voor bedrijven die zich bezighouden met compliance of Zero Trust-doelen.
Identiteitsuitbreiding en autorisatie drift
Hetzelfde gebeurt met sessie logica gebeurt met autorisatie.Zodra het is geduwd naar de applicatie code, wordt het bijna onmogelijk om centraal te beheren.
En uiteindelijk weet niemand precies wie toegang heeft tot wat - of waarom. Zelfs apps die moderne authenticatie ondersteunen, kunnen hier falen, omdat AuthZ niet deel uitmaakt van het protocol.
Orchestratie moet volgen
Op dit punt denk ik dat het duidelijk is: moderne authenticatie is slechts een stukje van de puzzel.
De voordelen van het gebruik van orchestratie zijn onder meer:
- De mogelijkheid om sessies onmiddellijk te annuleren
- Sessie- en authZ-beleid consequent toepassen
- Federatie sleutels en certs van één plaats beheren
- Integratie met risicosignalen (zoals CAEP) om Zero Trust te ondersteunen
- En dat alles zonder apps opnieuw te schrijven of identiteitsleveranciers te wisselen
Orchestratie brengt de kloof tussen “moderne protocolondersteuning” en echte identiteitsmodernisatie over.
Centralisatie betekent niet dat je achteruit gaat
Soms gaan mensen ervan uit dat het terugbrengen van identiteitscontrole op één plek een stap terug is.
Het gaat om het mogelijk maken van behendigheid. over het geven van beveiligingsteams de zichtbaarheid die ze nodig hebben zonder ontwikkelaars te vertragen. over het beheren van identiteit als een service - niet als een reeks app-specifieke hacks.
Wanneer je geen orchestratie hebt, wordt elke identiteitsuitdaging een eenmalige oplossing.
Als ik met een beveiligingsteam praat, stel ik meestal een vraag als deze: "Hoe snel kon je de sessies van een gebruiker intrekken?Over elke app in uw bedrijfOp dit moment?”
Als het antwoord iets minder is dan "onmiddellijk", is er een probleem dat het oplossen waard is.
De takeaway: stop niet bij SSO
Ik zal het duidelijk zeggen: moderne authenticatie is essentieel, maar het is onvolledig.Als je stopt bij SSO, mis je de besturingslaag die alles anders werkt - veilig, consequent en op schaal.
Dus ja, adopteer SAML. Roll out OIDC. Maar laat het inlogvak niet de eindlijn zijn.
Als je echte veiligheid wilt, moet orchestreren deel uitmaken van de reis.
Over de auteur
Darren Platt heeft engineeringteams geleid bij Securant Technologies, Ping Identity, Simplified, RSA en Oracle. hij is nu VP van Product Management en Engineering bij Strata Identity, waar hij het eerste gedistribueerde Identity Orchestration-platform voor gedistribueerde omgevingen bouwt en bijdraagt aan de nieuwe standaard voor beleidsorchestratie, IDQL en de referentiesoftware Hexa.
