Marceli Formela, Autor w serwisie Inero Software - Rozwiązania IT i Konsulting https://inero-software.com/pl/author/marceli-formela/ Tworzymy cyfrowe innowacje Fri, 21 Mar 2025 11:25:52 +0000 pl-PL hourly 1 https://wordpress.org/?v=6.9.1 https://inero-software.com/wp-content/uploads/2018/11/inero-logo-favicon.png Marceli Formela, Autor w serwisie Inero Software - Rozwiązania IT i Konsulting https://inero-software.com/pl/author/marceli-formela/ 32 32 153509928 Konfiguracja polityki haseł w Keycloak https://inero-software.com/pl/konfiguracja-polityki-hasel-w-keycloak/ Fri, 21 Mar 2025 11:14:52 +0000 https://inero-software.com/?p=7653 W tym artykule najpierw przyjrzymy się wbudowanym mechanizmom zarządzania polityką haseł w Keycloak. Następnie omówimy możliwości ich dostosowania do specyficznych wymagań.

Artykuł Konfiguracja polityki haseł w Keycloak pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>

Skuteczne zarządzanie hasłami jest istotnym elementem zabezpieczania kont użytkowników, a Keycloak dostarcza narzędzia do egzekwowania silnych zasad uwierzytelniania. Dzięki konfiguracji reguł haseł administratorzy mogą zadbać o zgodność poświadczeń ze standardami bezpieczeństwa, minimalizując ryzyko nieautoryzowanego dostępu. Platforma oferuje elastyczne opcje, umożliwiające definiowanie wymagań, dotyczących długości i złożoności haseł, ich ważności oraz zapobiegania ponownemu użyciu.

W tym artykule najpierw przyjrzymy się wbudowanym mechanizmom zarządzania polityką haseł w Keycloak. Następnie omówimy możliwości ich dostosowania do specyficznych wymagań.

Wbudowane polityki

Wbudowane polityki haseł w Keycloak umożliwiają administratorom egzekwowanie zasad bezpieczeństwa w celu wzmocnienia uwierzytelniania użytkowników. Poniżej znajduje się krótki opis każdej z nich:

  1. Wygasanie hasła (Expire Password) – Wymusza zmianę hasła po określonym czasie.
  2. Iteracje hashowania (Hashing Iterations) – Określa liczbę iteracji podczas hashowania hasła w celu zwiększenia bezpieczeństwa.
  3. Brak ponownego użycia (Not Recently Used) – Zapobiega ponownemu użyciu ostatnich haseł przez użytkownika.
  4. Czarna lista haseł (Password Blacklist) – Blokuje określone hasła, zwykle słabe lub powszechnie używane.
  5. Wyrażenie regularne (Regular Expression) – Pozwala wymusić niestandardowy wzorzec regex dla walidacji hasła.
  6. Minimalna długość (Minimum Length) – Ustawia minimalną liczbę znaków wymaganą w haśle.
  7. Brak nazwy użytkownika jako hasła (Not Username) – Uniemożliwia ustawienie nazwy użytkownika jako hasła.
  8. Brak adresu e-mail jako hasła (Not Email) – Zapobiega używaniu adresu e-mail jako hasła.
  9. Brak ponownego użycia w określonym czasie (Not Recently Used in Days) – Blokuje ponowne użycie hasła przez określoną liczbę dni.
  10. Nie zawiera nazwy użytkownika (Not Contains Username) – Wymusza, aby hasło nie zawierało nazwy użytkownika.
  11. Znaki specjalne (Special Characters) – Wymaga co najmniej jednego znaku specjalnego w haśle.
  12. Wielkie litery (Uppercase Characters) – Wymusza obecność co najmniej jednej wielkiej litery w haśle.
  13. Małe litery (Lowercase Characters) – Wymaga co najmniej jednej małej litery w haśle.
  14. Cyfry (Digits) – Wymaga co najmniej jednej cyfry w haśle.
  15. Maksymalny czas ważności uwierzytelnienia (Maximum Authentication Age) – Określa maksymalny czas ważności sesji przed wymuszeniem ponownego logowania.
  16. Algorytm hashowania (Hashing Algorithm) – Określa algorytm używany do szyfrowania haseł.
  17. Maksymalna długość (Maximum Length) – Definiuje maksymalną dopuszczalną długość hasła.

Implementacja niestandardowej polityki haseł przy użyciu SPI

Aby zaimplementować niestandardową politykę haseł w Keycloak, należy użyć interfejsu dostawcy usług (SPI – Service Provider Interface).

W tym przypadku definiujemy niestandardowego dostawcę polityki haseł, implementując interfejs PasswordPolicyProviderFactory.

				
					public class PasswordCustomPolicyProviderFactory implements PasswordPolicyProviderFactory {

	public static final Integer DEFAULT_VALUE = 1;
	public static final String MIN_PASSWORD_LIFETIME_ID = "minimumPasswordLifetime";

	@Override
	public String getId() {
    	return MIN_PASSWORD_LIFETIME_ID;
	}

	@Override
	public PasswordPolicyProvider create(KeycloakSession session) {
    	return new PasswordCustomPolicyProvider(session);
	}
[...]
}

Factory instancjonuje i zwraca nową instancję PasswordCustomPolicyProvider, która zawiera logikę walidacji wymuszającą minimalny czas życia hasła. Stała MIN_PASSWORD_LIFETIME_ID pełni rolę unikalnego identyfikatora tej niestandardowej polityki, a stała DEFAULT_VALUE określa domyślny minimalny czas życia hasła (w dniach), jeśli nie zostanie skonfigurowana inna wartość w Admin Console.

				
					public class PasswordCustomPolicyProvider implements PasswordPolicyProvider {
np.
   private static final String POLICY_VIOLATION_MESSAGE = "passwordLifetimeViolation";


   private final KeycloakSession keycloakSession;

   public PasswordCustomPolicyProvider(KeycloakSession keycloakSession) {
   	this.keycloakSession = keycloakSession;
   }


   @Override
   public PolicyError validate(RealmModel realm, UserModel user, String password) {
   	PasswordCredentialProvider credentialProvider = new PasswordCredentialProvider(keycloakSession);
   	PasswordCredentialModel credentialModel = credentialProvider.getPassword(realm, user);

   	if (credentialModel == null) {
       	return null;
   	}

   	long passwordCreationTime = credentialModel.getCreatedDate();
   	long currentTime = Time.currentTimeMillis();
   	long elapsedTime = currentTime - passwordCreationTime;

   	PasswordPolicy passwordPolicy = realm.getPasswordPolicy();
   	int minPasswordLifetimeDays = passwordPolicy.getPolicyConfig(PasswordCustomPolicyProviderFactory.MIN_PASSWORD_LIFETIME_ID);
   	long minPasswordLifetimeMillis = TimeUnit.DAYS.toMillis(minPasswordLifetimeDays);
   	return elapsedTime >= minPasswordLifetimeMillis ? null : new PolicyError(POLICY_VIOLATION_MESSAGE, minPasswordLifetimeDays);
   }
[...]
}

PasswordCredentialProvider może uzyskać dostęp do zapisanego znacznika czasu utworzenia hasła za pośrednictwem instancji PasswordCredentialModel. Następnie oblicza elapsedTime jako różnicę między tym znacznikiem a bieżącym czasem systemowym, co określa, jak długo hasło jest już używane.

Następnie obiekt PasswordPolicy pobiera politykę haseł dla danego realm’u, wyodrębnia minimalny wymagany czas życia hasła w dniach (minPasswordLifetimeDays) i przelicza go na milisekundy (minPasswordLifetimeMillis). Polityka ta zapewnia, że hasło było używane przez co najmniej wymagany okres. Jeśli warunek ten nie zostanie spełniony, zwracany jest obiekt PolicyError. Klucz wiadomości o błędzie jest zapisany w stałej POLICY_VIOLATION_MESSAGE, a jego treść może być dostosowana w naszym motywie. Pozwala to na zdefiniowanie przyjaznego komunikatu, który informuje użytkownika, dlaczego zmiana hasła jest niedostępna i ile czasu pozostało do możliwości ustawienia nowego.

W ten sposób możemy definiować niestandardowe polityki haseł w Keycloak, gdy domyślny zestaw polityk okazuje się niewystarczający dla konkretnych wymagań. Taka elastyczność umożliwia bardziej szczegółową kontrolę nad uwierzytelnianiem użytkowników i zarządzaniem hasłami, gdy zachodzi taka potrzeba.

Dostosowanie interfejsu w celu poprawy UX

Domyślnie Keycloak wyświetla niespełnione polityki haseł osobno na stronie logowania. Może to być problematyczne dla wielu użytkowników, zwłaszcza gdy naruszonych jest kilka zasad jednocześnie. Prowadzi to do przeładowanego interfejsu i utrudnia użytkownikom zrozumienie wszystkich wymagań dotyczących hasła. Aby temu zaradzić, można dostosować ekran logowania tak, aby prezentował zbiorczą listę wszystkich niespełnionych polityk haseł, co zapewni bardziej przejrzyste i przyjazne dla użytkownika doświadczenie.

				
					public class CustomFreeMarkerLoginFormsProvider extends FreeMarkerLoginFormsProvider {
/**
* Mapping between password policy provider IDs and custom messages
* Note: contains only standard policies that must be displayed in the UI
*/
private final Map<String, String> policyPropertyMessages = Map.of(
LengthPasswordPolicyProviderFactory.ID, MINIMUM_LENGTH_MESSAGE,
MaximumLengthPasswordPolicyProviderFactory.ID, MAXIMUM_LENGTH_MESSAGE,
DigitsPasswordPolicyProviderFactory.ID, MINIMUM_DIGIT_MESSAGE,
SpecialCharsPasswordPolicyProviderFactory.ID, MINIMUM_SPECIAL_CHAR_MESSAGE,
UpperCasePasswordPolicyProviderFactory.ID, MINIMUM_UPPERCASE_MESSAGE,
LowerCasePasswordPolicyProviderFactory.ID, MINIMUM_LOWERCASE_MESSAGE,
NotUsernamePasswordPolicyProviderFactory.ID, NOT_USERNAME_MESSAGE,
NotContainsUsernamePasswordPolicyProviderFactory.ID, NOT_CONTAINS_USERNAME_MESSAGE,
NotEmailPasswordPolicyProviderFactory.ID, NOT_EMAIL_MESSAGE
);

[...]

@Override
protected void createCommonAttributes(Theme theme, Locale locale, Properties messagesBundle,
UriBuilder baseUriBuilder, LoginFormsPages page) {
super.createCommonAttributes(theme, locale, messagesBundle, baseUriBuilder, page);
if (realm != null && realm.getPasswordPolicy() != null) {
attributes.put("passwordPolicies", getPasswordPolicyMessages(realm.getPasswordPolicy(), messagesBundle));
}}

[...]

private Map<String, String> getPasswordPolicyMessages(PasswordPolicy passwordPolicy, Properties messagesBundle) {
Map<String, String> policyMessages = new HashMap<>();
PasswordPolicy.Builder builder = passwordPolicy.toBuilder();
for (String policyName : passwordPolicy.getPolicies()) {
var value = builder.get(policyName);
String message = extractPolicyMessage(policyName, value, messagesBundle);
if (message != null) {
policyMessages.put(policyName, message);
}
}
return policyMessages;
}

[...]

/**
* Extracts a message for a given password policy from the messages bundle
* Note: Policy message is constructed by replacing the {0} placeholder with the policy value
*/
private String extractPolicyMessage(String policy, String value, Properties messagesBundle) {
String property = policyPropertyMessages.get(policy);
if (property == null) {
return null;
}
String policyMessage = messagesBundle.getProperty(property);
return policyMessage != null ? policyMessage.replace("{0}", value) : null;
}

Funkcja getPasswordPolicyMessages() już zbiera polityki haseł z obiektu PasswordPolicy i mapuje je na odpowiednie komunikaty z pliku wiadomości (message bundle). Można ją rozszerzyć tak, aby wyświetlała wszystkie niespełnione zasady w jednej zbiorczej wiadomości.

Polityki haseł, takie jak minimalna długość, wymagane cyfry, znaki specjalne itp., są mapowane na komunikaty za pomocą metody extractPolicyMessage(). Nasza implementacja serwisu przechodzi przez każdą z zasad i sprawdza, czy jest spełniona. Jeśli nie – wyświetlany jest odpowiadający jej komunikat.

Na stronie update-password.ftl możesz zaprezentować te niespełnione zasady jako listę przy użyciu szablonów FreeMarker.

				
					
    	<#if passwordPolicies?has_content>
        	<div class="${properties.kcAlertClass}">
            	<div class="${properties.kcAlertIconWrapperClass}">
                	<span class="${properties.kcAlertIconClass}"></span>
            	</div>
            	<span class="${properties.kcAlertTitleClass}">
            	${msg("passwordInstruction")} <br>
            	<#list passwordPolicies?keys as key>
                	<span class="${properties.kcAlertTitleClass}">&#x2022; ${passwordPolicies[key]}</span><br/>
            	</#list>
            	</span>
        	</div>
    	</#if>

Praktyczne przykłady polityk haseł

Zobaczmy, jak wyglądają polityki haseł w dużych firmach.

 

Apple wymaga, aby hasła miały co najmniej osiem znaków i zawierały zarówno litery, jak i cyfry. Dodatkowo, hasła nie mogą zawierać trzech lub więcej identycznych znaków pod rząd i nie mogą być powszechnie używanymi hasłami.

 

Facebook narzuca minimalną długość hasła wynoszącą ponad sześć znaków, choć zaleca stosowanie dłuższych haseł. Choć Meta nie wymaga użycia znaków specjalnych ani cyfr, zachęca do tworzenia złożonych haseł.

 

Microsoft wymaga, aby hasła miały co najmniej 8 znaków i zawierały co najmniej dwa z następujących typów znaków: wielkie litery, małe litery, cyfry lub symbole. Dodatkowo, system może blokować możliwość ustawienia hasła zbyt podobnego do poprzedniego.

 

Chociaż firmy te korzystają z różnych narzędzi uwierzytelniania, warto zwrócić uwagę na standardy bezpieczeństwa wdrażane w dużych systemach produkcyjnych.

 

I mimo że te polityki haseł nie są skrajnie restrykcyjne, użytkownicy powinni unikać wykorzystywania w hasłach wrażliwych danych osobowych, takich jak imiona, daty urodzenia czy numery telefonów. Należy również unikać ponownego używania haseł w różnych usługach, ponieważ może to prowadzić do naruszeń bezpieczeństwa w przypadku przejęcia jednego z kont. Włączenie uwierzytelniania dwuskładnikowego (2FA) i okresowy przegląd bezpieczeństwa haseł to kolejne kroki, które użytkownicy mogą podjąć w celu zwiększenia ochrony.

Podsumowanie

Jak widać, Keycloak oferuje zestaw domyślnych polityk haseł, które obejmują standardowe zasady bezpieczeństwa, takie jak minimalna długość, wymagania dotyczące złożoności czy historia użycia haseł. Wbudowane polityki są wystarczające w wielu przypadkach, jednak w razie potrzeby istnieje możliwość ich dostosowania do konkretnych wymagań organizacyjnych. Keycloak pozwala również na tworzenie własnych polityk haseł, co daje większą kontrolę nad bezpieczeństwem.

 

Oprócz modyfikacji samych zasad, Keycloak umożliwia także dostosowanie interfejsu użytkownika. Jest to szczególnie przydatne w sytuacjach, gdy domyślny sposób prezentowania naruszeń polityk haseł — np. wyświetlanie niespełnionych wymagań osobno — nie spełnia naszych oczekiwań. W takich przypadkach możemy zmienić sposób prezentacji błędów lub wzbogacić komunikaty o dodatkowe informacje, aby były bardziej czytelne i zrozumiałe dla użytkownika.

 

Dzięki tym możliwościom Keycloak pokazuje wysoki poziom elastyczności, umożliwiając pełną kontrolę zarówno nad politykami bezpieczeństwa, jak i nad wyglądem interfejsu. Czyni go to uniwersalnym rozwiązaniem do zarządzania tożsamością i dostępem. Możliwość definiowania własnych reguł i dostosowywania komponentów sprawia, że Keycloak to skalowalne narzędzie, które z łatwością można dopasować do indywidualnych potrzeb organizacji.

Artykuł Konfiguracja polityki haseł w Keycloak pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 7653 Konfiguracja logowania bezhasłowego za pomocą Passkey na urządzeniu mobilnym https://inero-software.com/pl/konfiguracja-logowania-bezhaslowego-za-pomoca-passkey-na-urzadzeniu-mobilnym/ Wed, 12 Mar 2025 09:02:00 +0000 https://inero-software.com/?p=7555 Ten wpis omawia konfiguracji Passkeys dla urządzeń mobilnych, zapewniając płynne i bezpieczne logowanie bez użycia hasła.

Artykuł Konfiguracja logowania bezhasłowego za pomocą Passkey na urządzeniu mobilnym pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>

Nasz pierwszy wpis na temat Passkeys w Keycloak znajdziesz tu: Wprowadzenie do Passkeys w Keycloak

W naszym poprzednim wpisie pokazaliśmy, jak skonfigurować Passkeys w Keycloak, zastępując tradycyjne hasła uwierzytelnianiem opartym na WebAuthn. Omówiliśmy proces konfiguracji, kluczowe zalety oraz potencjalne ograniczenia. Ten wpis koncentruje się na konfiguracji Passkeys  dla urządzeń mobilnych, zapewniając płynne i bezpieczne logowanie bez hasła.

W tym wpisie ponownie omówimy konfigurację uwierzytelniania za pomocą Passkey w Keycloak, jednak tym razem wykorzystamy więcej niż jedno urządzenie.

Korzystanie z Passkey przechowywanego na telefonie

Podczas logowania na innym urządzeniu, takim jak laptop lub komputer stacjonarny, użytkownicy mogą uwierzytelnić się za pomocą Passkey przechowywanego na telefonie. Proces ten przebiega następująco:

  1. Wybór logowania za pomocą Passkey

    Zamiast wprowadzać hasło, użytkownik wybiera opcję uwierzytelniania za pomocą Passkey. Przeglądarka na laptopie generuje żądanie uwierzytelnienia. Następnie należy nawiązać bezpieczne połączenie między telefonem (np. iPhone) a laptopem.

  2. Skanowanie kodu QR

    Interfejs logowania generuje kod QR, który użytkownik skanuje aparatem telefonu. Laptop wysyła następnie kryptograficzne wyzwanie do telefonu, prosząc o podpisanie żądania za pomocą przechowywanego Passkey. Telefon komunikuje się z laptopem w sposób bezpieczny, wykorzystując Bluetooth lub inne protokoły łączności bliskiego zasięgu (np. NFC).

  3. Potwierdzenie tożsamości

    Po otrzymaniu wyzwania telefon prosi użytkownika o uwierzytelnienie biometryczne (np. Face ID lub Touch ID). Dzięki temu weryfikuje, czy osoba próbująca się zalogować jest uprawnionym użytkownikiem.

  4. Bezpieczne uwierzytelnienie

    Laptop sprawdza odpowiedź telefonu, weryfikując podpis kryptograficzny względem klucza publicznego zarejestrowanego w usłudze. Jeśli weryfikacja przebiegnie pomyślnie, użytkownik zostaje zalogowany bez konieczności wprowadzania hasła.

Krok po kroku: Konfiguracja Passkey za pomocą smartfona

Zanim przejdziemy do niestandardowego procesu uwierzytelniania, należy upewnić się, że w danym realmie jest włączona wymagana akcja WebAuthn Register Passwordless (Authentication → zakładka Required Actions).

Dzięki temu możemy na przykład wymusić konfigurację Passkey przez użytkowników po ich następnym pomyślnym logowaniu. Należy jednak pamiętać, że jest to tylko jedna z wielu metod konfigurowania uwierzytelniania wieloskładnikowego.

Gdy potwierdzimy, że ta opcja jest aktywna, możemy przejść do konfiguracji procesu uwierzytelniania.

Ten niestandardowy proces uwierzytelniania w Keycloak został zaprojektowany tak, aby pokazać, jak użytkownicy mogą wybierać między uwierzytelnianiem opartym na haśle a uwierzytelnianiem za pomocą Passkey (WebAuthn) podczas logowania. Oto jak to działa:

    • Użytkownicy muszą podać swoją nazwę użytkownika, aby kontynuować proces uwierzytelniania.
    • Ten krok wymusza uwierzytelnienie, jednak użytkownicy mogą wybrać między logowaniem opartym na haśle a logowaniem za pomocą Passkey.
    • Jeśli użytkownik wybierze uwierzytelnianie hasłem, wprowadza swoje dane logowania.
    • Jeśli preferuje logowanie bezhasłowe przy użyciu Passkey, może uwierzytelnić się tą metodą zamiast hasła.

Na tym etapie użytkownicy mogą wprowadzić swoją nazwę użytkownika lub adres e-mail, aby kontynuować proces uwierzytelniania. Jest to krok wymagany, który zapewnia, że system identyfikuje użytkownika przed udostępnieniem opcji uwierzytelniania.

Na tym etapie możliwe jest jedynie uwierzytelnianie za pomocą hasła, ponieważ Passkey (WebAuthn) nie został jeszcze skonfigurowany. Po jego ustawieniu użytkownicy będą mieli możliwość wyboru między uwierzytelnianiem opartym na haśle a logowaniem bezhasłowym.

Zamiast rejestrowania kodu PIN urządzenia, jak wspomniano wcześniej, w tym przykładzie użyjemy uwierzytelniania za pomocą telefonu, konkretnie iPhone’a.

Teraz powinien pojawić się kod QR, umożliwiający rejestrację Passkey na naszym koncie. Zeskanujmy go za pomocą aparatu w telefonie i zweryfikujmy operację, na przykład przy użyciu Face ID.

Teraz nasz Passkey powinien być widoczny w sekcji Credentials.

Podczas następnego logowania powinna pojawić się opcja wyboru między uwierzytelnianiem za pomocą hasła a uwierzytelnianiem za pomocą Passkey.

 

To rozwiązanie zwiększa wygodę użytkowników, umożliwiając im wybór preferowanej metody uwierzytelniania. Passkeys zapewniają bezpieczniejsze i odporne na phishing logowanie, podczas gdy hasła pozostają dostępne dla tych, którzy preferują tradycyjne metody. Dzięki tej elastyczności można zagwarantować zarówno bezpieczeństwo, jak i łatwy dostęp, dostosowany do różnych preferencji użytkowników.

 

Warto pamiętać, że tradycyjne hasła stanowią słabe ogniwo w bezpieczeństwie cyfrowym i często są narażone na ataki związane z ich ponownym użyciem, phishingiem lub wyciekami danych. Passkeys oferują nowoczesną metodę uwierzytelniania bez hasła, zwiększającą zarówno bezpieczeństwo, jak i wygodę użytkowania dzięki wykorzystaniu kryptograficznych par kluczy zarządzanych przez platformowe mechanizmy uwierzytelniania. Zapewniają odporność na phishing, płynny dostęp na różnych urządzeniach oraz zgodność ze standardami uwierzytelniania wieloskładnikowego (MFA).

Najlepsze praktyki w Keycloak

Przeczytaj

Artykuł Konfiguracja logowania bezhasłowego za pomocą Passkey na urządzeniu mobilnym pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 7555 Wprowadzenie do Passkey w Keycloak https://inero-software.com/pl/wprowadzenie-do-passkey-w-keycloak/ Wed, 26 Feb 2025 08:54:28 +0000 https://inero-software.com/?p=7441 W tym wpisie pokażemy, jak skonfigurować Passkeys w Keycloak.

Artykuł Wprowadzenie do Passkey w Keycloak pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>

Tradycyjne hasła od dawna stanowią słaby punkt zabezpieczeń cyfrowych. Często te same hasła są wykorzystywane w wielu miejscach, co zwiększa ryzyko ich przejęcia i ułatwia ataki phishingowe. Passkeys to nowoczesne rozwiązanie, które zastępuje hasła kryptograficznymi parami kluczy przypisanymi do konkretnej aplikacji i zarządzanymi przez mechanizmy wbudowane w platformę. Dzięki wykorzystaniu wielu czynników weryfikacyjnych spełniają wymagania MFA (wieloskładnikowego uwierzytelniania) i są zgodne z powszechnie stosowanymi standardami.

W tym wpisie pokażemy, jak skonfigurować Passkeys na podstawie ustawień Keycloak omówionych we wcześniejszych artykułach (zobacz Zabezpieczanie endpointów Java Spring za pomocą Keycloak lub Praktyczne Keycloak SSO: od konfiguracji do integracji). Choć Passkeys zapewniają wygodne i bezpieczne logowanie, ich wdrożenie w istniejącym systemie może wiązać się z pewnymi wyzwaniami. Przeprowadzimy Cię przez podstawowy proces konfiguracji. Jeśli chcesz unowocześnić swoją strategię zabezpieczeń, to idealne miejsce, by zacząć.

Jak działają Passkeys?

Passkeys to metoda logowania, zaprojektowana jako bezpieczniejsza i wygodniejsza alternatywa dla tradycyjnych haseł. W przeciwieństwie do nich, które mogą zostać wyłudzone, skradzione lub zapomniane, passkeys eliminują te zagrożenia dzięki wykorzystaniu kryptograficznych par kluczy przechowywanych w zaufanym narzędziu uwierzytelniającym, takim jak smartfon, inne urządzenie lub menedżer haseł. Zamiast ręcznie tworzyć i zapamiętywać hasło, użytkownik korzysta z autoryzowanego narzędzia do generowania i zarządzania passkey.

Passkey składa się z dwóch elementów:

    • Klucz publiczny – przechowywany przez aplikację
    • Klucz prywatny – bezpiecznie zapisany w narzędziu uwierzytelniającym użytkownika

Klucz prywatny nigdy nie opuszcza urządzenia, co gwarantuje, że nawet w przypadku naruszenia klucza publicznego konta pozostają bezpieczne.

  1. Podczas logowania aplikacja wysyła wyzwanie do narzędzia uwierzytelniającego.
  2. Użytkownik potwierdza swoją tożsamość za pomocą biometrii (Face ID, Touch ID), kodu PIN lub hasła.
  3. Narzędzie uwierzytelniające podpisuje wyzwanie kluczem prywatnym i odsyła je do weryfikacji.
  4. Jeśli podpis jest poprawny, dostęp zostaje przyznany – bez konieczności używania hasła.

Zalety Passkeys

    • W przeciwieństwie do haseł, passkeys nie mogą zostać skradzione w wyniku ataków phishingowych. Są powiązane z konkretną stroną internetową lub aplikacją, co oznacza, że nie zadziałają na fałszywych stronach logowania. Nawet jeśli użytkownik wejdzie na stronę phishingową, nie zostanie poproszony o użycie passkey, a logowanie nie nastąpi, co zapobiega kradzieży danych uwierzytelniających.
    • Użytkownicy nie muszą zarządzać wieloma hasłami do różnych kont – logowanie sprowadza się do użycia biometrii (Face ID, Touch ID) lub kodu PIN urządzenia.
    • Hasła można odgadnąć, ponownie wykorzystać lub wyciekają – passkeys nie. Nawet niektóre metody 2FA, takie jak kody SMS, są podatne na phishing i ataki typu SIM-swapping, podczas gdy passkeys są na nie odporne. Dzięki wykorzystaniu kryptografii klucza publicznego nie mogą zostać przechwycone ani skradzione w wyniku naruszenia danych.
    • Passkeys są przechowywane w platformowych narzędziach uwierzytelniających (np. Google Password Manager, Windows Hello). Mogą być automatycznie synchronizowane między urządzeniami, co zapewnia dostęp bez potrzeby ręcznego przenoszenia kluczy.

Ograniczenia Passkeys

    • Nie wszystkie strony internetowe i aplikacje obsługują passkeys, co oznacza, że użytkownicy mogą nadal musieć polegać na hasłach w niektórych usługach.

    • Utrata dostępu do głównego urządzenia lub konta w chmurze może zablokować użytkownika, wymagając opcji odzyskiwania, takich jak urządzenia zapasowe.

    • Wielu użytkowników nie zna jeszcze passkeys, a przejście z haseł wymaga edukacji.

    • Ponieważ passkeys nie wymagają ręcznego wpisywania, użytkownicy mogą odczuwać brak kontroli nad swoimi danymi logowania w porównaniu do tradycyjnego zarządzania hasłami.

Konfiguracja Passkey dla Realm

Keycloak oferuje elastyczne opcje uwierzytelniania, tradycyjnie opierając się na hasłach i uwierzytelnianiu wieloskładnikowym (MFA) z wykorzystaniem jednorazowych kodów (OTP). Jednak wraz z rosnącą popularnością metod bezhasłowych, Keycloak obsługuje również WebAuthn Passwordless (Passkeys). W tej konfiguracji wyłączymy zarówno hasła, jak i uwierzytelnianie OTP, zapewniając, że użytkownicy mogą logować się wyłącznie za pomocą Passkeys.

Kolejność mechanizmów uwierzytelniania określa przebieg logowania w Keycloak. Pozostawiamy uwierzytelnianie za pomocą plików cookie, aby użytkownicy mogli utrzymywać aktywne sesje. Aby obsłużyć uwierzytelnianie zewnętrzne, włączamy Identity Provider Redirect, co pozwala na logowanie za pomocą dostawców tożsamości, takich jak Google lub inna instancja Keycloak.

Następnie konfigurujemy właściwy formularz logowania. Domyślnie browser flow w Keycloak obejmuje nazwę użytkownika, hasło i uwierzytelnianie wieloskładnikowe (MFA). Możemy wyłączyć wszystkie te elementy i zastąpić je jednym krokiem – dodaniem WebAuthn Passwordless Authenticator, co zapewni, że użytkownicy będą mogli logować się wyłącznie za pomocą Passkeys.

 

Końcowa konfiguracja powinna wyglądać następująco:

Gdy WebAuthn Passwordless Authenticator zostanie skonfigurowany, kolejnym krokiem jest powiązanie go z przebiegiem logowania w przeglądarce.

Teraz pozostaje już tylko wymusić reset hasła dla przykładowego użytkownika, ustawiając wymaganą akcję na WebAuthn Register Passwordless.

Po kliknięciu linku w otrzymanym e-mailu Keycloak wyświetli okno dialogowe z instrukcją rejestracji passkey.

Wystarczy kliknąć, aby zarejestrować passkey.

Na ekranie pojawi się platformowy mechanizm uwierzytelniania urządzenia, prezentujący dostępne opcje potwierdzenia tożsamości użytkownika. Załóżmy, że chcemy skorzystać z Windows Hello i zweryfikować tożsamość za pomocą kodu PIN – tego samego, który jest używany do logowania do konta Windows.

Passkey powinien być teraz widoczny w sekcji poświadczeń wybranego użytkownika.

Teraz możemy przejść do strony logowania w danym realm i spróbować użyć passkey zamiast standardowej nazwy użytkownika i hasła.

Twój platformowy mechanizm uwierzytelniania powinien ponownie się pojawić, oferując użycie zarejestrowanego passkey.

 

Passkeys nie są rozwiązaniem idealnym, ale dla większości użytkowników ich zalety przewyższają ograniczenia. Wraz z rosnącą adopcją wiele z tych niedoskonałości zostanie wyeliminowanych. Jednak w krótkim okresie zarówno użytkownicy, jak i organizacje muszą być świadomi potencjalnych wyzwań związanych z ich wdrażaniem.

 

Organizacje, które chcą zintegrować passkeys ze swoimi systemami uwierzytelniania, mogą skorzystać z narzędzi takich jak Keycloak. Dzięki takiej integracji użytkownicy zyskują bezpieczny, bezhasłowy dostęp do aplikacji, przy jednoczesnym wykorzystaniu kluczowych funkcji Keycloak, takich jak Single Sign-On (SSO), uwierzytelnianie wieloskładnikowe (MFA) oraz szczegółowa kontrola dostępu.

Artykuł Wprowadzenie do Passkey w Keycloak pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 7441 Wdrażanie uwierzytelniania wieloskładnikowego za pomocą wiadomości e-mail w Keycloak https://inero-software.com/pl/wdrazanie-uwierzytelniania-wieloskladnikowego-za-pomoca-e-maila-w-keycloak/ Thu, 13 Feb 2025 11:26:40 +0000 https://inero-software.com/?p=7058 W tym artykule przyjrzymy się niestandardowej implementacji MFA, która wysyła jednorazowy kod uwierzytelniający na adres e-mail użytkownika.

Artykuł Wdrażanie uwierzytelniania wieloskładnikowego za pomocą wiadomości e-mail w Keycloak pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>
Keycloak natywnie obsługuje wiele bezpiecznych metod logowania i zawiera wbudowane mechanizmy jednorazowych haseł (OTP), takie jak uwierzytelnianie za pomocą aplikacji mobilnych, np. Google Authenticator lub naszego rozwiązania AuthM8. Jednak jeśli chcemy korzystać z innych zaawansowanych metod uwierzytelniania i na przykład wysyłać kody OTP przez e-mail, to – podobnie jak w przypadku uwierzytelniania wieloskładnikowego za pomocą SMS (więcej szczegółów TUTAJ) – musimy samodzielnie zaimplementować tę funkcjonalność. W tym artykule przyjrzymy się niestandardowej implementacji MFA, która wysyła jednorazowy kod uwierzytelniający na adres e-mail użytkownika.

Jak działa uwierzytelnianie wieloskładnikowe oparte na e-mailu?

Proces uwierzytelniania składa się z dwóch głównych etapów:

    • Generowanie i wysyłanie kodu MFA

Jeśli użytkownik ma już aktywny plik cookie potwierdzający wcześniejszą weryfikację MFA, powinien zostać natychmiast uwierzytelniony. W przeciwnym razie Keycloak tworzy nowe poświadczenie dla użytkownika i generuje jednorazowy kod na podstawie konfigurowalnych parametrów, takich jak długość lub czas ważności. Kod jest przechowywany w poświadczeniach użytkownika, a następnie wysyłany e-mailem za pośrednictwem dostawcy poczty e-mail.

 

    • Weryfikacja wprowadzonego kodu

Gdy użytkownik wprowadzi kod, Keycloak pobiera zapisane poświadczenie i porównuje wprowadzoną wartość. Jeśli kod jest poprawny i nadal ważny (nie wygasł), uwierzytelnienie kończy się sukcesem, a plik cookie zostaje zapisany w celu zapamiętania weryfikacji. Jeśli kod jest niepoprawny, użytkownik zostaje poproszony o ponowne jego wprowadzenie. Jeśli kod wygasł, wyświetlany jest komunikat o błędzie i proces musi zostać rozpoczęty od nowa.

Plusy i minusy

Uwierzytelnianie wieloskładnikowe (MFA) oparte na e-mailu zapewnia dodatkowe zabezpieczenie w przypadku naruszenia podstawowego czynnika, takiego jak hasło. Jest to szczególnie przydatne w sytuacjach, gdy hasła zostają złamane metodą brute-force lub są łatwe do odgadnięcia, na przykład w przypadku popularnych kombinacji, takich jak „123456”. Podobnie, to rozwiązanie chroni przed atakami typu credential stuffing, w których cyberprzestępcy wykorzystują wyciekłe hasła z innych naruszeń do prób logowania na konta.


Dodatkowe korzyści z używania za pomocą e-maila jako metody MFA:

    • Brak konieczności podawania dodatkowych wrażliwych informacji, takich jak numer telefonu, co zmniejsza obawy o prywatność.
    • Brak potrzeby instalowania osobnej aplikacji ani przechodzenia przez skomplikowaną konfigurację, co upraszcza cały proces.
    • Użytkownicy są przyzwyczajeni do podawania adresu e-mail w różnych celach, takich jak otrzymywanie ważnych powiadomień o koncie czy resetowanie haseł. Ta znajomość sprawia, że metoda ta jest łatwiejsza do zaakceptowania.


Ograniczenia MFA opartego na e-mailu:

E-mail jako kanał dostarczania kodów ma również pewne wady. Jeśli atakujący przejmie dostęp do skrzynki e-mail (np. uzyska dane logowania lub wykorzysta aktywną sesję), może potencjalnie zresetować hasła do innych kont. W przypadku użytkowników znajdujących się w szczególnie narażonych sytuacjach, np. korzystających ze współdzielonych urządzeń, MFA oparte na e-mailu może nie zapewnić pełnej ochrony.

Jak w przypadku każdej metody zabezpieczeń, kluczowe jest rozważenie korzyści w stosunku do potencjalnych ryzyk i uzupełnienie MFA opartego na e-mailu innymi środkami bezpieczeństwa, takimi jak silna polityka haseł i bezpieczne praktyki korzystania z poczty e-mail.

Wdrożenie MFA opartego na e-mailu

W tym zmodyfikowanym przepływie uwierzytelniania w przeglądarce, integrujemy niestandardowe MFA jako dodatkową metodę uwierzytelniania. Dodane zostały dwa nowe kroki:

    • Konfiguracja MFA opartego na e-mailu – ten etap zapewnia, że e-mail użytkownika jest skonfigurowany i zweryfikowany przed kontynuacją procesu. Jeśli użytkownik nie posiada niestandardowego poświadczenia MFA (które przechowuje kody OTP jako tajne dane), zostanie ono również ustawione.
public class MfaEmailSetupAuthenticator implements Authenticator, CredentialValidator<MfaEmailCredentialProvider> {
@Override
public void authenticate(AuthenticationFlowContext context) {
[…]
// Require email verification
if (!userModel.isEmailVerified()) {
userModel.addRequiredAction(UserModel.RequiredAction.VERIFY_EMAIL);
}
// Add MFA email credential if not present
if (!getCredentialProvider(context.getSession()).isConfiguredFor(realmModel, userModel, MfaEmailCredentialModel.TYPE)) {
userModel.credentialManager().createStoredCredential(new MfaEmailCredentialModel(new MfaEmailCredentialData()));
}
[…]
    • Uwierzytelnianie MFA oparte na e-mailu – to właściwy etap uwierzytelniania, w którym jednorazowy kod jest wysyłany na adres e-mail użytkownika. Jest oznaczony jako Alternatywny, co oznacza, że może być używany zamiast innych metod MFA, takich jak OTP z aplikacji mobilnej.
    • Max Cookie Age – to ustawienie określa, jak długo sesja MFA (plik cookie) pozostaje ważna. Jeśli plik cookie jest nadal aktywny, użytkownik nie zostanie ponownie poproszony o uwierzytelnienie MFA.
    • Time-to-live – wskazuje czas życia kodu MFA.

 

Teraz przyjrzyjmy się kodowi.

 

Poniższa metoda obsługuje sam proces MFA. Jeśli istnieje ważny plik cookie (co oznacza, że użytkownik już ukończył MFA), metoda natychmiast zwraca sukces, kończąc przepływ uwierzytelniania bez konieczności podejmowania dodatkowych działań.

@Override
public void authenticate(AuthenticationFlowContext context) {
if (hasValidCookie(context)) {
context.success();
return;
}
[…]

Jeśli plik cookie nie istnieje, należy spróbować pobrać istniejące poświadczenie MFA użytkownika z dostawcy poświadczeń. Jeśli użytkownik go nie posiada, tworzona jest nowa instancja przy użyciu MfaEmailCredentialModel, który rozszerza wbudowany CredentialModel.

 

[…]
// get existing credential or create a new one
CredentialModel credentialModel = getCredentialProvider(session)
.getDefaultCredential(session, context.getRealm(), user);
if (credentialModel == null) {
credentialModel = user.credentialManager().createStoredCredential(new MfaEmailCredentialModel(new MfaEmailCredentialData()));
}
[…]

Następnie metoda authenticate odczytuje właściwości konfiguracyjne, takie jak długość kodu i TTL (time-to-live). Sam kod może zostać wygenerowany za pomocą odpowiedniej metody narzędziowej i zostanie zapisany jako secretData w modelu poświadczeń.

// generate and store code
int length = Integer.parseInt(configMap.get(CONFIG_CODE_LENGTH));
int ttl = Integer.parseInt(configMap.get(CONFIG_CODE_TTL));
String code = MfaEmailCodesUtils.generateCode(length);
credentialModel.setSecretData(code);
user.credentialManager().updateStoredCredential(credentialModel);
AuthenticationSessionModel authSession = context.getAuthenticationSession();
authSession.setAuthNote("ttl", Long.toString(System.currentTimeMillis() + (ttl * 1000L)));

Na końcu wywoływana jest metoda sendCode, która wysyła wygenerowany kod na adres e-mail użytkownika. Jeśli wiadomość e-mail zostanie wysłana pomyślnie, metoda wyświetla formularz, w którym użytkownik może wprowadzić kod MFA.

// send email and show input form
try {
MfaEmailCodesUtils.sendCode(session, user, ttl, code, configMap);
context.challenge(context.form().setAttribute("realm", context.getRealm()).createForm(TPL_CODE));
} catch (Exception e) {
context.failureChallenge(AuthenticationFlowError.INTERNAL_ERROR,
context.form().setError("mfaEmailNotSent", e.getMessage())  .createErrorPage(Response.Status.INTERNAL_SERVER_ERROR));
}

Drugą kluczową częścią naszego mechanizmu uwierzytelniania jest metoda action, która odpowiada za walidację kodu wprowadzonego przez użytkownika. Jest ona wywoływana w momencie, gdy użytkownik przesyła formularz po otrzymaniu wiadomości e-mail.

Metoda pobiera poświadczenie użytkownika od dostawcy, a następnie kod jest weryfikowany poprzez porównanie go z zapisanym poświadczeniem za pomocą niestandardowej metody isValid.

[…]
final MfaEmailCredentialModel credentialModel = getCredentialProvider(session)
        .getDefaultCredential(session, context.getRealm(), user);
boolean isValid = getCredentialProvider(session).isValid(context.getRealm(), user,
     new UserCredentialModel(credentialModel.getId(), getCredentialProvider(context.getSession()).getType(), enteredCode));
[…]

Jeśli kod jest poprawny, następnym krokiem jest sprawdzenie, czy nie wygasł. Możemy również ustawić plik cookie przechowujący sesję MFA, aby zapobiec ponownemu proszeniu użytkownika o uwierzytelnienie MFA w okresie ważności tego pliku cookie.

[…]
// valid
HttpResponse response = context.getSession().getContext().getHttpResponse();
response.setCookieIfAbsent(createCookie(context));
context.success();
[…]

 

Oczywiście, w tym artykule nie omówimy całego zagadnienia, pomijając szczegóły implementacyjne, takie jak wysyłanie kodu, jego generowanie, walidacja oraz tworzenie niestandardowego pliku cookie.

 

Jednak przeanalizowaliśmy kluczowe kroki implementacji uwierzytelniania dwuskładnikowego (2FA) przy użyciu kodów wysyłanych na e-mail. Z jednej strony podejście to oferuje prostą i łatwo dostępną metodę zabezpieczeń. Choć ma pewne wady, zastosowanie go w rozwiązaniach takich jak Keycloak pozwala zminimalizować wiele z tych zagrożeń. Keycloak zapewnia również elastyczność w łączeniu MFA opartego na e-mailu z innymi mechanizmami zabezpieczeń, tworząc bardziej warstwowy i odporny proces uwierzytelniania, który może skutecznie chronić przed rozwijającymi się zagrożeniami cybernetycznymi.

Czy potrzebujesz pomocy w konfiguracji uwierzytelniania wieloskładnikowego?

Umów spotkanie, aby dowiedzieć się, jak możemy Ci pomóc.
Umów spotkanie

Artykuł Wdrażanie uwierzytelniania wieloskładnikowego za pomocą wiadomości e-mail w Keycloak pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 7058 Migracja Keycloak: Porady i najlepsze praktyki https://inero-software.com/pl/migracja-keycloak-porady-i-najlepsze-praktyki/ Tue, 28 Jan 2025 14:32:55 +0000 https://inero-software.com/?p=6817 W tym tekście przedstawiamy najważniejsze zmiany wprowadzone w najnowszych wersjach Keycloak oraz ich wpływ na proces migracji.

Artykuł Migracja Keycloak: Porady i najlepsze praktyki pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>

W tym tekście przedstawiamy najważniejsze zmiany wprowadzone w najnowszych wersjach Keycloak oraz ich wpływ na proces migracji. Pokażemy także przykłady rozwiązywania typowych problemów, które pomogą przejść płynnie na nowsze wersje. Niezależnie od tego, czy chodzi o dostosowanie zaktualizowanych konfiguracji, czy zarządzanie wycofanymi funkcjami, ten artykuł dostarczy Ci praktycznych wskazówek, które usprawnią migrację Keycloak.

Migracja do dystrybucji Quarkus

Migracja do dystrybucji Quarkus była jednym z najbardziej wymagających procesów dla wielu użytkowników, szczególnie podczas aktualizacji do Keycloak 17, kiedy architektura zmieniła się z WildFly na framework Quarkus. Ta zmiana oznaczała odejście od tradycyjnego modelu serwera aplikacyjnego na rzecz nowoczesnego, lekkiego podejścia dostosowanego do Quarkusa. Konfiguracja Keycloak została całkowicie zmieniona – zamiast wdrażać aplikację na zewnętrznym serwerze aplikacyjnym, działa ona teraz jako samodzielna aplikacja, co znacząco upraszcza proces wdrażania.

Na przykład custom providers, które wcześniej było dynamicznie pakowane jako moduły dla WildFly, muszą obecnie zostać przebudowane i dostosowane, ponieważ środowisko wykonawcze (runtime) jest niezmienne. Wymaga to modyfikacji zależności, ładowania klas i metod pakowania. Choć ta zmiana upraszcza wdrażanie w środowiskach takich jak Kubernetes, wymusza również zmianę podejścia w pracy zespołów przyzwyczajonych do rozwiązań opartych na WildFly. Przejście na Quarkus zapewnia znaczące korzyści wydajnościowe i nowocześniejsze środowisko deweloperskie, jednak wymaga starannego planowania i testowania, aby migracja przebiegła pomyślnie.

Kluczowe zmiany wprowadzone w nowych wersjach

Migracja wprowadza istotne zmiany, które wpływają na konfigurację, endpointy oraz implementacje custom providers:

Wymóg HTTPS w trybie produkcyjnym
Uruchamianie Keycloak za pomocą polecenia [keycloak_quarkus_root]/26.1.0/bin/kc.bat start wymaga teraz certyfikatu HTTPS, ponieważ opcja start jest przeznaczona do użytku produkcyjnego. Do lokalnego środowiska deweloperskiego należy używać opcji start-dev.

Usunięcie /auth z podstawowej ścieżki
Segment /auth został usunięty z domyślnej podstawowej ścieżki. Aplikacje korzystające z endpointów Keycloak muszą zaktualizować swoje konfiguracje, aby uwzględnić tę zmianę.

Zmiany w identyfikatorze realm
W poprzednich wersjach identyfikator realm był identyczny z jego nazwą. Począwszy od Keycloak 21, identyfikator realm jest teraz unikalną, systemowo generowaną wartością. Aplikacje korzystające z identyfikatorów realm muszą uwzględnić tę zmianę podczas migracji.

Wycofanie userLocalStorage
Custom providers korzystający z metody userLocalStorage interfejsu KeycloakSession muszą przejść na metodę users, ponieważ userLocalStorage została wycofana począwszy od Keycloak 19.

Transport jdbc-ping jako nowy domyślny
W wersji Keycloak 26.1.0 domyślną metodą wykrywania innych węzłów w klastrze stało się korzystanie z bazy danych, zamiast opierania się wyłącznie na multicast. Ta zmiana eliminuje potrzebę dodatkowej konfiguracji sieciowej, szczególnie w środowiskach chmurowych.

Problemy z głównymi migracjami

Podczas migracji Keycloak zdecydowanie zaleca się aktualizowanie wersji krok po kroku, zamiast przeskakiwania przez kilka wydań jednocześnie. Takie stopniowe podejście pozwala na identyfikację i rozwiązywanie problemów na bieżąco, minimalizując ryzyko nieoczekiwanych komplikacji. Przeskakiwanie przez wiele wersji—szczególnie jeśli obejmuje kilkanaście lub więcej wydań—może znacznie skomplikować proces z uwagi na nagromadzone zmiany, wycofane funkcje oraz zmiany w architekturze, takie jak przejście na Quarkus. Realizowanie zmian związanych z kompatybilnością i konfiguracją etapami pozwala na lepszą kontrolę nad migracją oraz redukcję przestojów i zakłóceń w środowiskach produkcyjnych.

Jednak w wielu przypadkach konieczna staje się duża, jednorazowa migracja, na przykład z Keycloak 12 bezpośrednio do Keycloak 26, co stanowi wyzwanie, które zespoły muszą skutecznie rozwiązać. Proces ten często wiąże się z istotnymi zmianami zarówno w samym serwerze Keycloak, jak i w aplikacjach zależnych, szczególnie w klientach frontendowych korzystających z jego API.

W tym przewodniku przedstawimy jak podejść do przeprowadzenia takiej dużej migracji.

Konfiguracja Dockerfile

W naszym przykładowym projekcie wszystkie niestandardowe motywy oraz rozszerzenia SPI (Service Provider Interface) zostały bezpośrednio skopiowane do bazowego obrazu Keycloak, bez dedykowanego procesu budowania. Było to zrealizowane w standardowy sposób stosowany dla WildFly.

FROM quay.io/keycloak/keycloak:12.0.2

COPY themes/custom-theme /opt/jboss/keycloak/themes/custom-theme
COPY api-extensions/target/spi-resource-0.0.1-SNAPSHOT.jar

ENTRYPOINT /opt/jboss/tools/docker-entrypoint.sh -b 0.0.0.0

Nowe podejście może wykorzystywać proces wieloetapowy z oddzielnymi kontenerami, takimi jak:

FROM eclipse-temurin:17-jdk as spi_builder
[…]
FROM quay.io/keycloak/keycloak:$BASE_IMAGE_TAG as keycloak_builder
[…]
FROM quay.io/keycloak/keycloak:$BASE_IMAGE_TAG

SPI jest budowane podczas procesu budowania kontenera przy użyciu narzędzia Maven. Takie podejście zapewnia pobranie zależności oraz optymalizację wygenerowanego pliku JAR do wdrożenia.

### Runtime dependencies build container
FROM registry.access.redhat.com/ubi9 AS runtime_dependencies_builder
RUN mkdir -p /mnt/rootfs

RUN dnf install --installroot /mnt/rootfs curl --releasever 9 --setopt install_weak_deps=false --nodocs -y \
&& dnf --installroot /mnt/rootfs clean all

### SPI build container
FROM eclipse-temurin:17-jdk as spi_builder
ARG BASE_IMAGE_TAG
WORKDIR /workspace/app

COPY api-extensions/mvnw .
COPY api-extensions/.mvn .mvn
COPY api-extensions/pom.xml .

# dos2unix:
RUN sed -i -e 's/\r//g' mvnw
RUN ./mvnw dependency:go-offline
COPY api-extensions/src src
RUN ./mvnw -o package -DskipTests
 

Nowy proces kopiuje wiele niestandardowych motywów do Keycloak opartego na Quarkus podczas etapu budowania, zapewniając ich uwzględnienie w finalnym zoptymalizowanym środowisku wykonawczym. Takie podejście poprawia wydajność uruchamiania i jest zgodne z filozofią niezmiennych kontenerów.

### Build container
FROM quay.io/keycloak/keycloak:$BASE_IMAGE_TAG as keycloak_builder
COPY --from=spi_builder /workspace/app/target/spi-resource-0.0.1-SNAPSHOT-jar-with-dependencies.jar /opt/keycloak/providers/

#Copy custom themes
COPY themes/custom-theme /opt/keycloak/themes/custom-theme

#Build an optimized server runtime
RUN /opt/keycloak/bin/kc.sh build

### Runtime container
FROM quay.io/keycloak/keycloak:$BASE_IMAGE_TAG
COPY --from=keycloak_builder /opt/keycloak/ /opt/keycloak/
WORKDIR /opt/keycloak
ENTRYPOINT ["/opt/keycloak/bin/kc.sh"]

Zasadniczo, wykorzystując budowanie wieloetapowe oraz lekkie obrazy, nowy proces jest zgodny z najlepszymi praktykami dotyczącymi wdrożeń konteneryzowanych. Więcej szczegółów na temat tych kroków znajdziesz tutaj: https://www.keycloak.org/server/containers.

Zmiana domyślnej ścieżki kontekstu /auth

Wraz z przejściem na dystrybucję Keycloak opartą na Quarkus, domyślna ścieżka kontekstu została zmodyfikowana – /auth nie jest już domyślnie częścią URL.

Ta zmiana jest zgodna z celem Quarkusa, jakim jest dostarczenie bardziej zoptymalizowanego i minimalistycznego podejścia do aplikacji webowych, redukując niepotrzebne prefiksy ścieżek.

Dla użytkowników lub aplikacji, które nadal wymagają ścieżki kontekstu /auth, można ją ponownie wprowadzić za pomocą opcji build http-relative-path.

Na przykład, uruchamiając Keycloak przy użyciu następującego polecenia, można przywrócić ścieżkę /auth:

bin/kc.[sh|bat] start-dev --http-relative-path /auth

Lub za pomocą Docker Compose:

KC_HTTP_RELATIVE_PATH: /auth

Pozwala to na zachowanie kompatybilności z istniejącymi klientami lub konfiguracjami, które opierają się na prefiksie /auth. Po określeniu względnej ścieżki Keycloak nadal automatycznie przekieruje żądania z katalogu głównego (np. localhost:8080/) na ścieżkę /auth (np. localhost:8080/auth). Dzięki temu aplikacje lub użytkownicy przyzwyczajeni do wcześniejszej struktury URL mogą nadal działać zgodnie z oczekiwaniami, bez konieczności wprowadzania większych zmian.

Zmiany w zarządzaniu dostawcami

Wraz z przejściem na dystrybucję Keycloak opartą na Quarkus, nastąpiły istotne zmiany w sposobie wdrażania i zarządzania custom providers (SPI). W dystrybucji opartej na WildFly byli oni wdrażani poprzez kopiowanie do katalogu standalone/deployments, a zależności umieszczano w określonych lokalizacjach w strukturze serwera WildFly. Jednak w nowej dystrybucji Quarkus model wdrażania został uproszczony — dostosowani dostawcy powinni być teraz kopiowani do katalogu /providers.

Dodatkowo Quarkus nie obsługuje formatu pakowania EAR ani plików jboss-deployment-structure.xml, które były powszechnie wykorzystywane w dystrybucji WildFly do konfiguracji wdrożeń i zarządzania zależnościami. W efekcie proces pakowania został uproszczony, ale dostosowane konfiguracje, które wcześniej były realizowane za pomocą tych plików, muszą być teraz obsługiwane w inny sposób.

Co więcej, jeśli dostosowani dostawcy korzystali z API JavaEE, takich jak sesyjne lub bezstanowe komponenty (session/stateless beans), nie będą one już obsługiwane w dystrybucji Quarkus.

Migracja niestandardowych motywów

Poprzedni Keycloak korzystał z silnika szablonów FreeMarker do renderowania dynamicznych treści w motywach.
Choć podejście to jest nadal stosowane w nowych wersjach (szczególnie w motywach v1 i v2), wprowadzono aktualizacje w składni szablonów oraz strukturze motywów, aby dostosować je do nowej architektury Quarkus. Niestandardowe szablony mogą wymagać dostosowania, aby były kompatybilne z nowszymi wersjami FreeMarker, ponieważ struktura motywów uległa pewnym zmianom.

Dodatkowo niektóre funkcje i makra szablonów, dostępne w starszych wersjach, takich jak Keycloak 12, mogły zostać wycofane lub zastąpione bardziej wydajnymi odpowiednikami.

Motywy, które zostały wcześniej dostosowane, prawdopodobnie nie obsługują trybu ciemnego. Aby uniknąć problemów bez konieczności całkowitego ich przepisywania, najprostszym rozwiązaniem jest dodanie opcji darkMode=false w pliku theme.properties. Co więcej, od wersji 26.1.0 w zakładce „Themes” pojawiły się przełączniki umożliwiające włączanie trybu ciemnego dla poszczególnych realmów.

Dostosowanie nowego serwera Keycloak do współpracy z frontendem klienta w starszej wersji

Problemy związane z checkLoginIframe

W jednym z naszych projektów musieliśmy zaktualizować Keycloak o 14 wersji. Jednak z różnych powodów nie mogliśmy zaktualizować frontendu, który działał na dość starej wersji Angulara oraz bibliotece keycloak-angular. Dlatego teraz omówimy modyfikacje, które musieliśmy wprowadzić, aby przywrócić funkcjonalność procesu logowania.

Keycloak-angular to biblioteka typu wrapper dla keycloak-js, która ułatwia jego wykorzystanie w aplikacjach Angular. Rozszerza oryginalne funkcjonalności o dodatkowe możliwości i wprowadza nowe metody, które ułatwiają integrację w aplikacjach Angular. Biblioteka oferuje również podstawową implementację AuthGuard, umożliwiając dostosowanie logiki autoryzacji. Dodatkowo można korzystać z HttpClient Interceptor, który dodaje nagłówek autoryzacyjny do wybranych żądań HTTP.

"keycloak-angular": "^8.1.0",
"keycloak-js": "^12.0.4",

Po zintegrowaniu nowej wersji Keycloak (26.1.0) ze starym frontendem klienta napotkaliśmy problem, który pojawiał się po zalogowaniu i objawiał się w następujący sposób:

Ta opcja określa, czy Keycloak powinien sprawdzać status logowania za pomocą iframe. Należy jej używać ostrożnie, ponieważ niewłaściwa konfiguracja może prowadzić do problemów, takich jak ciągłe przeładowywanie strony. Nowsze wersje Keycloak mogły ulepszyć lub zmienić sposób zarządzania sesjami, szczególnie w kontekście plików cookie typu cross-site, przepływów uwierzytelniania lub obsługi iframe (setupCheckLoginIframe, check3pCookiesSupported). Te zmiany mogą wpływać na sposób, w jaki frontend obsługuje stany logowania, zwłaszcza jeśli korzysta z przestarzałych metod sprawdzania statusów logowania lub przetwarzania callbacków.

Biorąc pod uwagę znaczną różnicę wersji między frontendem a serwerem, jednym z przydatnych rozwiązań może być wyłączenie opcji setupCheckLoginIframe, co może również pomóc w sytuacjach, gdy po aktualizacji występują nieskończone pętle przekierowań.

Oto przykład, jak wyłączyć tę opcję podczas inicjalizacji:

function initializeKeycloak(keycloak: KeycloakService, permissionsService: PermissionsService) 
{
  return () =>
    keycloak.init({

   config: {
     url: environment.keycloakUrl,
     realm: 'test-realm',
     clientId: 'test-realm-web',
   },
   initOptions: {
        checkLoginIframe: false
   }
}).then(() => permissionsService.init());
}

Brak klucza nonce w żądaniu

W nowszych wersjach Keycloak, zgodnie ze specyfikacją OpenID Connect Core 1.0, klucz nonce jest teraz dodawany do tokena ID tylko wtedy, gdy parametr ten został uwzględniony w żądaniu autoryzacyjnym. Zgodnie ze specyfikacją, klucz nonce jest obowiązkowy w tokenie ID, ale nie powinien być zawarty w tokenach po żądaniu odświeżenia. Wcześniej klucz nonce był dodawany do wszystkich tokenów (Access, Refresh i ID) we wszystkich odpowiedziach, w tym także w odpowiedziach odświeżających.

W rezultacie korzystanie ze starszej wersji adaptera keycloak-js może powodować problemy z logowaniem, takie jak błędy „Invalid nonce, clearing token” lub nieskończone pętle przekierowań po próbach logowania. Aby rozwiązać ten problem, użytkownicy mogą dodać predefiniowany mapper „Nonce backwards compatible” za pomocą przycisku „By Configuration” w dedykowanym zakresie klienta. Więcej informacji można znaleźć w oficjalnej dokumentacji Keycloak (https://www.keycloak.org/docs/latest/upgrading/index.html#nonce-claim-is-only-added-to-the-id-token).

Problemy z przekierowaniem URI po wylogowaniu

Zgodnie z informacjami zawartymi w notatkach do wydania wersji 18, Keycloak nie obsługuje już parametru redirect_uri podczas wylogowywania. Zamiast tego należy używać parametru post_logout_redirect_uri wraz z parametrem client_id lub id_token_hint. W praktyce oznacza to, że podczas wywoływania funkcji wylogowania należy zastąpić redirect_uri parametrem post_logout_redirect_uri.

W naszym przypadku (przy użyciu starszej wersji keycloak-js) proces wylogowania można zaimplementować w następujący sposób:

window.location.replace(this.keycloak['_instance']['endpoints'].logout() +
   '?post_logout_redirect_uri=' + encodeURIComponent(window.location.origin) +
   '&client_id=test-realm-web');

Ta zmiana powinna rozwiązać najczęstsze problemy z przekierowaniami po wylogowaniu z aplikacji.

Podsumowanie

W ciągu ostatnich kilku lat Keycloak przeszedł znaczące zmiany, szczególnie te wprowadzone podczas migracji z WildFly na Quarkus. Zmiany te były konieczne dla poprawy wydajności, bardziej efektywnego wykorzystania zasobów oraz lepszej skalowalności.

Choć proces migracji może wydawać się trudny, jest on zazwyczaj wykonalny, nawet w przypadku starszych wersji. Stopień trudności migracji w dużej mierze zależy jednak od konkretnego przypadku, zwłaszcza od poziomu dostosowania. Na przykład, jeśli motywy były mocno zmodyfikowane w poprzedniej wersji Keycloak, ich dostosowanie do nowszych dystrybucji może wymagać więcej czasu i wysiłku, ponieważ struktura i silniki szablonów uległy zmianie.

Podobnie integracje z systemami starszej generacji mogą wymagać starannego planowania, aby zapewnić ich kompatybilność z nowszymi wersjami Keycloak. Z drugiej strony, w przypadku standardowych konfiguracji z minimalnym stopniem dostosowania, przejście na nową wersję jest zazwyczaj płynniejsze i szybsze. Proces migracji może być również wspierany przez szczegółową dokumentację oraz społeczność, która znacznie się rozwinęła w ostatnich latach.

Podsumowując, choć każdy projekt migracyjny niesie ze sobą własne wyzwania, to przy odpowiednim planowaniu i testowaniu przejście na nowszą wersję Keycloak zazwyczaj nie jest zbyt skomplikowane. Długoterminowe korzyści z aktualizacji, takie jak poprawiona wydajność i funkcje bezpieczeństwa, sprawiają, że wysiłek ten jest wart podjęcia.

Planujesz aktualizację Keycloak?

Jeśli szukasz partnera, który poprowadzi Cię przez proces aktualizacji to koniecznie skontaktuj się z nami.
Zaplanuj rozmowę

Artykuł Migracja Keycloak: Porady i najlepsze praktyki pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 6817 Praktyczne wprowadzenie do Keycloak SSO: Od konfiguracji do integracji https://inero-software.com/pl/praktyczne-wprowadzenie-do-keycloak-sso-od-konfiguracji-do-integracji/ Tue, 17 Dec 2024 09:48:48 +0000 https://inero-software.com/?p=6522 SSO to protokół umożliwiający użytkownikom uwierzytelnianie i uzyskiwanie dostępu do wielu aplikacji za pomocą jednego zestawu danych logowania.

Artykuł Praktyczne wprowadzenie do Keycloak SSO: Od konfiguracji do integracji pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>

Jedną z największych zalet, jakie Keycloak oferuje jest Single Sign-On (SSO). Funkcja ta znacząco usprawnia zarządzanie użytkownikami, upraszcza procesy uwierzytelniania w aplikacjach firmowych i stanowi skuteczne rozwiązanie w zakresie wyzwań związanych z bezpieczeństwem. Dziś przyjrzymy się, jak działa oraz jak skonfigurować przykładową integrację.

SSO (Single Sign-On)

SSO to protokół umożliwiający użytkownikom uwierzytelnianie i uzyskiwanie dostępu do wielu aplikacji za pomocą jednego zestawu danych logowania. Takie podejście jest niezwykle wygodne, ponieważ eliminuje potrzebę zapamiętywania wielu haseł lub wielokrotnego logowania się. Co więcej, SSO zwiększa bezpieczeństwo, zmniejszając ryzyko związane ze słabymi, powtórnie używanymi lub zgubionymi hasłami.

Centrum SSO stanowi dostawca tożsamości (IdP), który działa jak centralny serwer uwierzytelniający. Gdy użytkownicy logują się do swojej pierwszej aplikacji, są przekierowywani do IdP, gdzie podają swoje dane uwierzytelniające. Po pomyślnym uwierzytelnieniu IdP inicjuje sesję SSO i generuje zaszyfrowany token dostępu, który aplikacja wykorzystuje do potwierdzenia tożsamości użytkownika.

Po aktywacji sesji SSO użytkownik może uzyskać dostęp do innych zaufanych aplikacji bez konieczności ponownego logowania. Kiedy druga aplikacja wymaga uwierzytelnienia, komunikuje się z IdP, który weryfikuje aktywną sesję użytkownika i wydaje kolejny token dostępu, umożliwiając płynny dostęp bez ponownego wprowadzania danych logowania.

Nowoczesne rozwiązania IAM ułatwiają implementację SSO w różnych aplikacjach, często wykorzystując otwarte standardy, takie jak OAuth 2.0 i OpenID Connect (OIDC). Standardy te umożliwiają uwierzytelnianie nie tylko w aplikacjach wewnętrznych, ale także w tych, które opierają się na zewnętrznych dostawcach tożsamości. Dodatkowo SSO obsługuje logowanie za pomocą mediów społecznościowych, co pozwala użytkownikom na uwierzytelnienie przy użyciu istniejących danych logowania z platform takich jak Google, Facebook czy Twitter.

Typy SSO

Podczas wdrażania i zarządzania Single Sign-On (SSO) kluczowe jest zrozumienie różnych protokołów i standardów, które umożliwiają jego działanie. Do najczęściej stosowanych należą Security Assertion Markup Language (SAML) oraz OpenID Connect (OIDC). Keycloak obsługuje oba te protokoły, co czyni je głównym punktem naszej dyskusji. Warto jednak zauważyć, że inne protokoły, takie jak Kerberos, również odgrywają rolę w niektórych scenariuszach SSO.

Security Access Markup Language (SAML)

SAML to standard oparty na XML, zaprojektowany do kodowania i wymiany informacji o tożsamości pomiędzy aplikacjami. Stał się on fundamentem dla SSO, umożliwiając bezpieczne potwierdzanie żądań uwierzytelniania w aplikacjach internetowych. SAML 2.0, najczęściej stosowana wersja, jest zoptymalizowana specjalnie pod kątem środowisk przeglądarkowych, pozwalając na bezpieczne przekazywanie informacji o użytkownikach za pośrednictwem przeglądarek internetowych. Ze względu na swoją rozwlekłość i mniejszą efektywność przetwarzania danych w porównaniu do nowoczesnych standardów, SAML najlepiej sprawdza się w starszych oraz korporacyjnych aplikacjach internetowych, zwłaszcza tych działających wewnątrz organizacji.

OpenID Connect (OIDC)

OIDC to rozszerzenie protokołu OAuth 2.0, które dodaje informacje o użytkownikach i umożliwia SSO. Wykorzystuje JSON oraz RESTful API do wymiany danych, co sprawia, że jest szybkie i łatwe do integracji, zwłaszcza w środowiskach mobilnych i opartych na chmurze. OIDC jest szczególnie przydatne w scenariuszach związanych z logowaniem przez media społecznościowe (np. Google, Facebook) oraz zewnętrznymi interfejsami API. Jest to najlepszy wybór w sytuacjach, gdy aplikacje wymagają elastycznego, skalowalnego uwierzytelniania opartego na tokenach i zapewniającego wysoki poziom bezpieczeństwa.

Zalety i wady wdrożenia SSO

Kluczowe korzyści Single Sign-On (SSO) to:

  • SSO ogranicza potrzebę zapamiętywania wielu nazw użytkowników i haseł, konsolidując uwierzytelnianie do jednego zestawu danych logowania.
  • Redukuje liczbę resetów haseł i problemów z logowaniem, co zmniejsza obciążenie działu IT i prowadzi do oszczędności kosztów.
  • Eliminuje przerwy spowodowane wielokrotnym logowaniem i zarządzaniem hasłami, pozwalając użytkownikom szybko uzyskać dostęp do potrzebnych zasobów i skupić się na zadaniach. Usprawnia proces logowania oraz umożliwia wylogowanie jednym kliknięciem z wielu aplikacji.
  • Centralizacja danych użytkowników ułatwia administratorom zarządzanie i dostosowywanie uprawnień dostępu w całej sieci, zapewniając lepszą kontrolę.
  • Konsolidacja danych logowania zmniejsza ryzyko związane ze słabym zarządzaniem hasłami. Administratorzy mogą łatwiej wyłączać konta w razie potrzeby, co podnosi ogólny poziom bezpieczeństwa.

Podsumowując, SSO poprawia doświadczenie użytkowników, zwiększa produktywność, wzmacnia bezpieczeństwo i upraszcza zadania administracyjne, centralizując proces uwierzytelniania i ułatwiając zarządzanie dostępem.

Potencjalne wady SSO

  • Pojedynczy punkt awarii (SPOF)
    Jeśli dostawca SSO doświadczy awarii lub zostanie naruszony, użytkownicy mogą utracić dostęp do wielu aplikacji jednocześnie.

  • Złożoność wdrożenia
    Konfiguracja i utrzymanie systemu SSO może być technicznie wymagające, szczególnie w środowiskach zróżnicowanych pod względem aplikacji i protokołów. Nie wszystkie aplikacje natywnie obsługują SSO, co może wymagać niestandardowych integracji.

  • Problemy ze skalowalnością
    W środowiskach o dużym ruchu system SSO musi obsługiwać znaczne obciążenia, co może wymagać dodatkowych zasobów oraz starannego planowania przyszłych integracji.

SSO z Keycloak i Spring

Teraz omówimy, jak skonfigurować prosty mechanizm SSO przy użyciu Spring Security, biblioteki keycloak-angular oraz Keycloak jako dostawcy tożsamości. Wybór Keycloak jest podyktowany kilkoma czynnikami. Wykorzystuje on dobrze ugruntowany standard OpenID Connect, zapewniając szeroką kompatybilność. Wyróżnia się również dużą liczbą gotowych przykładów integracji zarówno dla aplikacji front-end, jak i back-end. Oferuje także znaczną elastyczność dzięki rozszerzeniom opartym na Javie, umożliwiając łatwą personalizację.

Aby uruchomić demo SSO, przejdziemy przez przygotowanie serwera autoryzacji, serwera zasobów oraz dwóch różnych aplikacji klienckich. Gdy użytkownik spróbuje uzyskać dostęp do zasobu jednej z aplikacji klienckich, powinien zostać przekierowany do serwera autoryzacji w celu uzyskania tokena. Keycloak zarządza procesem logowania, a po zalogowaniu użytkownika do pierwszej aplikacji klienckiej, jeśli uzyska on dostęp do drugiej aplikacji klienckiej z tej samej przeglądarki, nie będzie musiał logować się ponownie, ponieważ sesja SSO pozostaje aktywna. W tym przykładzie użyjemy klienta OIDC obsługującego OAuth2 oraz Authorization Code Flow do zarządzania procesem uwierzytelniania między punktami końcowymi.

Serwer autoryzacji

Do realizacji zadań dostawcy tożsamości (Identity Provider) lub serwera autoryzacji możemy wykorzystać obraz Dockera z najnowszą wersją Keycloak. Dzięki wdrożeniu za pomocą pliku docker-compose możemy szybko przygotować i skonfigurować środowisko, w tym bazę danych, bez potrzeby ręcznej instalacji. Prosta konfiguracja docker-compose będzie zawierać dwie usługi: Keycloak oraz bazę danych PostgreSQL.

x-keycloak: &keycloak

  build: keycloak

  ports:

– „8080:8080”

  depends_on:

– db-postgres-keycloak

 

x-common-variables: &common-variables

  KC_BOOTSTRAP_ADMIN_USERNAME: admin

  KC_BOOTSTRAP_ADMIN_PASSWORD: admin

  KC_HOSTNAME_STRICT: „false”

  KC_HTTP_RELATIVE_PATH: /auth

  KC_HTTP_ENABLED: 'true’

  KC_LOG_LEVEL: „INFO,io.quarkus.http.access-log:DEBUG”

  KC_DB: postgres

  KC_DB_URL_HOST: db-postgres-keycloak

  KC_DB_USERNAME: keycloak

  KC_DB_PASSWORD: password

  KC_DB_SCHEMA: public

  QUARKUS_HTTP_ACCESS_LOG_ENABLED: 'true’

services:
   keycloak:
          <<: *keycloak
         environment:
         <<: *common-variables
       profiles: [„example”]
      command: start –optimized

db-postgres-keycloak:
      profiles: [„example”]
      image: postgres:15
      environment:
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: password
      POSTGRES_DB: keycloak

Po uruchomieniu kontenerów możemy zalogować się do konsoli administracyjnej (dostępnej pod adresem http://localhost:8080). Zanim jednak przejdziemy do konfiguracji klientów w ramach realm, warto poświęcić chwilę na zapoznanie się z ustawieniami w sekcji Realm Settings -> Sessions.

SSO konfiguracja sesji

Podczas konfigurowania nowego realm możemy dostosować ustawienia zarządzania sesjami, aby zrównoważyć bezpieczeństwo i wygodę użytkowników. Ustawienia te określają, jak długo użytkownicy pozostają uwierzytelnieni oraz warunki, w których muszą ponownie się zalogować. Poniżej opisujemy najważniejsze z nich:

  • SSO Session Idle – to ustawienie kontroluje, jak długo użytkownik może pozostawać nieaktywny, zanim jego sesja wygaśnie. Jeśli użytkownik nie podejmie żadnej aktywności przez określony czas, będzie musiał ponownie się uwierzytelnić przy następnej interakcji z aplikacją. Licznik jest resetowany, gdy klient wysyła żądania odświeżenia tokena.

  • SSO Session Max – parametr ten definiuje maksymalny czas trwania sesji, niezależnie od aktywności użytkownika. Gdy sesja przekroczy ten czas, użytkownik zostanie wylogowany i poproszony o ponowne zalogowanie się.

  • SSO Session Idle Remember Me oraz SSO Session Max Remember Me – działają podobnie jak parametry SSO Session, ale odnoszą się do sytuacji, gdy użytkownik zaznaczył opcję Remember Me (Zapamiętaj mnie).

  • Client Session Idle oraz Client Session Max – te parametry powinny mieć krótsze wartości czasu niż ogólne ustawienia SSO. Określają one maksymalny okres ważności tokena odświeżania i mogą być nadpisane dla poszczególnych klientów w ich ustawieniach.

Dostosowanie tych ustawień pozwala precyzyjnie zarządzać sesjami użytkowników, zwiększając kontrolę nad bezpieczeństwem aplikacji oraz optymalizując doświadczenie użytkowników.

Serwer zasobów

Jednym z klientów realm będzie serwer zasobów, który pełni podwójną rolę – jako klient Keycloak oraz backend dla dwóch różnych aplikacji uczestniczących w opisanym przepływie. Proces integracji aplikacji Spring Boot z Keycloak jest bardzo podobny do tego, który opisaliśmy w jednym z wcześniejszych wpisów (https://inero-software.com/pl/zabezpieczanie-punktow-koncowych-java-spring-za-pomoca-keycloak/).

Dlatego nie będziemy tutaj skupiać się na samej aplikacji Java. Skonfigurowany w ten sposób serwer zasobów będzie wystawiał przykładowy endpoint dostępny tylko dla użytkowników uwierzytelnionych w ramach tego realm.

Serwer zasobów musi zarządzać zasobami w ramach realm, dlatego w Keycloak należy zaznaczyć opcję Authorization. To ustawienie jest przeznaczone głównie dla serwerów zasobów, które potrzebują dostępu do różnych endpointów, takich jak Token Endpoint.

W tej konfiguracji klient jest ustawiony jako confidential (poufny) z sekretem, który musi być współdzielony zarówno przez serwer Keycloak, jak i samą aplikację. Sekret można wygenerować w Admin Console, a następnie umieścić go w pliku application.properties aplikacji Spring, aby zapewnić bezpieczną komunikację.

Pozostałe pola formularza można pozostawić z domyślnymi wartościami.

Frontend clients

Konfiguracja klientów frontendu jest dość podobna do poprzedniej, jednak warto zwrócić uwagę na pewne różnice. W przypadku klientów działających w przeglądarce nie ustawiamy ich jako confidential. Opcja „Authorization” również nie jest tutaj wymagana. Kluczowym aspektem jest właściwa konfiguracja Redirect URIs oraz Web Origins. Zazwyczaj mogą one być takie same, co zapewnia, że Keycloak prawidłowo rozpozna dozwolone źródła, z których aplikacja frontendowa może wykonywać żądania.

Jednak nie zaleca się polegania na wildcardach (*) w Redirect URIs. Najnowsza specyfikacja OAuth 2.1 wymaga, aby URI były porównywane przy użyciu dokładnego dopasowania ciągu znaków.

Aby uwierzytelnić użytkownika i wyświetlić stronę logowania Keycloak w naszym projekcie Angular, użyjemy Injection Token.

function initializeKeycloak(keycloak: KeycloakService) {
return () =>
     keycloak.init({
         config: {
             url: environment.keycloakUrl,
             realm: 'sso-realm',
             clientId: 'sso-app-1',
         },
         initOptions: {
             checkLoginIframe: false,
             scope: 'sso-resource-server'
         }
     });
}

Powyższa funkcja przyjmuje jako argument KeycloakService, czyli obiekt z biblioteki keycloak-angular, dzięki czemu możemy go skonfigurować, podając URL serwera, nazwę realm oraz identyfikator klienta aplikacji, który został utworzony w poprzednim kroku. Następnie musimy zarejestrować tę funkcję w pliku app.module.ts jako provider:

providers: [
     {
     provide: APP_INITIALIZER,
     useFactory: initializeKeycloak,
     multi: true,
     deps: [KeycloakService],
     },
],

Kolejnym krokiem będzie utworzenie Guard, który zabezpieczy ścieżki w aplikacji. Biblioteka, której używamy, dostarcza już wstępnie skonfigurowaną, abstrakcyjną klasę KeycloakAuthGuard, którą rozszerzymy, tworząc własny Guard. Następnie musimy nadpisać metodę isAccessAllowed.

public async isAccessAllowed(
      route: ActivatedRouteSnapshot,
      state: RouterStateSnapshot

) {

     // Force the user to log in if currently unauthenticated.
    if (!this.authenticated) {
    await this.keycloak.login({
    redirectUri: window.location.origin + '/#/' + state.url
     });

     }
    // Get the roles required from the route.
    const requiredRoles = route.data['roles'];

   // Allow the user to proceed if no additional roles are required to access the route.
   if (!(requiredRoles instanceof Array) || requiredRoles.length === 0) {
   return true;
   }

   // Allow the user to proceed if all the required roles are present.
  return requiredRoles.every((role) => this.roles.includes(role));
}

Następnie musimy przypisać AuthGuard do określonych ścieżek w module routingu. Po poprawnej konfiguracji wszystkich komponentów biblioteki keycloak-angular, użytkownik powinien zostać przekierowany na stronę logowania Keycloak, a po pomyślnej autoryzacji uzyska dostęp do chronionych zasobów.

Test i podsumowanie

Aby przetestować funkcjonalność SSO, uruchom serwer zasobów (aplikację Spring) oraz oba klientów działających w przeglądarce. Gdy wszystkie komponenty będą działały, otwórz przeglądarkę i zaloguj się do jednej z aplikacji frontendowych. Następnie otwórz nową kartę lub okno i przejdź do drugiej aplikacji Angular. Po kliknięciu przycisku logowania powinieneś zostać bezpośrednio przekierowany do aplikacji i uzyskać dostęp do chronionego endpointu.

W ten sposób można zobaczyć, jak wbudowane funkcje Keycloak upraszczają zarządzanie uprawnieniami dostępu. Wykorzystując Keycloak jako dostawcę tożsamości (Identity Provider), możemy skonfigurować system, w którym użytkownicy muszą zalogować się tylko raz, aby uzyskać dostęp do różnych połączonych aplikacji. Centralizując dane logowania użytkowników, zwiększamy zarówno bezpieczeństwo, jak i doświadczenie użytkownika, a także ograniczamy ryzyko związane z podatnościami wynikającymi z haseł.

Jeśli Twoja firma potrzebuje pomocy przy wdrożeniu systemu IAM

skontaktuj się z nami. Posiadamy bogate portfolio zrealizowanych projektów.
Napisz do nas

Artykuł Praktyczne wprowadzenie do Keycloak SSO: Od konfiguracji do integracji pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 6522 Keycloak: wskazówki dotyczące monitorowania i ochrony przy użyciu wbudowanych narzędzi konfiguracyjnych https://inero-software.com/pl/keycloak-wskazowki-dotyczace-monitorowania-i-ochrony-przy-uzyciu-wbudowanych-narzedzi-konfiguracyjnych/ Thu, 26 Sep 2024 10:43:22 +0000 https://inero-software.com/?p=6192 Keycloak to nie tylko potężne narzędzie do zarządzania tożsamością i dostępem; jest również kluczowe dla monitorowania wydajności i zwiększania bezpieczeństwa, zwłaszcza w obronie przed atakami phishingowymi. Dzięki wbudowanym mechanizmom monitorowania i alertowania, administratorzy mogą wykrywać podejrzane działania użytkowników oraz utrzymywać optymalną wydajność systemu. Andrzej Chybicki CEO Inero Software Usługi Keycloak:…

Artykuł Keycloak: wskazówki dotyczące monitorowania i ochrony przy użyciu wbudowanych narzędzi konfiguracyjnych pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>

Keycloak to nie tylko potężne narzędzie do zarządzania tożsamością i dostępem; jest również kluczowe dla monitorowania wydajności i zwiększania bezpieczeństwa, zwłaszcza w obronie przed atakami phishingowymi. Dzięki wbudowanym mechanizmom monitorowania i alertowania, administratorzy mogą wykrywać podejrzane działania użytkowników oraz utrzymywać optymalną wydajność systemu.

Andrzej Chybicki

CEO Inero Software

Usługi Keycloak: Kompleksowa implementacja, utrzymanie i szkolenia

Wydajność Keycloak: Monitorowanie z Grafaną

Monitorowanie wydajności Keycloak jest kluczowe, zwłaszcza w dużych organizacjach, gdzie system musi obsługiwać jednocześnie tysiące użytkowników. Ciekawym narzędziem do tego celu jest na przykład Aerogear (https://github.com/aerogear/keycloak-metrics-spi). Aerogear umożliwia łatwe śledzenie krytycznych metryk w czasie rzeczywistym, co pozwala na optymalizację systemu i skalowanie.

Aerogear zapewnia dwie kluczowe funkcje: MetricsEventListener i MetricsEndpoint, które umożliwiają przesyłanie zdarzeń Keycloak do Prometheus oraz integrację z narzędziami wizualizacyjnymi, takimi jak Grafana. Dzięki temu administratorzy mogą monitorować ważne metryki, takie jak:

    • Zużycie pamięci,
    • Liczba zalogowanych użytkowników (według realm, klienta, globalnie, itp.),
    • Błędy logowania.

Grafana oferuje wysoki poziom dostosowywania, umożliwiając dodanie niestandardowych parametrów (np. z plików CSV lub baz danych) oraz konfigurację alertów. Te alerty mogą być wywoływane przez różne czynniki, takie jak:

    • Przekroczenie limitu czasu logowania,
    • Logowanie z nieautoryzowanych lokalizacji,
    • Niezwykle duża liczba żądań resetowania hasła.
żródło: grafana.com/grafana/dashboards/10441-keycloak-metrics-dashboard 

Ochrona przed atakami phishingowymi: Mechanizmy adaptacyjnego uwierzytelniania

Oprócz monitorowania wydajności, zaawansowane wbudowane funkcje bezpieczeństwa Keycloak pomagają chronić przed atakami phishingowymi poprzez analizę wzorców zdarzeń. Zdarzenia w Keycloak umożliwiają administratorom definiowanie niestandardowych odpowiedzi na określone działania użytkowników, takie jak resetowanie hasła po nieudanych próbach logowania — często będące wskaźnikiem aktywności phishingowej.

Przykładem funkcji bezpieczeństwa jest adaptacyjne uwierzytelnianie, które modyfikuje proces logowania użytkownika na podstawie wcześniejszych zachowań. Na przykład, jeśli użytkownik prosi o zresetowanie hasła bez wcześniejszych nieudanych prób logowania, system może uruchomić dodatkowy krok uwierzytelnienia, taki jak uwierzytelnianie dwuskładnikowe (2FA).

Tworzenie i dostosowywanie polityki bezpieczeństwa

Podczas wdrażania tych funkcji kluczowe jest określenie, kiedy działania użytkownika powinny budzić podejrzenia. Na przykład resetowanie hasła bez wcześniejszych nieudanych prób logowania może sygnalizować phishing, podczas gdy reset po wielu nieudanych logowaniach jest bardziej rutynowy. Można zdefiniować niestandardową politykę bezpieczeństwa, która będzie określać: „Jeśli użytkownik żąda resetowania hasła bez nieudanych logowań w ciągu ostatnich 3 minut, wymagana jest autoryzacja 2FA”.

Te mechanizmy adaptacyjnego uwierzytelniania zmniejszają obciążenie wynikające z wieloskładnikowego uwierzytelniania (MFA), jednocześnie utrzymując wysoki poziom bezpieczeństwa. Dzięki skonfigurowaniu systemu zdarzeń i alertów w Keycloak, organizacje mogą skuteczniej wykrywać nietypowe zachowania i szybciej reagować na potencjalne zagrożenia.

Keycloak to wszechstronne narzędzie, które wspiera zarówno monitorowanie wydajności, jak i zwiększone bezpieczeństwo. Integracja z narzędziami takimi jak Grafana pozwala administratorom śledzić kluczowe parametry systemowe, a zaawansowane mechanizmy oparte na zdarzeniach oraz adaptacyjne uwierzytelnianie wzmacniają ochronę przed phishingiem i innymi zagrożeniami. Odpowiednia konfiguracja tych funkcji może znacznie zwiększyć poziom bezpieczeństwa i poprawić czas reakcji na incydenty.

Artykuł Keycloak: wskazówki dotyczące monitorowania i ochrony przy użyciu wbudowanych narzędzi konfiguracyjnych pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 6192 Przewodnik integracji Keycloak: Logowanie przez platformy społecznościowe https://inero-software.com/pl/przewodnik-integracji-keycloak-logowanie-przez-platformy-spolecznosciowe/ Wed, 11 Sep 2024 13:42:01 +0000 https://inero-software.com/?p=6115  

Artykuł Przewodnik integracji Keycloak: Logowanie przez platformy społecznościowe pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>  

W poprzedniej publikacji pokazaliśmy, jak wdrożyć niestandardowe motywy w Keycloak i jak mogą one pomóc w zapobieganiu atakom phishingowym. W tym razem skupimy się na tym, jak włączyć logowanie społecznościowe za pomocą Keycloak, przedstawiając krok po kroku integrację z platformami, takimi jak Google. Niezależnie od tego, czy chcesz uprościć uwierzytelnianie, czy zwiększyć bezpieczeństwo, ten wpis przeprowadzi Cię przez kluczowe kroki konfiguracji i zarządzania logowaniem społecznościowym w Twojej aplikacji.

 

Jak to działa

Ogólna idea logowania społecznościowego jest dość prosta jako koncept: kiedy użytkownicy uzyskują dostęp do naszej aplikacji, mogą wybrać dostawcę sieci społecznościowej, takiego jak Google lub Facebook, do uwierzytelnienia zamiast ręcznego definiowania loginów i haseł. Następnie aplikacja wysyła żądanie logowania do wybranej platformy, a po potwierdzeniu tożsamości użytkownika przez sieć społecznościową, użytkownik uzyskuje dostęp do aplikacji i jest natychmiast zalogowany.

  1. Użytkownik, który nie jest jeszcze uwierzytelniony, próbuje uzyskać dostęp do chronionego zasobu w aplikacji klienckiej. Aplikacja przekierowuje przeglądarkę do Keycloak, który działa jako pośrednik tożsamości, a następnie ponownie przekierowuje użytkownika do jednego z dostawców tożsamości.
  2. Na stronie logowania prezentowana jest lista dostępnych dostawców tożsamości (takich jak Google, Facebook itp.), zgodnie z konfiguracją danego realm’u.
  3. Użytkownik wybiera dostawcę tożsamości, po czym jest przekierowywany na stronę logowania wybranego dostawcy, gdzie może podać swoje dane uwierzytelniające. Konfiguracja dostawcy tożsamości, w tym właściwości połączenia, została wcześniej ustawiona przez administratora za pomocą konsoli administracyjnej.
  4. Po pomyślnym uwierzytelnieniu użytkownik zostaje przekierowany z powrotem do Keycloak z odpowiedzią uwierzytelniającą, co ostatecznie prowadzi do uzyskania tokenu dostępu. Keycloak weryfikuje tożsamość i tworzy nowego użytkownika lub pomija ten krok, jeśli użytkownik już istnieje
  5. Gdy Keycloak pomyślnie uwierzytelni użytkownika, wydaje swój własny token umożliwiający dostęp do chronionego zasobu i przekierowuje użytkownika z powrotem do aplikacji klienckiej.

 

Kluczowe zalety

  • Użytkownicy mogą zarejestrować się i uzyskać dostęp do Twojej aplikacji w zaledwie kilku kliknięciach. Aplikacje mogą korzystać z danych profilowych zamiast zmuszać użytkowników do ręcznego wprowadzania tych informacji w formularzach, co może przyspieszyć i uprościć proces rejestracji.
  • Logowanie społecznościowe zmniejsza ryzyko korzystania ze słabych haseł i oferuje zaawansowane funkcje bezpieczeństwa, takie jak uwierzytelnianie wieloskładnikowe (MFA). W wielu aplikacjach użytkownicy często nie aktualizują swoich profili, jednak zazwyczaj dbają o to, aby ich dane były aktualne w sieciach społecznościowych. Dlatego po wdrożeniu logowania społecznościowego możemy założyć, że dane użytkowników, które zbieramy, są wiarygodne, ponieważ pochodzą bezpośrednio z ich regularnie aktualizowanych profili.
  • Dostawcy sieci społecznościowych często oferują dodatkowe dane użytkownika, takie jak lokalizacja, zainteresowania i inne informacje wykraczające poza podstawowe dane profilowe. Dzięki temu możemy skuteczniej dostarczać użytkownikom spersonalizowane treści, co pozwala na bardziej ukierunkowane interakcje i rekomendacje treści.
  • Dostawca sieci społecznościowej jest również odpowiedzialny za weryfikację adresu e-mail użytkownika. Jeśli dostawca udostępnia te informacje, otrzymujemy prawidłowy adres e-mail, a nie potencjalnie fałszywe, które użytkownicy mogą podać podczas rejestracji w aplikacjach internetowych. Ponadto dostawca zarządza procesem odzyskiwania hasła, co zmniejsza potrzebę zajmowania się tym aspektem przez Twoją aplikację, upraszczając zarządzanie użytkownikami.Dane zazwyczaj pokazują poprawę w konwersji, a w niektórych przypadkach bardzo znaczący wzrost. W artykule przygotowanym przez zespół marketingowy Auth0 stwierdzono, że logowanie społecznościowe może zwiększyć wskaźnik rejestracji nawet o 50%.

Nasze doświadczenie w rozwijaniu DocsQuality pozwala nam wierzyć w zasadność tych założeń. Po wdrożeniu logowania za pomocą mediów społecznościowych zaobserwowaliśmy kilkukrotny wzrost liczby nowych użytkowników.

 

Potencjalne wady 

Rozważając metody logowania społecznościowego w Keycloak, warto przemyśleć ich potencjalne wady, które przyczyniły się do zauważalnego spadku ich popularności w ostatnim czasie. Oto kilka kluczowych obaw:

  • Chociaż dość rzadkie, istnieje ryzyko, że logowanie społecznościowe może stać się jednym punktem awarii. Jeśli dane logowania do mediów społecznościowych użytkownika zostaną skompromitowane, hakerzy mogą potencjalnie uzyskać dostęp do Twojej platformy oraz powiązanych kont.
  • Użytkownicy często martwią się o to, jak platformy mediów społecznościowych zarządzają ich danymi. To zaniepokojenie może sprawić, że będą niechętni do udzielania dodatkowym aplikacjom dostępu do swoich informacji, co może prowadzić do mniejszego wykorzystania funkcji logowania społecznościowego.
  • Protokoły logowania społecznościowego, takie jak OpenID Connect, są otwarte i interoperacyjne, ale ich wdrożenie może być wyzwaniem. Nawet doświadczeni programiści mogą uznać integrację tych standardów za czasochłonną i złożoną.

Aby zaradzić tym obawom, ważne jest promowanie dobrych praktyk bezpieczeństwa w mediach społecznościowych wśród użytkowników. Zachęcanie do stosowania silnych, unikalnych haseł oraz dwuskładnikowego uwierzytelniania dla kont w mediach społecznościowych. Może to pomóc w zminimalizowaniu ryzyka i zwiększyć bezpieczeństwo metod logowania. Na szczęście, ostatni aspekt jest w dużej mierze rozwiązany przez Keycloak, który upraszcza wdrażanie tych protokołów. Dlatego w naszym przykładzie skupimy się na wykorzystaniu Keycloak do uproszczenia procesu logowania społecznościowego.

 

Tu zaczynamy

W tym przykładzie użyjemy aplikacji, którą przygotowaliśmy w poprzednim wpisie na blogu, w którym dostosowaliśmy motywy. Początkowy widok wygląda następująco:

Teraz możesz zalogować się do jednej z konsol dostawców tożsamości, takich jak GitHub w tym przypadku.

Przejdź do   Settings -> Developer settings -> OAuth Apps. Kliknij New OAuth App i wypełnij niezbędne informacje:

– Nazwa aplikacji (Application Name)
– URL strony głównej (Homepage URL)
– URL przekierowania autoryzacji (Authorization callback URL)

Ostatni adres powinien mieć format:<your-keycloak-domain>/auth/realms/<your-realm>/broker/github/endpoint.. Do celów testowych spróbujemy skonfigurować środowisko lokalne, używając portów 4200 i 8080. Po wypełnieniu formularza kliknij Register Application. GitHub wygeneruje Client ID oraz Client Secret.

Teraz przejdź do konsoli administracyjnej Keycloak. W wybranym realmie, nawiguj do sekcji Identity Providers z menu po lewej stronie. Z rozwijanego menu Add provider wybierz GitHub.

Wklej Client ID oraz Client Secret, które otrzymałeś od GitHub. Jeśli to konieczne, wybierz dodatkowe opcje, takie jak przechowywanie tokenów wydanych przez dostawcę (na przykład w celu dalszych zapytań do zasobów akceptujących ten token), automatyczna weryfikacja adresów e-mail lub inicjowanie określonego przepływu uwierzytelnienia po pomyślnym logowaniu. Po włączeniu dostawcy logowania społecznościowego w konsoli, strona logowania powinna wyglądać tak:

Po kliknięciu przycisku GitHub powinniśmy zobaczyć standardowe żądanie autoryzacji OAuth. Dzięki temu dostawcy logowania społecznościowego, tacy jak GitHub, mogą oznaczyć tę aplikację jako zweryfikowaną i automatycznie zezwalać na dalsze próby logowania w przyszłości.

Po zatwierdzeniu autoryzacji powinniśmy zostać przekierowani z powrotem do aplikacji.

Podsumowując

Przeszliśmy przez cały proces rejestracji dostawcy tożsamości w Keycloak, i jak widać, jest to dość proste. Jest to również świetny punkt wyjścia do dalszej nauki funkcji protokołu OAuth, obsługi niestandardowych dostawców tożsamości oraz wdrażania rozwiązań Single Sign-On (SSO), które być może omówimy w kolejnych wpisach.

Takie podejście nie tylko upraszcza proces rejestracji i zwiększa bezpieczeństwo, ale także zapewnia spójny i łatwy do zarządzania sposób łączenia się z różnymi platformami. Chociaż każdy dostawca może mieć specyficzne niuanse konfiguracyjne, cały proces konfiguracji pozostaje prosty i w dużej mierze podobny na różnych stronach internetowych. Dzięki zmniejszeniu barier wejścia dla użytkowników oraz efektywnemu, nowoczesnemu zarządzaniu uwierzytelnieniem, Keycloak umożliwia płynniejsze i bezpieczniejsze doświadczenie użytkownika.

Artykuł Przewodnik integracji Keycloak: Logowanie przez platformy społecznościowe pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 6115 Jak tworzyć i stosować własne motywy w Keycloak? https://inero-software.com/pl/jak-tworzyc-i-stosowac-wlasne-motywy-w-keycloak/ Mon, 02 Sep 2024 12:59:16 +0000 https://inero-software.com/?p=6079  

Artykuł Jak tworzyć i stosować własne motywy w Keycloak? pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>  

W naszym ostatnim poście (Integracja Keycloak i Lightweight Directory Access Protocol) omówiliśmy to, jak łatwo importować użytkowników do naszego serwera Keycloak z innego systemu za pomocą protokołu LDAP. Tym razem przyjrzymy się bliżej wizualnemu aspektowi tego rozwiązania, dostosowując arkusz stylów naszej aplikacji.

Wbudowane motywy

Keycloak oferuje wiele możliwości dostosowywania interfejsu użytkownika i wyglądu za pomocą tzw. „motywów”. Ich dostosowywanie  pozwala nam dopasować wygląd i „user experience” aplikacji do określonych potrzeb, wzmacniając przy tym wizualną tożsamość marki.

Keycloak zawiera kilka wbudowanych motywów dołączonych do swojej dystrybucji. Dostępne motywy obejmują motyw bazowy, który dostarcza szablony HTML i zestawy komunikatów, z których korzystają wszystkie inne motywy, w tym również te niestandardowe. Motyw keycloak zawiera obrazy i arkusze stylów do ulepszania CSS stron i jest używany domyślnie, jeśli nie dostarczono niestandardowego motywu. Dodatkowo, motyw keycloak.v2 to motyw oparty na React, zaprojektowany dla nowego Admin Console, podczas gdy starsza wersja konsoli zostanie wycofana. Modyfikowanie istniejących motywów nie jest zalecane; zamiast tego preferowane jest utworzenie nowego motywu, który rozszerza jeden z istniejących.

Dla pełnej personalizacji, idealnym rozwiązaniem jest skopiowanie zawartości z folderu base, ale w przypadku częściowej modyfikacji bardziej praktyczne jest rozpoczęcie od zawartości z katalogu keycloak. Jak już wspomnieliśmy, do nowego niestandardowego folderu powinny zostać dodane tylko te części motywu, które wymagają nadpisania.

 

Szablony FreeMarker

Motywy FTL w Keycloak odnoszą się do szablonów napisanych w języku Freemarker Template Language, które definiują wygląd i wrażenia z różnych stron i wiadomości e-mail w Keycloak. Te motywy pozwalają na dostosowanie wszystkiego, od stron logowania, przez komunikaty o błędach, po interfejsy zarządzania kontem.

Motywy w Keycloak są zazwyczaj zorganizowane w cztery główne kategorie:

– Login: Dostosowuje wygląd stron logowania, rejestracji i resetowania hasła.
– Account: Modyfikuje interfejs zarządzania kontem użytkownika.
– Email: Dostosowuje treść i wygląd wiadomości e-mail wysyłanych przez Keycloak (np. e-maile weryfikacyjne, e-maile resetowania hasła).
– Admin: Pozwala na dostosowanie konsoli administracyjnej Keycloak.

Przyjrzyjmy się kilku istotnym szablonom:

– login.ftl – najczęściej dostosowywany szablon w Keycloak. Odpowiada za renderowanie strony logowania, na której użytkownicy wprowadzają swoje dane uwierzytelniające (nazwa użytkownika/adres e-mail i hasło), aby uzyskać dostęp do Twojej aplikacji.
– register.ftl – używany na stronie rejestracji, gdzie nowi użytkownicy mogą utworzyć konto.
– login-reset-password.ftl – używany, gdy użytkownik inicjuje proces resetowania hasła.
– login-update-password.ftl – używany, gdy użytkownik musi zaktualizować swoje hasło, albo po udanym resetowaniu hasła, albo ze względu na wymóg polityki (np. okresowe zmiany hasła).

Właściwości motywu

Oprócz szablonów HTML, zestawów komunikatów, obrazów i arkuszy stylów, motyw Keycloak zawiera jeszcze kilka innych elementów, takich jak właściwości motywu. Każdy typ motywu posiada własny plik konfiguracyjny. Na przykład, rozważmy plik theme.properties z motywu logowania:

parent=keycloak
import=common/keycloak

styles=css/login.css css/tile.css
stylesCommon=web_modules/@fortawesome/fontawesome-free/css/icons/all.css 
web_modules/@patternfly/react-core/dist/styles/base.css 
web_modules/@patternfly/react-core/dist/styles/app.css 
node_modules/patternfly/dist/css/patternfly.min.css 
node_modules/patternfly/dist/css/patternfly-additions.min.css lib/pficon/pficon.css

Ten plik pokazuje, że motyw dziedziczy po motywie bazowym, aby korzystać z jego szablonów HTML i zestawów komunikatów. Importuje również motyw common, aby włączyć dodatkowe style. Ponadto, motyw określa własny arkusz stylów, css/login.css.

 

Wiadomości i i18n

Keycloak wspiera internacjonalizację w motywach, pozwalając na tworzenie plików właściwości specyficznych dla danego języka, które przechowują tłumaczenia tekstów używanych w szablonach. Te pliki, nazwane messages_<locale>.properties, zawierają pary klucz-wartość, gdzie klucz reprezentuje element tekstowy, a wartość to jego tłumaczenie na docelowy język. W naszych szablonach FTL odwołujemy się do tych kluczy za pomocą dyrektywy ${msg()}, co pozwala naszej aplikacji automatycznie wyświetlać odpowiednie tłumaczenie.

Powinno to odnosić się do języka aktualnie wybranego przez użytkownika. Keycloak określa język na podstawie ustawień przeglądarki, pod warunkiem że język ten jest skonfigurowany w systemie.

Na przykład na stronie logowania można dostarczyć tłumaczenie nagłówka „Zaloguj się na swoje konto,” który domyślnie może nie być przetłumaczony na języki takie jak niderlandzki czy hiszpański. Aby to zrobić, można edytować pole loginAccountTitle w pliku messages, dodając odpowiednie tłumaczenie dla każdego języka. Dzięki temu, gdy użytkownicy wybiorą swój język, zobaczą przetłumaczoną wersję w interfejsie logowania.

messages.nl
loginAccountTitle=Inloggen

messages.es
loginAccountTitle=Iniciar sesi\u00F3n

messages.en
loginAccountTitle=Sign In

Ostatnim krokiem jest skonfigurowanie ustawień internacjonalizacji dla Twojej domeny zgodnie z dostarczonym zrzutem ekranu. To zapewni, że dodane tłumaczenia, takie jak dla pola loginAccountTitle, będą prawidłowo stosowane w zależności od wybranego przez użytkownika języka.

Oryginalna wersja angielska oraz ostateczny wynik dla wersji hiszpańskiej i niderlandzkiej są pokazane poniżej.

Dostosowywanie naszego motywu

Przed rozpoczęciem dostosowywania motywu upewnij się, że masz działającą instancję Keycloak. Będziesz potrzebować dostępu do plików serwera Keycloak oraz uprawnień administracyjnych, aby zastosować motyw. Jeśli uruchamiasz Keycloak w kontenerze Docker, możesz użyć montowania woluminu, aby uzyskać dostęp do plików motywu na swoim lokalnym komputerze.

Utwórz strukturę katalogów dla swojego niestandardowego motywu, postępując zgodnie z poniższym przykładem. Domyślne pliki motywu znajdują się w dystrybucji serwera Keycloak w katalogu themes/keycloak/login. Aby rozpocząć, skopiuj te domyślne pliki motywu z dystrybucji Keycloak do swojego niestandardowego katalogu motywu.

Zaczniemy od podstawowej strony logowania, jak pokazano poniżej:

 

Zlokalizuj i edytuj plik CSS, który kontroluje stylizację strony logowania. Zazwyczaj nosi on nazwę login.css i znajduje się w katalogu resources/css w Twoim niestandardowym motywie. Teraz możemy zmienić właściwość background i dodać własny plik .png.

.login-pf-page::before {
content: "";
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;  
opacity: 1;
background: rgba(255, 255, 255, 0.4) url("../img/fb-background.png") no-repeat;
background-size: cover;
     z-index: -1;
}

Oprócz zmiany tła, możemy również zmodyfikować kolor górnej krawędzi ekranu logowania oraz kolor przycisku logowania. Następnie możemy dodać niestandardowe logo. Można to zrobić, modyfikując następujące klasy:

pf-m-primary {
color: black !important;
background-color: #B646AE !important;
}

.card-pf {
margin: 0 auto;
box-shadow: var(--pf-global--BoxShadow--lg);
padding: 0 20px;
max-width: 500px;
border-top: 4px solid;
border-color: #B646AE;
background-color: #fff;
}

#kc-header-wrapper::before {
content: "";
position: relative;
margin: auto;
display: block;
width: 200px;
background: url("../img/fb-logo.png") no-repeat;
background-size: auto;
}

Ostatnim krokiem będzie aktywacja niestandardowego motywu w konsoli administratora dla konkretnej domeny.

Po wprowadzeniu powyższych zmian, ostateczny efekt powinien wyglądać następująco:

Ostateczny rezultat może się jednak różnić w zależności od użycia różnych plików graficznych i definicji kolorów. Dostosowując te elementy, możesz łatwo osiągnąć unikalny wygląd, który będzie zgodny z Twoją marką i preferencjami w zakresie designu. Przy użyciu różnych zasobów może to wyglądać tak:

Jak widać, dostosowywanie motywu Keycloak jest dość proste.

Do tej pory omówiliśmy, jak dostosować motywy Keycloak poprzez modyfikację elementów wizualnych. Przedstawiliśmy podstawy wbudowanych motywów Keycloak, które obejmują opcje dostosowywania strony logowania. W większości przypadków proces ten polega na skopiowaniu domyślnych plików motywu, modyfikacji CSS w celu wprowadzenia zmian w stylizacji, takich jak obrazy tła i kolory przycisków, oraz edycji szablonów FreeMarker w celu dostosowania układu. Dodatkowo, omówiliśmy, jak używać pliku theme.properties do konfiguracji niestandardowego motywu. Teraz mamy kilka podstawowych narzędzi, aby zmodyfikować wygląd Keycloak i lepiej dostosować go do potrzeb marki oraz użytkowników.

 

Podsumowanie

Możesz w pełni dostosować stronę logowania, aby upewnić się, że nie przypomina ona domyślnego motywu Keycloak. To nie tylko poprawia doświadczenie użytkownika, ale także pomaga użytkownikom łatwiej odróżnić autentyczną stronę logowania od potencjalnych prób phishingu.

Keycloak umożliwia również dostosowanie treści i układu wiadomości e-mail (np. szablonów resetowania hasła). Tworząc unikalne, markowe treści, możesz pomóc użytkownikom rozpoznawać autentyczne prośby o resetowanie hasła, zmniejszając ryzyko stania się ofiarą ataków phishingowych, które naśladują takie wiadomości.

Poza wizualną personalizacją, motywy wspierają internacjonalizację, co pozwala na zapewnienie użytkownikom spójnych wrażeń w ich rodzimym języku. Może to obejmować tłumaczenie wszystkich tekstów na stronach logowania oraz w wiadomościach e-mail na odpowiedni język, co zwiększa użyteczność dla globalnych użytkowników.

Ogólnie rzecz biorąc, dostosowywanie motywów oferuje szerokie możliwości poprawy doświadczenia użytkownika i bezpieczeństwa Twojego systemu IAM.

Czy potrzebujesz pomocy we wdrożeniu, aktualizacji lub szkolenia z Keycloak? Skontaktuj się ze mną.

           

Andrzej Chybicki 

CEO, Inero Software Sp. z o. o.
@ andy@inero-software.com
Tel: +48 695 875 588

 

 

 

 

Artykuł Jak tworzyć i stosować własne motywy w Keycloak? pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 6079 Integracja Keycloak i Lightweight Directory Access Protocol https://inero-software.com/pl/integracja-keycloak-i-lightweight-directory-access-protocol/ Fri, 26 Jul 2024 11:33:09 +0000 https://inero-software.com/?p=6038 Artykuł Integracja Keycloak i Lightweight Directory Access Protocol pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]>

Z poprzednich wpisów wiemy, że Keycloak daje nam przestrzeń do zarządzania tożsamościami użytkowników, zabezpieczania aplikacji i integracji z różnymi dostawcami. Dlatego jedną z jego kluczowych funkcji jest zdolność do integracji z katalogami Lightweight Directory Access Protocol (LDAP). Ten artykuł stanowi krótki przewodnik po eksporcie kont do federowanych realm’ów poprzez migrację użytkowników z ich poświadczeniami oraz importowanie grup za pomocą niestandardowych mapowań.

 

Zrozumienie usług katalogowych

Usługa katalogowa jest zbudowana w celu zarządzania i przechowywania danych w formacie par „klucz-wartość”. Ta struktura jest zoptymalizowana pod kątem operacji odczytu, co sprawia, że jest szczególnie dobrze dostosowana do informacji, które są często dostępne, ale rzadko aktualizowane. Dane w takim katalogu są często opisowe, służąc do szczegółowego przedstawienia różnych atrybutów jednostek.

Na przykład, wyobraź sobie używanie usługi katalogowej do zarządzania książką adresową. Każdy wpis w tej książce adresowej reprezentuje indywidualną osobę, a pary klucz-wartość przechowują jej dane kontaktowe, miejsce zatrudnienia i inne istotne informacje. Taka metoda organizacji danych jest szczególnie korzystna przy obsłudze informacji jakościowych i opisowych, które muszą być łatwo dostępne.

LDAP działa przy użyciu hierarchicznej struktury katalogowej, co umożliwia efektywne przechowywanie i dostęp do danych. Ten protokół jest powszechnie używany do śledzenia szczegółów organizacyjnych, w tym informacji o użytkownikach, zasobach i różnych jednostkach. Jego model wspiera elastyczne podejście do definiowania i zarządzania tymi jednostkami i ich atrybutami, zapewniając, że usługa katalogowa pozostaje dostosowana do różnych potrzeb organizacyjnych i skalowalna wraz z rosnącą ilością danych.

Kluczowe funkcje LDAP

    • Standaryzowany protokół: LDAP jest szeroko rozpoznawanym protokołem, wspieranym przez liczne usługi katalogowe, w tym Microsoft Active Directory, OpenLDAP i Apache Directory Server.
    • Struktura hierarchiczna: Katalogi LDAP są strukturyzowane hierarchicznie, podobnie jak drzewo, co ułatwia efektywną organizację i wyszukiwanie informacji.
    • Skalowalność: LDAP jest zoptymalizowany do zarządzania dużą ilością operacji odczytu i wyszukiwania, co czyni go idealnym dla środowisk korporacyjnych na dużą skalę z rozległymi bazami użytkowników.

Architektura LDAP 

Zrozumienie architektury LDAP jest kluczowe dla maksymalnego wykorzystania jego możliwości. Główne komponenty obejmują:

 

Drzewo informacji katalogowej (DIT)

Hierarchiczna struktura katalogu składa się z wpisów, z których każdy reprezentuje obiekt, taki jak użytkownik, grupa czy urządzenie, i jest jednoznacznie identyfikowany przez nazwę wyróżniającą (Distinguished Name, DN). DIT jest zorganizowany hierarchicznie, z korzeniem drzewa na szczycie. Poniżej korzenia znajdują się różne poziomy węzłów, z których każdy reprezentuje różne typy jednostek, takie jak organizacje, departamenty i indywidualni użytkownicy. Taka  struktura pozwala na efektywne i logiczne zarządzanie oraz dostęp do danych katalogowych.

Atrybuty / Wpisy

Atrybuty są grupowane w jednostki zwane klasami obiektów (objectClasses), które są zbiorami powiązanych atrybutów przydatnych do opisywania określonych jednostek. Tworząc wpis, można wykorzystać atrybuty zdefiniowane przez klasę obiektów, przypisując pożądaną klasę obiektów do wpisu. W rzeczywistości atrybut objectClass jest jedynym atrybutem, który można ustawić bez konieczności specyfikowania dodatkowych klas obiektów.

Na przykład, tworząc wpis reprezentujący osobę, włączenie klasy obiektów—oraz wszelkich pochodnych klas obiektów—umożliwia korzystanie ze wszystkich atrybutów związanych z tą konkretną klasą obiektów. W takim wpisie można ustawić atrybuty takie jak cn (common name) dla nazwy zwyczajowej, description dla krótkiego opisu wpisu oraz sn dla nazwiska.

Schemat 

Atrybuty i klasy obiektów są grupowane razem w tzw, schemat. Mechanizm ten dba o spójność i integralność w drzewie katalogowym, którego używamy. W przeciwieństwie do relacyjnych baz danych, te schematy to po prostu zbiory powiązanych obiektów i atrybutów. Pojedyncze drzewo informacji katalogowej (DIT) może wykorzystywać wiele schematów do tworzenia potrzebnych wpisów i atrybutów.

Schematy zazwyczaj zawierają dodatkowe specyfikacje atrybutów i mogą wymagać atrybutów określonych w innych schematach. Na przykład, klasa obiektów person wymaga włączenia atrybutu nazwiska (sn) dla wszelkich powiązanych wpisów. W przypadkach, gdy te atrybuty są nieobecne na serwerze LDAP, schemat zawierający te definicje może zostać zintegrowany ze strukturą drzewa serwera.

 

Odmiany protokołu

LDAP to w istocie protokół, który definiuje interfejs komunikacyjny do pracy z usługami katalogowymi, często określanymi jako LDAP lub ldap. Istnieje kilka odmian formatu protokołu LDAP, które warto zauważyć:

    • ldaps://: Ta odmiana oznacza LDAP zabezpieczony za pomocą SSL/TLS. Chociaż standardowy ruch LDAP jest nieszyfrowany, większość implementacji LDAP obsługuje szyfrowanie. Jednakże użycie SSL/TLS do szyfrowania LDAP jest przestarzałe, a zalecanym sposobem zabezpieczenia połączeń LDAP jest STARTTLS.
    • ldap://: Jest to standardowy protokół LDAP, który zapewnia strukturalny dostęp do usługi katalogowej.
    • ldapi://: Ta odmiana oznacza LDAP przez IPC (Inter-Process Communication). Zazwyczaj używany do bezpiecznych lokalnych połączeń z systemem LDAP do celów administracyjnych, na przykład przy użyciu wewnętrznych gniazd.

Chociaż wszystkie trzy formaty korzystają z protokołu LDAP, dwa z nich rozszerzają możliwości tej komunikacji.

 

Powrót do realm i konfiguracja LDAP

Po zapoznaniu się z teorią działania LDAP, możemy wrócić do realm, o którego konfiguracji wspominaliśmy w poprzednim poście (znajdziesz go tu), i przejść do zakładki User Federation, w której możemy wprowadzić niezbędne dane, aby połączyć się z serwerem LDAP dostarczonym przez przykładowego dostawcę.

Niezbędne informacje, których potrzebujemy, obejmują adres URL połączenia, nazwę wyróżniającą administratora LDAP (bind DN) oraz nazwę wyróżniającą użytkowników (users DN), która jest nadrzędna dla wszystkich użytkowników w drzewie LDAP. Większość atrybutów, takich jak nazwa użytkownika LDAP, UUID LDAP lub klasy obiektów użytkowników, można pozostawić na domyślnych wartościach, ponieważ są one zgodne z wymaganiami naszego dostawcy serwera LDAP.

Po zsynchronizowaniu użytkowników widzimy, że w zakładce Users pojawiły się dwa nowe wpisy. Synchronizacja z LDAP oferuje więcej możliwości niż tylko prosty import kont użytkowników. Sprawdźmy, jak działają mapery (mappers).

Przykład 1: hardcoded-attribute-mapper

Możemy oznaczyć importowanych użytkowników, przypisując im niestandardowy atrybut. Można to zrobić za pomocą hardcoded-attribute-mapper, który przypisuje nowy atrybut, authenticationMethod, każdemu nowemu użytkownikowi i nadaje mu wartość „ldap„.

W oknie Użytkownicy (Users) -> Szczegóły użytkownika (User Details) -> zakładka Atrybuty (Attributes), możemy zobaczyć, że użytkownicy pochodzący z LDAP rzeczywiście mają ten atrybut. Może on na przykład zostać uwzględniony w tokenach dostępu.

Przykład 2: group-ldap-mapper

Często w LDAP zdefiniowany jest system ról lub grup, do których należą importowani użytkownicy. Keycloak może również importować grupy i automatycznie przypisywać do nich wspomnianych użytkowników. Aby to zrobić, możemy skonfigurować kolejny mapper, tym razem typu group-ldap-mapper, jak pokazano na poniższym obrazku:

W tym przypadku nazwa wyróżniająca dla grup będzie taka sama jak DN dla wszystkich użytkowników, czyli:

ou=Users,o=66a20b93d2f2fc6db2e89ff3,dc=jumpcloud,dc=com

Grupy przechowywane w LDAP są zdefiniowane przez klasę obiektów o nazwie groupOfNames, co oznacza, że atrybutem reprezentującym członkostwo po stronie LDAP będzie zazwyczaj member.

Jak widzimy, trzy grupy zostały poprawnie zaimportowane, wraz z relacjami między grupą a jej użytkownikami. Dzięki temu administratorzy LDAP mogą łatwo uzyskać odpowiednie uprawnienia po naszej stronie realm. Następnie możemy powiązać określone role z daną grupą, aby jeszcze wygodniej zarządzać dostępem do zasobów.

Podsumowanie

Integracja Keycloak z LDAP to potężne narzędzie do zarządzania tożsamościami i bezpieczeństwem w organizacji. Ta integracja pozwala na efektywną synchronizację użytkowników i grup z LDAP, umożliwiając centralne zarządzanie uprawnieniami i dostępem do zasobów. Kluczowe kroki obejmują skonfigurowanie połączenia LDAP, synchronizację danych oraz użycie mapperów do dostosowania importowanych informacji, takich jak atrybuty i grupy użytkowników. Ważne jest, aby zrozumieć architekturę i działanie LDAP, aby w pełni wykorzystać jego możliwości. Implementacja LDAP z Keycloak nie tylko usprawnia zarządzanie kontami, ale także zwiększa bezpieczeństwo i upraszcza integrację z istniejącymi systemami. Korzystając z mapperów, możemy dodatkowo dostosować sposób importowania i wykorzystywania informacji w naszym systemie, co prowadzi do lepszej organizacji i kontroli dostępu w organizacji.

Artykuł Integracja Keycloak i Lightweight Directory Access Protocol pochodzi z serwisu Inero Software - Rozwiązania IT i Konsulting.

]]> 6038