Autentifikācijas profili — kad "Apstiprināt" paveic vairāk nekā pieteikšanos

Katra Notakey autentifikācija noslēdzas vienādi: lietotājs izlasa, ko apstiprina, un pieskaras Apstiprināt vai Noraidīt: tā ir parakstīta, pārbaudāma atbilde “jā” vai “nē”. Parasti ar šo atbildi lietotājs tiek ielaists sistēmā. Taču sistēmai ir vienalga, kāds bijis jautājums: autentifikācijas profils ļauj atbildei piesaistīt servera puses callback izsaukumus, tāpēc Apstiprināt (vai Noraidīt) var iedarbināt jebko, kam ir HTTP API — durvju kontrolieri, tīkla politiku, biļešu sistēmu, viedo releju.

QR skenēšana vai API izsaukums ──▶ autentifikācijas pieprasījums ──▶ push/app ──▶ lietotājs nospiež Apstiprināt
     (no profila)                                                                          │
                                                        callback izsaukumi notiek fonā:
                                                        ├─▶ https://door.local/open?…
                                                        ├─▶ https://nac/api/policy…
                                                        └─▶ jebkas cits, ko pievienojat

Galvenās sastāvdaļas (tā, kā tās nosauktas pašā produktā):

• Profils nosaka, kādu pieprasījumu redz lietotājs (nosaukumu, aprakstu, derīguma termiņu), un jebkurā laukā var lietot {variable} aizstāšanu ({username}, {user_email}, {state} un citus mainīgos).
• Callback izsaukumus profilā piesaista notikumiem: Create (pieprasījums izveidots), Approve, Deny, Response (jebkura atbilde), Error vai Any. Callback izsaukumu skaits profilā nav ierobežots, un tie darbojas fonā, tāpēc lēns trešās puses API nekad nebloķē pašu autentifikāciju.
• Katru izsaucamo URL var aizsargāt ar OAuth 2.0 klienta piekļuves datiem vai autentifikāciju galvenē (header) ar koplietotu tokenu; neaizsargāts webhook nav jāatstāj.

Profilus izveido vadības panelī, jūsu servisa sadaļā Authentication profiles; pēc tam uz profilu var atsaukties gan API pieprasījumos, gan (un tieši tas paver praktisku lietojumu fiziskajā pasaulē) QR kodā, pavisam bez push paziņojuma.

Izmēģiniet tūlīt — tieši tā notiek pieteikšanās demo bankā

Nav jāpaļaujas tikai uz mūsu vārdiem: demo bankas pieteikšanās ir tieši šis mehānisms. Pieteikšanās lapā redzams QR kods, un pašā lapā nekas nav jāraksta. Atveriet Notakey Authenticator, pieskarieties skenēšanas pogai un pavērsiet kameru pret ekrānu:

Noskenējot kodu, autentifikācijas pieprasījums rodas tieši jūsu tālrunī: tas ir nākamajā sadaļā aprakstītais a=a deeplink darbībā. Jūs redzat tieši to, ko apstiprināt, un pietiek ar vienu pieskārienu pogai Apstiprināt:

…un pārlūka cilne, no kuras skenējāt, ir pieteikusies. Interesantākais notiek neredzamajā pusē: jūsu apstiprinājums izraisa callback izsaukumu uz bankas backend sistēmu ar pieprasījuma state parametru, backend to sasaista ar gaidošo lapu, un sesija atveras. Ne lietotājvārda lauka, ne paroles lauka, ne saites “aizmirsu paroli” — nekā tāda nav, jo nekas no tā nav vajadzīgs. Tieši šo modeli pārējā raksta daļa pārnes uz citiem kontekstiem.

Praktisks piemērs — durvis, kas prasa apstiprinājumu tālrunī

Iedomājieties datu centra durvis ar laminētu QR kodu blakus. Noskenējot to ar Notakey Authenticator, autentifikācijas pieprasījums tiek izveidots turpat uz vietas: deeplink darbība a=a dokumentācijā aprakstīta kā “pieprasīt autentifikāciju bez push paziņojuma”, tāpēc tā darbojas arī tad, ja tālrunim nekas nav sūtīts:

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

Iekodējiet šo URI QR kodā (k ir servisa ID, p — profila ID; abi redzami vadības panelī) un izdrukājiet to. Kodam piesaistītais profils:

• Nosaukums / apraksts: “Atvērt datu centra durvis — {username}, apstipriniet ar biometriju.” Iestatiet īsu derīguma termiņu, piemēram, 60 sekundes: neviens, kas noskenējis durvju kodu, nedomās piecas minūtes.
• Callback izsaukums notikumam Approve: durvju kontroliera API, https://door-controller.internal/open?door=dc-1&user={username}, aizsargāts ar tokenu galvenē. Apstiprināt → HTTP izsaukums → slēdzene atveras.
• Callback izsaukums notikumam Deny (nav obligāts, bet noder): pieprasījums, kas tika izveidots, bet noraidīts, nozīmē, ka pie jūsu durvīm kāds stāvēja un tālruņa īpašnieks pateica “nē”. Savienojiet šo notikumu ar savu brīdinājumu sistēmu. Mainīgie {response_ip} un {username} parādīs, kas noticis.
• Callback izsaukums notikumam Create (nav obligāts): ieraksts audita žurnālā brīdī, kad kāds noskenē kodu, vēl pirms atbildes.

Lietotājam tā ir tā pati demo bankas plūsma, tikai šoreiz tā atver durvis, nevis apstiprina maksājumu: noskenē, izlasa, ko apstiprina, pieskaras — un notiek attiecīgā darbība. Nav klonējamu piekļuves karšu, nav visai komandai zināma durvju PIN koda, un katra atvēršana ir parakstīts notikums, kas piesaistīts konkrētai personai.

Praktisks piemērs — VPN pieteikšanās, kas konfigurē tīklu

Callback izsaukumi labi papildina RADIUS uzstādījumu no mūsu VPN 2FA rokasgrāmatas. Šis modelis nāk no reālas ieviešanas ar Aruba kontrolieri: VPN lietotāju kā ierasts autentificē caur RADIUS ar auth-proxy, un pēc tam callback izsaukums liek tīkla kontrolierim aktivizēt šim lietotājam pareizo tīkla profilu. Pieteikšanās un tīkla autorizācija saplūst vienā apstiprinājumā: vairs nav divu atsevišķu sistēmu, par kuru saskaņu atliek vien cerēt.

Callback izsaukuma pieprasījuma saturā īpaši noder profila mainīgie: {username}, {user_guid} (Active Directory GUID, noderīgs kā stabila atslēga kontroliera pusē) un {state} tiek aizstāti katrā pieprasījumā atsevišķi, tāpēc viens profils apkalpo visus lietotājus.

No API puses

Visu, ko var iedarbināt ar QR kodu, var iedarbināt arī jūsu backend sistēma. Autentifikācijas pieprasījuma API pieņem parametru profile (tad pieprasījums nosaukumu, tekstu un derīguma termiņu ņem no profila), kā arī custom_vars: JSON hash ar jūsu pašu atslēgu un vērtību pāriem, kas nonāk profila laukos un callback izsaukumos. Piemēram, rezervāciju sistēma var nodot {"room": "B12", "slot": "14:00"}, parādīt tieši šos datus tālrunī un pēc tam nodot tos callback izsaukumam, kas īstajā laikā atslēdz īsto telpu.

Divas lietas, ko zināt, pirms ķeraties pie izstrādes:

• Notikumi ir arī Deny un Error. Produkcijā visnoderīgākie callback izsaukumi bieži nav tie, kas seko veiksmīgajam scenārijam: lieciet kādam uzzināt par Deny un žurnalējiet Error ar {error} / {error_message}, kad lejupējais API pārstāj atbildēt.
• Callback izsaukumi darbojas pēc principa “izsauc un aizmirsti”. Tie notiek fonā, un noslogotā iekārtā daudzi paralēli callback izsaukumi var sastāties rindā. Veidojiet saņēmēja pusi idempotentu: pieprasījuma {uuid} ir jūsu atslēga dublikātu atsijāšanai.

Kur tas iederas

Sarežģītā daļa bija autentifikācija: parakstīta, personai piesaistīta, ar biometriju apstiprināta atbilde “jā/nē” ar audita pierakstu. Profili ļauj šo pamatelementu izmantot atkārtoti it visam apkārtējam: fiziskajai piekļuvei, tīkla politikai, apstiprinājumiem iekšējos rīkos. Ja iekārta jau apkalpo jūsu pieteikšanās, tad līdz nākamajai sistēmai, kurai jāatbild uz jautājumu “kurš to apstiprināja?”, visticamāk, atlicis tikai viens profils un viens callback izsaukums.

Saistītās rokasgrāmatas

• Push paziņojumi no jebkura skripta: tā paša API informējošā puse
• VPN 2FA ar RADIUS — pilna auth-proxy uzstādīšana: RADIUS plūsma, uz kuras balstās Aruba piemērs
• Izmēģiniet demo banku: tā pati plūsma “noskenēt, izlasīt, apstiprināt”, tikai maksājuma apstiprināšanai