Jedno konto do trzech aplikacji: wybór wspólnego logowania
Cel był prosty: jedno konto dla trzech aplikacji. Na stole miałem dwa warianty — docelowo idealny i realistyczny na wyznaczony czas. Wybrałem drugi, zachowując pierwszy jako możliwy kierunek rozwoju.
- Cel
- Ustalić, jak dojść do jednego konta i wspólnego logowania w trzech aplikacjach w wyznaczonym czasie.
- Narzędzia
Przegląd istniejącego kodu i procesów · Keycloak jako wspólny system tożsamości · porównanie dwóch wariantów architektury
- Proces
- Potrzeba użytkownika → analiza istniejących procesów → wariant idealny i realistyczny → porównanie zakresu, migracji i zależności → wybór pierwszego etapu.
- Efekt
- Wybrany wariant realistyczny i uzgodniony zakres pierwszego etapu dla programisty. Osobna usługa kont pozostała możliwym kierunkiem dalszego rozwoju.
Jeden klucz, osobne zasady dostępu
Jedno konto do kilku aplikacji przypomina jeden klucz do różnych budynków. Korzystanie z niego ma być wygodne, ale każdy budynek zachowuje własne pomieszczenia i zasady wejścia. W aplikacjach wspólne potwierdzenie tożsamości też musi współistnieć z lokalnymi uprawnieniami i danymi.
Z perspektywy użytkownika potrzeba była konkretna: loguję się raz i przechodzę do kolejnej aplikacji bez ponownego wpisywania hasła, dopóki trwa wspólna sesja. To wspólne logowanie, czyli SSO — od angielskiego single sign-on. W obu rozważanych wariantach miało ono korzystać z Keycloak, systemu potwierdzającego tożsamość użytkownika i obsługującego sesję logowania. Wspólne logowanie nie zastępuje jednak zasad nadawania i odbierania dostępu, które opisuję też w materiale o onboardingu i offboardingu.
Zanim wybrałem rozwiązanie, sprawdziłem punkt wyjścia
Aplikacje już istniały. Miały rejestrację, aktywację kont, ustawianie pierwszego hasła, reset hasła, profile i panel administratora. Jedna z nich obsługiwała wspólne dane biznesowe, a aplikacja edukacyjna miała własne logowanie i własne dane produktowe.
Dlatego analiza objęła cały cykl życia konta. Trzeba było ustalić, które procesy zachować, które przenieść i jak powiązać użytkownika pomiędzy aplikacjami. Dopiero z tym obrazem na stole mogłem sensownie porównać dwa warianty.
Wariant idealny: osobna usługa kont
W rozwiązaniu docelowym powstałaby osobna usługa wspólnego konta. Zarządzałaby profilem, danymi kontaktowymi, zgodami i procesami konta dla wszystkich produktów. Keycloak nadal odpowiadałby za tożsamość, hasło i wspólną sesję. Każda aplikacja zachowałaby swoje dane oraz uprawnienia.
To dawało czytelny podział odpowiedzialności: wspólny profil nie należałby do żadnego z produktów. Kolejna aplikacja mogłaby dołączyć do neutralnej usługi kont. Wspólny panel profilu również miałby własne miejsce.
Tyle że oznaczało to zbudowanie i późniejsze utrzymywanie nowej usługi, przeniesienie danych oraz przebudowę rejestracji, aktywacji, obsługi haseł i panelu administratora. Dochodziły szersza migracja, więcej testów i plan wycofania zmian, gdyby wdrożenie poszło źle. To wszystko trzeba byłoby uwzględnić w czasie potrzebnym do uzyskania pierwszego efektu dla użytkownika.
Wariant realistyczny: wykorzystać istniejące procesy
W drugim wariancie wspólny profil pozostawał w aplikacji, która już nim zarządzała. Zachowywaliśmy jej rejestrację, aktywację, panel konta i istniejący sposób inicjowania resetu hasła. Keycloak miał zapewnić wspólną tożsamość i sesję logowania.
Aplikacja edukacyjna miała korzystać z tego samego logowania, bez utrzymywania osobnego hasła dla tych użytkowników. Lokalny profil byłby tworzony lub łączony przy pierwszym poprawnym wejściu. Jej organizacje, materiały, postęp i uprawnienia pozostawały na miejscu.
Zakres migracji i przebudowy był mniejszy. Był też konkretny kompromis: aplikacja historycznie odpowiedzialna za jeden produkt nadal miała obsługiwać wspólny profil. Kolejne produkty zależałyby od udostępnianych przez nią danych i zasad integracji.
Co faktycznie porównywałem
| Obszar | Wariant idealny | Wariant realistyczny |
|---|---|---|
| Wspólny profil | Osobna usługa kont | Istniejąca aplikacja |
| Rejestracja i aktywacja | Przeniesione do centralnego procesu | Zachowane istniejące procesy |
| Panel konta | Nowy, neutralny panel | Dotychczasowy panel |
| Migracja i testy | Szerszy zakres zmian | Ograniczony zakres zmian |
| Praca przed pierwszym efektem | Więcej budowania i przenoszenia | Więcej wykorzystania tego, co już działa |
| Koszt wyboru | Nowa usługa do utrzymania | Dalsza zależność od istniejącej aplikacji |
Wybrałem zakres na wyznaczony czas
Do pierwszego etapu wybrałem wariant realistyczny. Priorytetem było jedno konto i przechodzenie między trzema aplikacjami bez kolejnego hasła. Ograniczenie zmian pozwalało skupić zaplanowaną pracę na tym celu.
Wariant idealny został punktem odniesienia dla dalszego rozwoju. Do osobnej usługi kont można wrócić, gdy przybędzie produktów, wspólnych procesów albo zależność od jednej aplikacji zacznie utrudniać kolejne zmiany. Taki krok wymagałby ponownej oceny podziału odpowiedzialności i migracji.
Co trafiło do pierwszego etapu
Zakres obejmował wspólne logowanie, trwałe powiązanie rekordów użytkownika oraz mapowanie istniejących ról. Lokalny profil aplikacji edukacyjnej miał powstawać przy pierwszym poprawnym logowaniu. Wydzielenie nowej usługi kont, dołączenie kolejnego produktu i płatne subskrypcje pozostały poza tym etapem.
Warunki odbioru opisywały zachowanie użytkownika: przejście z jednej aplikacji do drugiej, wejście z nowej karty, obsługę braku aktywnej sesji i powrót do właściwej strony po zalogowaniu. Szczegóły konfiguracji produkcyjnej wymagały jeszcze potwierdzenia przed wdrożeniem.
Efektem tej analizy był uzgodniony zakres dla programisty. Obok rozwiązania docelowego miałem wariant wybrany do realizacji w wyznaczonym czasie — wraz z jasno nazwanym kompromisem. W podobnym zadaniu warto zapisać właśnie te trzy rzeczy: co robimy teraz, co zostawiamy na później i jaką zależność świadomie zachowujemy.