Hvorfor én OTP ikke kan dække Wi-Fi, VPN og et registry

Single sign-on lover én identitet og færre opfordringer, og løftet brister ved den tredje protokol. Fælden er at antage, at én vellykket godkendelse producerer et token, som alle andre protokoller kan fremvise. Wi-Fi-adgang, VPN-indgang og et container-registry kører hver en forskellig udveksling med forskellige publikummer og levetider. At dele kontoen er en beslutning i mappen; at dele legitimationsoplysningen er en protokolbeslutning, og protokollerne er sjældent enige.

Tre udvekslinger, tre ejere

Virksomheds-Wi-Fi kører en EAP-metode inde i 802.1X, normalt afsluttet af en RADIUS-tjeneste, der har sit eget syn på brugeren eller enheden. En VPN-gateway godkender gennem sit eget understøttede flow og holder derefter en session med sin egen genbekræftelsestimer. Et registry svarer på en uautentificeret anmodning med en udfordring, der navngiver en tokentjeneste, et publikum og et omfang, og klienten bytter sine legitimationsoplysninger for et kortlivet token.

Det er ikke tre visninger af én session. Hver har sin egen verifikator, sin egen levetid og sin egen tilbagekaldelsesvej, og derfor kan en adgangskodeændring i mappen efterlade den ene fungerende og den anden brudt. Behandl dem som tre integrationer, der tilfældigvis deler en brugermappe.

Hvad browser-SSO bærer og ikke bærer

En browsersession hos en identitetsudbyder er virkelig nyttig: applikationer, der omdirigerer til den, arver det login, brugeren allerede har gennemført. Det virker, fordi disse applikationer taler de samme omdirigerings- og tokenprotokoller og accepterer det samme publikum. En supplikant, der taler EAP, har ingen omdirigering at følge, og en Docker-klient, der modtager en registry-udfordring, beder ikke om et OIDC-id-token. Identitetsudbyderen kan kun garantere for protokoller, den blev bygget til at tale.

Fejlen er let at se i logfilerne, når man ved, hvor man skal kigge. Identitetsudbyderen rapporterer et vellykket login, mens Wi-Fi-tilknytningen stadig fejler, eller registry’et returnerer 401 efter en tokenudveksling, som browseren aldrig så. To succeser og én fejl er ikke en modsigelse; det er tre separate godkendelser.

Hvor et certifikat erstatter en gentagen kode

For administrerede enheder fjerner certifikatbaseret EAP det menneskelige trin uden at fjerne identitet: enheden fremviser et certifikat, RADIUS-tjenesten kontrollerer det mod den udstedende myndighed, og tilbagekaldelse sker hos den myndighed i stedet for i en delt hemmelighed. Byttehandlen er livscyklusarbejde, fordi certifikater udløber og skal fornyes, før de gør.

Registries har en tilsvarende opdeling. En interaktiv bruger kan logge ind én gang og lade en legitimationshjælper gemme det resulterende token, mens automatisering bør bruge en snævert afgrænset tjenestekonto eller en workload-identitet. Ingen af dem bør være et menneskes engangskode kopieret ind i en pipeline. Hjælperen gemmer et token til et bestemt registry-publikum, så det kan ikke peges mod VPN-gatewayen ved at redigere en konfigurationsfil.

docker login registry.example.com

Sammenlign vedligeholdelsesomkostningen, ikke antallet af opfordringer

En delt legitimationsoplysning ser billig ud, fordi arbejdet er usynligt, indtil det fejler. Tæl i stedet, hvad hver mulighed koster over et år: tilmelding, fornyelse, tilbagekaldelse, radiusen af en lækage og antallet af systemer, der berøres, når nogen forlader organisationen. En certifikatflåde koster mere at bygge og mindre at drive i skala; en kopieret kode koster intet at starte og alt at rulle tilbage.

Vælg derefter for hvert ben i stedet for globalt. Wi-Fi kan flytte til certifikater, VPN’en kan beholde sit understøttede SSO med MFA, og registry’et kan bruge tokens med eksplicitte omfang. Registrer ejer, publikum, omfang, udløb og tilbagekaldelsesvej for hver af dem, og opfordringerne falder, hvor de skal, i stedet for overalt på én gang. Den registrering er også svaret, når en revisor spørger, hvilke systemer der stadig stoler på en adgangskode.