Jedno logowanie do kilku aplikacji brzmi jak proste zadanie: wspólny ekran, jeden e-mail i jedno hasło. W praktyce najważniejsze pytanie pojawia się krok później. Kto decyduje, co dana osoba może zrobić w każdym systemie?
5 września KERNAL ID domknął integrację logowania i provisioningu z KERNAL BUILD. Wcześniej do wspólnej warstwy zostały podłączone MOS i KERNAL BUSINESS. Powstał działający fundament jednej tożsamości dla rodziny aplikacji — bez budowania jednego, nieczytelnego słownika uprawnień.
Centralne konto, lokalne znaczenie
KERNAL ID wie, kim jest człowiek, do jakich organizacji należy i z jakich aplikacji może korzystać. Obsługuje logowanie, drugi składnik, stan konta oraz przekazanie użytkownika do właściwego systemu. Nie próbuje jednak rozumieć całej logiki produktu.
Rola projektanta w BUILD opisuje pracę z modelem budynku. Rola pracownika w BUSINESS dotyczy obsługi klientów, projektów i finansów. Uprawnienia w MOS mają jeszcze inne znaczenie. Sprowadzenie ich do wspólnego mianownika dałoby pozorny porządek, ale odebrałoby rolom kontekst.
Provisioning zamiast ręcznego zakładania kont
Po nadaniu dostępu KERNAL ID przekazuje do aplikacji minimalny zestaw danych potrzebny do utworzenia lub aktualizacji lokalnego konta. Aplikacja zachowuje własny profil i własne reguły, ale nie wymaga od operatora powtarzania tej samej pracy w kilku panelach.
W BUILD provisioning jest powiązany z tenantem i katalogiem ról tej aplikacji. Zawieszenie organizacji odcina dostęp przy kolejnym żądaniu, a próba nadania roli spoza dozwolonego zakresu kończy się odmową. Kolizja adresu również nie jest traktowana jak przypadkowy błąd serwera — system zwraca kontrolowaną decyzję.
BUSINESS pozostaje systemem wewnętrznym
Wspólne logowanie nie oznacza, że wszystkie systemy mają identyczny model użytkowników. KERNAL BUSINESS jest narzędziem wewnętrznym. Klient może korzystać z własnego portalu, ale nie staje się przez to operatorem BUSINESS. Ta granica jest egzekwowana zarówno w warstwie tożsamości, jak i w samej aplikacji.
Dostęp awaryjny jest częścią projektu
Centralna tożsamość tworzy zależność, dlatego potrzebuje kontrolowanej drogi awaryjnej. Kody jednorazowe są przechowywane w postaci skrótów i po użyciu tracą ważność. Lokalne logowanie pozostaje tam, gdzie wynika to z rodzaju użytkowników i ryzyka operacyjnego.
Najważniejszy rezultat
Jedno konto nie musi oznaczać jednego wielkiego systemu. Dobra warstwa tożsamości upraszcza wejście, pilnuje granic i synchronizuje dostęp, ale zostawia decyzje domenowe tam, gdzie mają znaczenie. Dzięki temu kolejne produkty mogą dołączać do wspólnego ekosystemu bez oddawania własnej odpowiedzialności.