Hitelesítési profilok: amikor a Jóváhagyás nem csak beléptet

Minden Notakey-hitelesítés ugyanúgy végződik: a felhasználó elolvassa, mit hagy jóvá, majd megérinti a Jóváhagyás vagy az Elutasítás gombot: ez egy aláírt, auditálható igen vagy nem. Ez a válasz általában egy bejelentkezést old fel. A készüléket azonban nem érdekli, mi volt a kérdés: egy hitelesítési profillal szerveroldali callbackeket köthet ehhez a válaszhoz, így a Jóváhagyás (vagy az Elutasítás) bármit elindíthat, aminek van HTTP API-ja: ajtóvezérlőt, hálózati házirendet, hibajegykezelő rendszert, okosrelét.

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

Az építőelemek, mind közvetlenül a termékből:

A profil határozza meg a felhasználó által látott kérést (cím, leírás, érvényességi idő), és bármely mezőben működik a {variable} behelyettesítés ({username}, {user_email}, {state} és társaik).
Profilonként callbackeket rendelhet az eseményekhez: Create (a kérés létrejött), Approve, Deny, Response (bármelyik válasz), Error vagy Any. Egy profilhoz korlátlan számú callback tartozhat, és mind a háttérben fut, így egy lassú külső API sosem akasztja meg magát a hitelesítést.
Minden meghívott URL védhető OAuth 2.0 client credentials vagy fejlécalapú hitelesítéssel (megosztott hozzáférési tokennel), így nem kényszerül hitelesítés nélküli webhook közzétételére.

A profilokat az irányítópulton, a szolgáltatás Hitelesítési profilok menüpontjában hozhatja létre; ezután a kérések hivatkozhatnak a profilra az API-ból, vagy (és ettől válik a megoldás a fizikai térben is igazán használhatóvá) egy QR-kódból, mindenféle push értesítés nélkül.

Próbálja ki most azonnal: így jelentkezhet be a demóbankba

Nem kell elhinnie nekünk, milyen érzés: a demóbank bejelentkezése pontosan ez a mechanizmus. A bejelentkezési oldalon egy QR-kód látható; az oldalon semmit sem kell begépelnie. Nyissa meg a Notakey Authenticatort, érintse meg a beolvasás gombot, és irányítsa a kamerát a képernyőre:

A kód beolvasása magán a telefonon hozza létre a hitelesítési kérést: ez a következő szakaszban bemutatott a=a deeplink működés közben. Pontosan látja, mit hagy jóvá, majd egyetlen érintés a Jóváhagyás gombon:

…és a böngészőfül, amelyről a kódot beolvasta, be van jelentkezve. Ami igazán érdekes, az a láthatatlan fele: a jóváhagyás egy callbacket indít a bank backendje felé a kérés state paraméterével, a backend ezt párosítja a várakozó oldallal, és a munkamenet megnyílik. Felhasználónév-mező, jelszómező, „elfelejtett jelszó” link: egyik sem létezik, mert egyikre sincs szükség. Az útmutató hátralévő része ugyanezt a mintát irányítja más célpontokra.

Példa a gyakorlatból: az ajtó, amely a telefonjától kér engedélyt

Egy adatközponti ajtó, mellette laminált QR-kód. A Notakey Authenticatorral beolvasva a hitelesítési kérés helyben létrejön: az a=a deeplink-művelet dokumentált jelentése „hitelesítés kérése push értesítés nélkül”, így ez annak ellenére működik, hogy a telefonra senki semmit nem küldött:

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

Kódolja ezt az URI-t QR-kódba (a k a szolgáltatás azonosítója, a p a profilé; mindkettő látható az irányítópulton), és nyomtassa ki. A mögötte álló profil:

Cím / leírás: „DC-ajtó nyitása – {username}, erősítse meg biometriával.” Állítson be rövid érvényességet, például 60 másodpercet: senki sem olvas be egy ajtókódot azért, hogy aztán öt percig gondolkodjon rajta.
Callback az Approve eseményre: az ajtóvezérlő API-ja, https://door-controller.internal/open?door=dc-1&user={username}, fejléctokennel védve. Jóváhagyás → HTTP-hívás → nyílik a zár.
Callback a Deny eseményre (nem kötelező, de megéri): egy kérés, amely létrejött ugyan, de elutasították, azt jelenti, hogy valaki az ajtajánál állt, és a telefon tulajdonosa nemet mondott: kösse ezt a riasztási rendszerére. A {response_ip} és a {username} változó elmeséli a történetet.
Callback a Create eseményre (opcionális): bejegyzés az auditnaplóba abban a pillanatban, amikor bárki beolvassa a kódot, még a válasz előtt.

A felhasználói élmény a demóbankos folyamat, csak fizetés helyett egy zárra irányítva: beolvassa, elolvassa, mit hagy jóvá, megérinti – és a dolog megtörténik. Nincs klónozható belépőkártya, nincs az egész csapat által ismert ajtó-PIN; minden nyitás pedig személyhez kötött, aláírt esemény.

Példa a gyakorlatból: VPN-belépés, amely a hálózatot is beállítja

A callbackek jól kombinálhatók a VPN 2FA útmutatónk RADIUS-összeállításaival. Egy minta egy valós telepítésből, Aruba-vezérlővel: a VPN a szokásos módon, az auth-proxyn keresztül, RADIUS-szal hitelesíti a felhasználót, majd egy callback szól a hálózati vezérlőnek, hogy aktiválja az adott felhasználóhoz tartozó hálózati profilt. A bejelentkezésről és a hálózati jogosultságokról így egyetlen jóváhagyás dönt, nem két külön rendszer, amelyet aztán még szinkronban is kellene tartani egymással.

A callback törzsében mutatkozik meg igazán, mit érnek a profilváltozók: a {username}, a {user_guid} (az Active Directory GUID, a vezérlő oldalán jól használható stabil kulcs) és a {state} kérésenként behelyettesítődik, így egyetlen profil kiszolgál minden felhasználót.

Az API felől

Amit egy QR-kód el tud indítani, azt a backendje is. A hitelesítési kérés API elfogad egy profile paramétert (a kérés ekkor a profiltól kapja a címét, a szövegét és az érvényességét), valamint a custom_vars-t, egy JSON-hash-t saját kulcs–érték párokkal, amelyek a profil mezőibe és callbackjeibe is eljutnak. Egy foglalási rendszer például átadhatja a {"room": "B12", "slot": "14:00"} párokat, pontosan ezt jelenítheti meg a telefonon, majd továbbadhatja annak a callbacknek, amely a megfelelő termet a megfelelő időpontban nyitja.

Két részlet, amelyet érdemes tudni, mielőtt fejlesztésbe fogna:

A Deny és az Error is esemény. Éles környezetben a leghasznosabb callbackek gyakran nem a sikeres ágon vannak: riasszon valakit Deny esetén, és naplózza az Error eseményt az {error} / {error_message} változókkal, amikor egy mögöttes API nem válaszol többé.
A callbackek a felhasználó szemszögéből „indítsd el és felejtsd el” jellegűek. A háttérben futnak; egy leterhelt készüléken a sok párhuzamos callback sorban állhat. A fogadó oldalt tervezze idempotensre: a kérés {uuid}-ja a deduplikációs kulcs.

Hova illeszkedik mindez

A nehezét a hitelesítés jelentette: egy aláírt, személyhez kötött, biometriával fedezett igen/nem, auditnyomvonallal. A profilokkal ezt az alapelemet mindenre újrahasznosíthatja, ami körülötte van: fizikai belépés, hálózati házirend, jóváhagyások a belső eszközökben. Ha a készülék már most is kezeli a bejelentkezéseit, a következő „ki hagyta ezt jóvá?” rendszerhez, amelyet éppen megépíteni készült, lehet, hogy már csak egy profil és egy callback hiányzik.

Kapcsolódó útmutatók

Push értesítések bármilyen szkriptből – ugyanennek az API-nak az értesítő oldala
VPN 2FA RADIUS-szal: az auth-proxy teljes beállítása – a RADIUS-folyamat, amelyre az Aruba-minta épül
Próbálja ki a demóbankot – ugyanez a beolvasás–ellenőrzés–jóváhagyás folyamat, egy tranzakcióra irányítva