De ce un singur OTP nu acoperă Wi-Fi, VPN și un registru

Autentificarea unică promite o identitate și mai puține solicitări, iar promisiunea se rupe la al treilea protocol. Capcana este să presupunem că o autentificare reușită produce un token pe care orice alt protocol îl poate prezenta. Accesul Wi-Fi, intrarea VPN și un registru de containere fac fiecare un schimb diferit, cu publicuri și durate de viață diferite. A partaja contul este o decizie a directorului; a partaja acreditarea este o decizie a protocolului, iar protocoalele rareori sunt de acord.

Trei schimburi, trei proprietari

Wi-Fi-ul de întreprindere rulează o metodă EAP în 802.1X, de obicei încheiată de un serviciu RADIUS care are propria viziune asupra utilizatorului sau dispozitivului. O poartă VPN se autentifică prin propriul flux acceptat și apoi menține o sesiune cu propriul temporizator de reautentificare. Un registru răspunde unei cereri neautentificate cu o provocare care numește un serviciu de tokenuri, un public și un domeniu, iar clientul își schimbă acreditarea pe un token de scurtă durată.

Acestea nu sunt trei vederi ale unei singure sesiuni. Fiecare are propriul verificator, propria durată de viață și propria cale de revocare, de aceea o schimbare de parolă în director poate lăsa unul funcțional și altul rupt. Tratează-le ca trei integrări care împart din întâmplare un director de utilizatori.

Ce duce SSO-ul din browser și ce nu duce

O sesiune de browser la un furnizor de identitate este cu adevărat utilă: aplicațiile care redirecționează acolo moștenesc autentificarea pe care utilizatorul a finalizat-o deja. Aceasta funcționează pentru că acele aplicații vorbesc aceleași protocoale de redirecționare și de tokenuri și acceptă același public. Un solicitant care vorbește EAP nu are nicio redirecționare de urmat, iar un client Docker care primește o provocare de registru nu cere un token de identitate OIDC. Furnizorul de identitate poate garanta doar protocoalele pentru care a fost construit.

Eșecul este ușor de văzut în jurnale când știi unde să te uiți. Furnizorul de identitate raportează o autentificare reușită în timp ce asocierea Wi-Fi încă eșuează, sau registrul returnează 401 după un schimb de token pe care browserul nu l-a văzut niciodată. Două reușite și un eșec nu sunt o contradicție; sunt trei autentificări separate.

Unde un certificat înlocuiește un cod repetat

Pentru dispozitivele gestionate, EAP bazat pe certificat elimină pasul uman fără a elimina identitatea: dispozitivul prezintă un certificat, serviciul RADIUS îl verifică la autoritatea emitentă, iar revocarea are loc la acea autoritate, nu într-un secret partajat. Prețul este munca de ciclu de viață, pentru că certificatele expiră și trebuie reînnoite înainte.

Registrele au o împărțire echivalentă. Un utilizator interactiv se poate autentifica o dată și poate lăsa un asistent de acreditări să stocheze tokenul rezultat, în timp ce automatizarea ar trebui să folosească o acreditare de serviciu cu domeniu îngust sau o identitate de sarcină de lucru. Niciuna nu ar trebui să fie codul de unică folosință al unei persoane copiat într-o conductă. Asistentul stochează un token pentru un public anume al registrului, așa că nu poate fi redirecționat către poarta VPN editând un fișier de configurare.

docker login registry.example.com

Comparați costul de întreținere, nu numărul de solicitări

O acreditare partajată pare ieftină pentru că munca este invizibilă până când eșuează. Numărați în schimb cât costă fiecare opțiune într-un an: înscriere, reînnoire, revocare, raza de impact a unei scurgeri și numărul de sisteme atinse când cineva pleacă. O flotă de certificate costă mai mult de construit și mai puțin de operat la scară; un cod copiat nu costă nimic la început și totul la descurcare.

Apoi alegeți pe segment, nu global. Wi-Fi-ul poate trece la certificate, VPN-ul poate păstra SSO-ul acceptat cu MFA, iar registrul poate folosi tokenuri cu domenii explicite. Notați proprietarul, publicul, domeniul, expirarea și calea de revocare pentru fiecare, iar solicitările vor cădea unde trebuie, nu peste tot deodată. Acea evidență este și răspunsul când un auditor întreabă ce sisteme mai au încredere într-o parolă.