Uwierzytelnianie dwuskładnikowe w SSO: KeyCloak oraz Apereo CAS
Podziel się

W artykule prezentujemy wybrane możliwości konfiguracyjne uwierzytelniania dwuskładnikowego w dwóch systemach SSO: Apereo CAS oraz KeyCloak przy użyciu odmiennych mechanizmów 2FA.

O rozwiązaniach Apereo CAS i KeyCloak pisaliśmy szerzej na naszym blogu. Polecamy artykuły:

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

oraz

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

MFA/2FA

Uwierzytelnianie wieloskładnikowe staje się powoli standardem bezpiecznego uwierzytelniania użytkownika w wielu miejscach, do których dostęp jest szeroko otwarty (czyli różne usługi publiczne), jak również „zamknięty” (czyli dedykowany rozwiązaniom dla wąskich grup biznesowych).

Oba omawiane rozwiązania SSO wspierają standard 2FA, a Apereo CAS wspiera także MFA. System KeyCloak posiada wsparcie dla Google Authenticator lub FreeOTP. W CAS możliwe są konfiguracje wspierające mechanizmy Duo Secuirty, Authy Authenticator, Google Authenticator, YubiKey czy Fido U2F. Pełna lista wspieranych dostawców jest dostępna na stronach:

Supported Providers

OTP Policies

2FA

Czyli uwierzytelnianie dwuskładnikowe, to dość często używany przypadek uwierzytelniania wieloskładnikowego. 

W poniższym przeglądzie przejrzymy tego typu rozwiązanie/autentykację na przykładzie implementacji simple-mfa z użyciem email w systemie CAS oraz na przykładzie implementacji Aplikacji mobilnych do uwierzytelniania w systemie KeyCloak.

simple-mfa @cas

Dostawca simple-mfa dedykowany jest do prostych kanałów komunikacji, takich jak email lub wiadomości tekstowe. W tym rozwiązaniu CAS działa jako dostawca uwierzytelniania wieloskładnikowego, samodzielnie wystawiając tokeny autentykujące i wysyłając je do użytkowników końcowych za pośrednictwem wstępnie zdefiniowanych kanałów komunikacji.

Tokeny autentykujące wydane przez CAS są śledzone za pomocą wewnętrznego rejestru biletów i przypisywane są do nich konfigurowalne zasady wygaśnięcia kontrolowane przez ustawienia CAS.

Włączenie tej funkcjonalności sprowadza się do zawarcia modułu w liście zależności dla kompilacji CAS:

dependencies { 
implementation "org.apereo.cas:cas-server-support-simple-mfa:${casServerVersion}" 
}

oraz ustawienia wartości kluczy właściwości:

# CAS MFA settings 
cas.authn.mfa.provider-selection-enabled=true 
cas.authn.mfa.globalProviderId=mfa-simple 

# MFA Simple 
cas.authn.mfa.simple.name=mfa-simple 
cas.authn.mfa.simple.order=1 
cas.authn.mfa.simple.timeToKillInSeconds=30 
cas.authn.mfa.simple.tokenLength=3

Taka minimalna konfiguracja pozwoli na poprawne skompilowanie aplikacji oraz uruchomienie jej w kontenerze Tomcat. Pozwoli także na wyświetlenie obu etapów logowania, czyli użycie loginu i hasła jako etapu pierwszego:

oraz wprowadzenie wygenerowanego tokenu autentykującego, czyli etapu drugiego:

Jak zademonstrowane jest na powyższej wizualizacji, wraz z samą funkcjonalnością generowania tokenu autentykującego tożsamość, dostajemy “niejako z pudełka” opcje ponownego wygenerowania tokenu autentykującego.

Opisany token autentykujący nie jest skomplikowany i ma dość prostą formę. Składa się ze stałej część “CASMFA-”, która nie jest konfigurowalna oraz dodatkowej części losowej o długości definiowanej w ustawieniu cas.authn.mfa.simple.tokenLength.

Wiadomość email, która jest wysyłana do użytkownika, jest w pełni konfigurowalna. Przykładowo może wyglądać w następujący sposób:

Za wysyłkę wiadomości email odpowiada wbudowany wewnętrzny moduł Spring framework, który jest skonfigurowany globalnie. Natomiast ustawienia dotyczące samej wiadomości email są definiowane przez administratora aplikacji w następujących kluczach właściwości:

# Email MFA 
cas.authn.mfa.simple.mail.from=mfa@mockmock.jar 
cas.authn.mfa.simple.mail.text=Twój dwuetapowy kod bezpieczeństwa to <h4>%s</h4> 
cas.authn.mfa.simple.mail.subject=Logowanie dwuetapowe 
cas.authn.mfa.simple.mail.cc= 
cas.authn.mfa.simple.mail.bcc= 
cas.authn.mfa.simple.mail.replyTo= 
cas.authn.mfa.simple.mail.validateAddresses=false 
cas.authn.mfa.simple.mail.html=true 
cas.authn.mfa.simple.mail.attributeName=mail

Urządzenia zaufane

Wraz z włączeniem Uwierzytelniania dwuskładnikowego możliwe jest dodanie użytkownikom końcowym ułatwienia w pracy z aplikacjami wykorzystującymi system CAS poprzez dodawanie używanych urządzeń/przeglądarek do puli zaufanych dla danego użytkownika. Rozwiązanie to — jeśli pozwala na to wymagany poziom zabezpieczeń stosowany w organizacji, po pierwszym poprawnym użyciu danego urządzenia w trakcie uwierzytelniania dwuskładnikowego, wyświetli monit o dodanie (i nazwanie) aktualnego urządzenie do puli zaufanych:

Podobnie jak z dodaniem simple-mfa do kompilacji, włączenie funkcjonalności urządzeń zaufanych sprowadza się do zawarcia modułu w liście zależności:

dependencies { 
implementation "org.apereo.cas:cas-server-support-trusted-mfa:${casServerVersion}" 
} 

oraz skonfigurowaniu kluczy ustawień:

# MFA Trusted Device/Browser 
cas.authn.mfa.trusted.authenticationContextAttribute=isFromTrustedMultifactorAuthentication 

cas.authn.mfa.trusted.deviceRegistrationEnabled=true 
cas.authn.mfa.trusted.expiration=30 
cas.authn.mfa.trusted.timeUnit=DAYS 
#

Przegląd i usuwanie aktywnych, a także zarejestrowanych urządzeń jest możliwy przez punkt administracyjny RESTAPI multifactorTrustedDevices.

Pełny opis tego punktu administracyjnego jest dostępny pod adresem Administrative Endpoints.

Przykładowa struktura JSON dla zarejestrowanego urządzenia, która została pobrana przez wywołanie GET.

app @keycloak

Implementacja 2FA w systemie KeyCloak jest oparta o Zasady OTP (hasło jednorazowe), które szczegółowo jest opisane w dokumentacji pod tym adresem. Standardowo, zasady te są dostępne w podstawowej instalacji i nie wymagają instalowania dodatkowych pakietów.

Domyślnie, każda tworzona Domena bezpieczeństwa (Realm) będzie miała włączone 2FA oraz opcjonalną możliwość korzystania z tej funkcjonalności. Oznacza to, że każdy dodany użytkownik do takiej Domeny bezpieczeństwa, będzie mógł sobie skonfigurować klienta do takiego uwierzytelniania — opcjonalnie.

Wymuszenie używania tej funkcjonalności przez użytkowników sprowadza się do włączenia Akcji domyślnej w wierszu Konfiguracji OTP na zakładce Wymagane działania dostępnej w sekcji Uwierzytelnianie.

Dodatkowo, jeśli w konfigurowanej Domenie bezpieczeństwa są już założone konta użytkowników, każdemu z nich należy dodać wymuszenie używania 2FA. Wymuszenie to ustawiamy przez wybranie pozycji Konfiguracja OTP z listy Wymagane działania użytkownika na zakładce Szczegóły dla wybranego użytkownika z listy dostępnej w sekcji Użytkownicy.

Jest to wymagane, aby 2FA było wykorzystywane przez wszystkich istniejących użytkowników w systemie.

Konfiguracja zasad OTP

Domyślna konfiguracja zasad OTP w większości przypadków jest wystarczająca a predefiniowany wybór typu, oparty na czasie (TOTP) jest uważany za bardziej bezpieczny od HOTP. Niemniej jednak TOTP wymaga „synchronizacji” czasu między serwerem Keycloaka a urządzeniem użytkownika końcowego. Może to czasami powodować problemy z poprawnością wygenerowanego kodu (error=expired_code). W takim przypadku należy dopasować wartość dodatkowego okna czasu [mnożnik] na zakładce zasady OTP dostępnej w sekcji uwierzytelnianie.

Dodawanie urządzenia uwierzytelniającego użytkownika

Po włączeniu i ustawieniu wszystkich potrzebnych parametrów serwera Keycloak, przy kolejnych sesjach użytkowników pojawią się monity po zakończeniu uwierzytelniania nazwy użytkownika za pomocą hasła. Użytkownik będzie zmuszony skonfigurować aplikację uwierzytelniającą na smartphonie (lub innym urządzeniu mobilnym) przy pomocy wygenerowanego kodu QR:

Po zeskanowaniu aplikacją uwierzytelniającą FreeOTP wyświetlonego kodu QR serwer autentykacji zostanie automatycznie dodany do listy w aplikacji i rozpocznie się generowanie kodów jednorazowych „spiętych” z serwerem autentykacji Keycloak.

Wprowadzony kod z generatora FreeOTP pozwoli na zalogowanie się do serwera autentykacji i przegląd informacji użytkownika. Opcjonalnie wprowadzona nazwa identyfikująca urządzenie/aplikację uwierzytelniającą ułatwi w przyszłości zarządzanie urządzeniami 2FA.

Podsumowanie

Celem artykułu było zaprezentowanie wybranych możliwości konfiguracyjnych uwierzytelniania dwuskładnikowego w dwóch systemach SSO: Apereo CAS oraz KeyCloak przy użyciu odmiennych mechanizmów 2FA.

Porównanie obu systemów zostało sporządzone i przestawione w wymienionych na wstępie artykułach. I tak cytując autora wybór MFA/2FA jest zależny od potrzeb i możliwości:

„[…] 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. […]”

! Do celów developerskich przy testowaniu konfiguracji KeyCloak w ramach OTP, można użyć otwarto-źródłowego projektu GAuth Authenticator dostępnego w formie strony internetowej.

Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments

    Skontaktuj się z nami