Autentimisprofiilid – kui Kinnita peaks tegema enamat kui sisse logima

Iga Notakey autentimine lõpeb ühtmoodi: kasutaja loeb, mida ta kinnitab, ja vajutab Kinnita või Keela: allkirjastatud, auditeeritav jah või ei. Tavaliselt avab see vastus sisselogimise. Kuid seadme jaoks pole vahet, mis küsimus oli: autentimisprofiil võimaldab siduda selle vastusega serveripoolsed tagasikutsed (callback’id), nii et Kinnita (või Keela) võib käivitada mida tahes, millel on HTTP API: uksekontrolleri, võrgupoliitika, piletisüsteemi, nutika relee.

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

Kõik osad tulevad otse tootest:

Profiil määrab päringu, mida kasutaja näeb (pealkirja, kirjelduse, kehtivusaja), ning igas väljas töötab {variable}-asendus ({username}, {user_email}, {state} ja teised).
Iga profiili juures saab tagasikutsed siduda sündmustega: Create (päring loodud), Approve, Deny, Response (kumb tahes vastus), Error või Any. Tagasikutsete arv profiili kohta on piiramatu ja need töötavad taustal, nii et aeglane kolmanda osapoole API ei blokeeri kunagi autentimist ennast.
Iga väljakutsutavat URL-i saab kaitsta OAuth 2.0 kliendimandaadi või päisepõhise autentimisega (jagatud pääsutõend ehk token), nii et te ei pea jätma veebihaaki autentimata.

Profiilid luuakse halduspaneelil teie teenuse jaotises Authentication profiles (autentimisprofiilid); seejärel saab päring profiilile viidata kas API kaudu või (ja just see teeb füüsilise maailma kasutusjuhud praktiliseks) QR-koodist, ilma et ühtegi tõukesõnumit üldse saadetaks.

Proovige kohe järele: demopank logib teid sisse just nii

Te ei pea meid uskuma pelgalt sõnast: demopanga sisselogimine ongi seesama mehhanism. Sisselogimisleht kuvab QR-koodi. Lehel endal ei sisesta te midagi. Avage Notakey Authenticator, vajutage skaneerimisnuppu ja suunake kaamera ekraanile:

Koodi skaneerimine loob autentimispäringu otse teie telefonis. Siin ongi tööl järgmises jaotises kirjeldatav a=a deeplink. Näete täpselt, mida kinnitate, ja üksainus vajutus nupule Kinnita:

…ja brauseriaken, millest skaneerisite, ongi sisse logitud. Huvitav on just nähtamatu pool: teie kinnitus käivitab tagasikutse panga taustsüsteemi koos päringu state-parameetriga, taustsüsteem sobitab selle ootava lehega ja seanss avaneb. Kasutajanime väli, parooliväli, „unustasin parooli“ link – ühtegi neist pole olemas, sest ühtegi pole vaja. Ülejäänud juhend suunab sellesama mustri teistele sihtmärkidele.

Näide elust: uks, mis küsib luba teie telefonilt

Andmekeskuse uks, mille kõrval ripub lamineeritud QR-kood. Selle skaneerimine Notakey Authenticatoriga loob autentimispäringu kohapeal. Deeplink-toiming a=a on dokumenteeritud kui „autentimispäring ilma tõukesõnumita“, nii et see töötab, kuigi telefonile pole keegi midagi saatnud:

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

Kodeerige see URI QR-koodiks (k on teenuse ID, p profiili ID, mõlemad halduspaneelil nähtavad) ja printige välja. Selle taga olev profiil:

Pealkiri / kirjeldus: „Ava DC uks – {username}, kinnitage biomeetriaga.“ Määrake lühike kehtivusaeg, nt 60 sekundit; keegi ei skaneeri uksekoodi selleks, et selle üle viis minutit juurelda.
Tagasikutse sündmusel Approve: uksekontrolleri API, https://door-controller.internal/open?door=dc-1&user={username}, kaitstud päises edastatava tokeniga. Kinnita → HTTP-päring → lukk avaneb.
Tagasikutse sündmusel Deny (valikuline, aga vaeva väärt): päring, mis küll loodi, kuid millest keelduti, tähendab, et keegi seisis teie ukse taga ja telefoni omanik ütles ei. Ühendage see oma häiresüsteemiga. Muutujad {response_ip} ja {username} räägivad kogu loo.
Tagasikutse sündmusel Create (valikuline): kirje auditilogisse hetkel, mil keegi üldse skaneerib, juba enne vastust.

Kasutajakogemus on demopanga voog, mis on makse asemel suunatud lukule: skaneerige, lugege, mida kinnitate, vajutage – ja asi juhtub. Pole kloonitavaid uksekaarte ega kogu meeskonna vahel jagatud ukse-PIN-i ning iga avamine on konkreetse inimesega seotud allkirjastatud sündmus.

Näide elust: VPN-i sisselogimine, mis seadistab võrgu

Tagasikutsed kombineeruvad meie VPN-i 2FA juhendi RADIUS-seadistustega. Üks muster päris juurutusest, Aruba kontrolleriga: VPN autendib kasutaja tavapäraselt RADIUS-e kaudu läbi auth-proxy ning tagasikutse annab seejärel võrgukontrollerile korralduse aktiveerida sellele kasutajale õige võrguprofiil. Sisselogimisest ja võrguõiguste andmisest saab üks kinnitus kahe süsteemi asemel, mis loodetavasti omavahel klapivad.

Tagasikutse sisus teenivadki profiilimuutujad oma koha välja: {username}, {user_guid} (Active Directory GUID, mis sobib kontrolleri poolel püsivõtmeks) ja {state} asendatakse igas päringus eraldi, nii et üks profiil teenindab kõiki kasutajaid.

API poolelt

Kõike, mida saab käivitada QR-koodiga, saab käivitada ka teie taustsüsteem. Autentimispäringute API võtab vastu parameetri profile (päring saab siis pealkirja, teksti ja kehtivusaja profiilist) ning lisaks custom_vars, JSON-räsi teie enda võti-väärtus paaridest, mis jõuavad profiili väljadesse ja tagasikutsetesse. Näiteks broneerimissüsteem võib edastada {"room": "B12", "slot": "14:00"}, kuvada täpselt sellesama telefonis ja anda selle siis edasi tagasikutsele, mis avab õige ruumi õigel ajal.

Kaks detaili, mida enne ehitama asumist teada:

Deny ja Error on samuti sündmused. Toodangus on kõige kasulikumad tagasikutsed sageli hoopis mujal kui õnnelikul rajal: teavitage kedagi sündmusel Deny, logige Error koos {error} / {error_message} väärtustega, kui mõni allavoolu API on vastamast lakanud.
Kasutaja vaatevinklist on tagasikutsed „saada ja unusta“. Need töötavad taustal; koormatud seadmes võivad paljud paralleelsed tagasikutsed järjekorda koguneda. Kavandage vastuvõttev pool idempotentsena; päringu {uuid} on teie deduplitseerimisvõti.

Kuhu see sobitub

Autentimine oligi see raske osa: allkirjastatud, isikupõhine, biomeetriaga tagatud jah/ei koos auditijäljega. Profiilid lasevad sama algosa taaskasutada kõigeks selle ümber: füüsiline ligipääs, võrgupoliitika, kinnitused sisemistes tööriistades. Kui seade haldab juba teie sisselogimisi, võib järgmine „kes selle kinnitas?“ süsteem, mida te just ehitama hakkasite, olla kõigest ühe profiili ja ühe tagasikutse kaugusel.

Seotud juhendid

Tõukesõnumid mis tahes skriptist: sama API teavituslik pool
VPN-i 2FA RADIUS-ega – auth-proxy täielik seadistus: RADIUS-e voog, millele Aruba muster toetub
Proovige demopanka: seesama skaneeri-loe-kinnita voog, suunatud tehingule