Profile uwierzytelniania – gdy Approve ma robić coś więcej niż logować

Każde uwierzytelnienie w Notakey kończy się tak samo: użytkownik czyta, co potwierdza, i naciska Approve albo Deny: podpisane, możliwe do audytu tak lub nie. Zwykle ta odpowiedź odblokowuje logowanie. Urządzeniu jest jednak obojętne, jak brzmiało pytanie: profil uwierzytelniania pozwala podłączyć do tej odpowiedzi serwerowe callbacki, dzięki czemu Approve (lub Deny) może uruchomić cokolwiek, co ma API HTTP: kontroler drzwi, politykę sieciową, system zgłoszeń, inteligentny przekaźnik.

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

Elementy składowe, wszystkie prosto z produktu:

Profil definiuje żądanie, które widzi użytkownik (tytuł, opis, okres ważności), z podstawianiem {variable} ({username}, {user_email}, {state} i podobne) w dowolnym polu.
Do każdego profilu podłącza się callbacki do zdarzeń: Create (żądanie utworzone), Approve, Deny, Response (dowolna z odpowiedzi), Error lub Any. Liczba callbacków na profil jest nieograniczona, a wykonują się one w tle, więc powolne API innego dostawcy nigdy nie blokuje samego uwierzytelniania.
Każdy wywoływany adres URL można zabezpieczyć danymi logowania klienta OAuth 2.0 lub uwierzytelnianiem nagłówkowym (wspólny token), więc nie trzeba wystawiać nieuwierzytelnionego webhooka.

Profile tworzy się w panelu, w sekcji Authentication profiles danej usługi; żądania mogą się następnie odwoływać do profilu albo z poziomu API, albo (i to właśnie czyni zastosowania w świecie fizycznym praktycznymi) z kodu QR, całkowicie bez powiadomienia push.

Do wypróbowania od razu: demo bank loguje właśnie tak

Nie muszą Państwo wierzyć nam na słowo, jak to działa w praktyce: logowanie do demo banku jest tym mechanizmem. Strona logowania pokazuje kod QR. Na samej stronie nie wpisuje się niczego. Wystarczy otworzyć Notakey Authenticator, nacisnąć przycisk skanowania i skierować aparat na ekran:

Zeskanowanie kodu tworzy żądanie uwierzytelnienia bezpośrednio na Państwa telefonie. To działanie deeplinku a=a z następnej sekcji. Widzą Państwo dokładnie, co potwierdzają, i jedno naciśnięcie Approve:

…i karta przeglądarki, z której skanowali Państwo kod, jest zalogowana. Najciekawsza jest niewidoczna połowa: Państwa potwierdzenie wyzwala callback do backendu banku z parametrem state żądania, backend dopasowuje go do oczekującej strony i sesja się otwiera. Pole nazwy użytkownika, pole hasła, link „nie pamiętam hasła” – nic z tego nie istnieje, bo nic z tego nie jest potrzebne. To ten sam wzorzec, który reszta tego przewodnika kieruje na inne cele.

Przykład praktyczny: drzwi, które pytają telefon

Drzwi do centrum danych, a obok zalaminowany kod QR. Zeskanowanie go za pomocą Notakey Authenticator tworzy żądanie uwierzytelnienia od razu na miejscu. Akcja deeplinku a=a jest udokumentowana jako „zażądaj uwierzytelnienia bez powiadomienia push”, więc działa to, mimo że nikt niczego nie wysłał na telefon:

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

Ten URI należy zakodować w kodzie QR (k to identyfikator usługi, p – identyfikator profilu, oba widoczne w panelu) i wydrukować. Profil, który za tym stoi:

Tytuł/opis: „Otwórz drzwi DC — {username}, potwierdź biometrią”. Warto ustawić krótką ważność, np. 60 sekund; nikt nie skanuje kodu przy drzwiach i nie zastanawia się nad nim pięć minut.
Callback przy Approve: API kontrolera drzwi, https://door-controller.internal/open?door=dc-1&user={username}, zabezpieczone tokenem w nagłówku. Approve → wywołanie HTTP → zamek się otwiera.
Callback przy Deny (opcjonalny, ale warto): żądanie, które zostało utworzone, ale odrzucone, oznacza, że ktoś stał przy Państwa drzwiach, a właściciel telefonu powiedział nie. Warto podłączyć to do systemu alarmowania. Zmienne {response_ip} i {username} opowiadają, co się stało.
Callback przy Create (opcjonalny): wpis w dzienniku audytu w chwili, gdy ktokolwiek skanuje, zanim odpowie.

Dla użytkownika to ten sam przebieg co w demo banku, tylko skierowany na zamek zamiast na płatność: skan, lektura tego, co się potwierdza, naciśnięcie – i rzecz się dzieje. Żadnych kart zbliżeniowych do sklonowania, żadnego PIN-u do drzwi współdzielonego przez cały zespół, a każde otwarcie to podpisane zdarzenie przypisane do konkretnej osoby.

Przykład praktyczny: logowanie do VPN, które konfiguruje sieć

Callbacki łączą się z konfiguracjami RADIUS z naszego przewodnika po VPN 2FA. Jeden wzorzec z rzeczywistego wdrożenia, z kontrolerem Aruba: VPN uwierzytelnia użytkownika przez RADIUS za pośrednictwem auth-proxy jak zwykle, a następnie callback nakazuje kontrolerowi sieci aktywować właściwy profil sieciowy dla tego użytkownika. Logowanie i autoryzacja sieciowa stają się jednym potwierdzeniem zamiast dwóch systemów, które, miejmy nadzieję, są ze sobą zgodne.

To w treści callbacku zmienne profilu pokazują swoją wartość: {username}, {user_guid} (identyfikator GUID z Active Directory, przydatny jako stabilny klucz po stronie kontrolera) oraz {state} są podstawiane osobno dla każdego żądania, więc jeden profil obsługuje wszystkich użytkowników.

Od strony API

Wszystko, co potrafi uruchomić kod QR, potrafi też Państwa backend. API żądań uwierzytelnienia przyjmuje parametr profile (żądanie przejmuje wtedy tytuł, tekst i ważność z profilu) oraz custom_vars, hasz JSON z Państwa własnymi parami klucz–wartość, które przepływają aż do pól i callbacków profilu. System rezerwacji może na przykład przekazać {"room": "B12", "slot": "14:00"}, pokazać dokładnie to na telefonie, a następnie podać dalej do callbacku, który o właściwej porze otwiera właściwe pomieszczenie.

Dwa szczegóły, które warto poznać przed rozpoczęciem budowy:

Deny i Error to też zdarzenia. Najbardziej przydatne callbacki w środowisku produkcyjnym często nie leżą na ścieżce pozytywnej: powiadomienie kogoś przy Deny, zapis Error z {error} / {error_message}, gdy docelowe API przestało odpowiadać.
Z perspektywy użytkownika callbacki działają w trybie „uruchom i zapomnij”. Wykonują się w tle; wiele równoległych callbacków na mocno obciążonym urządzeniu może ustawić się w kolejce. Stronę odbierającą należy zaprojektować jako idempotentną; {uuid} żądania służy jako klucz do deduplikacji.

Gdzie to pasuje

Uwierzytelnianie było najtrudniejszą częścią: podpisane, przypisane do osoby, potwierdzone biometrią tak/nie ze śladem audytu. Profile pozwalają wykorzystać ten element ponownie do wszystkiego, co go otacza: dostępu fizycznego, polityk sieciowych, zatwierdzeń w narzędziach wewnętrznych. Jeśli urządzenie obsługuje już Państwa logowania, kolejny system typu „kto to zatwierdził?”, który właśnie zamierzali Państwo zbudować, może dzielić od gotowości tylko jeden profil i jeden callback.

Powiązane przewodniki

Powiadomienia push z dowolnego skryptu: informacyjna połowa tego samego API
VPN 2FA z RADIUS – kompletna konfiguracja auth-proxy: przebieg RADIUS, na którym opiera się wzorzec Aruba
Demo bank do wypróbowania: ten sam przebieg skanuj-sprawdź-potwierdź, skierowany na transakcję