Hvorfor én OTP ikke kan dekke Wi-Fi, VPN og et register

Én pålogging lover én identitet og færre spørsmål, og løftet brister ved den tredje protokollen. Fellen er å anta at én vellykket autentisering produserer et token som alle andre protokoller kan legge fram. Wi-Fi-innslipp, VPN-inngang og et containerregister kjører hver sin utveksling, med ulike publikummer og levetider. Å dele kontoen er en katalogbeslutning; å dele legitimasjonen er en protokollbeslutning, og protokollene er sjelden enige.

Tre utvekslinger, tre eiere

Bedrifts-Wi-Fi kjører en EAP-metode inne i 802.1X, vanligvis avsluttet av en RADIUS-tjeneste som har sitt eget syn på brukeren eller enheten. En VPN-gateway autentiserer gjennom sin egen støttede flyt og holder deretter en sesjon med sin egen reautentiseringstimer. Et register svarer på en uautentisert forespørsel med en utfordring som navngir en tokentjeneste, et publikum og et omfang, og klienten bytter legitimasjonen sin mot et kortlivet token.

Det er ikke tre visninger av én sesjon. Hver har sin egen verifiserer, sin egen levetid og sin egen tilbakekallingsvei, og derfor kan en passordendring i katalogen la én fortsette å virke og en annen brytes. Behandle dem som tre integrasjoner som tilfeldigvis deler en brukerkatalog.

Hva nettleser-SSO bærer og ikke bærer

En nettlesersesjon hos en identitetsleverandør er virkelig nyttig: applikasjoner som omdirigerer dit, arver påloggingen brukeren allerede har fullført. Det virker fordi disse applikasjonene snakker de samme omdirigerings- og tokenprotokollene og godtar det samme publikummet. En supplikant som snakker EAP har ingen omdirigering å følge, og en Docker-klient som mottar en registerutfordring ber ikke om et OIDC-id-token. Identitetsleverandøren kan bare garantere for protokoller den ble bygget for å snakke.

Feilen er lett å se i loggene når man vet hvor man skal se. Identitetsleverandøren rapporterer en vellykket pålogging mens Wi-Fi-tilknytningen fortsatt feiler, eller registeret returnerer 401 etter en tokenutveksling som nettleseren aldri så. To suksesser og én feil er ikke en motsetning; det er tre separate autentiseringer.

Hvor et sertifikat erstatter en gjentatt kode

For administrerte enheter fjerner sertifikatbasert EAP det menneskelige trinnet uten å fjerne identitet: enheten legger fram et sertifikat, RADIUS-tjenesten kontrollerer det mot utstederen, og tilbakekalling skjer hos den utstederen i stedet for i en delt hemmelighet. Prisen er livssyklusarbeid, fordi sertifikater utløper og må fornyes før de gjør det.

Registre har en tilsvarende deling. En interaktiv bruker kan logge på én gang og la en legitimasjonshjelper lagre tokenet som oppstår, mens automativering bør bruke en snevert avgrenset tjenestekonto eller en arbeidsbelastningsidentitet. Ingen av dem bør være en persons engangskode kopiert inn i en pipeline. Hjelperen lagrer et token for et bestemt registerpublikum, så det kan ikke pekes mot VPN-gatewayen ved å redigere en konfigurasjonsfil.

docker login registry.example.com

Sammenlign vedlikeholdskostnaden, ikke antall spørsmål

Delt legitimasjon ser billig ut fordi arbeidet er usynlig til det feiler. Tell i stedet hva hvert alternativ koster over et år: påmelding, fornying, tilbakekalling, radiusen av en lekkasje og antall systemer som berøres når noen slutter. En sertifikatflåte koster mer å bygge og mindre å drive i skala; en kopiert kode koster ingenting å starte og alt å nøste opp.

Velg deretter per ben i stedet for globalt. Wi-Fi kan flytte til sertifikater, VPN-en kan beholde sin støttede SSO med MFA, og registeret kan bruke tokens med eksplisitte omfang. Registrer eier, publikum, omfang, utløp og tilbakekallingsvei for hver av dem, og spørsmålene faller der de skal i stedet for overalt på én gang. Den registreringen er også svaret når en revisor spør hvilke systemer som fortsatt stoler på et passord.