Zašto jedan OTP ne može pokriti Wi-Fi, VPN i registar

Jedinstvena prijava obećava jedan identitet i manje upita, ali obećanje se lomi na trećem protokolu. Zamka je pretpostavka da jedna uspješna autentikacija stvara token koji svaki drugi protokol može predstaviti. Pristup Wi-Fi mreži, ulaz u VPN i registar kontejnera svaki provodi drugačiju razmjenu, s različitim publikama i rokovima. Dijeljenje računa odluka je imenika; dijeljenje akreditiva odluka je protokola, a protokoli se rijetko slažu.

Tri razmjene, tri vlasnika

Poslovni Wi-Fi izvodi EAP metodu unutar 802.1X, obično je zaključuje RADIUS servis koji ima vlastiti pogled na korisnika ili uređaj. VPN pristupnik autentificira se kroz vlastiti podržani tok i zatim drži sesiju s vlastitim mjeračem ponovne autentikacije. Registar odgovara na neautentificirani zahtjev izazovom koji imenuje servis tokena, publiku i opseg, a klijent razmjenjuje svoj akreditiv za kratkotrajni token.

To nisu tri pogleda na jednu sesiju. Svaki ima vlastiti provjerivač, vlastiti rok i vlastiti put opoziva, zbog čega promjena lozinke u imeniku može ostaviti jedan od njih radnim, a drugi slomljenim. Tretirajte ih kao tri integracije koje slučajno dijele korisnički imenik.

Što SSO u pregledniku prenosi, a što ne

Sesija preglednika kod davatelja identiteta uistinu je korisna: aplikacije koje preusmjeravaju na njega nasljeđuju prijavu koju je korisnik već završio. To funkcionira jer te aplikacije govore iste protokole preusmjeravanja i tokena i prihvaćaju istu publiku. Tražitelj koji govori EAP nema preusmjeravanja da slijedi, a Docker klijent koji primi izazov registra ne traži OIDC token identiteta. Davatelj identiteta može jamčiti samo za protokole za koje je izgrađen.

Kvar je lako vidjeti u zapisima kad znate gdje gledati. Davatelj identiteta izvještava o uspješnoj prijavi dok povezivanje s Wi-Fi mrežom još uvijek ne uspijeva, ili registar vraća 401 nakon razmjene tokena koju preglednik nikad nije vidio. Dva uspjeha i jedan kvar nisu proturječje; to su tri odvojene autentikacije.

Gdje certifikat zamjenjuje ponovljeni kod

Za upravljane uređaje EAP zasnovan na certifikatima uklanja ljudski korak bez uklanjanja identiteta: uređaj predstavlja certifikat, RADIUS servis ga provjerava kod izdavatelja, a opoziv se događa kod tog izdavatelja, a ne u dijeljenoj tajni. Cijena je rad na životnom ciklusu, jer certifikati istječu i moraju se obnoviti prije toga.

Registri imaju jednakovrijednu podjelu. Interaktivni korisnik može se prijaviti jednom i pustiti pomoćnika za akreditive da pohrani dobiveni token, dok automatizacija treba koristiti usko ograničen servisni akreditiv ili identitet radnog opterećenja. Ni jedno ne bi smio biti čovjekov jednokratni kod kopiran u cjevovod. Pomoćnik pohranjuje token za određenu publiku registra, pa se ne može preusmjeriti na VPN pristupnik uređivanjem konfiguracijske datoteke.

docker login registry.example.com

Usporedite trošak održavanja, ne broj upita

Dijeljeni akreditiv izgleda jeftin jer je rad nevidljiv dok ne pokvari. Umjesto toga izbrojite što svaka opcija stoji tijekom godine: upis, obnova, opoziv, domet posljedica curenja i broj sustava dotaknutih kad netko ode. Flota certifikata skuplja je za izgradnju i jeftinija za pogon u mjerilu; kopirani kod ne stoji ništa za početak i sve za razmotavanje.

Zatim birajte po segmentu, a ne globalno. Wi-Fi može prijeći na certifikate, VPN može zadržati podržani SSO s MFA, a registar može koristiti tokene s izričitim opsezima. Zabilježite vlasnika, publiku, opseg, istek i put opoziva za svaki, i upiti će pasti gdje treba umjesto svugdje odjednom. Taj je zapis i odgovor kad revizor pita koji sustavi još vjeruju lozinci.