Ogni autenticazione Notakey si conclude allo stesso modo: l’utente legge ciò che sta approvando e tocca Approve o Deny: un sì o un no firmato e verificabile. Di solito quella risposta sblocca un accesso. Ma all’appliance non importa quale fosse la domanda: un profilo di autenticazione vi permette di collegare callback lato server a quella risposta, così Approve (o Deny) può innescare qualunque cosa disponga di un’API HTTP: un controller di porte, una policy di rete, un sistema di ticketing, un relè intelligente.
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 addGli elementi, tutti direttamente dal prodotto:
- Un profilo definisce la richiesta che l’utente vede (titolo, descrizione,
periodo di validità), con la sostituzione di
{variable}({username},{user_email},{state}e affini) in qualsiasi campo. - Per ogni profilo collegate callback a eventi:
Create(richiesta creata),Approve,Deny,Response(l’una o l’altra risposta),ErroroAny. Il numero di callback per profilo è illimitato ed essi vengono eseguiti in background, così un’API di terze parti lenta non blocca mai l’autenticazione stessa. - Ogni URL invocato può essere protetto tramite client credentials OAuth 2.0 o autenticazione basata su header (un token condiviso), così non siete costretti a esporre un webhook non autenticato.
I profili si creano nel dashboard, sotto Authentication profiles del vostro servizio; le richieste possono poi fare riferimento al profilo dall’API oppure – ed è ciò che rende concreti gli usi nel mondo fisico – da un QR code, senza alcuna notifica push.
Provatelo subito: la demo bank vi autentica proprio così
Non dovete crederci sulla parola quanto al risultato: l’accesso alla demo bank è questo meccanismo. La pagina di accesso mostra un QR code. Non digitate nulla sulla pagina. Aprite Notakey Authenticator, toccate il pulsante di scansione e puntate la fotocamera verso lo schermo:
La scansione del codice crea la richiesta di autenticazione direttamente sul
telefono: è il deeplink a=a della sezione successiva all’opera. Vedete
esattamente ciò che state approvando, e con un solo tocco su Approve:
…e la scheda del browser da cui avete scansionato risulta autenticata. La metà invisibile è la parte interessante: la vostra approvazione innesca un callback verso il backend della banca con il parametro state della richiesta, il backend lo abbina alla pagina in attesa e la sessione si apre. Campo del nome utente, campo della password, link «password dimenticata» – nessuno di essi esiste, perché nessuno di essi è necessario. È lo schema che il resto di questa guida punta verso altri bersagli.
Esempio pratico: la porta che interroga il vostro telefono
Una porta di datacenter con accanto un QR code plastificato. Scansionarlo con
Notakey Authenticator crea una richiesta di autenticazione sul posto. L’azione
di deeplink a=a è documentata come «richiedere l’autenticazione senza notifica
push», quindi funziona anche se nessuno ha inviato nulla al telefono:
notakey://qr?a=a&u=ntk.example.com&k=<service-id>&p=<profile-id>Codificate questo URI in un QR code (k è l’ID del servizio, p l’ID del
profilo, entrambi visibili nel dashboard) e stampatelo. Il profilo che lo
sostiene:
- Titolo / descrizione: «Aprire la porta del DC – {username}, confermate con la biometria.» Impostate una validità breve, per esempio 60 secondi: nessuno scansiona il codice di una porta per poi rifletterci sopra cinque minuti.
- Callback su
Approve: l’API del controller di porta,https://door-controller.internal/open?door=dc-1&user={username}, protetta da un token di header. Approve → chiamata HTTP → la serratura si apre. - Callback su
Deny(opzionale ma utile): una richiesta che è stata creata ma rifiutata significa che qualcuno si è presentato alla vostra porta e il proprietario del telefono ha detto no. Collegatela al vostro sistema di allerta. Le variabili{response_ip}e{username}raccontano l’accaduto. - Callback su
Create(opzionale): una voce nel registro di audit nel momento stesso in cui qualcuno scansiona, prima ancora che risponda.
L’esperienza utente è il flusso della demo bank puntato su una serratura anziché su un pagamento: scansionare, leggere ciò che si approva, toccare, e la cosa accade. Nessun badge da clonare, nessun PIN di porta condiviso da tutto il team, e ogni apertura è un evento firmato associato a una persona.
Esempio pratico: un accesso VPN che configura la rete
I callback si combinano con le configurazioni RADIUS della nostra guida 2FA VPN. Uno schema tratto da un’implementazione reale, con un controller Aruba: il VPN autentica l’utente tramite RADIUS attraverso l’auth-proxy come di consueto, e poi un callback indica al controller di rete di attivare il profilo di rete giusto per quell’utente. Accesso e autorizzazione di rete diventano un’unica approvazione, anziché due sistemi che si spera vadano d’accordo.
È nel corpo del callback che le variabili del profilo danno il meglio:
{username}, {user_guid} (il GUID di Active Directory, utile come chiave
stabile sul lato del controller) e {state} vengono sostituiti a ogni richiesta,
così un solo profilo serve tutti gli utenti.
Dal lato API
Tutto ciò che un QR code può avviare, lo può fare anche il vostro backend.
L’API di richiesta di autenticazione
accetta un parametro profile (la richiesta ricava allora il proprio titolo,
testo e validità dal profilo), oltre a custom_vars, una hash JSON di coppie
chiave-valore vostre che si propagano fino ai campi e ai callback del profilo. Un
sistema di prenotazione, per esempio, può passare {"room": "B12", "slot": "14:00"}
e mostrare esattamente questo sul telefono, per poi consegnarlo al callback che
sblocca la stanza giusta al momento giusto.
Due dettagli da conoscere prima di mettervi all’opera:
- Anche Deny ed Error sono eventi. I callback più utili in produzione spesso
non sono quelli dello scenario ideale: allertate qualcuno su
Deny, registrateErrorcon{error}/{error_message}quando un’API di destinazione ha smesso di rispondere. - Dal punto di vista dell’utente, i callback funzionano in modalità «lancia e
dimentica». Vengono eseguiti in background; molti callback in parallelo su
un’appliance sotto carico possono accodarsi. Progettate il lato ricevente
affinché sia idempotente: il
{uuid}della richiesta è la vostra chiave di deduplicazione.
Dove si colloca
L’autenticazione era la parte difficile: un sì/no firmato, personale, garantito dalla biometria e corredato di una traccia di audit. I profili vi permettono di riutilizzare questa primitiva per tutto ciò che le sta intorno: accesso fisico, policy di rete, approvazioni negli strumenti interni. Se l’appliance gestisce già i vostri accessi, il prossimo sistema «chi l’ha approvato?» che stavate per costruire potrebbe già essere a un profilo e a un callback di distanza.
Guide correlate
- Notifiche push da qualsiasi script, la metà informativa della stessa API
- 2FA VPN con RADIUS – l’installazione completa dell’auth-proxy, il flusso RADIUS su cui si basa lo schema Aruba
- Provate la demo bank: lo stesso flusso scansiona-verifica-approva, puntato su una transazione