Kvifor éin OTP ikkje kan dekkje Wi-Fi, VPN og eit register

Éin pålogging lovar éin identitet og færre spørsmål, og løftet brest ved den tredje protokollen. Fella er å tru at éin vellukka autentisering lagar eit token som alle andre protokollar kan leggje fram. Wi-Fi-innslepp, VPN-inngang og eit containerregister køyrer kvar si utveksling, med ulike publikum og levetider. Å dele kontoen er ei katalogavgjerd; å dele legitimasjonen er ei protokollavgjerd, og protokollane er sjeldan samde.

Tre utvekslingar, tre eigarar

Bedrifts-Wi-Fi køyrer ein EAP-metode inne i 802.1X, vanlegvis avslutta av ein RADIUS-teneste som har sitt eige syn på brukaren eller eininga. Ein VPN-gateway autentiserer gjennom sin eigen støtta flyt og held deretter ein sesjon med sin eigen reautentiseringstimer. Eit register svarar på ei uautentisert førespurnad med ei utfordring som namngir ein tokenteneste, eit publikum og eit omfang, og klienten byter legitimasjonen sin mot eit kortliva token.

Det er ikkje tre visingar av éin sesjon. Kvar har sin eigen verifiserar, si eiga levetid og sin eigen tilbakekallingsveg, og difor kan ei passordendring i katalogen la éin halde fram med å verke og ein annan bli broten. Handsame dei som tre integrasjonar som tilfeldigvis deler ein brukarkatalog.

Kva nettlesar-SSO ber og ikkje ber

Ein nettlesarsesjon hos ein identitetsleverandør er verkeleg nyttig: applikasjonar som omdirigerer dit, arvar pålogginga brukaren alt har fullført. Det verkar fordi desse applikasjonane snakkar dei same omdirigerings- og tokenprotokollane og godtek det same publikumet. Ein supplikant som snakkar EAP har inga omdirigering å følgje, og ein Docker-klient som får ei registerutfordring ber ikkje om eit OIDC-id-token. Identitetsleverandøren kan berre garantere for protokollar han vart bygd for å snakke.

Feilen er lett å sjå i loggane når ein veit kvar ein skal sjå. Identitetsleverandøren rapporterer ei vellukka pålogging medan Wi-Fi-tilkoplinga framleis feilar, eller registeret returnerer 401 etter ei tokenutveksling som nettlesaren aldri såg. To suksessar og éin feil er ikkje ei motsetning; det er tre separate autentiseringar.

Kvar eit sertifikat erstattar ein gjenteken kode

For styrte einingar fjernar sertifikatbasert EAP det menneskelege trinnet utan å fjerne identitet: eininga legg fram eit sertifikat, RADIUS-tenesta kontrollerer det mot utferdaren, og tilbakekalling skjer hos den utferdaren i staden for i ein delt løyndom. Prisen er livssyklusarbeid, fordi sertifikat går ut og må fornyast før dei gjer det.

Register har ei tilsvarande deling. Ein interaktiv brukar kan logge på éin gong og la ein legitimasjonshjelpar lagre tokenet som oppstår, medan automatisering bør bruke ein snevert avgrensa tenestekonto eller ein arbeidslastidentitet. Ingen av dei bør vere ein persons eingongskode kopiert inn i ein pipeline. Hjelparen lagrar eit token for eit bestemt registerpublikum, så det kan ikkje peikast mot VPN-gatewayen ved å redigere ei konfigurasjonsfil.

docker login registry.example.com

Samanlikn vedlikehaldskostnaden, ikkje talet på spørsmål

Delt legitimasjon ser billeg ut fordi arbeidet er usynleg til det feilar. Tel i staden kva kvart alternativ kostar over eit år: påmelding, fornying, tilbakekalling, radiusen av ei lekkasje og talet på system som vert rørte når nokon sluttar. Ein sertifikatflåte kostar meir å byggje og mindre å drive i skala; ein kopiert kode kostar ingenting å starte og alt å nøste opp.

Vel deretter per ben i staden for globalt. Wi-Fi kan flytte til sertifikat, VPN-en kan halde på sin støtta SSO med MFA, og registeret kan bruke token med eksplisitte omfang. Registrer eigar, publikum, omfang, utløp og tilbakekallingsveg for kvar av dei, og spørsmåla fell der dei skal i staden for overalt på éin gong. Den registreringa er også svaret når ein revisor spør kva system som framleis stolar på eit passord.