Apero CAS vs KeyCloak, który serwer SSO warto wybrać? – cz. 2

W zdecydowanej większości projektów będziemy mieli do czynienia z pojedynczym repozytorium dostarczającym informacji o naszych podmiotach logowania. W pierwszej części artykułu zwróciłem uwagę na podstawowe różnice pomiędzy systemami SSO – CAS i KeyCloak. Poruszyłem temat wspieranych przez nie protokołów oraz wsparcia dla integracji aplikacji klienckich. W tej części postaram się omówić pozostałe kwestie, które mają wpływ na wybór systemu SSO, takie jak: integracja z dostawcami tożsamości, funkcje delegowania uwierzytelnienia, dostosowanie wyglądu okien logowania. Zajmę się także omówieniem zaawansowanych funkcjonalności i jakości dokumentacji obydwu projektów.

Integracja z dostawcami tożsamości (federowanie kont użytkowników)

W zdecydowanej większości projektów będziemy mieli do czynienia z pojedynczym repozytorium dostarczającym informacji o naszych podmiotach logowania w postaci bazy usługi katalogowej LDAP/Active Directory. Zarówno w Apero CAS, jak i KeyCloak podpięcie się do takiego pojedynczego repozytorium nie będzie stanowiło większego problemu. Przyjrzyjmy się zatem bardziej zaawansowanym funkcjonalnościom, jakie w zakresie podłączania się do źródeł tożsamości oferują obydwa systemy.

W przypadku KeyCloak/Red Hat SSO już po instalacji otrzymujemy gotowe rozwiązanie – bez dodatkowej konfiguracji system działa w oparciu o wbudowaną bazę danych RDBMS, w której przechowuje informacje o użytkownikach. Dodatkowo możemy skonfigurować federowanie kont użytkowników na podstawie źródła Kerberos lub bazy LDAP.

Konfiguracja każdego z dostawców jest niezwykle prosta i odbywa się przy użyciu kreatora, w którym dodatkowo dostępne są szablony konfiguracyjne dla typowych usług LDAP (np. RedHat IdM czy Active Directory). Istnieje możliwość konfiguracji wielu dostawców tożsamości i określenia ich priorytetu. W takim wypadku użytkownicy będą wyszukiwani kolejno z uwzględnieniem określonych priorytetów w każdym ze zdefiniowanych dostawców.

Dodając w systemach KeyCloak/RH SSO dostawcę LDAP mamy dodatkowo możliwość określenia trybu edycji co daje możliwość synchronizacji zwrotnej informacji z systemu SSO do bazy LDAP (funkcja niezbędna w przypadku zapewnienia np. opcji rejestracji czy edycji własnego konta przez samego użytkownika).

Mamy też możliwość określenia polityki synchronizacji danych z bazą LDAP czy też opcji związanych z trwałością danych dotyczących użytkowników w systemie SSO. Jest to szczególnie ważne w przypadkach, kiedy usługa katalogowa jest dostawcą tożsamości nie tylko dla naszego systemu SSO i istnieje konieczność odpowiedniego zarządzania jej obciążeniem.

Bardzo ważną funkcją jest też możliwość określenia pobierania ze źródła dostawcy tożsamości LDAP dodatkowych atrybutów konta użytkownika. W systemie Red Hat SSO/Keycloak określamy to na poziomie konfiguracji dostawcy tożsamości poprzez definicję tzw. mapperów. Pobrane atrybuty mogą dodatkowo charakteryzować konto użytkownika i być na etapie konfiguracji aplikacji klienckich przekazywane do nich z wykorzystaniem mechanizmów danego protokołu SSO. Alternatywnie mogą też być mapowane na role bezpieczeństwa (uprawnienia) w samym systemie SSO i warunkować dostęp do wybranych funkcji systemu SSO czy aplikacji klienckich.

Wszystkie opisane powyżej funkcjonalności a w zasadzie ich bezpośrednie odpowiedniki znajdziemy także w systemie CAS, który ponadto oferuje bezpośrednie wsparcie dla mniej typowych dostawców tożsamości oraz bardziej zaawansowane mechanizmy pobierania danych o kontach użytkownika.

Wśród możliwych do konfiguracji dostawców znajdziemy bazy RDBMS, LDAP w tym Active Directory, SPNEGO, JAAS, JWT, Radius, MongoDB. Podobnie jak w poprzednio omawianym przypadku istnieje możliwość dodawania wielu dostawców z określeniem ich priorytetów oraz określenie polityki uwierzytelnienia. Taka polityka może być też osobno dostosowywane per serwis (aplikacja kliencka).

Istnieje też możliwość zaawansowanej konfiguracji bardzo nietypowych sytuacji, w których uwierzytelnienie będzie przebiegało w oparciu o jednego dostawcę – na podstawie tak pobranych danych (np. na podstawie nazwy konta) od innego zdefiniowanego dostawcy będą pobierane dodatkowe atrybuty konta. Pozwala to na łatwiejsze adaptowanie systemu SSO do pracy w heterogenicznym środowisku, w którym pełne dane konta nie są przetrzymywane w jednym miejscu.

Delegowanie uwierzytelnienia

W dobie wszechobecnych serwisów społecznościowych jednym z założeń naszego projektu może być pozostawienie użytkownikom możliwości logowania się do naszych systemów przy użyciu kont przechowywanych u zewnętrznego dla nas dostawcy.

Oba opisywane systemy zapewnią nam możliwość implementacji takich założeń. System KeyCloak/RH SSO zapewnia możliwość integracji z dostawcami obsługującymi protokoły SAML 2.0 i OpenID Connect/OAuth 2.0. W celu ułatwienia administratorom konfiguracji takiej funkcjonalności dla typowych dostawców, takich jak np. Github, Twitter, Facebook, Google, LinkedIn, Microsoft itp. dostarczono specjalne szablony konfiguracyjne.

System CAS może być skompilowany ze wsparciem dla delegowania uwierzytelniania do innych serwerów CAS, dostawców OpenID Connect, SAML 2.0, Oauth 2.0, ale także ADFS. Tradycyjnie lista wspieranych przez CAS standardów jest szersza, ale i konfiguracja każdego z nich na pewno dużo trudniejsza.

Warto zauważyć, że ponieważ CAS może być skompilowany ze wsparciem dla protokołów SAML 2.0 czy OpenID Connect, OAuth 2.0, zarówno CAS może być dostawcą tożsamości dla KeyCloak, jak i KeyCloak może stać się dostawcą tożsamości dla CAS.

Dostosowywanie wyglądu i lokalizacja interfejsów

Obydwa narzędzia oferują mechanizmy łatwego dostosowywania widoków, jakie wyświetlane są naszym użytkownikom. W systemie CAS lokalizację dostosowujemy, podmieniając w procesie kompilacji odpowiednie pliki messsages.properties. Istnieje też możliwości podmiany plików lokalizacyjnych poprzez ładowanie ich spoza dedykowanej kompilacji systemu przy wykorzystaniu odpowiednich opcji konfiguracyjnych.

Domyślnym mechanizmem dostosowania wyglądu okien CAS jest szkielet Thymeleaf www.thymeleaf.org. W ramach jednej kompilacji systemu możemy przygotować domyślnie wiele tematów graficznych. Dostosowany może być także wygląd panelu administracyjnego CAS. Jeśli opracujemy więcej niż jeden domyślny temat graficzny mamy możliwość wybierania różnych tematów w zależności od serwisu/aplikacji klienckiej CAS.

Analogicznie wygląda sytuacja w przypadku systemów KeyCloak/RH SSO. Tutaj również określamy tematy graficzne, na które składają się: szablony HTML Freemaker wraz z plikami lokalizacyjnymi. Szablony przechowywane są w katalogu wdrożenia systemu w podkatalogu theme i zawierają swoje deskryptory w postaci plików theme.properties.

Zarówno w przypadku CAS, jak i KeyCloak dobrym pomysłem jest rozpoczęcie wprowadzania własnych definicji od skopiowania istniejących tematów i podmiany lub edycji interesujących nas elementów, takich jak pliki html z definicjami poszczególnych widoków, arkusze stylów css, pliki java skryptów czy plików graficznych.

Dokumentacja

Realizując nasz projekt wdrożenia systemu SSO wcześniej lub później napotkamy problem. W takim przypadku będziemy posiłkować się dostępną dla projektów dokumentacją.

W przypadku systemów KeyCloak/Red Hat SSO oficjalna dokumentacja jest niezwykle przejrzysta i poparta wieloma przykładami. Dostępna jest pod adresami: https://www.keycloak.org/docs/latest/getting_started/index.html oraz https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/

Znajdziemy w niej osobne obszerne sekcje poświęcone wprowadzeniu (ang. Getting Started), instalacji (ang. Server Installation), integracji z aplikacjami (ang. Securing Apps), administracji (ang. Server Admin), rozszerzeniu funkcjonalności systemu SSO (ang. Server Development), usługom autoryzacji (ang. Authorization Services), aktualizacji (ang. Upgrading) czy poszczególnym wydaniom (ang. Release Notes). Przejrzystość i przydatność tej dokumentacji w mojej opinii jest absolutnie wzorcowa.

Nie mogę niestety tego samego powiedzieć o oficjalnej dokumentacji CAS dostępnej pod adresem https://apereo.github.io/cas/6.0.x/. Sama dokumentacja podzielona jest na sekcje funkcjonalne od planowania poprzez instalację, konfigurację, uwierzytelnienie, podłączania dostawców tożsamości itp.

Bez wątpienia znajdziemy w niej jasne informacje dotyczące oferowanych funkcjonalności i tego, jak należy przygotować kompilację systemu wspierającą daną funkcjonalność. Nie możemy jednak liczyć na konkretne przykłady konfiguracji. Jednakże jej największą wadą jest brak jednoznacznego opisu wszystkich dostępnych opcji konfiguracyjnych.

Na szczęście w większości przypadków nazwy poszczególnych opcji są wystarczające do zrozumienia tego, do czego tak naprawdę służą. Jeśli jednak znajdziemy takie opcje konfiguracyjne, których znaczenia nie będziemy w stanie jednoznacznie zrozumieć, wtedy pozostaje nam posiłkowanie się dostępnym kodem źródłowym.

Usprawiedliwiając twórców, warto dodać, że dokumentacja i tak jest bardzo obszerna, ze względu na oferowaną przez system ogromną ilość dostępnych funkcjonalności, a opisywanie każdej opcji z osobna wraz z przykładami byłoby mrówczą pracą. Jeśli dokumentacja dostawcy nie jest dla nas wystarczająca, w sieci znajdziemy wiele studiów wykonalności oraz porad, spośród których na szczególną uwagę zasługuje dokumentacja dostępna pod adresem: https://dacurry-tns.github.io/deploying-apereo-cas/introduction_overview.html.

Dodatkowo dostępne inne ciekawe funkcjonalności

Powyżej i w poprzedniej części artykułu opisałem najważniejsze elementy wpływające na wybór rozwiązania SSO. Teraz skupię się na innych interesujących funkcjonalnościach.

Obydwa systemy oferują możliwość integracji z systemem pocztowym w zakresie funkcji przypominania czy resetowania hasła użytkownika. Dodatkowo KeyCloak dostarcza aplikację umożliwiającą użytkownikowi zarządzanie jego własnym kontem.

Obydwa systemy mogą zostać skonfigurowane tak, aby istniała możliwość przejmowania uprawnień użytkowników w wybranych lub wszystkich aplikacjach. W KeyCloak jest to opcja impersonate i odpowiadające jej uprawnienia użytkownika administracyjnego serwera. CAS daje nam możliwość przygotowania kompilacji wspierającej funkcje surogacji i jej skonfigurowania globalnie lub per serwis/aplikacja kliencka. Obydwa narzędzia wspierają mechanizmy Captcha w obu przypadkach w oparciu o Google reCaptcha.

Nieco inaczej wygląda wsparcie dla standardów 2FA (w CAS MFA). System KeyCloak posiada wsparcie dla Google Authenticator lub FreeOTP. W CAS możliwe są konfiguracje wspierające mechanizmy Duo Secuirty, Authy, Google Authenticator, YubiKey czy Fido U2F. Oba systemy pozwalają na określenie przebiegów uwierzytelniania i autoryzacji (innych niż standardowo oferowane) oraz zdefiniowanie domyślnych dla użytkowników akcji, takich jak np. konieczność akceptacji regulaminów każdorazowo lub przy pierwszym logowaniu.

Obydwa systemy pozwalają na określenie typowych nagłówków bezpieczeństwa ustawianych przez serwer podczas uwierzytelniania. System KeyCloak pozwala na wdrożenie skutecznej ochrony przed atakami słownikowymi z możliwością blokowania kont podejmujących często powtarzające się próby nieudanego logowania. Odpowiadającą temu funkcjonalnością CAS jest funkcja dławienia prób logowania (ang. Throttling), która wymusza na dostawcy systemu CAS wdrożenie mechanizmu przechowywania danych o zdarzeniach logowania.

Obydwa systemy posiadają też rozbudowane interfejsy REST. W przypadku KeyCloak oferuje on więcej funkcjonalności, w tym obsługę funkcji administracyjnych systemu SSO.

Bardzo ciekawą funkcją oferowaną przez CAS jest możliwość przygotowania kompilacji wspierającej funkcje uwierzytelnienia z detekcją ryzyka i możliwością blokowania uwierzytelnienia lub wdrożenia uwierzytelnienia wielopoziomowego w zależności od oceny tego ryzyka. Funkcja ta pozwala na uwzględnienie w ocenie ryzyka takich informacji jak: adresacja IP, przeglądarka użytkownika, geolokalizacja żądań uwierzytelnienia czy też data i czas logowania.

Podsumowanie

Gdybyśmy chcieli oceniać obydwa systemy, biorąc pod uwagę jedynie suchą listę oferowanych funkcjonalności, CAS zdecydowanie wygrałby tę rywalizację. Odpowiedź na pytanie, jaki system warto wybrać, nie jest jednak tak jednoznaczna i prosta.

Jeśli dysponujemy ograniczonymi zasobami ludzkimi i jednocześnie posiadany przez nas stos technologicznych oparty jest na produktach firmy Red Hat lub zgodnych z nimi, wdrożenie, utrzymanie i zarządzanie systemem opartym na KeyCloak, czy też na jego wersji komercyjnej, czyli Red Hat SSO, będzie na pewno procesem dużo prostszym. Jeszcze ważniejszy będzie fakt, że taki proces obarczony będzie zdecydowanie mniejszym ryzykiem niepowodzenia.

Oczywiście czytelnik tego artykułu może stwierdzić, że CAS oferuje mu kluczowe dla jego potrzeb funkcje, których brakuje w KeyCloak. Nie zapominajmy, że KeyCloak to podobnie jak CAS system Open Source, którego funkcjonalność może być rozbudowywana poprzez system wtyczek. Przykłady takich rozszerzeń podałem w pierwszej części artykułu. Jeśli czegoś nam realnie brakuje, zapoznajmy się z dokumentacją Server Development, może okazać się, że dodanie brakującej funkcji nie jest aż tak trudne.

Pamiętajmy, że wybierając system CAS, decydujemy się na proces wytwórczy. Będziemy potrzebować do tego zasobów nie tylko ludzkich, ale i sprzętowych. W efekcie uzyskamy rozwiązanie szyte na naszą konkretną miarę. Proces przygotowania tego rozwiązania pochłonie jednak zdecydowanie więcej czasu i będzie wymagał wdrożenia odpowiednich procedur testowania samego systemu SSO.

Jeśli rozważymy w odniesieniu do obydwu systemów konieczność wdrożenia mechanizmów wysokiej dostępności (ang. High Availability), to łatwo wysnujemy wniosek, że w przypadku KeyCloak czy RH SSO należy oprzeć się na funkcjach Clustra JBoss/Widlfly. Tym samym każdy doświadczony administrator serwerów aplikacji skonfiguruje nam system SSO do pracy w trybie HA w zaledwie kilka minut. Starając się osiągnąć to samo w przypadku CAS, po pierwsze musimy podjąć decyzję, jaki mechanizm replikacji informacji pomiędzy węzłami wybrać: Hazelcast, Ehcache, Memache, Ignite, Infinispan itd. (możliwych do konfiguracji mechanizmów jest naprawdę wiele). Po drugie możemy potrzebować także mechanizmu wykrywania dostępności węzłów – tutaj mamy do wyboru technologie takie jak Eureka czy Consul.

W praktyce każda funkcja w CAS może być zaimplementowana na wiele różnych sposobów przy użyciu najróżniejszych mechanizmów. To jest wielka zaleta CAS, ale też potencjalnie ogromna wada. Każdy wybór to potencjalne ryzyko problemów, szczególnie jeśli nasi pracownicy nie mają doświadczenia w pracy z daną technologią. Z własnego doświadczenia mogę śmiało stwierdzić, że kiedy stworzymy działający klaster SSO przy użyciu CAS i potwierdzimy poprawność jego pracy we wszystkich środowiskach, satysfakcja z wykonanej pracy na pewno będzie przeogromna. Pytanie brzmi czy nie została ona osiągnięta niewspółmiernym nakładem czasu do oferowanych przez system funkcji.

KeyCloak czy Red Hat SSO to rozwiązania, które po prostu działają, szczególnie tam, gdzie wymagania są dość standardowe, a środowisko, w jakim wdrażamy system SSO, nie jest heterogeniczne.

Weźmy więc pod uwagę wszystkie za i przeciw, zanim podejmiemy ostateczną decyzję. Wszystko sprowadza się do poprawnej identyfikacji naszych potrzeb. Nic też nie stoi na przeszkodzie, aby rozpocząć od wykonania PoC w małej skali.