Migracja z Okta do FoxIDs

Przenieś logowanie z Okta do FoxIDs, dobierając sposób migracji do miejsca uwierzytelniania każdej grupy użytkowników. Zaimportuj użytkowników lokalnych i pozwól im wybrać nowe hasło lub włącz logowanie bezhasłowe kodami jednorazowymi. Dla logowania społecznościowego i firmowego skonfiguruj metody uwierzytelniania FoxIDs ufające zewnętrznym dostawcom tożsamości. Okta może też pozostać dostawcą tożsamości podczas przenoszenia aplikacji do FoxIDs.

Ten przewodnik techniczny obejmuje użytkowników Okta Universal Directory, konfigurację aplikacji i mapowanie kont dla Okta Identity Engine i Classic Engine.

Dla importu użytkowników lokalnych przekształć sprawdzony eksport Okta w plik CSV i użyj FoxIDs Seed Tool, aby zbiorczo załadować użytkowników do FoxIDs. Poniższe przykłady CSV pokazują pola ustawiania haseł i logowania bezhasłowego.

Wybierz podejście dla każdej grupy:

Przygotowanie środowiska docelowego i aplikacji

Osobne środowisko testowe pozwala wypróbować migrację na małej grupie użytkowników przed przejściem do produkcji. Kroki konfiguracji:

1. Jeśli chcesz używać własnej domeny, skonfiguruj i zweryfikuj ją w dzierżawie przed konfiguracją aplikacji i zewnętrznych dostawców tożsamości. Używaj wynikowych adresów URL FoxIDs podczas całej migracji. Późniejsza zmiana domeny wymaga aktualizacji konfiguracji zewnętrznych, w tym adresów authority lub metadanych aplikacji oraz adresów zwrotnych i wylogowania dostawców.
2. Każde środowisko ma domyślną metodę uwierzytelniania Login o nazwie login. Dostosuj jej wygląd i interfejs logowania do potrzeb oraz opcje logowania do importowanych użytkowników.
3. Utwórz metody uwierzytelniania łączące użytkowników z zewnętrznymi dostawcami tożsamości, w tym Okta, jeśli pozostaje częścią przejścia.
4. Skonfiguruj aplikację, dozwolone adresy przekierowania, działanie wylogowania oraz API akceptujące jej tokeny dostępu.

FoxIDs Cloud zapewnia dostarczanie wiadomości e-mail i SMS do ustawiania haseł, logowania bezhasłowego i uwierzytelniania wieloskładnikowego (MFA), zależnie od wybranego planu FoxIDs Cloud.

Skonfiguruj wymagane ustawienia MFA i sposób rejestracji użytkowników. Opisane importy CSV przenoszą dane użytkowników, a nie rejestracje Okta Verify, rejestracje urządzeń FastPass, klucze dostępu ani inne rejestracje MFA. Użytkownicy uwierzytelniający się lokalnie w FoxIDs rejestrują skonfigurowane składniki uwierzytelniania. Użytkownicy nadal uwierzytelniający się przez Okta mogą zachować swoje rejestracje Okta.

Konfiguracja aplikacji jest osobnym obszarem prac względem importu użytkowników. Sprawdź wystawcę, odbiorców, zakresy, oświadczenia i walidację tokenów oraz zależności od Okta SDK lub Sign-In Widget, inline hooks, reguły grup i przypisania aplikacji. Odtwórz działanie wymagane przez aplikację. Ogólny przewodnik migracji opisuje szerszą inwentaryzację aplikacji i etapy wdrożenia.

Eksport określonej grupy użytkowników Okta

Użyj Okta Users API, aby pobrać dane użytkowników jako JSON do konwersji. Wybierz organizację źródłową i migrowanych użytkowników lub grupy. Podążaj za adresem rel="next" w nagłówku odpowiedzi Link, aż odczytasz wszystkie strony. Zwykła operacja listowania pomija użytkowników DEPROVISIONED; filtr lub zapytanie wyszukiwania może ich uwzględnić. Wyniki wyszukiwania są ostatecznie spójne, więc ostatnie zmiany mogą pojawić się z opóźnieniem.

Zachowaj organizację źródłową, id użytkownika, status cyklu życia, wymagane atrybuty profile i informacje credentials.provider. Zachowaj rozróżnienie użytkowników zarządzanych przez Okta, katalogowych i federacyjnych. Konfiguracja dostawców tożsamości i reguły routingu pomagają ustalić faktyczne miejsce uwierzytelniania.

Dla eksportu z raportu User Accounts dostępna jest opcja CSV Export. Jego kolumny nadal trzeba przekształcić do formatu FoxIDs Seed Tool. API przydaje się, gdy import wymaga niestandardowych atrybutów lub informacji o dostawcy nieobecnych w raporcie.

Eksportuj członkostwo w grupach i dostęp do aplikacji osobno, jeśli określają uprawnienia. Raporty Okta Group Membership i User App Access opisują te relacje; nie wszystkie znajdują się w obiekcie profile użytkownika.

Dostępność haseł

Okta oferuje eksport skrótów haseł wyłącznie na potrzeby migracji do Auth0, po spełnieniu określonych kryteriów.

FoxIDs może importować obsługiwane skróty haseł, gdy są dostępne.

Mapowanie danych użytkowników i zachowanie kont aplikacji

FoxIDs tworzy własny trwały identyfikator dla importowanych użytkowników lokalnych. Import id użytkownika Okta jako niestandardowego oświadczenia nie czyni go identyfikatorem użytkownika FoxIDs ani nie zachowuje automatycznie podmiotu aplikacji. Zapisz faktyczne OpenID Connect sub lub SAML NameID używane przez każdą aplikację wraz z organizacją źródłową i identyfikatorem użytkownika.

Jeśli aplikacja używa identyfikatora użytkownika Okta jako sub, zaimportuj go jako niestandardowe oświadczenie, np. legacy_okta_user_id. W metodzie uwierzytelniania Login skonfiguruj transformację oświadczeń Map z akcją Replace claim, oświadczeniem wejściowym legacy_okta_user_id i wyjściowym sub. Aplikacja otrzyma tę wartość jako sub, a trwały identyfikator użytkownika FoxIDs pozostanie niezmieniony. Jeśli aplikacja używa innej wartości podmiotu, zachowaj i mapuj tę wartość.

Aplikacje identyfikujące konta przez wystawcę i podmiot muszą także powiązać nowego wystawcę FoxIDs z istniejącymi kontami. Dla aplikacji SAML skonfiguruj wymagane NameID i format w rejestracji aplikacji SAML. Testowe logowanie pokazuje rzeczywistą tożsamość otrzymaną przez aplikację.

Utrzymuj mapowanie między tożsamością źródłową, nową tożsamością FoxIDs i istniejącym kontem aplikacji. Tożsamości używane podczas przejścia powinny wskazywać ten sam rekord klienta lub pracownika. Dla logowania społecznościowego i firmowego uwzględnij tożsamość otrzymaną bezpośrednio od dostawcy; może różnić się od identyfikatora użytkownika Okta.

Dla importu użytkowników lokalnych zastosuj następujące mapowanie:

Stany cyklu życia Okta są bardziej szczegółowe niż flaga wyłączenia FoxIDs. Przykłady włączają użytkowników wybranych z kont ACTIVE i pozostawiają zawieszone konta wyłączone. Stany takie jak STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED i LOCKED_OUT wymagają jawnego mapowania na zamierzone zachowanie aktywacji, ustawiania hasła lub dostępu.

Migracja logowania społecznościowego i firmowego

Utwórz metodę uwierzytelniania FoxIDs dla każdego społecznościowego lub firmowego dostawcy tożsamości obecnie podłączonego przez Okta, ustanawiając zaufanie bezpośrednio do niego. Użytkownicy zachowują u dostawcy konta i dane logowania.

1. Ustal dostawcę każdego połączenia. Skorzystaj z właściwego przewodnika integracji dostawcy, np. Google lub Microsoft Entra ID, i wybierz obsługiwaną metodę uwierzytelniania OpenID Connect, SAML 2.0 lub WS-Federation.
2. Zarejestruj lub skonfiguruj FoxIDs u dostawcy. Wymień ustawienia klienta lub metadane federacji i skonfiguruj adresy zwrotne oraz wylogowania podane w przewodniku integracji. Zachowaj połączenie Okta na czas przejścia.
3. Zezwól na nową metodę uwierzytelniania w aplikacji FoxIDs. Skonfiguruj Home Realm Discovery, aby użytkownicy mogli wybrać dostawcę lub byli do niego kierowani według skonfigurowanych reguł.
4. Mapuj tożsamość dostawcy na istniejące konto aplikacji. Jeśli potrzebujesz przechowywać w FoxIDs oświadczenia lub przypisania dostępu dla poszczególnych użytkowników, skonfiguruj i utwórz użytkowników zewnętrznych.
5. Odtwórz ograniczenia dostępu wcześniej egzekwowane przez Okta, w tym przypisania aplikacji, zawieszonych użytkowników i wymagane MFA.

Oczekiwany przepływ to aplikacja → FoxIDs → zewnętrzny dostawca tożsamości → FoxIDs → aplikacja. FoxIDs wydaje tokeny aplikacji po uwierzytelnieniu użytkownika przez dostawcę.

Możesz wypróbować każde połączenie, rozpoczynając logowanie w aplikacji, wybierając dostawcę i kończąc jego przepływ logowania. Pozwala to obserwować MFA, konto i uprawnienia w aplikacji oraz działanie wylogowania.

Migracja użytkowników z Active Directory

Jeśli Okta deleguje uwierzytelnianie hasłem do Active Directory, a AD pozostaje źródłem, FoxIDs może połączyć się bezpośrednio przez Directory Connector dla Active Directory. Skonfiguruj łącznik i metodę uwierzytelniania Login według tego przewodnika. FoxIDs synchronizuje użytkowników z AD i weryfikuje hasła w AD, więc ci użytkownicy nie potrzebują importu haseł CSV.

Domyślnie FoxIDs zapisuje lokalną kopię hasła po udanej weryfikacji przez Directory Connector. Umożliwia to późniejsze przejście na lokalne uwierzytelnianie FoxIDs przez wyłączenie łącznika. Użytkownicy, których haseł nie zapisano, mogą skorzystać z ustawiania hasła. Opcje konfiguracji opisuje obsługa haseł Directory Connector.

Użytkownik Okta pochodzący z AD nie musi nadal uwierzytelniać się w AD: Okta może przenieść uwierzytelnianie hasłem z AD do Okta. Bezpośredni łącznik ma zastosowanie, gdy AD nadal przechowuje i weryfikuje używane hasło.

Migracja użytkowników bezhasłowych

Zaimportuj użytkowników jako wewnętrznych użytkowników FoxIDs bez haseł i skonfiguruj logowanie bezhasłowe kodem e-mail lub SMS. Użytkownik wpisuje kod na już otwartej stronie logowania.

Oznacza to zmianę metody uwierzytelniania dla użytkowników Okta FastPass lub kluczy dostępu. Kody e-mail i SMS nie zapewniają takiej odporności na phishing jak FastPass.

1. Włącz e-mail lub telefon jako identyfikator logowania w metodzie uwierzytelniania FoxIDs Login i odpowiednio włącz Passwordless with email (one-time password) lub Passwordless with SMS (one-time password).
2. Dla metody logowania przeznaczonej dla użytkowników bezhasłowych wybierz Disable password authentication i wyłącz ustawianie/resetowanie hasła przez e-mail i SMS.
3. Zaimportuj użytkowników z pominięciem Password i wszystkich pól skrótu hasła. Pozostaw SetPasswordEmail, SetPasswordSms i ChangePassword jako false. Zachowaj zmapowany stan weryfikacji, stan wyłączenia i wymagane oświadczenia.

Na przykład ten CSV Seed Tool importuje fikcyjnego użytkownika z bezhasłowym logowaniem e-mail, którego poprzedni stan weryfikacji e-mail jest nieznany:

Email;EmailVerified;SetPasswordEmail;SetPasswordSms;ChangePassword;DisableAccount;Claims
alice@example.com;false;false;false;false;false;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"

Dla użytkowników SMS zastąp Email i EmailVerified polami Phone i PhoneVerified, używając wybranego numeru i jego znanego stanu weryfikacji. Obowiązuje ta sama procedura przesyłania.

Możesz wypróbować przepływ z zaimportowanym użytkownikiem testowym, wpisując jego adres e-mail lub numer telefonu i otrzymany kod. Prawidłowy kod pozwala aktywnemu użytkownikowi przejść przez wymagane MFA do aplikacji. Po udanym logowaniu bezhasłowym użytkownik nadal nie ma hasła.

Import użytkowników w celu ustawienia hasła

Włącz logowanie e-mail, uwierzytelnianie hasłem i ustawianie hasła przez e-mail w metodzie uwierzytelniania FoxIDs Login. Zaimportowani użytkownicy wybierają hasło przy pierwszym logowaniu.

Import użytkowników przygotowuje konta. Ustawienie hasła następuje, gdy użytkownik rozpoczyna logowanie, a nie podczas importu.

Przekształć sprawdzone rekordy w plik UTF-8 dla FoxIDs Seed Tool. Nagłówki rozróżniają wielkość liter, a separatorem jest średnik. Przykład zawiera fikcyjnych użytkowników z nieznanym poprzednim stanem weryfikacji e-mail; drugie konto pozostaje wyłączone:

Email;EmailVerified;SetPasswordEmail;DisableAccount;RequireMultiFactor;Claims
alice@example.com;false;true;false;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"
suspended@example.com;false;true;true;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO002""]}]"

SetPasswordEmail=true wybiera ustawienie hasła z potwierdzeniem przez e-mail. Pomiń Password i wszystkie kolumny skrótu hasła. RequireMultiFactor=true to polityka wybrana w przykładzie, wymagająca konfiguracji odpowiednich metod MFA.

Udostępniaj przykładowe oświadczenie legacy_okta_user_id tylko aplikacjom, które go potrzebują, przez ich skonfigurowaną obsługę oświadczeń.

Przesłanie użytkowników i sprawdzenie wyniku

Użyj tej procedury dla użytkowników bezhasłowych i użytkowników wybierających hasło przy pierwszym logowaniu, z polami odpowiednimi dla wybranej metody.

Seed Tool rozdziela pola średnikami; pola w cudzysłowach nie mogą zawierać średników ani podziałów wiersza. Użyj operacji użytkowników Control API, jeśli wartości wymagają bogatszej reprezentacji importu.

1. Pobierz i skonfiguruj Seed Tool dla docelowego środowiska. Ustaw SeedSettings.UsersSvcPath na przekonwertowany plik CSV.
2. Uruchom Seed Tool i wybierz U, aby zbiorczo przesłać użytkowników.
3. Zapisz nowe identyfikatory użytkowników w mapowaniu migracji.

Możesz wypróbować przesyłanie z plikiem CSV zawierającym kilku użytkowników w środowisku testowym. Seed Tool podaje liczbę sukcesów i niepowodzeń. W FoxIDs Control można sprawdzić identyfikatory, stan wyłączenia, oświadczenia i flagi ustawiania hasła zaimportowanych użytkowników.

Seed Tool używa zbiorczego aprowizowania, które może zastąpić istniejących użytkowników zamiast ich scalać. Ponowne przesłanie może usunąć dane logowania i stan oraz utworzyć nowe identyfikatory. Przy częściowo wykonanym imporcie uzgodnij wynik przed ponowieniem; dla późniejszych zmian używaj ukierunkowanych aktualizacji użytkowników.

Ustawienie hasła przy pierwszym logowaniu

Dla włączonego zaimportowanego użytkownika z SetPasswordEmail=true oczekiwany przepływ to:

1. Użytkownik otwiera aplikację i rozpoczyna logowanie przez FoxIDs Login.
2. FoxIDs rozpoznaje użytkownika na podstawie adresu e-mail i wysyła kod potwierdzający.
3. Użytkownik przesyła kod i nowe hasło zgodne z polityką haseł FoxIDs.
4. FoxIDs weryfikuje adres e-mail, zapisuje hasło i zeruje flagi ustawiania hasła. Logowanie przechodzi przez wymagane kroki MFA przed powrotem do aplikacji.

Import użytkownika nie wysyła wiadomości do ustawienia hasła. Kolejne logowania hasłem używają nowego hasła FoxIDs. Jeśli użytkownik nie może odebrać kodu, proces odzyskiwania potrzebuje innego sposobu weryfikacji tożsamości.

Możesz sprawdzić przepływ z użytkownikiem testowym, wykonując powyższe kroki logowania. Te scenariusze pokazują oczekiwane wyniki:

Zachowanie Okta podczas przejścia

FoxIDs może ufać Okta jako zewnętrznemu dostawcy tożsamości podczas przenoszenia aplikacji do FoxIDs. Użytkownicy uwierzytelniają się w Okta, a FoxIDs wydaje tokeny aplikacji. Hasła i środki uwierzytelniania Okta pozostają w Okta; nie są kopiowane do FoxIDs.

Dla połączenia OpenID Connect:

1. Utwórz w Okta integrację aplikacji internetowej OIDC dla FoxIDs z Authorization Code Flow. Przypisz użytkowników lub grupy logujące się przez integrację i skonfiguruj jej politykę logowania.
2. Utwórz w FoxIDs metodę uwierzytelniania OpenID Connect. Ustaw Authority na wybranego wystawcę Okta i skonfiguruj identyfikator klienta Okta w Optional custom SP client ID, jego sekret oraz odpowiednią metodę uwierzytelniania klienta punktu końcowego tokenów.
3. Zażądaj zakresów profile i email według potrzeb; FoxIDs uwzględnia openid. Wybierz Read claims from the UserInfo Endpoint instead of the access token or ID token w Show advanced, aby pobierać oświadczenia użytkownika przez UserInfo.
4. Zarejestruj Redirect URL pokazany przez FoxIDs jako URI przekierowania logowania w Okta i skonfiguruj odpowiedni URI wylogowania, jeśli jest używane.
5. Zezwól na metodę uwierzytelniania w aplikacji FoxIDs i skonfiguruj Home Realm Discovery dla użytkowników nadal korzystających z Okta.

Serwer autoryzacji organizacji Okta obsługuje logowanie OpenID Connect z wystawcą takim jak https://example.okta.com. Niestandardowy serwer autoryzacji używa wystawcy takiego jak https://example.okta.com/oauth2/default. Użyj wystawcy i konfiguracji oświadczeń wybranych dla integracji.

Inną opcją jest metoda uwierzytelniania SAML: utwórz w Okta aplikację SAML dla FoxIDs i wymień metadane oraz ustawienia dostawcy usług i dostawcy tożsamości.

Testowe logowanie przez aplikację pokazuje politykę uwierzytelniania Okta, oświadczenia, mapowanie kont i wylogowanie dla nowego połączenia. Gdy użytkownicy przechodzą na lokalne logowanie FoxIDs lub bezpośrednio podłączonych dostawców, kieruj ich do tych metod. Spójne mapowanie kont między metodami pozwala aplikacji nadal korzystać z tych samych rekordów kont.

Wdrożenie i zachowanie możliwości wycofania

Migrację można wdrażać według aplikacji lub grup użytkowników. Użytkownicy mogą nadal korzystać ze zwykłego adresu aplikacji ze skonfigurowanym logowaniem: ustawieniem hasła, kodem jednorazowym, hasłem katalogowym lub zewnętrznym dostawcą tożsamości.

Uzgodnij użytkowników utworzonych, zmienionych, zawieszonych lub usuniętych od czasu eksportu, w tym zmiany grup i przypisań aplikacji. Krótkie zamrożenie zmian lub kontrolowany proces uzgadniania może utrzymać spójność źródła i celu podczas przełączenia. Późniejsze aktualizacje powinny zachowywać dane logowania i stan już ustanowione w FoxIDs.

Monitoruj dostarczanie e-maili i SMS, błędy ustawiania hasła, logowania i mapowania kont. Wycofanie wymaga dostępności wcześniejszej konfiguracji Okta. Możesz wypróbować jej przywrócenie dla aplikacji testowej, aby zobaczyć powrót do logowania Okta.

Hasło ustawione lokalnie w FoxIDs nie jest synchronizowane z powrotem do Okta. Wycofanie korzysta więc z danych logowania nadal przechowywanych w Okta lub u podłączonego dostawcy. Użytkownicy utworzeni tylko w FoxIDs potrzebują ścieżki dostępu w razie wycofania. Gdy wymagani użytkownicy i aplikacje korzystają z docelowych metod uwierzytelniania, można wyłączyć integrację Okta.

Powiązana dokumentacja

• Przegląd migracji
• Załaduj wielu użytkowników
• Operacje użytkowników Control API
• Logowanie i Home Realm Discovery
• Directory Connector for Active Directory
• Metoda uwierzytelniania OpenID Connect