W czerwcu wbudowaliśmy warstwę tożsamości w aplikacje, które generuje OwlMeans.
Na wierzchu był ekran logowania. Za nim kryły się konta, sesje, uprawnienia i granica między użytkownikami naszej platformy a użytkownikami aplikacji klienta.
Chciałem, żeby te decyzje od początku należały do architektury aplikacji.
Konta i logowanie
Udane logowanie mówi aplikacji, kto przyszedł. Nie przesądza jednak, co ta osoba może czytać albo zmieniać.
Klient może potrzebować użytkownika, który widzi własne rekordy, operatora, który obsługuje kolejkę, i administratora, który zarządza dostępem. To różne zakresy odpowiedzialności, nawet jeśli ekrany wyglądają podobnie.
Objaśnienie OpenID Connect na stronie OpenID Foundation opisuje protokół tożsamości. O uprawnieniach nadal decydują reguły biznesowe aplikacji.
W czerwcu połączyliśmy proces logowania z generowaną aplikacją i wprowadziliśmy wspólny sposób opisywania dostępu. Reszta kodu dostała dzięki temu spójną podstawę, na której może się opierać.
Nie rozstrzygnęło to jednak za klientów, jakie zasady dostępu mają przyjąć.
Użytkownicy końcowi aplikacji logowali się w tej implementacji jednorazowymi danymi uwierzytelniającymi, które dostawali e-mailem. Dzięki temu generowana aplikacja nie potrzebowała osobnego procesu zarządzania hasłami.
Nie nazwałbym logowania przez e-mail ogólną gwarancją bezpieczeństwa ani nie stawiałbym go na równi z silniejszymi metodami uwierzytelniania.
Wciąż trzeba przemyśleć, którędy wiadomość dociera do użytkownika, jak odzyskuje się konto i jak zachowuje się sesja. Do tego dochodzi sposób, w jaki ktoś staje się członkiem organizacji klienta.
Łatwo przeoczyć te szczegóły, jeśli jedynym testem akceptacyjnym jest to, że formularz logowania daje się wysłać.
Granice dostępu
Model uprawnień to część, którą chciałem uchronić przed rozproszonymi, doraźnymi decyzjami.
Ekran może mieć wymaganie dostępu, a operacja, która za nim stoi, też potrzebuje wymagania, i to egzekwowanego. Ukrycie przycisku nie jest regułą autoryzacji.
W Authorization Cheat Sheet OWASP zaleca wyznaczenie granic dostępu, domyślne odmawianie dostępu i sprawdzanie uprawnień przy żądaniach. Domaga się też testów tych reguł.
W strukturze naszych aplikacji wymaganie deklaruje się zgodnie z konwencjami dostępu, które daje framework. Kod biznesowy powinien konsekwentnie się ich trzymać, zamiast w każdym handlerze wymyślać własną interpretację.
W zwykłym narzędziu do pracy testowałbym rzeczywiste różnice w uprawnieniach. Użytkownik może przeglądać swój rekord. Operator może obsłużyć przydzielone mu zgłoszenie. Żaden z nich nie powinien dostać uprawnień administratora tylko dlatego, że się zalogował.
Takie zachowanie powinno trafić do wymagań produktu i do testów. Sama nazwa protokołu go nie zapewni.
OwlMeans ma własne konta. Aplikacja zbudowana w OwlMeans ma swoich użytkowników końcowych. Rozdzielenie tych dwóch spraw było częścią pracy nad tożsamością.
Granice klienta, projektu i zasobu mają znaczenie, bo tożsamość może być ważna, a konkretna czynność i tak wykraczać poza jej uprawnienia. Sam identyfikator użytkownika nie wystarczy, żeby wyrazić wszystkie te granice.
Produkcja też potrzebuje docelowej konfiguracji logowania. Nie można z góry zakładać, że konta i adresy przekierowań używane w podglądzie to ustawienia produkcyjne.
W praktyce pytanie brzmi: czy właściwa osoba przejdzie zamierzony proces do końca i czy ktoś spoza tej granicy dostanie odmowę.
OIDC i dostarczenie aplikacji
OIDC daje aplikacji standardowy interfejs tożsamości. Nie oznacza to jednak, że dostępna jest każda korporacyjna integracja tożsamości, że każdą granicę między tenantami przetestowano ani że kwestionariusz bezpieczeństwa kupującego jest już wypełniony.
Wcześniejsza wersja tego artykułu przedstawiała to tak, jakby działo się samo.
Integracja nadal zależy od dostawcy i konfiguracji. Role klienta i zasady jego organizacji wciąż trzeba opisać w specyfikacji. Przegląd wygenerowanej aplikacji pozostaje częścią jej dostarczenia.
Wolę opisać elementy, które mamy, niż sugerować jakąś certyfikację tylko dlatego, że wybraliśmy protokół.
W sierpniu zintegrowany system tożsamości stał się jedyną implementacją IAM Platformy. Czerwcowe rozważania o przełączanym zewnętrznym backendzie mają już tylko wartość historyczną.
Obecne prace nad dostępem oddzielają też zabezpieczenia już zaimplementowane od usprawnień, które wciąż powstają. Dokumentacja i kod świadczą o samym mechanizmie. Nie mogą jednak dowieść, że każda aplikacja zbudowana z jego pomocą jest bezpieczna.
Aktualny przewodnik po uwierzytelnianiu objaśnia elementy składowe frameworka. Projekt dostępu w aplikacji trzeba sprawdzać w kontekście produktu, który powstaje.
Skoro wbudowaliśmy tożsamość, tę część systemu utrzymujemy my. Klienci nadal muszą opisać ludzi, zasoby i działania, których wymaga ich produkt. Mamy wspólny sposób, żeby te reguły wyrazić. Sprawdzenie ich pozostaje częścią pracy.
Poprawiono 15 października 2026 r. Tekst zachowuje historię czerwcowej implementacji, a prostuje wcześniejsze porównania cen i daleko idące obietnice dotyczące rozwiązań korporacyjnych i bezpieczeństwa.