Autentizační profily – když má Approve udělat víc než jen přihlásit

Každé ověření v Notakey končí stejně: uživatel si přečte, co schvaluje, a klepne na Approve, nebo Deny: podepsané, auditovatelné ano, či ne. Obvykle tato odpověď odemkne přihlášení. Zařízení je ale jedno, jaká byla otázka: autentizační profil vám umožní na odpověď navěsit serverové callbacky (zpětná volání), takže Approve (nebo Deny) může spustit cokoli, co má HTTP API: ovladač dveří, síťovou politiku, ticketovací systém, chytré 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

Stavební kameny, vše přímo z produktu:

Profil definuje požadavek, který uživatel uvidí (titulek, popis, dobu platnosti), s dosazováním proměnných {variable} ({username}, {user_email}, {state} a další) v libovolném poli.
Ke každému profilu připojíte callbacky na události: Create (požadavek vytvořen), Approve, Deny, Response (kterákoli odpověď), Error nebo Any. Počet callbacků na profil není omezen a všechny běží na pozadí, takže pomalé API třetí strany nikdy nezablokuje samotné ověření.
Každou volanou URL lze chránit OAuth 2.0 client credentials nebo autentizací v hlavičce (sdílený token), takže nejste odkázáni na nezabezpečený webhook.

Profily se vytvářejí v dashboardu v sekci Authentication profiles vaší služby; požadavky se pak na profil mohou odkazovat buď z API, nebo (a to je ta část, díky které dávají smysl i scénáře ve fyzickém světě) z QR kódu, úplně bez push notifikace.

Vyzkoušejte si to hned: přesně takhle vás přihlašuje demo banka

Nemusíte nám věřit na slovo, jak to působí: přihlášení do demo banky je přesně tento mechanismus. Přihlašovací stránka zobrazí QR kód. Na stránce samotné nepíšete vůbec nic. Otevřete Notakey Authenticator, klepněte na tlačítko skenování a namiřte fotoaparát na obrazovku:

Naskenováním kódu vznikne autentizační požadavek přímo na vašem telefonu. To je v akci deeplink a=a z následující kapitoly. Přesně vidíte, co schvalujete, a jedno klepnutí na Approve:

…a záložka prohlížeče, ze které jste skenovali, je přihlášená. To zajímavé se odehrálo v neviditelné polovině: vaše schválení spustí callback na backend banky s parametrem state daného požadavku, backend ho spáruje s čekající stránkou a relace se otevře. Pole pro jméno, pole pro heslo, odkaz „zapomenuté heslo“ – nic z toho neexistuje, protože nic z toho není potřeba. A právě tento vzor namíří zbytek návodu na jiné cíle.

Praktický příklad: dveře, které se ptají vašeho telefonu

Dveře do datacentra a vedle nich zalaminovaný QR kód. Jeho naskenováním v aplikaci Notakey Authenticator vznikne autentizační požadavek na místě. Akce deeplinku a=a je v dokumentaci popsaná jako „request authentication without push notification“ (vyžádat ověření bez push notifikace), takže to funguje, i když na telefon nikdo nic neposlal:

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

Tuto URI zakódujte do QR kódu (k je ID služby, p ID profilu, obojí najdete v dashboardu) a vytiskněte. Profil, který za tím stojí:

Titulek / popis: „Otevřít dveře DC – {username}, potvrďte biometrií.“ Nastavte krátkou platnost, např. 60 sekund; nikdo nenaskenuje kód u dveří, aby o něm pak pět minut přemýšlel.
Callback na Approve: API ovladače dveří, https://door-controller.internal/open?door=dc-1&user={username}, chráněné tokenem v hlavičce. Approve → HTTP volání → zámek se otevře.
Callback na Deny (volitelný, ale stojí za to): požadavek, který vznikl, ale byl zamítnut, znamená, že u vašich dveří někdo stál a majitel telefonu řekl ne. Napojte to na svůj alerting. Proměnné {response_ip} a {username} dopoví zbytek příběhu.
Callback na Create (volitelný): záznam v auditním logu v okamžiku, kdy kdokoli kód naskenuje, ještě předtím, než odpoví.

Z pohledu uživatele je to tok z demo banky, jen namířený na zámek místo na platbu: naskenovat, přečíst si, co schvalujete, klepnout, a věc se stane. Žádné přístupové karty, které lze naklonovat, žádný PIN ke dveřím sdílený celým týmem, a každé otevření je podepsaná událost přiřazená konkrétnímu člověku.

Praktický příklad: přihlášení k VPN, které rovnou nastaví síť

Callbacky se dají kombinovat s RADIUS scénáři z našeho návodu na 2FA pro VPN. Jeden vzor z reálného nasazení s kontrolerem Aruba: VPN ověří uživatele přes RADIUS skrz auth-proxy jako obvykle, a callback pak řekne síťovému kontroleru, aby danému uživateli aktivoval správný síťový profil. Přihlášení a autorizace v síti se stanou jedním schválením místo dvou systémů, které spolu snad souhlasí.

Tělo callbacku je místo, kde se proměnné profilu opravdu vyplatí: {username}, {user_guid} (GUID z Active Directory, užitečné jako stabilní klíč na straně kontroleru) a {state} se dosazují pro každý požadavek zvlášť, takže jeden profil obslouží všechny uživatele.

Ze strany API

Všechno, co umí spustit QR kód, umí spustit i váš backend. API autentizačních požadavků přijímá parametr profile (požadavek pak převezme titulek, text a platnost z profilu) a k tomu custom_vars, JSON hash vašich vlastních párů klíč–hodnota, které protečou do polí profilu i do callbacků. Rezervační systém tak může poslat třeba {"room": "B12", "slot": "14:00"}, zobrazit přesně tohle na telefonu a pak to předat callbacku, který odemkne správnou místnost ve správný čas.

Dva detaily, které se vyplatí znát, než začnete stavět:

Deny a Error jsou také události. Nejužitečnější callbacky v produkci často neobsluhují úspěšný průběh, ale výjimky: na Deny někoho přivolejte, Error zalogujte s {error} / {error_message}, když navazující API přestalo odpovídat.
Callbacky jsou z pohledu uživatele fire-and-forget. Běží na pozadí; mnoho paralelních callbacků na vytíženém zařízení se může řadit do fronty. Navrhněte přijímací stranu idempotentně; deduplikačním klíčem je {uuid} požadavku.

Kam tento mechanismus zapadá

Ověření bylo to těžké: podepsané, na osobu vázané ano/ne kryté biometrií, s auditní stopou. Profily vám dovolí použít tento základní kámen pro všechno okolo: fyzický přístup, síťové politiky, schvalování v interních nástrojích. Pokud už zařízení řeší vaše přihlašování, pak vás od příštího systému „kdo tohle schválil?“, který jste se chystali stavět, dělí už jen jeden profil a jeden callback.

Související návody

Push notifikace z libovolného skriptu, informační polovina téhož API
2FA pro VPN přes RADIUS – kompletní nastavení auth-proxy, RADIUS tok, na kterém staví vzor s Arubou
Vyzkoušejte demo banku: tentýž tok naskenovat–zkontrolovat–potvrdit, namířený na transakci