Authentifizierungsprofile – wenn Approve mehr auslösen soll als nur den Login

Jede Notakey-Authentifizierung endet gleich: Der Benutzer liest, was er bestätigt, und tippt auf Approve oder Deny – ein signiertes, auditierbares Ja oder Nein. Normalerweise schaltet diese Antwort einen Login frei. Der Appliance ist aber gleichgültig, wie die Frage lautete: Mit einem Authentifizierungsprofil hängen Sie serverseitige Callbacks an diese Antwort. Approve (oder Deny) kann damit alles auslösen, was eine HTTP-API hat: einen Türcontroller, eine Netzwerk-Policy, ein Ticketsystem, ein smartes Relais.

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

Die Bausteine, alle direkt aus dem Produkt:

• Ein Profil definiert die Anfrage, die der Benutzer sieht (Titel, Beschreibung, Gültigkeitsdauer), mit {variable}-Ersetzung ({username}, {user_email}, {state} und weitere) in jedem Feld.
• Pro Profil hängen Sie Callbacks an Events: Create (Anfrage erstellt), Approve, Deny, Response (beide Antworten), Error oder Any. Die Zahl der Callbacks pro Profil ist unbegrenzt, und sie laufen im Hintergrund; eine langsame Dritt-API blockiert also nie die Authentifizierung selbst.
• Jede aufgerufene URL lässt sich per OAuth 2.0 Client Credentials oder Header-basierter Authentifizierung (gemeinsames Token) schützen. Sie müssen also keinen ungeschützten Webhook ins Netz stellen.

Profile legen Sie im Dashboard Ihres Dienstes unter Authentication profiles an; Anfragen können sich dann entweder über die API auf das Profil beziehen oder über einen QR-Code, ganz ohne Push-Benachrichtigung – der Teil, der Anwendungen in der physischen Welt praktikabel macht.

Probieren Sie es gleich aus: Die Demobank meldet Sie genau so an

Wie sich das anfühlt, müssen Sie uns nicht einfach glauben: Der Login der Demobank ist dieser Mechanismus. Die Anmeldeseite zeigt einen QR-Code; auf der Seite selbst tippen Sie nichts ein. Öffnen Sie den Notakey Authenticator, tippen Sie auf die Scan-Schaltfläche und richten Sie die Kamera auf den Bildschirm:

Der Scan erzeugt die Authentifizierungsanfrage direkt auf Ihrem Telefon – hier ist der a=a-Deeplink aus dem nächsten Abschnitt am Werk. Sie sehen genau, was Sie bestätigen, und ein Tipp auf Approve:

…und der Browser-Tab, dessen QR-Code Sie gescannt haben, ist angemeldet. Die unsichtbare Hälfte ist der interessante Teil: Ihre Bestätigung löst einen Callback an das Backend der Bank aus, mit dem State-Parameter der Anfrage; das Backend ordnet ihn der wartenden Seite zu, und die Sitzung öffnet sich. Benutzernamenfeld, Passwortfeld, „Passwort vergessen“-Link: Nichts davon existiert, weil nichts davon gebraucht wird. Der Rest dieser Anleitung überträgt genau dieses Muster auf andere Ziele.

Praxisbeispiel: die Tür, die Ihr Telefon fragt

Eine Rechenzentrumstür, daneben ein laminierter QR-Code. Wer ihn mit dem Notakey Authenticator scannt, erzeugt an Ort und Stelle eine Authentifizierungsanfrage. Die Deeplink-Aktion a=a ist dokumentiert als „Authentifizierung ohne Push-Benachrichtigung anfordern“, das funktioniert also, obwohl niemand etwas an das Telefon gesendet hat:

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

Kodieren Sie diese URI in einen QR-Code (k ist die Service-ID, p die Profil-ID, beide im Dashboard sichtbar) und drucken Sie ihn aus. Das Profil dahinter:

• Titel/Beschreibung: „RZ-Tür öffnen – {username}, bitte mit Biometrie bestätigen.“ Setzen Sie eine kurze Gültigkeit, z. B. 60 Sekunden; niemand scannt einen Türcode und denkt dann fünf Minuten darüber nach.
• Callback bei Approve: die API des Türcontrollers, https://door-controller.internal/open?door=dc-1&user={username}, geschützt durch ein Header-Token. Approve → HTTP-Aufruf → das Schloss öffnet sich.
• Callback bei Deny (optional, aber lohnend): Eine Anfrage, die zwar erstellt, aber abgelehnt wurde, bedeutet: Jemand stand an Ihrer Tür, und der Besitzer des Telefons hat Nein gesagt. Verbinden Sie das mit Ihrer Alarmierung; die Variablen {response_ip} und {username} liefern dazu die Details.
• Callback bei Create (optional): ein Eintrag im Audit-Log in dem Moment, in dem jemand scannt, noch bevor er antwortet.

Für den Benutzer ist es der Demobank-Ablauf, nur auf ein Schloss statt auf eine Zahlung gerichtet: scannen, lesen, was man bestätigt, tippen – und es passiert. Keine klonbaren Zutrittskarten, keine Tür-PIN, die sich das ganze Team teilt; jede Öffnung ist ein signiertes Ereignis, das einer Person zugeordnet ist.

Praxisbeispiel: ein VPN-Login, der das Netzwerk konfiguriert

Callbacks lassen sich mit den RADIUS-Setups aus unserer VPN-2FA-Anleitung kombinieren. Ein Muster aus einem realen Deployment mit einem Aruba-Controller: Das VPN authentifiziert den Benutzer wie gewohnt über RADIUS durch den Auth-Proxy, und ein Callback weist anschließend den Netzwerkcontroller an, das passende Netzwerkprofil für diesen Benutzer zu aktivieren. Aus Login und Netzwerkautorisierung wird eine einzige Bestätigung statt zweier Systeme, die hoffentlich übereinstimmen.

Im Callback-Body zahlen sich die Profilvariablen aus: {username}, {user_guid} (die Active-Directory-GUID, nützlich als stabiler Schlüssel auf Controller-Seite) und {state} werden pro Anfrage ersetzt. Ein Profil bedient also alle Benutzer.

Von der API-Seite

Alles, was ein QR-Code anstoßen kann, kann auch Ihr Backend. Die API für Authentifizierungsanfragen akzeptiert einen profile-Parameter (die Anfrage übernimmt dann Titel, Text und Gültigkeit aus dem Profil) sowie custom_vars, einen JSON-Hash mit eigenen Schlüssel-Wert-Paaren, die bis in die Felder und Callbacks des Profils durchgereicht werden. Ein Buchungssystem kann etwa {"room": "B12", "slot": "14:00"} übergeben, genau das auf dem Telefon anzeigen und es dann an den Callback weitergeben, der zur richtigen Zeit den richtigen Raum aufschließt.

Zwei Details, die Sie vor der Umsetzung kennen sollten:

• Auch Deny und Error sind Events. Die nützlichsten Callbacks in der Produktion liegen oft nicht auf dem Happy Path: Alarmieren Sie jemanden bei Deny, protokollieren Sie Error mit {error} / {error_message}, wenn eine nachgelagerte API nicht mehr antwortet.
• Aus Sicht des Benutzers sind Callbacks Fire-and-Forget. Sie laufen im Hintergrund; viele parallele Callbacks auf einer stark ausgelasteten Appliance können sich stauen. Gestalten Sie die Empfängerseite idempotent – die {uuid} der Anfrage ist Ihr Deduplizierungsschlüssel.

Einordnung

Die Authentifizierung war der schwierige Teil: ein signiertes, personengebundenes, biometrisch abgesichertes Ja/Nein mit Auditspur. Profile machen dieses Grundelement über den Login hinaus wiederverwendbar: für physischen Zutritt, Netzwerk-Policies, Freigaben in internen Tools. Wenn die Appliance Ihre Logins bereits abwickelt, ist das nächste „Wer hat das freigegeben?“-System, das Sie gerade bauen wollten, vielleicht nur noch ein Profil und einen Callback entfernt.

Verwandte Anleitungen

• Push-Benachrichtigungen aus jedem Skript: die informative Hälfte derselben API
• VPN-2FA mit RADIUS – das komplette Auth-Proxy-Setup: der RADIUS-Ablauf, auf dem das Aruba-Muster aufbaut
• Demobank ausprobieren: derselbe Ablauf aus Scannen, Prüfen und Bestätigen, gerichtet auf eine Transaktion