Autentifikavimo profiliai – kai „Patvirtinti“ turi padaryti daugiau nei prijungti

Kiekvienas Notakey autentifikavimas baigiasi vienodai: naudotojas perskaito, ką tvirtina, ir paspaudžia Patvirtinti arba Atmesti – pasirašytą, audituojamą „taip“ arba „ne“. Paprastai šis atsakymas atrakina prisijungimą. Tačiau įrenginiui nesvarbu, koks buvo klausimas: autentifikavimo profilis leidžia prie atsakymo prisegti serverio pusėje vykdomus atgalinius kvietimus (angl. callbacks), todėl „Patvirtinti“ (arba „Atmesti“) gali paleisti bet ką, kas turi HTTP API – durų valdiklį, tinklo politiką, užklausų sistemą, išmaniąją relę.

QR scan or API call ──▶ auth request ──▶ push/app ──▶ user taps Approve
     (from a profile)                                        │
                                              callbacks fire in the background:
                                              ├─▶ https://door.local/open?…
                                              ├─▶ https://nac/api/policy…
                                              └─▶ anything else you add

Sudedamosios dalys, visos tiesiai iš produkto:

Profilis apibrėžia užklausą, kurią mato naudotojas (pavadinimą, aprašymą, galiojimo trukmę), su {variable} pakaitomis ({username}, {user_email}, {state} ir kitomis) bet kuriame lauke.
Kiekviename profilyje atgalinius kvietimus priskiriate įvykiams: Create (užklausa sukurta), Approve, Deny, Response (bet kuris atsakymas), Error arba Any. Atgalinių kvietimų skaičius profilyje neribojamas, o vykdomi jie fone, todėl lėtas trečiosios šalies API niekada nestabdo paties autentifikavimo.
Kiekvieną kviečiamą URL galima apsaugoti OAuth 2.0 „client credentials“ srautu arba autentifikavimu antraštėje (bendru prieigos raktu (token)), todėl nesate priversti palikti atviro, neautentifikuoto webhook.

Profiliai kuriami valdymo skydelyje, jūsų serviso skiltyje Authentication profiles; vėliau užklausos gali remtis profiliu per API arba (ir būtent tai fizinio pasaulio scenarijus daro praktiškus) per QR kodą, apskritai be jokio push pranešimo.

Išbandykite dabar pat: demonstracinis bankas jus prijungia būtent taip

Jums nereikia tikėti mūsų žodžiu, kaip tai atrodo: demonstracinio banko prisijungimas ir yra šis mechanizmas. Prisijungimo puslapyje rodomas QR kodas. Pačiame puslapyje nieko nevedate. Atsidarykite Notakey Authenticator, paspauskite skenavimo mygtuką ir nukreipkite kamerą į ekraną:

Nuskenavus kodą autentifikavimo užklausa sukuriama tiesiai jūsų telefone. Čia veikia kitame skyriuje aprašyta gilioji nuoroda a=a. Matote tiksliai, ką tvirtinate, ir vienas paspaudimas ant Patvirtinti:

…ir naršyklės kortelė, iš kurios skenavote, jau prijungta. Įdomiausia yra nematomoji pusė: jūsų patvirtinimas paleidžia atgalinį kvietimą į banko vidinę sistemą su užklausos būsenos (state) parametru, sistema jį susieja su laukiančiu puslapiu, ir sesija atsidaro. Naudotojo vardo laukas, slaptažodžio laukas, nuoroda „pamiršau slaptažodį“ – jų nėra, nes jų nereikia. Būtent šį šabloną likusi vadovo dalis nukreipia į kitus taikinius.

Praktinis pavyzdys: durys, kurios klausia jūsų telefono

Duomenų centro durys, o šalia – laminuotas QR kodas. Nuskenavus jį su Notakey Authenticator, autentifikavimo užklausa sukuriama vietoje. Giliosios nuorodos veiksmas a=a dokumentacijoje aprašytas kaip „užklausti autentifikavimo be push pranešimo“, todėl tai veikia, nors į telefoną niekas nieko nesiuntė:

notakey://qr?a=a&u=ntk.example.com&k=<service-id>&p=<profile-id>

Užkoduokite šį URI į QR kodą (k yra serviso ID, p – profilio ID; abu matomi valdymo skydelyje) ir atsispausdinkite. Už jo stovintis profilis:

Pavadinimas / aprašymas: „Atidaryti DC duris — {username}, patvirtinkite biometriniais duomenimis.“ Nustatykite trumpą galiojimą, pvz., 60 sekundžių: niekas, nuskenavęs durų kodą, negalvoja apie jį penkias minutes.
Atgalinis kvietimas įvykiui Approve: durų valdiklio API, https://door-controller.internal/open?door=dc-1&user={username}, apsaugotas prieigos raktu antraštėje. Patvirtinta → HTTP kvietimas → spyna atsirakina.
Atgalinis kvietimas įvykiui Deny (nebūtinas, bet vertas): užklausa, kuri buvo sukurta, bet atmesta, reiškia, kad prie jūsų durų kažkas stovėjo, o telefono savininkas pasakė „ne“. Susiekite tai su savo perspėjimų sistema. Kintamieji {response_ip} ir {username} papasakos visą istoriją.
Atgalinis kvietimas įvykiui Create (nebūtinas): įrašas audito žurnale tą pačią akimirką, kai kas nors nuskenuoja kodą, dar prieš atsakant.

Naudotojo patirtis – tas pats demonstracinio banko srautas, tik nukreiptas į spyną, o ne į mokėjimą: nuskenuojate, perskaitote, ką tvirtinate, paspaudžiate, ir įvyksta. Jokių klonuojamų kortelių, jokio visai komandai bendro durų PIN kodo, ir kiekvienas atidarymas yra pasirašytas, konkrečiam asmeniui priskirtas įvykis.

Praktinis pavyzdys: VPN prisijungimas, kuris sukonfigūruoja tinklą

Atgaliniai kvietimai puikiai dera su RADIUS sprendimais iš mūsų VPN 2FA vadovo. Vienas šablonas iš tikro diegimo su Aruba valdikliu: VPN naudotoją, kaip įprasta, autentifikuoja per RADIUS ir auth-proxy, o atgalinis kvietimas tada nurodo tinklo valdikliui aktyvuoti tam naudotojui skirtą tinklo profilį. Prisijungimas ir tinklo autorizacija tampa vienu patvirtinimu, o ne dviem sistemomis, kurios, tikėkimės, sutaria.

Atgalinio kvietimo turinyje profilio kintamieji ir atsiperka: {username}, {user_guid} (Active Directory GUID, patogus kaip pastovus raktas valdiklio pusėje) ir {state} pakeičiami kiekvienoje užklausoje, todėl vienas profilis aptarnauja visus naudotojus.

Iš API pusės

Viską, ką gali pradėti QR kodas, gali pradėti ir jūsų vidinė sistema. Autentifikavimo užklausų API priima profile parametrą (tuomet užklausa pavadinimą, tekstą ir galiojimą perima iš profilio) bei custom_vars: JSON struktūrą su jūsų pačių raktų ir reikšmių poromis, kurios perteka į profilio laukus ir atgalinius kvietimus. Pavyzdžiui, rezervacijų sistema gali perduoti {"room": "B12", "slot": "14:00"}, telefone parodyti būtent tai ir perduoti tai atgaliniam kvietimui, kuris tinkamu laiku atrakina tinkamą kambarį.

Dvi smulkmenos, kurias verta žinoti prieš imantis darbo:

Deny ir Error taip pat yra įvykiai. Naudingiausi atgaliniai kvietimai realioje eksploatacijoje dažnai susiję ne su sėkmės scenarijumi: gavę Deny, įspėkite atsakingą žmogų, o Error fiksuokite žurnale su {error} / {error_message}, kai toliau esantis API nustojo atsakinėti.
Naudotojo požiūriu atgaliniai kvietimai – „paleisk ir pamiršk“. Jie vykdomi fone; apkrautame įrenginyje daug lygiagrečių kvietimų gali kauptis eilėje. Priimančiąją pusę projektuokite idempotentišką: užklausos {uuid} yra jūsų dubliavimo prevencijos raktas.

Kur šis sprendimas pritampa

Autentifikavimas buvo sunkioji dalis: pasirašytas, asmeninis, biometrija paremtas „taip / ne“ su audito žurnalu. Profiliai leidžia šį primityvą panaudoti viskam aplinkui: fizinei prieigai, tinklo politikai, patvirtinimams vidiniuose įrankiuose. Jei įrenginys jau tvarko jūsų prisijungimus, kita „kas tai patvirtino?“ sistema, kurią ruošėtės statyti, galbūt tėra per vieną profilį ir vieną atgalinį kvietimą nuo jūsų.

Susiję vadovai

Push pranešimai iš bet kurio scenarijaus, informacinė tos pačios API pusė
VPN 2FA per RADIUS – išsamus auth-proxy diegimo vadovas, RADIUS srautas, kuriuo remiasi Aruba šablonas
Išbandykite demonstracinį banką: tas pats „nuskenuok–peržiūrėk–patvirtink“ srautas, nukreiptas į mokėjimo operaciją