Konfiguracja SSO
Konfiguracja SSO
Ten przewodnik jest przeznaczony dla administratora IT łączącego firmowego dostawcę tożsamości (IdP) z InterMIND. Po konfiguracji członkowie logują się ze standardowej strony logowania: Zaloguj się przez SSO → służbowy adres e-mail → Twój IdP → powrót do InterMIND. Aby zapoznać się z opisem nietechnicznym, zobacz stronę funkcji logowania jednokrotnego (SSO).
Dostępne w planach: Business i Enterprise Konfigurowane przez: właściciela zespołu lub administratora Protokół: Tylko OpenID Connect (OIDC). SAML 2.0 nie jest oferowany — Okta, Microsoft Entra ID i Google Workspace obsługują OIDC.
Wymagania wstępne
- Zweryfikowana domena — najpierw zweryfikuj swoją domenę e-mail za pomocą rekordu TXT w systemie DNS (zobacz Zarządzanie domenami). Logowanie przez SSO akceptuje tylko konta, których domena e-mail została zweryfikowana przez Twój zespół; to stanowi granicę dzierżawy.
- Dostawca IdP obsługujący OIDC z wykrywaniem (discovery) — musi udostępniać
/.well-known/openid-configurationpod adresem URL Issuer. Okta, Microsoft Entra ID i Google to obsługują.
Co zarejestrować w IdP
Utwórz aplikację internetową OIDC (OIDC Web Application) w swoim dostawcy IdP, podając:
| Ustawienie | Wartość |
|---|---|
| Redirect URI (callback) | https://intermind.com/api/auth/sso/callback — wyświetlane również na karcie SSO po wybraniu OIDC |
| Grant type | Authorization Code (PKCE S256 jest używany automatycznie) |
| Scopes | openid email profile |
Token ID wydawany przez Twojego dostawcę IdP musi zawierać adres email użytkownika, a domena tego adresu e-mail musi być jedną z Twoich zweryfikowanych domen — w przeciwnym razie logowanie zostanie odrzucone.
Następnie wypełnij kartę SSO na stronie integracji:
| Pole | Co wkleić |
|---|---|
| Display Name | Dowolna etykieta, którą Twoi członkowie rozpoznają |
| Issuer URL | Wystawca Twojego dostawcy IdP — adres URL, który udostępnia /.well-known/openid-configuration |
| Authorization URL | authorization_endpoint z tego dokumentu wykrywania (discovery) |
| Client ID / Client Secret | Z zarejestrowanej aplikacji |
Sekret klienta (Client Secret) jest szyfrowany w spoczynku i nigdy nie jest zwracany do przeglądarki po zapisaniu.
Okta
- Konsola administratora → Applications → Create App Integration → metoda logowania OIDC, typ aplikacji Web Application
- Sign-in redirect URI:
https://intermind.com/api/auth/sso/callback - Przypisz użytkowników lub grupy, które powinny mieć dostęp
- Skopiuj identyfikator Client ID i sekret Client Secret
- W InterMIND: Issuer URL = adres URL organizacji Okta (np.
https://acme.okta.comlub adres URL wystawcy Twojego serwera autoryzacji, taki jakhttps://acme.okta.com/oauth2/default, jeśli go używasz); Authorization URL =authorization_endpointz<issuer>/.well-known/openid-configuration
Microsoft Entra ID (Azure AD)
- Centrum administracyjne Entra → App registrations → New registration
- Platforma Web, identyfikator URI przekierowania
https://intermind.com/api/auth/sso/callback - Certificates & secrets → New client secret — natychmiast skopiuj Value (wartość) sekretu
- Client ID = Application (client) ID na stronie Overview
- Upewnij się, że token ID zawiera adres e-mail użytkownika: Token configuration → Add optional claim → ID → email
- W InterMIND: Issuer URL =
https://login.microsoftonline.com/<tenant-id>/v2.0; Authorization URL =https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
Google Workspace
Rejestracja aplikacji nie jest wymagana. Na karcie SSO wybierz typ dostawcy Google Workspace i zapisz — członkowie ze zweryfikowanych domen logują się za pomocą swojego konta Google i automatycznie dołączają do Twojego zespołu. (Możesz również połączyć Google jako ogólnego dostawcę OIDC z adresem URL wystawcy https://accounts.google.com, jeśli wolisz użyć jawnych poświadczeń klienta).
Testowanie połączenia
- Otwórz stronę logowania w oknie prywatnym/incognito
- Kliknij Zaloguj się przez SSO i wprowadź służbowy adres e-mail w Twojej zweryfikowanej domenie
- Zostaniesz przekierowany do swojego dostawcy IdP; po uwierzytelnieniu wrócisz do InterMIND jako zalogowany użytkownik
- Logowanie jest rejestrowane w dzienniku audytu zespołu (który można wyeksportować ze strony Users) jako
auth.loginz metodąsso
Rozwiązywanie problemów
| Objaw | Przyczyna |
|---|---|
| Komunikat „SSO is not configured” po wprowadzeniu adresu e-mail | Żadna włączona konfiguracja SSO nie pasuje do tej domeny e-mail — sprawdź, czy domena jest zweryfikowana, a karta SSO zapisana |
SSO login is not available: plan | Plan zespołu nie obejmuje już SSO |
SSO login is not available: domain-not-verified | Domena nadal oczekuje na weryfikację DNS |
SSO login is not available: config-incomplete | Brak identyfikatora Client ID lub sekretu Client Secret — zapisz ponownie kartę SSO |
SSO login is not available: type-unsupported | Zapisany typ dostawcy nie jest obsługiwany przez przepływ logowania — usuń konfigurację SSO i utwórz ją ponownie jako OIDC lub Google Workspace |
SSO IdP discovery failed | Adres URL Issuer jest nieprawidłowy lub nie udostępnia /.well-known/openid-configuration |
| Komunikat „login session expired, start again” | Między rozpoczęciem logowania a wywołaniem zwrotnym IdP minęło więcej niż 5 minut |
| Logowanie odrzucone po przekierowaniu przez IdP | IdP zwrócił adres e-mail spoza zweryfikowanych domen lub w ogóle brak oświadczenia (claim) email (Entra: dodaj opcjonalne oświadczenie dotyczące adresu e-mail) |
Właściwości bezpieczeństwa
Do kwestionariuszy bezpieczeństwa: przepływ SSO to usługa Authorization Code z elementami PKCE (S256), state i nonce; podpis tokena ID jest weryfikowany względem kluczy JWKS dostawcy IdP, wraz z wystawcą (issuer) i odbiorcą (audience); IdP jest autorytatywny tylko dla domen zweryfikowanych przez DNS — potwierdzenie dla dowolnego innego adresu e-mail nigdy nie tworzy sesji; sekret klienta OIDC jest szyfrowany w spoczynku; każde logowanie SSO trafia do dziennika audytu zespołu. Bramki planu, domeny i konfiguracji są egzekwowane po stronie serwera zarówno przy rozpoczynaniu logowania, jak i przy wywołaniu zwrotnym.