Konfiguracja SSO z Okta

Ta strona opisuje część konfiguracji po stronie Okta. Część po stronie Bird (weryfikacja domeny, testowanie, aktywacja i wymuszanie SSO) jest taka sama dla każdego dostawcy i znajduje się na stronie SSO i provisioning.

Okta i Bird potrzebują nawzajem swoich wartości, więc to, od czego zaczniesz, zależy od protokołu. Miej oba otwarte podczas pracy.

SAML

Dla SAML zacznij w Bird. Entity ID i Assertion Consumer Service URL połączenia SAML wynikają z samego połączenia, więc utwórz je z opcją I have not set up my provider yet, zarejestruj wartości, które się pojawią, i wróć do Supply the details. Konfiguracja SAML bez wartości zastępczych opisuje ten proces krok po kroku.

Nazwy pól w Okta nie odpowiadają nazwom w Bird. Dwa z nich są na tyle podobne, że łatwo je pomylić, a zamiana powoduje wysłanie odpowiedzi logowania na URL, który nie może jej obsłużyć.

Single sign-on URL w Okta to Assertion Consumer Service URL z Bird, a nie URL logowania z Bird. Jeśli wkleisz tam URL logowania, Okta wysyła każdą odpowiedź na niewłaściwy endpoint i logowanie kończy się błędem.

Identyfikuj członków po adresie e-mail

W ustawieniu Name ID format aplikacji SAML wybierz EmailAddress i ustaw Application username na wartość, po której Bird ma identyfikować konta. Bird odrzuca Unspecified i odrzuca odpowiedź, której format NameID nie zgadza się z formatem oczekiwanym przez połączenie.

Przeczytaj Jak identyfikowani są członkowie, zanim podejmiesz decyzję: identyfikator jest trwały dla każdego, kto loguje się przez to połączenie, więc nieprzezroczysty identyfikator aplikacji z adresem przesyłanym oddzielnie jako atrybut email jest bezpieczniejszym wyborem.

Ważność asercji

Okta podpisuje asercje ważne od pięciu minut przed wydaniem do pięciu minut po. Bird akceptuje to okno. Nie ma tu nic do konfiguracji.

OIDC

Dla OIDC zacznij w Okta. Bird potrzebuje issuer, client ID i client secret, żeby utworzyć połączenie OIDC, więc najpierw zarejestruj aplikację w Okta. Redirect URI Bird jest taki sam dla każdego połączenia i widoczny w Add connection jeszcze przed utworzeniem czegokolwiek, więc możesz go zarejestrować od razu.

Utwórz aplikację webową OIDC w Okta i skopiuj jej client ID oraz secret do Bird, podając issuer Okta jako Issuer. Bird uwierzytelnia się na endpoincie tokenów za pomocą client_secret_basic.

Zarejestruj Redirect URI z Bird jako sign-in redirect URI aplikacji.

Kafelek aplikacji Okta

Aby umożliwić członkom rozpoczęcie logowania z pulpitu Okta, ustaw:

• Login initiated by: Either Okta or App
• Application visibility: kafelek widoczny dla użytkowników
• Login flow: Redirect to app to initiate login (OIDC Compliant)
• Initiate login URI: Initiate login URI połączenia z Bird

Wybierz przepływ zgodny z OIDC. Przepływ Send ID Token directly to app (Okta Simplified) w Okta wysyła token do Bird zamiast przekierowywać, a Bird go nie akceptuje.

Przypisz aplikację

Członek, który nie jest przypisany do aplikacji Bird w Okta, zostaje odrzucony przez Okta, nie przez Bird. Bird zgłasza odmowę jako pochodzącą od dostawcy tożsamości, więc sprawdź przypisania i ewentualne reguły dostępu warunkowego w Okta, zanim ponownie sprawdzisz ustawienia samego połączenia.

Rotacja certyfikatu podpisującego

Najpierw zrotuj certyfikat w Okta, potem w Bird. Bird weryfikuje podpisy na podstawie certyfikatów przypisanych do połączenia, więc połączenie Bird zawierające tylko nowy certyfikat, podczas gdy Okta wciąż podpisuje starym, odrzuca każde logowanie do momentu aktywacji nowego certyfikatu w Okta. Odmowa przejawia się jako błąd podpisu i ustępuje, gdy obie strony się zgadzają.

Następne kroki

• SSO i provisioning: weryfikacja domeny, testowanie połączenia i wymuszanie SSO
• Konfiguracja SSO z Google Workspace
• Konfiguracja SSO z Microsoft Entra ID