Nie mogę zalogować się przez SSO

VaultPAM obsługuje logowanie jednokrotne (SSO) za pośrednictwem OpenID Connect (OIDC). Gdy logowanie SSO kończy się niepowodzeniem, przyczyną źródłową jest niemal zawsze jedna z pięciu kategorii: błędna konfiguracja OIDC, rozbieżność zegarów między VaultPAM a IdP, brak prowizjonowania użytkownika w dostawcy tożsamości (Identity Provider), nieprawidłowy redirect URI lub ustawienie realmu Keycloak. Administratorzy powinni przeanalizować je w tej kolejności — błędna konfiguracja OIDC jest zdecydowanie najczęstszą przyczyną.

Objawy

• Przycisk SSO na stronie logowania przekierowuje do dostawcy tożsamości, ale następnie zwraca błąd.
• Komunikaty o błędach, które możesz zobaczyć:
  • invalid_client lub unauthorized_client
  • redirect_uri_mismatch
  • access_denied
  • invalid_grant: Session not active
  • User not found lub Account is not fully set up
  • Ogólna strona „Something went wrong” po przekierowaniu powrotnym z IdP
• Użytkownik może uwierzytelnić się po stronie IdP, ale VaultPAM nie loguje go.

Przyczyny

1. Błędna konfiguracja OIDC

Client ID, Client Secret lub adres URL wykrywania OIDC skonfigurowane w VaultPAM nie odpowiadają temu, co zostało zarejestrowane w dostawcy tożsamości.

Sprawdź: W Organization → Security → SSO Settings zweryfikuj:

• OIDC Issuer URL rozwiązuje się i zwraca prawidłowy dokument .well-known/openid-configuration.
• Client ID dokładnie odpowiada temu zarejestrowanemu w aplikacji IdP.
• Client Secret nie został zrotowany po stronie IdP bez aktualizacji w VaultPAM.

Napraw: Zaktualizuj niezgodne pole i zapisz. Przetestuj, próbując ponownie zalogować się przez SSO.

2. Rozbieżność zegarów między VaultPAM a IdP

Tokeny OIDC zawierają oświadczenia iat (issued-at) i exp (expiry). Jeśli zegary serwera VaultPAM lub IdP różnią się o więcej niż ±60 sekund, walidacja tokenu kończy się niepowodzeniem z błędem invalid_grant lub „Session not active”.

Sprawdź: Na hoście VaultPAM (lub węźle Kubernetes) uruchom:

date -u

Porównaj z zegarem IdP (widocznym w oświadczeniu iat zdekodowanego JWT lub sprawdzonym za pośrednictwem konsoli administracyjnej IdP). Różnica musi być mniejsza niż 60 sekund.

Napraw: Upewnij się, że oba systemy synchronizują zegary ze źródłem NTP. W systemie Linux: timedatectl set-ntp true. W Kubernetes zegar węzła jest dziedziczony z hosta maszyny wirtualnej — upewnij się, że warstwa hipernadzorcy ma skonfigurowany NTP.

3. Użytkownik nieprowizjonowany w IdP

Konto użytkownika istnieje w VaultPAM, ale nie zostało utworzone ani aktywowane w dostawcy tożsamości, lub adres e-mail konta IdP nie odpowiada adresowi e-mail konta VaultPAM.

Sprawdź: W konsoli administracyjnej IdP potwierdź, że konto użytkownika istnieje i jest aktywne. Zweryfikuj, że adres e-mail jest dokładnie zgodny (w niektórych IdP obowiązuje porównanie z rozróżnianiem wielkości liter).

Napraw: Utwórz lub aktywuj konto użytkownika w IdP albo zaktualizuj adres e-mail w jednym z systemów, aby zapewnić ich zgodność. Jeśli Twoja organizacja korzysta z prowizjonowania SCIM, potwierdź, że konektor prowizjonowania jest aktywny, a użytkownik należy do prowizjonowanej grupy.

4. Nieprawidłowy redirect URI

Redirect URI, który VaultPAM wysyła podczas przepływu OIDC Authorization Code, musi dokładnie odpowiadać jednemu z dozwolonych adresów redirect URI zarejestrowanych w aplikacji IdP. Nawet różnica w postaci końcowego ukośnika powoduje błąd redirect_uri_mismatch.

Sprawdź: W Organization → Security → SSO Settings zanotuj wyświetlany Callback URL. Otwórz rejestrację aplikacji IdP i zweryfikuj, że ten dokładny URI znajduje się na liście dozwolonych adresów redirect URI.

Napraw: Dodaj dokładny adres callback URL do listy dozwolonych adresów redirect URI aplikacji IdP i zapisz.

5. Ustawienia realmu Keycloak

Gdy VaultPAM korzysta z osadzonej lub samodzielnie hostowanej instancji Keycloak, błędnie skonfigurowane ustawienia realmu mogą uniemożliwić logowanie nawet wtedy, gdy klient OIDC jest poprawnie skonfigurowany.

Typowe problemy specyficzne dla Keycloak:

• Realm jest wyłączony lub w trybie tylko do odczytu.
• Access Type klienta jest ustawiony na public, podczas gdy VaultPAM oczekuje confidential.
• Wymagane zakresy openid, email lub profile nie są zmapowane w kliencie.
• Valid Redirect URIs w kliencie Keycloak nie zawiera adresu callback URL VaultPAM.

Sprawdź: Otwórz konsolę administracyjną Keycloak, przejdź do Realms → [nazwa realmu] → Clients → [klient VaultPAM] i zweryfikuj:

• Klient jest Enabled.
• Access Type to confidential.
• Valid Redirect URIs zawiera adres callback URL VaultPAM.
• Client Scopes zawierają openid, email oraz profile.

Napraw: Popraw ustawienia klienta Keycloak i zapisz. W przypadku większości zmian konfiguracji Keycloak ponowne uruchomienie nie jest wymagane.

Kroki rozwiązania

1. Otwórz Organization → Security → SSO Settings i zweryfikuj, że OIDC Issuer URL, Client ID oraz Client Secret dokładnie odpowiadają rejestracji aplikacji IdP.
2. Sprawdź zegary serwera na hoście VaultPAM oraz IdP. Jeśli rozbieżność przekracza 30 sekund, skonfiguruj NTP w obu systemach.
3. W konsoli administracyjnej IdP potwierdź, że konto użytkownika istnieje, jest aktywne, a adres e-mail odpowiada adresowi e-mail konta VaultPAM.
4. Potwierdź, że Callback URL wyświetlany w Organization → Security → SSO Settings znajduje się na liście dozwolonych adresów redirect URI w aplikacji IdP.
5. Jeśli korzystasz z Keycloak, otwórz konsolę administracyjną Keycloak i zweryfikuj, że klient jest włączony, access type to confidential, prawidłowe adresy redirect URI zawierają adres callback URL, a wymagane zakresy są zmapowane.
6. Po każdej zmianie wyczyść pliki cookie przeglądarki i ponów próbę logowania SSO z okna prywatnego/incognito, aby uniknąć zbuforowanego stanu sesji.

Ścieżka eskalacji

Jeśli przeanalizowałeś wszystkie pięć przyczyn, a logowanie SSO nadal kończy się niepowodzeniem:

1. Przechwyć pełny adres URL wyświetlany w pasku adresu przeglądarki w momencie niepowodzenia (zawiera on kod błędu i opis jako parametry zapytania).
2. Zbierz dziennik zdarzeń Keycloak lub IdP dla nieudanej próby uwierzytelnienia.
3. Zanotuj dokładny komunikat o błędzie widoczny na ekranie.
4. Otwórz zgłoszenie do pomocy technicznej, podając: typ i wersję Twojego IdP, adres URL błędu, fragment dziennika zdarzeń oraz potwierdzenie, które kroki już wykonałeś.

Powiązane artykuły

• Skonfiguruj MFA
• Mój kod MFA jest odrzucany
• Zaproś członka zespołu