Perfiles de autenticación: cuando Approve debe hacer más que iniciar sesión

Toda autenticación de Notakey termina igual: el usuario lee qué está aprobando y pulsa Approve o Deny, un sí o un no firmado y auditable. Normalmente esa respuesta desbloquea un inicio de sesión. Pero al appliance le da igual cuál fuera la pregunta: un perfil de autenticación permite asociar callbacks de servidor a esa respuesta, de modo que Approve (o Deny) puede desencadenar cualquier cosa que tenga una API HTTP: un controlador de puertas, una política de red, un sistema de tickets, un relé inteligente.

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

Las piezas, todas directamente del producto:

Un perfil define la petición que ve el usuario —título, descripción, periodo de validez— con sustitución de {variable} ({username}, {user_email}, {state} y compañía) en cualquier campo.
A cada perfil se le asocian callbacks a eventos: Create (petición creada), Approve, Deny, Response (cualquiera de las dos respuestas), Error o Any. El número de callbacks por perfil es ilimitado y se ejecutan en segundo plano, de modo que una API de terceros lenta nunca bloquea la propia autenticación.
Cada URL invocada puede protegerse con credenciales de cliente OAuth 2.0 o autenticación por cabecera (un token compartido): no está obligado a exponer un webhook sin autenticar.

Los perfiles se crean en el panel, dentro de los Authentication profiles de su servicio; las peticiones pueden luego referenciar el perfil bien desde la API o —y esto es lo que hace prácticos los usos del mundo físico— desde un código QR, sin ninguna notificación push de por medio.

Pruébelo ahora mismo: el demo bank lo inicia así

No hace falta que se fíe de nuestra palabra sobre cómo se siente: el inicio de sesión del demo bank es este mecanismo. La página de inicio de sesión muestra un código QR; en la página no se escribe nada. Abra Notakey Authenticator, pulse el botón de escaneo y apunte la cámara a la pantalla:

Escanear el código crea la petición de autenticación directamente en su teléfono —este es el deeplink a=a de la siguiente sección en acción—. Ve exactamente qué está aprobando y basta un toque en Approve:

…y la pestaña del navegador desde la que escaneó queda con la sesión iniciada. La mitad interesante es la invisible: su aprobación dispara un callback al backend del banco con el parámetro state de la petición, el backend lo asocia a la página en espera y la sesión se abre. Campo de usuario, campo de contraseña, enlace de «olvidé mi contraseña»: ninguno existe, porque ninguno hace falta. Ese es el patrón que el resto de esta guía dirige hacia otros destinos.

Ejemplo práctico: la puerta que consulta a su teléfono

Una puerta de centro de datos con un código QR plastificado al lado. Escanearlo con Notakey Authenticator crea una petición de autenticación al momento —la acción de deeplink a=a está documentada como «solicitar autenticación sin notificación push», así que funciona aunque nadie haya enviado nada al teléfono—:

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

Codifique ese URI en un código QR (k es el identificador del servicio, p el del perfil, ambos visibles en el panel) e imprímalo. El perfil que hay detrás:

Título / descripción: «Abrir puerta DC — {username}, confirme con biometría». Ponga una validez corta, p. ej. 60 segundos: nadie escanea el código de una puerta y se lo piensa durante cinco minutos.
Callback en Approve: la API del controlador de puertas, https://door-controller.internal/open?door=dc-1&user={username}, protegida por un token en cabecera. Approve → llamada HTTP → el cerrojo se abre.
Callback en Deny (opcional, pero merece la pena): una petición que sí se creó pero se denegó significa que alguien estuvo ante su puerta y el dueño del teléfono dijo que no; conecte eso a sus alertas. Las variables {response_ip} y {username} cuentan la historia.
Callback en Create (opcional): una entrada en el registro de auditoría en el instante en que alguien escanea, antes de que responda.

Para el usuario es el flujo del demo bank apuntado a un cerrojo en lugar de a un pago: escanear, leer qué se aprueba, tocar, y la cosa ocurre. Sin tarjetas de acceso que clonar, sin un PIN de puerta compartido por todo el equipo, y cada apertura es un evento firmado y ligado a una persona.

Ejemplo práctico: el inicio de sesión VPN que configura la red

Los callbacks se combinan con las configuraciones RADIUS de nuestra guía de VPN 2FA. Un patrón de un despliegue real, con un controlador Aruba: la VPN autentica al usuario por RADIUS a través del auth-proxy como de costumbre, y a continuación un callback indica al controlador de red que active el perfil de red correcto para ese usuario. El inicio de sesión y la autorización de red pasan a ser una sola aprobación, en lugar de dos sistemas que ojalá coincidan.

El cuerpo del callback es donde las variables del perfil demuestran su valor: {username}, {user_guid} (el GUID de Active Directory, útil como clave estable en el lado del controlador) y {state} se sustituyen en cada petición, de modo que un solo perfil sirve para todos los usuarios.

Desde el lado de la API

Todo lo que puede iniciar un código QR, también puede iniciarlo su backend. La API de peticiones de autenticación acepta un parámetro profile —la petición toma entonces su título, texto y validez del perfil— más custom_vars, un hash JSON con sus propias parejas clave-valor que fluyen hasta los campos y callbacks del perfil. Un sistema de reservas, por ejemplo, puede pasar {"room": "B12", "slot": "14:00"} y mostrar exactamente eso en el teléfono, para luego entregárselo al callback que abre la sala correcta a la hora correcta.

Dos detalles que conviene conocer antes de construir:

Deny y Error también son eventos. Los callbacks más útiles en producción a menudo no son los del caso en que todo va bien: avise a alguien en Deny, registre Error con {error} / {error_message} cuando una API de destino deje de responder.
Desde la perspectiva del usuario, los callbacks son «dispara y olvida». Se ejecutan en segundo plano; muchos callbacks en paralelo en un appliance cargado pueden acumularse en cola. Diseñe el lado receptor para que sea idempotente: el {uuid} de la petición es su clave de deduplicación.

Dónde encaja

La autenticación era la parte difícil: un sí/no firmado, por persona y respaldado por biometría, con un rastro de auditoría. Los perfiles permiten reutilizar esa primitiva para todo lo que la rodea: acceso físico, políticas de red, aprobaciones en herramientas internas. Si el appliance ya gestiona sus inicios de sesión, el próximo sistema de tipo «¿quién aprobó esto?» que estaba a punto de construir quizá esté a solo un perfil y un callback de distancia.

Guías relacionadas

Notificaciones push desde cualquier script: la mitad informativa de la misma API
VPN 2FA con RADIUS: la configuración completa del auth-proxy: el flujo RADIUS sobre el que se apoya el patrón de Aruba
Pruebe el demo bank: el mismo flujo de escanear-revisar-aprobar, apuntado a una transacción