Kial unu OTP ne povas kovri Wi-Fi, VPN kaj registron

Unueca sinensaluto promesas unu identecon kaj malpli da demandoj, sed la promeso rompiĝas ĉe la tria protokolo. La kaptilo estas supozi, ke unu sukcesa aŭtentikigo produktas ĵetonon, kiun ĉiu alia protokolo povas prezenti. Wi-Fi-aliro, VPN-eniro kaj uja registro ĉiu faras malsaman interŝanĝon, kun malsamaj publikoj kaj vivdaŭroj. Kunhavigi la konton estas decido de la dosierujo; kunhavigi la akreditilon estas decido de protokolo, kaj la protokoloj malofte konsentas.

Tri interŝanĝoj, tri posedantoj

Entreprena Wi-Fi ruligas EAP-metodon ene de 802.1X, kutime finitan de RADIUS-servo, kiu havas propran vidon al la uzanto aŭ aparato. VPN-pordego aŭtentikigas per sia propra subtenata fluo kaj poste tenas seancon kun propra reaŭtentikiga tempigilo. Registro respondas neaŭtentikigitan peton per defio, kiu nomas ĵeton-servon, publikon kaj amplekson, kaj la kliento interŝanĝas sian akreditilon kontraŭ mallongdaŭra ĵetono.

Tiuj ne estas tri vidpunktoj de unu seanco. Ĉiu havas propran kontrolanton, propran vivdaŭron kaj propran revokvojon, kaj tial pasvorta ŝanĝo en la dosierujo povas lasi unu funkcianta kaj alian rompita. Traktu ilin kiel tri integriĝojn, kiuj hazarde kunhavigas uzantodosierujon.

Kion retumila SSO portas kaj kion ne

Retumila seanco ĉe identecprovizanto estas vere utila: aplikaĵoj, kiuj alidirektas al ĝi, heredas la saluton, kiun la uzanto jam kompletigis. Tio funkcias ĉar tiuj aplikaĵoj parolas la samajn alidirektajn kaj ĵetonajn protokolojn kaj akceptas la saman publikon. Petanto, kiu parolas EAP, havas neniun alidirekton por sekvi, kaj Docker-kliento, kiu ricevas registran defion, ne petas OIDC-identecan ĵetonon. La identecprovizanto povas garantii nur protokolojn, por kiuj ĝi estis konstruita.

La malsukceso estas facile videbla en la protokoloj, post kiam vi scias, kien rigardi. La identecprovizanto raportas sukcesan saluton, dum la Wi-Fi-asocio ankoraŭ malsukcesas, aŭ la registro redonas 401 post ĵetoninterŝanĝo, kiun la retumilo neniam vidis. Du sukcesoj kaj unu malsukceso ne estas kontraŭdiro; ili estas tri apartaj aŭtentikigoj.

Kie atestilo anstataŭas ripetan kodon

Por administrataj aparatoj, atestila EAP forigas la homan paŝon sen forigi identecon: la aparato prezentas atestilon, la RADIUS-servo kontrolas ĝin ĉe la eldona aŭtoritato, kaj revoko okazas ĉe tiu aŭtoritato anstataŭ en kunhavigita sekreto. La interŝanĝo estas vivcikla laboro, ĉar atestiloj eksvalidiĝas kaj devas esti renovigitaj antaŭ tio.

Registroj havas ekvivalentan dividon. Interaga uzanto povas saluti unufoje kaj lasi akreditilan helpanton konservi la rezultantan ĵetonon, dum aŭtomatigo uzu mallarĝe limigitan servan akreditilon aŭ laborŝarĝan identecon. Neniu el ili estu unufoja kodo de homo kopiita en pipon. La helpanto konservas ĵetonon por specifa registra publiko, do ĝi ne povas esti realidirektita al la VPN-pordego per redaktado de agorda dosiero.

docker login registry.example.com

Komparu la prizorgan koston, ne la nombron de demandoj

Kunhavigita akreditilo ŝajnas malmultekosta, ĉar la laboro estas nevidebla ĝis ĝi malsukcesos. Anstataŭe kalkulu, kion ĉiu opcio kostas dum jaro: aliĝo, renovigo, revoko, la efikradiuso de liko, kaj la nombro de sistemoj tuŝataj, kiam iu foriras. Atestila floto kostas pli por konstrui kaj malpli por funkciigi je skalo; kopiita kodo kostas nenion por komenci kaj ĉion por malimpliki.

Poste elektu laŭ gambo anstataŭ tutmonde. Wi-Fi povas transiri al atestiloj, la VPN povas konservi sian subtenatan SSO kun MFA, kaj la registro povas uzi ĵetonojn kun eksplicitaj ampleksoj. Notu la posedanton, publikon, amplekson, findaton kaj revokvojon por ĉiu, kaj la demandoj falos tie, kie ili devas, anstataŭ ĉie samtempe. Tiu noto ankaŭ estas la respondo, kiam revizoro demandas, kiuj sistemoj ankoraŭ fidas pasvorton.