Varför en OTP inte täcker Wi-Fi, VPN och ett register

Enkel inloggning lovar en identitet och färre frågor, och löftet brister vid det tredje protokollet. Fällan är att anta att en lyckad autentisering producerar en token som alla andra protokoll kan visa upp. Wi-Fi-inträde, VPN-ingång och ett containerregister kör var sin utväxling, med olika publiker och livslängder. Att dela kontot är ett katalogbeslut; att dela credentialen är ett protokollbeslut, och protokollen är sällan eniga.

Tre utbyten, tre ägare

Företags-Wi-Fi kör en EAP-metod inuti 802.1X, vanligtvis avslutad av en RADIUS-tjänst som har sin egen syn på användaren eller enheten. En VPN-gateway autentiserar genom sitt eget stödda flöde och håller sedan en session med sin egen reautentiseringstimer. Ett register svarar på en oautentiserad begäran med en utmaning som namnger en tokentjänst, en publik och en omfattning, och klienten byter sin credential mot en kortlivad token.

Det är inte tre vyer av en session. Var och en har sin egen verifierare, sin egen livslängd och sin egen återkallningsväg, vilket är varför en lösenordsändring i katalogen kan lämna den ena fungerande och den andra trasig. Behandla dem som tre integrationer som råkar dela en användarkatalog.

Vad webbläsar-SSO bär och inte bär

En webbläsarsession hos en identitetsleverantör är verkligen användbar: applikationer som omdirigerar dit ärver den inloggning som användaren redan har slutfört. Det fungerar eftersom dessa applikationer talar samma omdirigerings- och tokenprotokoll och accepterar samma publik. En supplikant som talar EAP har ingen omdirigering att följa, och en Docker-klient som tar emot en registerutmaning ber inte om en OIDC-id-token. Identitetsleverantören kan bara garantera protokoll som den byggdes för att tala.

Felet är lätt att se i loggarna när man vet var man ska titta. Identitetsleverantören rapporterar en lyckad inloggning medan Wi-Fi-anslutningen fortfarande misslyckas, eller registret returnerar 401 efter en tokenutväxling som webbläsaren aldrig såg. Två framgångar och ett misslyckande är ingen motsägelse; det är tre separata autentiseringar.

Där ett certifikat ersätter en upprepad kod

För hanterade enheter tar certifikatbaserad EAP bort det mänskliga steget utan att ta bort identitet: enheten visar upp ett certifikat, RADIUS-tjänsten kontrollerar det mot utfärdaren, och återkallning sker hos den utfärdaren i stället för i en delad hemlighet. Priset är livscykelarbete, eftersom certifikat löper ut och måste förnyas innan dess.

Register har en motsvarande uppdelning. En interaktiv användare kan logga in en gång och låta en credential-hjälpare lagra den resulterande token, medan automatisering bör använda en snävt avgränsad tjänstecredential eller en arbetsbelastningsidentitet. Ingen av dem bör vara en människas engångskod kopierad in i en pipeline. Hjälparen lagrar en token för en specifik registerpublik, så den kan inte pekas om mot VPN-gatewayen genom att redigera en konfigurationsfil.

docker login registry.example.com

Jämför underhållskostnaden, inte antalet frågor

En delad credential ser billig ut eftersom arbetet är osynligt tills det misslyckas. Räkna i stället vad varje alternativ kostar under ett år: registrering, förnyelse, återkallning, radien av ett läckage och antalet system som berörs när någon slutar. En certifikatflotta kostar mer att bygga och mindre att driva i skala; en kopierad kod kostar ingenting att starta och allt att nysta upp.

Välj sedan per ben i stället för globalt. Wi-Fi kan flytta till certifikat, VPN kan behålla sin stödda SSO med MFA, och registret kan använda tokens med explicita omfattningar. Registrera ägare, publik, omfattning, utgång och återkallningsväg för var och en, och frågorna faller där de ska i stället för överallt på en gång. Den registreringen är också svaret när en revisor frågar vilka system som fortfarande litar på ett lösenord.