Zaloguj zespół przez SSO

Co zbudujesz

Po ukończeniu tego samouczka będziesz mieć:

• połączenie SAML między serwerem Control Center a dostawcą tożsamości (jako przykładu używamy Okta),
• jednego użytkownika aprowizowanego automatycznie przy pierwszym logowaniu oraz
• politykę członkostwa w obszarach roboczych, którą świadomie wybrałeś.

Potrzebujesz serwera, którym administrujesz (właściciel serwera — operator instalacji), oraz aplikacji IdP, którą umiesz skonfigurować. Zaplanuj na to 20 minut.

1. Otwórz ustawienia logowania jednokrotnego

Zaloguj się do Control Center i przejdź do Ustawienia → Serwer → Logowanie jednokrotne. Ekran przełącza się między SAML a OpenID Connect, jest na nim też karta Provisioning użytkowników (SCIM). Zostań na SAML.

Wszystko na tym ekranie obejmuje cały serwer: jeden IdP uwierzytelnia ludzi ze wszystkich obszarów roboczych, więc edytować to może wyłącznie właściciel serwera.

2. Wklej metadane IdP

W Okta otwórz kartę Sign On swojej aplikacji i skopiuj XML metadanych (albo pobierz go i wklej zawartość pliku). Z powrotem w Control Center wklej go w pole XML metadanych IdP i naciśnij Przetestuj połączenie.

Powiadomienie podaje punkt końcowy logowania IdP — dowód, że metadane zostały sparsowane, certyfikat odczytany, a serwer potrafi na ich podstawie zbudować żądanie logowania (test sprawdza wszystko oprócz rundy przez przeglądarkę). Jeśli się nie powiedzie, XML nie był kompletnym EntityDescriptor (karta SAML w Okta nazywa go „Metadata URL”; otwórz ten URL i skopiuj to, co zwraca). Ten sam przycisk na karcie OpenID Connect sprawdza zamiast tego dokument discovery Twojego wystawcy. Aby wychwycić dodatkowo certyfikat podpisu bliski wygaśnięcia i zobaczyć, czy IdP rozpoznaje Control Center, użyj weryfikatora z kroku 6.

3. Zarejestruj Control Center u dostawcy tożsamości

Naciśnij Skopiuj metadane SP i przekaż je osobie, która konfiguruje stronę Okta (albo podaj jej dwie wartości, o które pyta):

• Adres URL ACS: https://<your-server>/saml/acs
• Identyfikator encji: https://<your-server>/saml

Adresy URL wynikają z origin, który osiągają przeglądarki Twoich użytkowników. Jeśli serwer działa za tunelem lub odwrotnym proxy, upewnij się, że origin jest stabilny (Ustawienia → Serwer → Połączenie i status → Udostępnij ten serwer pokazuje publiczny URL) — albo przypnij identyfikator encji jawnie w polu Identyfikator encji SP.

Za NAT-em?

Logowanie SAML nie wymaga publicznego adresu IP ani domeny: IdP nigdy nie łączy się z Twoim serwerem — rundę przenosi przeglądarka użytkownika, więc localhost, sieć LAN, VPN, Tailscale czy tunel — wszystko zadziała. Dwie rzeczy, których nie wolno pomylić:

• origin używany przez przeglądarkę musi zgadzać się z adresem URL ACS / identyfikatorem encji zarejestrowanym u IdP (przypnij identyfikator encji, jeśli użytkownicy osiągają serwer pod więcej niż jednym origin),
• aprowizacja SCIM jest wyjątkiem — IdP wywołuje Twój serwer bezpośrednio, więc potrzebuje tunelu albo publicznego adresu URL (Provisionuj użytkowników przez SCIM).

4. Wybierz, co przyznaje logowanie

O tym, co zrobi pierwsze logowanie, decydują dwie polityki:

• Dodawaj użytkowników do każdego obszaru roboczego przy pierwszym logowaniu — pozostaw włączone przy wdrożeniu jednego zespołu, w którym SSO równa się zaufaniu. Wyłącz, gdy serwer współdzieli kilka zespołów lub klientów: każdy nowy użytkownik potrzebuje wtedy wyraźnego zaproszenia do obszaru roboczego, co jest bezpieczniejszym ustawieniem domyślnym.
• Zakładaj konta nieznanym użytkownikom przy pierwszym logowaniu — domyślnie włączone; wyłącz, aby odrzucać każdego, czyje konto jeszcze nie istnieje.

Opcjonalnie zmapuj atrybut przenoszący nazwy grup (w Okta jest to zwykle groups) i przełóż grupy na role za pomocą mapy — na przykład {"platform-leads": "admin"}. SSO nigdy nie może przyznać roli właściciela.

5. Włącz logowanie i wykonaj je

Włącz Użyj SAML do logowania, naciśnij Zapisz połączenie, a następnie otwórz okno przeglądarki w trybie prywatnym pod adresem https://<your-server>/saml/login. Zaloguj się w Okta i wrócisz do klienta webowego — zalogowany, z utworzonym kontem i członkostwem przyznanym zgodnie z wybraną polityką.

Ten sam punkt wejścia pojawia się na ekranie łączenia w przeglądarce (Zaloguj się przez SAML) w chwili wpisania adresu serwera — formularz dopasowuje się do tego, co oferuje serwer (OpenID Connect pokazuje Zaloguj się przez OpenID Connect). Przycisk otwiera logowanie w nowej karcie; gdy runda się zakończy, oczekująca karta automatycznie przejmuje sesję. Ekran konfiguracji serwera w aplikacji desktopowej działa tak samo: wpisz URL serwera, pojawi się przycisk Zaloguj się przez SAML, który otwiera przeglądarkę, a aplikacja loguje się po zakończeniu rundy.

6. Sprawdź to z tej strony

Zanim wdrożysz SSO albo gdy logowanie się nie powiedzie, sprawdź tutaj jego elementy. Weryfikator działa w całości w Twojej przeglądarce: czyta metadane, które wklejasz na tej karcie, i stosuje te same reguły co serwer. Gdy podasz adres serwera, zapyta go również, czy logowanie SAML jest włączone.

Wychwytuje to, czego Przetestuj połączenie w aplikacji nie widzi: certyfikat podpisu bliski wygaśnięcia, IdP, który wymaga podpisanych żądań, oraz — dzięki testowemu logowaniu — czy IdP w ogóle rozpoznaje Control Center.

Runs in your browserYour metadata is read in this tab and never uploaded. Add a server address and your browser also asks that server which sign-in methods it offers.

IdP metadata XMLLoad a file

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

SP entity ID (optional)

Only if you pinned one in the app.

Check metadata

Następne kroki

• Oddaj kontrolę nad cyklem życia również swojemu IdP: Provisionuj i cofaj aprowizację użytkowników przez SCIM.
• Twój dostawca tożsamości obsługuje OpenID Connect, a nie SAML? Połącz dostawcę OpenID Connect.
• Ciekawi Cię, co właściwie weryfikuje runda przez przeglądarkę? Jak działa logowanie jednokrotne.