W każdej dużej firmie, a X5 Retail Group nie jest wyjątkiem, w miarę jej rozwoju wzrasta liczba projektów wymagających autoryzacji użytkowników. Z biegiem czasu wymagane jest płynne przechodzenie użytkowników z jednej aplikacji do drugiej, a następnie pojawia się potrzeba wykorzystania jednego serwera Single-Sing-On (SSO). Co jednak w sytuacji, gdy dostawcy tożsamości tacy jak AD lub inni, którzy nie mają dodatkowych atrybutów, są już wykorzystywani w różnych projektach. Na ratunek przyjdzie klasa systemów zwana „brokerami identyfikacji”. Najbardziej funkcjonalni są jego przedstawiciele, tacy jak Keycloak, zarządzanie Gravitee Access itp. Najczęściej przypadki użycia mogą być różne: interakcja z maszyną, udział użytkownika itp. Rozwiązanie musi obsługiwać elastyczną i skalowalną funkcjonalność, która może połączyć wszystkie wymagania w jedno, i takich rozwiązań nasza firma posiada obecnie brokera wskazań – Keycloak.
Keycloak to produkt typu open source do kontroli tożsamości i dostępu, obsługiwany przez firmę RedHat. Stanowi podstawę produktów firmy wykorzystujących technologię SSO - RH-SSO.
Podstawowe pojęcia
Zanim zaczniesz zajmować się rozwiązaniami i podejściami, powinieneś zdecydować o warunkach i kolejności procesów:
Identyfikacja to procedura rozpoznawania podmiotu po jego identyfikatorze (innymi słowy jest to definicja imienia, loginu lub numeru).
Uwierzytelnianie - jest to procedura uwierzytelniająca (użytkownik sprawdzany jest hasłem, list sprawdzany jest podpisem elektronicznym itp.)
autoryzacja - jest to zapewnienie dostępu do zasobu (na przykład do poczty elektronicznej).
Płaszcz na klucze brokera tożsamości
Keyclock to rozwiązanie do zarządzania tożsamością i dostępem o otwartym kodzie źródłowym, przeznaczone do użytku w systemach informatycznych, w których można zastosować wzorce architektury mikrousług.
Keycloak oferuje takie funkcje, jak jednokrotne logowanie (SSO), tożsamość za pośrednictwem brokera i logowanie społecznościowe, federacja użytkowników, karty klienckie, konsola administracyjna i konsola zarządzania kontami.
Podstawowa funkcjonalność obsługiwana przez Keycloak:
- Pojedyncze logowanie i jednokrotne wylogowanie w aplikacjach przeglądarkowych.
- Obsługa OpenID/OAuth 2.0/SAML.
- Identity Brokering - uwierzytelnianie przy użyciu zewnętrznych dostawców tożsamości OpenID Connect lub SAML.
- Logowanie społecznościowe - obsługa Google, GitHub, Facebook, Twitter w celu identyfikacji użytkownika.
- Federacja użytkowników - synchronizacja użytkowników z serwerów LDAP i Active Directory oraz innych dostawców tożsamości.
- Most Kerberos - wykorzystanie serwera Kerberos do automatycznego uwierzytelniania użytkowników.
- Konsola administracyjna — do ujednoliconego zarządzania ustawieniami i opcjami rozwiązań przez Internet.
- Konsola Zarządzania Kontem - do samodzielnego zarządzania profilem użytkownika.
- Personalizacja rozwiązania w oparciu o identyfikację wizualną firmy.
- Uwierzytelnianie 2FA - obsługa TOTP/HOTP przy użyciu Google Authenticator lub FreeOTP.
- Przepływy logowania - możliwa jest samodzielna rejestracja użytkownika, odzyskiwanie i resetowanie hasła oraz inne.
- Zarządzanie sesjami - administratorzy mogą zarządzać sesjami użytkowników z jednego miejsca.
- Token Mappers - wiązanie atrybutów użytkownika, ról i innych wymaganych atrybutów z tokenami.
- Elastyczne zarządzanie polityką w obrębie domeny, aplikacji i użytkowników.
- Obsługa CORS — karty klienckie mają wbudowaną obsługę CORS.
- Interfejsy dostawcy usług (SPI) — duża liczba interfejsów SPI, które umożliwiają dostosowanie różnych aspektów serwera: przepływów uwierzytelniania, dostawców tożsamości, mapowania protokołów i innych.
- Adaptery klienckie dla aplikacji JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Obsługa pracy z różnymi aplikacjami obsługującymi bibliotekę OpenID Connect Reling Party lub bibliotekę dostawcy usług SAML 2.0.
- Możliwość rozbudowy za pomocą wtyczek.
Do procesów CI/CD, a także automatyzacji procesów zarządzania w Keycloak można wykorzystać REST API/JAVA API. Dokumentacja dostępna jest w wersji elektronicznej:
REST API
API JAVA
Dostawcy tożsamości dla przedsiębiorstw (lokalnie)
Możliwość uwierzytelniania użytkowników za pośrednictwem usług federacji użytkowników.
Można również zastosować uwierzytelnianie przekazywane - jeśli użytkownicy uwierzytelniają się na stacjach roboczych za pomocą protokołu Kerberos (LDAP lub AD), mogą zostać automatycznie uwierzytelnieni w Keycloak bez konieczności ponownego wpisywania nazwy użytkownika i hasła.
Do uwierzytelniania i dalszej autoryzacji użytkowników można zastosować relacyjny system DBMS, który najlepiej sprawdza się w środowiskach programistycznych, gdyż nie wymaga długotrwałych ustawień i integracji na wczesnych etapach projektów. Domyślnie Keycloak używa wbudowanego systemu DBMS do przechowywania ustawień i danych użytkownika.
Lista obsługiwanych systemów DBMS jest obszerna i obejmuje: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle i inne. Najbardziej przetestowane jak dotąd to klaster Oracle 12C Release1 RAC i Galera 3.12 dla MariaDB 10.1.19.
Dostawcy tożsamości - logowanie społecznościowe
Możliwe jest użycie loginu z sieci społecznościowych. Aby aktywować możliwość uwierzytelniania użytkowników, użyj konsoli administracyjnej Keycloack. Zmiany w kodzie aplikacji nie są wymagane, a funkcjonalność jest dostępna od razu i można ją aktywować na dowolnym etapie projektu.
Do uwierzytelniania użytkowników można używać dostawców tożsamości OpenID/SAML.
Typowe scenariusze autoryzacji przy użyciu OAuth2 w Keycloak
Przepływ kodu autoryzacyjnego - używany z aplikacjami po stronie serwera. Jeden z najpopularniejszych typów uprawnień autoryzacyjnych, ponieważ dobrze nadaje się do aplikacji serwerowych, gdzie kod źródłowy aplikacji i dane klienta nie są dostępne dla osób z zewnątrz. Proces w tym przypadku opiera się na przekierowaniu. Aplikacja musi mieć możliwość interakcji z agentem użytkownika (user-agentem), takim jak przeglądarka internetowa, aby otrzymywać kody autoryzacyjne API przekierowane za pośrednictwem agenta użytkownika.
niejawny przepływ - wykorzystywane przez aplikacje mobilne lub webowe (aplikacje działające na urządzeniu użytkownika).
Typ uprawnienia do autoryzacji ukrytej jest używany w aplikacjach mobilnych i internetowych, w których nie można zagwarantować poufności klienta. Typ uprawnienia ukrytego wykorzystuje również przekierowanie agenta użytkownika, w wyniku czego token dostępu jest przekazywany agentowi użytkownika w celu dalszego wykorzystania w aplikacji. Dzięki temu token staje się dostępny dla użytkownika i innych aplikacji na urządzeniu użytkownika. Tego typu uprawnienia autoryzacyjne nie uwierzytelniają tożsamości aplikacji, a sam proces opiera się na adresie URL przekierowania (wcześniej zarejestrowanym w serwisie).
Implicit Flow nie obsługuje tokenów odświeżania tokenów dostępu.
Przepływ uprawnień klienta — są wykorzystywane, gdy aplikacja uzyskuje dostęp do API. Ten typ uprawnień autoryzacyjnych jest zwykle używany w przypadku interakcji serwer-serwer, które muszą być wykonywane w tle, bez bezpośredniej interakcji użytkownika. Przepływ przyznawania poświadczeń klienta umożliwia usłudze internetowej (klientowi poufnemu) korzystanie z własnych poświadczeń zamiast podszywać się pod użytkownika w celu uwierzytelnienia podczas wywoływania innej usługi internetowej. Aby zapewnić wyższy poziom bezpieczeństwa, usługa wywołująca może używać certyfikatu (zamiast wspólnego hasła) jako poświadczenia.
Specyfikacja OAuth2 jest opisana w
Token JWT i jego zalety
JWT (JSON Web Token) to otwarty standard (), który definiuje kompaktowy i niezależny sposób bezpiecznego przesyłania informacji między stronami jako obiekt JSON.
Zgodnie ze standardem token składa się z trzech części w formacie base-64, oddzielonych kropkami. Pierwsza część nazywa się nagłówkiem, który zawiera typ tokena i nazwę algorytmu skrótu służącego do uzyskania podpisu cyfrowego. Druga część przechowuje podstawowe informacje (użytkownik, atrybuty itp.). Trzecia część to podpis cyfrowy.
. .
Nigdy nie przechowuj tokena w swojej bazie danych. Ponieważ prawidłowy token jest równoznaczny z hasłem, przechowywanie tokena przypomina przechowywanie hasła w postaci zwykłego tekstu.
Token dostępu to token, który zapewnia swojemu właścicielowi dostęp do bezpiecznych zasobów serwera. Zwykle ma krótki czas życia i może zawierać dodatkowe informacje, takie jak adres IP strony żądającej tokena.
Odśwież token to token, który pozwala klientom zażądać nowych tokenów dostępowych po wygaśnięciu ich ważności. Tokeny te są zazwyczaj wydawane na długi okres czasu.
Główne zalety zastosowania w architekturze mikroserwisowej:
- Możliwość dostępu do różnych aplikacji i usług poprzez jednorazowe uwierzytelnienie.
- W przypadku braku szeregu wymaganych atrybutów w profilu użytkownika istnieje możliwość wzbogacenia o dane, które można dodać do payloadu, także automatycznie i na bieżąco.
- Nie ma potrzeby przechowywania informacji o aktywnych sesjach, aplikacja serwera musi jedynie zweryfikować podpis.
- Bardziej elastyczna kontrola dostępu dzięki dodatkowym atrybutom w ładunku.
- Zastosowanie podpisu tokenowego dla nagłówka i ładunku zwiększa bezpieczeństwo rozwiązania jako całości.
Token JWT - skład
Tytuł - domyślnie nagłówek zawiera jedynie rodzaj tokena i algorytm zastosowany do szyfrowania.
Typ tokena przechowywany jest w kluczu „typ”. Klucz „typ” jest ignorowany w tokenie JWT. Jeśli występuje klucz „typ”, jego wartością musi być JWT, aby wskazać, że ten obiekt jest tokenem internetowym JSON.
Drugi klucz „alg” definiuje algorytm używany do szyfrowania tokena. Domyślnie powinien być ustawiony na HS256. Nagłówek jest zakodowany w base64.
{ "alg": "HS256", "typ": "JWT"}
ładunek (treść) - ładunek przechowuje wszelkie informacje, które należy sprawdzić. Każdy klucz w ładunku nazywany jest „roszczeniem”. Na przykład możesz wejść do aplikacji tylko za zaproszeniem (zamknięta promocja). Kiedy chcemy kogoś zaprosić do udziału, wysyłamy mu zaproszenie. Ważne jest, aby sprawdzić, czy adres e-mail należy do osoby, która przyjmie zaproszenie, dlatego uwzględnimy ten adres w ładunku, w tym celu przechowujemy go w kluczu „e-mail”
{ "e-mail": "[email chroniony]"}
Klucze w ładunku mogą być dowolne. Istnieje jednak kilka zarezerwowanych:
- iss (Wydawca) – Identyfikuje aplikację, z której wysyłany jest token.
- sub (Subject) - określa temat tokena.
- aud (Audience) to tablica ciągów znaków lub identyfikatorów URI, w których rozróżniana jest wielkość liter, która stanowi listę odbiorców tego tokena. Gdy strona odbierająca otrzyma JWT z podanym kluczem, musi sprawdzić swoją obecność w odbiorcach - w przeciwnym razie zignoruj token.
- exp (Czas wygaśnięcia) — wskazuje, kiedy wygasa token. Standard JWT wymaga, aby wszystkie jego implementacje odrzucały tokeny, które wygasły. Klucz exp musi być znacznikiem czasu w formacie uniksowym.
- nbf (Not Before) to czas w formacie uniksowym, który określa moment, w którym token staje się ważny.
- iat (Wydano o) — ten klucz reprezentuje godzinę wystawienia tokenu i może służyć do określenia wieku tokenu JWT. Klucz iat musi być znacznikiem czasu w formacie uniksowym.
- Jti (JWT ID) — ciąg znaków definiujący unikalny identyfikator tego tokena, rozróżniana jest wielkość liter.
Ważne jest, aby zrozumieć, że ładunek nie jest przesyłany w formie zaszyfrowanej (chociaż tokeny można zagnieżdżać i wówczas możliwe jest przesyłanie zaszyfrowanych danych). Dlatego nie może przechowywać żadnych tajnych informacji. Podobnie jak nagłówek, ładunek jest zakodowany w formacie Base64.
podpis - gdy mamy tytuł i ładunek, możemy obliczyć podpis.
Zakodowane w formacie Base64: pobierany jest nagłówek i ładunek, a następnie łączone w ciąg znaków przechodzący przez kropkę. Następnie ten ciąg znaków i tajny klucz są wprowadzane do algorytmu szyfrowania określonego w nagłówku (klucz „alg”). Kluczem może być dowolny ciąg. Dłuższe struny będą najbardziej preferowane, ponieważ ich podniesienie zajmie więcej czasu.
{"alg":"RSA1_5","ładunek":"A128CBC-HS256"}
Budowanie architektury klastra pracy awaryjnej Keycloak
W przypadku korzystania z jednego klastra dla wszystkich projektów zwiększają się wymagania dotyczące rozwiązania SSO. Gdy liczba projektów jest niewielka, wymagania te nie są tak zauważalne dla wszystkich projektów, jednak wraz ze wzrostem liczby użytkowników i integracji rosną wymagania dotyczące dostępności i wydajności.
Zwiększenie ryzyka awarii pojedynczego SSO zwiększa wymagania dotyczące architektury rozwiązania i metod stosowanych w przypadku redundantnych komponentów i prowadzi do bardzo wąskiej umowy SLA. W związku z tym coraz częściej na etapie tworzenia lub wczesnych etapów wdrażania rozwiązań projekty posiadają własną, nieodporną na błędy infrastrukturę. W miarę postępu rozwoju konieczne jest określenie możliwości rozwoju i skalowania. Najbardziej elastyczne jest zbudowanie klastra pracy awaryjnej przy użyciu wirtualizacji kontenerów lub podejścia hybrydowego.
Aby pracować w trybach klastra Active/Active i Active/Passive, należy zapewnić spójność danych w relacyjnej bazie danych - oba węzły bazy danych muszą być synchronicznie replikowane pomiędzy różnymi geograficznie rozproszonymi centrami danych.
Najprostszy przykład instalacji odpornej na błędy.
Jakie są korzyści z używania pojedynczego klastra:
- Wysoka dostępność i wydajność.
- Obsługa trybów pracy: Aktywny/Aktywny, Aktywny/Pasywny.
- Możliwość dynamicznego skalowania – w przypadku korzystania z wirtualizacji kontenerów.
- Możliwość scentralizowanego zarządzania i monitorowania.
- Ujednolicone podejście do identyfikacji/uwierzytelniania/autoryzacji użytkowników w projektach.
- Bardziej przejrzysta interakcja między różnymi projektami bez udziału użytkownika.
- Możliwość ponownego wykorzystania tokena JWT w różnych projektach.
- Pojedynczy punkt zaufania.
- Szybsze uruchamianie projektów z wykorzystaniem mikroserwisów/wirtualizacji kontenerów (nie ma potrzeby podnoszenia i konfigurowania dodatkowych komponentów).
- Istnieje możliwość zakupu wsparcia komercyjnego od dostawcy.
Na co zwrócić uwagę planując klaster
DBMS
Keycloak wykorzystuje system zarządzania bazami danych do przechowywania: dziedzin, klientów, użytkowników itp.
Obsługiwana jest szeroka gama systemów DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak ma własną wbudowaną relacyjną bazę danych. Zaleca się używanie w środowiskach nieobciążonych - takich jak środowiska programistyczne.
Do pracy w trybach klastra aktywny/aktywny i aktywny/pasywny wymagana jest spójność danych w relacyjnej bazie danych, a oba węzły klastra bazy danych są synchronicznie replikowane pomiędzy centrami danych.
Rozproszona pamięć podręczna (Infinspan)
Aby klaster działał poprawnie, wymagana jest dodatkowa synchronizacja następujących typów pamięci podręcznych przy użyciu JBoss Data Grid:
Sesje uwierzytelniające – służą do zapisywania danych podczas uwierzytelniania konkretnego użytkownika. Żądania z tej pamięci podręcznej zazwyczaj obejmują tylko przeglądarkę i serwer Keycloak, a nie aplikację.
Tokeny akcji są używane w scenariuszach, w których użytkownik musi potwierdzić akcję asynchronicznie (za pośrednictwem poczty elektronicznej). Na przykład podczas zapominania hasła pamięć podręczna actionTokens Infinispan jest używana do śledzenia metadanych dotyczących powiązanych tokenów akcji, które zostały już wykorzystane, więc nie można ich ponownie wykorzystać.
Buforowanie i unieważnianie trwałych danych - używane do buforowania trwałych danych, aby uniknąć niepotrzebnych zapytań do bazy danych. Kiedy dowolny serwer Keycloak aktualizuje dane, wszystkie pozostałe serwery Keycloak we wszystkich centrach danych muszą o tym wiedzieć.
Praca — używana tylko do wysyłania nieprawidłowych komunikatów między węzłami klastra a centrami danych.
Sesje użytkownika – służą do przechowywania danych o sesjach użytkownika, które obowiązują przez czas trwania sesji przeglądarki użytkownika. Pamięć podręczna musi przetwarzać żądania HTTP od użytkownika końcowego i aplikacji.
Ochrona przed brutalną siłą - służy do śledzenia danych o nieudanych logowaniach.
Równoważenie obciążenia
Moduł równoważenia obciążenia jest pojedynczym punktem wejścia do maskowania kluczy i musi obsługiwać sesje trwałe.
Serwery aplikacji
Służą do kontrolowania interakcji komponentów ze sobą i mogą być wirtualizowane lub konteneryzowane przy użyciu istniejących narzędzi automatyzacji i dynamicznego skalowania narzędzi automatyzacji infrastruktury. Najczęstsze scenariusze wdrożeń w OpenShift, Kubernates, Rancher.
Na tym kończy się część pierwsza – teoretyczna. W kolejnej serii artykułów zostaną przeanalizowane przykłady integracji z różnymi dostawcami tożsamości oraz przykłady ustawień.
Źródło: www.habr.com