Logowanie SSO

Przegląd

SSO pozwala ludziom z twojej organizacji wchodzić do admina Cmssy przez waszego dostawcę tożsamości, zamiast przez hasło w Cmssy. Cmssy mówi w OpenID Connect, więc Google Workspace, Microsoft Entra ID i Okta działają.

Składają się na to trzy rzeczy, konfigurowane w tej kolejności:

1. Dostawca tożsamości — wystawca, client id i client secret.
2. Jedna lub więcej domen e-mail, każda potwierdzona rekordem DNS TXT.
3. Opcjonalnie wymuszenie — osoby z zweryfikowanej domeny nie zalogują się już hasłem.

SSO należy do planu Enterprise. W pozostałych planach ekran tłumaczy, czym to jest, ale ustawienia pozostają zamknięte.

Zanim zaczniesz

• Musisz być właścicielem lub adminem organizacji.
• Potrzebujesz dostępu do strefy DNS domeny, którą chcesz zająć, żeby opublikować jeden rekord TXT.
• Potrzebujesz uprawnień do zarejestrowania aplikacji u swojego dostawcy.

Krok 1 — zarejestruj Cmssy u dostawcy

Utwórz aplikację OpenID Connect i ustaw redirect URI na:

https://www.cmssy.io/api/auth/sso/callback

Poproś o scope'y openid, email i profile. Dostawca da ci client id i client secret.

Google Workspace

Wystawca jest ten sam dla każdego tenanta:

https://accounts.google.com

Microsoft Entra ID

Wystawca jest per tenant — skopiuj tenant id z przeglądu rejestracji aplikacji:

https://login.microsoftonline.com/<tenant-id>/v2.0

Entra dla kont służbowych i szkolnych często nie wysyła claimu email_verified. Cmssy przyjmuje token bez tego claimu, bo kotwicą zaufania jest domena zweryfikowana niżej, a nie claim, który dostawca może wysłać albo nie. Token z email_verified: false nadal jest odrzucany.

Okta

https://<twoja-organizacja>.okta.com

Krok 2 — uzupełnij dostawcę

Otwórz Dashboard → twoja organizacja → Logowanie SSO i uzupełnij:

• Nazwa wyświetlana — to, co rozpoznają twoi ludzie, np. Acme Entra.
• Adres wystawcy — z sekcji wyżej.
• Client ID i Client secret — od dostawcy.

Zapis od razu sprawdza wystawcę, pobierając jego konfigurację OpenID, więc literówka wychodzi, gdy na nią patrzysz, a nie przy pierwszym logowaniu kogoś z zespołu. Secret jest szyfrowany i nigdy nie wraca do przeglądarki — po zapisaniu pole pokazuje placeholder i zostaje puste, dopóki nie wpiszesz nowego.

Testuj połączenie ponownie sprawdza wystawcę. Dowodzi, że wystawca odpowiada; nie dowodzi poprawności client id, secretu ani redirect URI, bo te sprawdza dopiero prawdziwe logowanie.

Krok 3 — zweryfikuj domenę

W sekcji Domeny e-mail dodaj domenę, której używają twoi ludzie, np. acme.com. Cmssy pokaże rekord TXT:

cmssy-verification=<twój-token>

Opublikuj go na korzeniu domeny w swoim DNS, poczekaj na propagację i naciśnij Zweryfikuj.

Dopóki domena nie jest zweryfikowana, nie robi nic: jest niewidoczna dla logowania i dla wyszukiwania dostawcy na ekranie logowania. To celowe — bez dowodu własności dowolna organizacja mogłaby zająć cudzą domenę i przejąć konta jej pracowników.

Domeny zweryfikowanej już przez inną organizację nie da się zająć. Darmowi dostawcy poczty i publiczne sufiksy są odrzucane od razu.

Krok 4 — włącz SSO

Gdy dostawca jest kompletny, a domena zweryfikowana, przełącz SSO włączone. Od tego momentu wpisanie adresu z zweryfikowanej domeny na ekranie logowania Cmssy kieruje daną osobę do waszego dostawcy.

Twórz konta automatycznie jest domyślnie włączone: kto loguje się pierwszy raz, dostaje konto i dołącza do organizacji z domyślną rolą członka. Wyłącz to, jeśli wolisz zapraszać ludzi samodzielnie — nieznane adresy będą wtedy odrzucane.

Krok 5 — wymagaj SSO (opcjonalnie)

Wymagaj SSO odbiera osobom z zweryfikowanej domeny możliwość logowania hasłem. Logowanie hasłem, rejestracja, reset hasła oraz logowanie przez Google i Apple są dla tych adresów odrzucane.

Włączysz to tylko wtedy, gdy spełnione są trzy warunki:

• jesteś właścicielem organizacji, nie tylko adminem
• ktoś już zalogował się skutecznie przez waszego dostawcę
• ty, właściciel, masz hasło

Dwa ostatnie istnieją z tego samego powodu: jeśli wasz dostawca padnie, wygaśnie lub zostanie źle skonfigurowany, ktoś musi móc wrócić do środka. Właściciel zachowuje dostęp hasłem na stałe właśnie na ten wypadek — traktuj to konto odpowiednio.

Wyłączenie SSO wyłącza także wymuszenie. Organizacja nigdy nie skończy, wymuszając dostawcę, którego wyłączyła.

Jak wygląda logowanie

1. Osoba wpisuje swój służbowy adres na ekranie logowania Cmssy.
2. Cmssy sprawdza, czy domena należy do organizacji z włączonym SSO, i jeśli tak — kieruje ją do waszego dostawcy.
3. Uwierzytelnia się u was, razem z całym MFA i dostępem warunkowym, który wymuszacie.
4. Wasz dostawca odsyła ją do Cmssy, które weryfikuje token kluczami podpisującymi waszego wystawcy i loguje ją.

Adres zwrócony przez waszego dostawcę musi należeć do jednej z waszych zweryfikowanych domen. Konto gościa z innego tenanta jest odrzucane, nawet jeśli wasz dostawca za nie ręczy.

Osoby, których domena nie ma SSO, widzą zwykły formularz z hasłem — dla nich nic się nie zmienia.

Rozwiązywanie problemów

Ekran logowania nie proponuje naszego dostawcy

Sprawdź, czy domena jest zweryfikowana (a nie tylko dodana), czy SSO włączone jest aktywne i czy adres faktycznie używa tej domeny.

„Logowanie SSO nie doszło do skutku”

Wymiana z waszym dostawcą się nie powiodła. Najczęstsze przyczyny to redirect URI, który nie zgadza się co do znaku, zrotowany client secret albo logowanie, które wracało dłużej niż dziesięć minut.

„… nie należy do domeny zweryfikowanej przez tę organizację”

Wasz dostawca zwrócił adres spoza zweryfikowanych domen — zwykle konto gościa lub prywatne w tym samym tenancie.

Wymuszenie nie chce się włączyć

Przeczytaj komunikat: nazywa ten z trzech warunków, który nie jest spełniony. Najczęściej nikt jeszcze nie zalogował się przez dostawcę.

Zmienił nam się plan i SSO przestało działać

SSO wymaga planu Enterprise. Konfiguracja i zweryfikowane domeny zostają, a ich odczyt i usuwanie działają dalej, więc nic nie przepada, zanim uporządkujesz plan.