Apereo CAS vs KeyCloak, który serwer SSO warto wybrać? cz. 1

Wybór rozwiązania zapewniającego pojedyncze uwierzytelnienie nie jest zadaniem prostym. Powinien on być podyktowany przede wszystkim dobrą identyfikacją własnych potrzeb i wymagań, jakie stawiamy wdrażanemu systemowi. Na rynku dostępnych jest wiele rozwiązań wspierających zaawansowane procesy uwierzytelniania i autoryzacji użytkowników.

W tym tekście postaram się porównać dwa w obecnej chwili chyba najpopularniejsze systemy Open Source, jakimi są system Apereo CAS oraz system Keycloak przedstawiając ich zalety, ale również ograniczenia. Poniższy tekst i niektóre zawarte w nim tezy wynikają z mojego osobistego doświadczenia i mogą mieć charakter subiektywny. Moim celem nie jest rozpoczynanie wojny religijnej i udowadnianie wyższości jednej technologii nad drugą, ale przekazanie pewnych faktów oraz ocen, które mogą pomóc czytającemu wybrać rozwiązanie lepiej odpowiadające wymaganiom jego projektu.

Ze względu na szeroki zakres materiału artykuł podzieliłem na 2 części. W pierwszej skupię się na zasadniczych różnicach pomiędzy oboma rozwiązaniami, wspieranych przez nie protokołach SSO i kwestii integracji klienckich aplikacji z systemem SSO.

Krótki rys historyczny Apereo CAS i Keycloak

Projekt CAS stworzony został na uniwersytecie Yale jako Yale CAS. Od 2004 roku rozwijany przez fundację Java in Administration Special Intrest Group jako JASIG CAS. Fundacja ta w roku 2008 po konsolidacji z fundacją Sakai zmienia nazwę na APEREO, a system przemianowany zostaje od wersji 4.0 na Apereo CAS. Podstawowym celem działania fundacji jest zapewnienie jednostkom edukacyjnym wiarygodnego oprogramowania Open Source, które może sprostać konkurencji rynkowej ze strony zamkniętych komercyjnych systemów i rozwiązań. System CAS do dziś stanowi wiodący standard uwierzytelnienia w wielu ośrodkach akademickich także w naszym kraju. Na początku stycznia 2019 wydana została wersja oznaczona numerem 6.0.

Historie rozwoju projektu Keycloak od systemu CAS dzieli aż 10 lat. Pierwsze produkcyjne wydanie projektu rozwijanego w ramach Jboss Community miało miejsce w roku 2014. W 2016 roku firma Red Hat zmieniła stosowany dotychczas w swoim produkcie Red Hat SSO szkielet PicketLink na system KeyCloak, tym samym od wersji 7.0 Red Hat SSO oparte zostaje na systemie KeyCloak. Dzięki tej decyzji baza kodu PicketLink oraz dostępne w niej funkcjonalności zostają zintegrowane z systemem KeyCloak. Bezpośrednie wsparcie dużego i uznanego dostawcy dostarcza dodatkowego paliwa dla rozwoju projektu.

Powiązanie pomiędzy projektem KeyCloak a Red Hat SSO jest bezpośrednie – Red Hat SSO w wersji 7.0 oparty został na KeyCloak 1.9.8, RH SSO 7.1 na KeyCloak 2.5.5, a RH SSO 7.2 na KeyCloak 3.4.3. W listopadzie wydana została aktualizacja do wersji 7.2.5 systemu RH SSO, a w grudniu wersja 4.8 systemu KeyCloak.

Zasadnicze różnice pomiędzy systemami – Apereo CAS vs Keycloak

Pierwszą i najbardziej podstawową różnicą jest sposób wydania i dostarczenie systemu. System CAS skonstruowany jest w oparciu stos technologiczny Spring Webflow/Spring Boot. W przypadku CAS trudno mówić o dostarczeniu gotowego systemu, na stronie dostawcy nie znajdziemy gotowych do pobrania instalacji systemu SSO, które nadawałyby się do wykorzystania produkcyjnego.

CAS wydawany jest w postaci repozytorium War (ang. War Overlay), które stanowić będzie podstawę do zbudowania własnej dedykowanej i dostosowanej do własnych potrzeb kompilacji systemu SSO. CAS jest więc nie tyle gotowym do wdrożenia systemem SSO, lecz raczej stanowi szkielet ułatwiający budowanie własnych wysoce spersonalizowanych rozwiązań SSO.

Sam proces wdrożenia systemu będzie się opierał na dograniu (podmianie) interesujących nas elementów (takich jak widoki, elementy domyślnej konfiguracji czy większe fragmenty kodu źródłowego) oraz określeniu każdej interesującej nas funkcji (w tym także wyboru jednego z wielu modeli implementacji każdej z funkcjonalności). Działania te będziemy mogli wykonać poprzez systemy zarządzania zależnościami Maven (dostępny do wersji 5.x) lub Gradle (dostępny od wersji 5.x), przy których użyciu możemy zbudować gotowy system SSO.

System możemy uruchomić na jednym z wielu wspieranych serwerów aplikacji czy też kontenerów servletów. Tak wykonana kompilacja będzie musiała zostać gruntownie przetestowania przed jej wykorzystaniem w środowisku produkcyjnym. Poza samym serwerem CAS projekt dostarcza osobno aplikację pozwalającą na zarządzanie aplikacjami klienckimi systemu SSO – proces jej budowy i wdrożenia jest analogiczny do procesu budowy samego serwera CAS.

Z powyższego opisu widać wyraźnie, że proces wdrożenia systemu SSO CAS jest zdecydowanie procesem wytwórczym i będzie wymagał dodatkowego zaangażowania narzędzi typowo wytwórczych, takich jak systemy kontroli wersji czy środowiska developerskie. Można wysnuć zatem wniosek, że osoby odpowiedzialne za przygotowanie kompilacji systemu CAS muszą posiadać wiedzę z zakresu wykorzystania tego typu narzędzi i muszą posiadać przynajmniej podstawową wiedzę na temat technologii wykonania systemu.

Nieco inaczej wygląda sytuacja z systemem KeyCloak. KeyCloak jest oparty na szkielecie Spring, ale stanowi rozwiązanie silnie zintegrowane z podsystemem JBoss/Wildfly. Na stronie projektu znajdziemy gotowe do instalacji wersje projektu dystrybuowane wraz z serwerami aplikacji – dla KeyCloak jest to Wildfly, a dla Red Hat SSO JBoss EAP. Instalacje z pominięciem serwera aplikacji nie są wspierane, podobnie jak utrzymywanie na danym serwerze WildFly/EAP innych aplikacji niż KeyCloak/Red Hat SSO.

Instalacja samego systemu jest analogiczna do instalacji samego serwera aplikacji, a konfiguracja nie nastręcza większych problemów. Koniecznym dodatkowym krokiem konfiguracyjnym jest podłączenie systemu SSO do produkcyjnego źródła danych RDBMS (wbudowana testowa baza H2 powinna zostać zastąpiona wydajnym systemem). System może jeszcze wymagać drobnej rekonfiguracji podsystemu WWW w przypadku chęci wystawienia go za Reverse Proxy. Doświadczony administrator serwerów aplikacji JBoss EAP/WildFly nie powinien mieć najmniejszych problemów z wdrożeniem systemu. W zasadzie po kilkunastu minutach od pobrania otrzymujemy wdrożony gotowy do pracy system SSO.

Warto zaznaczyć, że proces aktualizacji systemów w przypadku CAS wymaga przygotowania nowej kompilacji systemu, dla KeyCloak wgrania (podmiany) starej wersji na nową wersję systemu, ale już w przypadku oficjalnie wspieranego systemu Red Hat SSO wydawane są poprawki, które można dograć poprzez podsystem patchowania serwera aplikacji. Dla systemów CAS i KeyCloak procesy aktualizacyjne nie gwarantują pełnej wstecznej zgodności i bezwzględnie powinny być uzupełnione o odpowiednie testy. Firma Red Hat wydając poprawki, gwarantuje ich wsteczną zgodność z zainstalowaną wersją Red Hat SSO.

Kolejną zasadniczą różnicą jest podejście do zarządzania systemami klienckimi i ustawieniami. W przypadku systemu KeyCloak stosowany jest model wielu domen (ang. realm) uwierzytelniania i autoryzacji, podczas gdy CAS stosuje jedną domenę. W praktyce jednak podobną konfigurację możemy osiągnąć w obu systemach, po prostu wprowadzimy ją nieco inaczej. W KeyCloak ustawienie takie jak: źródła podmiotów logowania dostarczające informacji o użytkownikach (zwane federacjami), ustawienia wyglądu okien logowania, przekazywanie uwierzytelnienia do zewnętrznych systemów, ustawienia zaawansowanych zabezpieczeń, przepływów procesu logowania, opcje auto rejestracji, akceptacji regulaminów wprowadzamy na poziomie domeny dla całej grupy aplikacji/systemów. Instalacja systemu KeyCloak może jednocześnie obsługiwać wiele takich grup aplikacji poprzez definicję wielu domen (ang. realm). W serwerze CAS natomiast możemy określić podobne ustawienia globalnie przy zachowaniu możliwości wprowadzenia bardzo specyficznej konfiguracji per każdy system kliencki, sprawia to, że CAS jest nieco bardziej elastycznym systemem.

Wspierane protokoły dla Apereo CAS i Keycloak

Zasadniczą kwestią przy wyborze docelowego rozwiązania jest dobór metod komunikacji oraz przepływów uwierzytelnienia, czyli wybór wykorzystywanych przez system i nasze aplikacje protokołów. Oczywiście wybór może być podyktowany naszą aktualną sytuacją. Jeśli posiadamy już działające aplikacje, ich aktualna konfiguracja może wymuszać na nas wybór konkretnego protokołu. Jeśli aplikacje nie stawiają nam jednoznacznych wymagań i dopiero budujemy cały podsystem uwierzytelniania, na nasz wybór może mogą mieć wpływ dodatkowe wymagania, np. konieczność zarówno podpisywania, jak i szyfrowania danych przekazywanych w procesach uwierzytelnienia i autoryzacji, a także konieczność dodatkowego nadawania uprawnień w procesie uwierzytelnienia lub przekazywania rozbudowanego zakresu danych pobieranych ze źródła tożsamości.

W przypadku systemów KeyCloak/RedHat SSO oficjalnie wspierane są protokoły OpenID Connect (będący rozszerzeniem protokołu OAuth 2.0) oraz SAML 2.0. W przypadku CAS możemy przygotować kompilację systemu obsługującą jeden lub więcej ze wskazanej grupy protokołów: natywny protokół CAS, OpenID Connect/OpenID/OAuth 2, SAML i SAML 2.0, WS Federation.

Porównując obie listy, może wydawać się, że CAS zapewnia szersze wsparcie, jednakże musimy pamiętać, że funkcjonalności KeyCloak mogą być rozbudowywane przez system wtyczek. Decyzja o skupieniu się na pełnym wsparciu jedynie dwóch protokołów jest bardzo racjonalnym podejściem podyktowanym także świadczeniem komercyjnego wsparcia dla produktu przez firmę Red Hat. Społeczność użytkowników systemu KeyCloak wypełnia luki, jakich nie mogą wypełnić oficjalni developerzy. Przykładem takich rozwiązań może być implementacja protokołu CAS dla KeyCloak: https://github.com/Doccrazy/keycloak-protocol-cas, czy też implementacja protokołu WS-Federation dla KeyCloak: https://github.com/cloudtrust/keycloak-wsfed.

Warto przy tej okazji zwrócić uwagę na fakt, że implementacje poszczególnych protokołów z wyjątkiem protokołów natywnych dla obu systemów mogą nie być pełne, np. w przypadku protokołu OpenID Connect dla CAS implementowane są jedynie przepływy Authorization Code Flow oraz Implicit Flow. Oznacza to, że jeśli zdecydujemy się na wdrożenie wsparcia dla protokołów innych niż natywne, nasz projekt powinniśmy rozpocząć od wykonania Proof Of Concept sprawdzającego, czy implementacje poszczególnych funkcji i przebiegów protokołów są zgodne z naszymi oczekiwaniami i wystarczające w naszej sytuacji.

Integracja aplikacji klienckich

Jeśli budujemy aplikacje, które później chcemy integrować z naszym systemem uwierzytelniania, ważną kwestią jest bezpośrednie wsparcie i dostępność bibliotek klienckich dla wykorzystywanych przez nas technologii programistycznych czy wdrożeniowych. Dostępność takich bibliotek przyśpieszy proces integracji naszych aplikacji z systemem SSO, pozwalając programistom skupić się na implementacji funkcji biznesowych, a nie samych protokołów uwierzytelnienia i autoryzacji.

W przypadku oficjalnie wspieranego przez firmę Red Hat systemu SSO możemy liczyć na dostępność bibliotek klienckich i adapterów technologicznych dla: JBoss EAP 6.0 i 7.0, Fuse, JavaScript czy Node.js. Dodatkowo projekt KeyCloak dostarcza biblioteki dla: WidlFly od wersji 9 do 14 oraz kontenerów servletów Jetty i Tomcat. Nie powinniśmy mieć też problemu ze znalezieniem bibliotek dla protokołów OpenIDC i/lub SAML 2.0 dla każdej popularnej technologi czy szkieletu programistycznego. W przypadku systemu CAS i jego natywnego protokołu znajdziemy biblioteki klienckie .NET, Java, PHP. Ponadto możemy się spodziewać wsparcia dla protokołu CAS w szkieletach programistycznych takich jak Spring Security, Apache Shiro, Pac4J.

Znaczącą w procesie adaptacji rozwiązań będą miały także praktyczne przykłady działających aplikacji pozwalające nie tylko na poznanie technologii przez naszych programistów, ale także na przetestowanie poprawności konfiguracji systemów SSO przez naszych administratorów. W przypadku Red Hat SSO przykładowe aplikacje znajdziemy w repozytorium https://github.com/redhat-developer/redhat-sso-quickstarts. Należy zaznaczyć, że w osobnym branchu repozytorium znajdziemy aplikacje przystosowane do wdrożenia w systemie orkiestracji konteneryzacji OpenShift. Dla KeyCloak jeszcze większą ilość przykładów znajdziemy w repozytorium: https://github.com/keycloak/keycloak-quickstarts. W przypadku CAS listę przykładowych aplikacji znajdziemy, odwiedzając repozytoria zgromadzone pod adresem: https://github.com/cas-projects – lista dostępnych dla CAS przykładowych aplikacji jest jednak znacznie uboższa niż w przypadku Red Hat SSO czy KeyCloak.

W drugiej części artykułu przedstawię porównanie funkcjonalności zapewniających integrację z bazami usług katalogowych, delegowaniem autoryzacji do systemów zewnętrznych czy też mechanizmów dostosowywania wyglądu okien logowania. Zaprezentuję także zbiorcze porównanie zaawansowanych funkcji obu systemów SSO. Na koniec, co oczywiste, postaram się także „udzielić odpowiedzi” na zadane w tytule artykułu pytanie.

Źródła:
https://apereo.github.io/cas/6.0.x/index.html
https://www.apereo.org/
https://www.keycloak.org/documentation.html
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/