Migracja

Migracja do FoxIDs zwykle łączy migrację aplikacji, migrację użytkowników i kontrolowane przejście pomiędzy istniejącą platformą tożsamości a FoxIDs. Zaplanuj te strumienie pracy razem, aby identyfikatory, oświadczenia, zachowanie uwierzytelniania i opcje wycofywania pozostały spójne przez cały okres przejścia.

Najemcy FoxIDs obsługują oddzielne środowiska. Korzystaj z dedykowanych środowisk programistycznych, testowych, przejściowych i produkcyjnych, aby równolegle konfigurować i weryfikować przepływy migracji bez przedwczesnej zmiany środowiska produkcyjnego.

Oceń istniejącą platformę tożsamości

Zacznij od nagrania:

Aplikacje, API i środowiska połączone z istniejącą platformą.
Konfiguracje OpenID Connect, OAuth 2.0, SAML 2.0 i WS-Federation.
Dostawcy tożsamości, metody uwierzytelniania i wymagania dotyczące uwierzytelniania wieloskładnikowego.
Identyfikatory użytkowników, profile, oświadczenia, grupy, role i przypisania dostępu.
Opcje przechowywania, sprawdzania poprawności i resetowania haseł dostępne na platformie źródłowej.
Certyfikaty, metadane, adresy URL przekierowań, zachowanie przy wylogowaniu i okresy życia tokenów.
Wymagania dotyczące monitorowania, audytu i wycofywania zmian w przypadku przejścia na nową wersję.

Źródłem może być AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID lub inny dostawca tożsamości lub niestandardowe repozytorium użytkowników. Dostępna ścieżka migracji zależy od protokołów, możliwości eksportu i opcji sprawdzania poprawności hasła udostępnianych przez to źródło.

Migracja aplikacji

Migruj aplikacje według protokołu i środowiska, zamiast traktować osiedle jako pojedyncze przeniesienie.

Zarejestruj aplikację w nieprodukcyjnym środowisku FoxIDs.
Odtwórz wymagane oświadczenia, zakresy, identyfikatory, certyfikaty i zachowanie przy wylogowaniu.
Podłącz istniejącego dostawcę tożsamości jako metodę uwierzytelniania, gdy wymagane jest uwierzytelnianie równoległe.
Przetestuj pełny przepływ logowania, tokena i wylogowania z reprezentatywnymi użytkownikami i integracjami.
Przenieś kontrolowaną grupę lub jedną aplikację na raz przed szerszym wdrożeniem.

FoxIDs mostkowanie protokołów pozwala aplikacji zachować bieżący protokół podczas zmiany strony dostawcy tożsamości. Jest to przydatne, gdy nowoczesne aplikacje OpenID Connect i istniejące aplikacje SAML 2.0 lub WS-Federation muszą działać w tym samym okresie migracji.

Profile użytkowników i identyfikatory

Zdecyduj, który identyfikator pozostanie stabilny przed zaimportowaniem lub utworzeniem użytkowników. Adresy e-mail, numery telefonów i nazwy użytkowników mogą się zmieniać, dlatego używaj stabilnego identyfikatora źródłowego, jeśli integracja go obsługuje.

Mapuj informacje o użytkowniku wymagane po migracji:

Właściwości profilu użytkownika i identyfikatory logowania.
Oświadczenia używane przez aplikacje i interfejsy API.
Grupy, role i przypisania dostępu.
Wymagania dotyczące uwierzytelniania wieloskładnikowego oraz podejście do rejestracji lub odzyskiwania po migracji.
Konta wyłączone, usunięte lub w inny sposób ograniczone.

Użyj Prześlij wielu użytkowników, jeśli użytkowników można eksportować i importować partiami. Użyj Directory Connector, jeśli istniejący katalog lub niestandardowe repozytorium powinno pozostać wiarygodne podczas przejścia. W przypadku Active Directory użyj Directory Connector for Active Directory.

Strategia dotycząca haseł

Wybierz ścieżkę hasła w oparciu o to, co platforma źródłowa może ujawnić lub bezpiecznie zweryfikować:

Importuj hasła lub obsługiwane skróty haseł tylko wtedy, gdy są dostępne w kompatybilnej formie i można je bezpiecznie obsługiwać.
Zweryfikuj istniejące hasło za pomocą narzędzia Directory Connector, podczas gdy katalog źródłowy pozostaje wiarygodny.
Domyślnie FoxIDs zapisuje lokalną kopię hasła po pomyślnym sprawdzeniu poprawności Directory Connector. Umożliwia to późniejsze wyłączenie łącznika i przeniesienie sprawdzania poprawności hasła na identyfikatory FoxIDs bez konieczności resetowania każdego użytkownika.
Wyłącz lokalną kopię hasła, jeśli zasady wymagają, aby katalog zewnętrzny pozostał jedynym magazynem haseł.
Wymagaj resetowania hasła, jeśli importowanie lub zachowanie istniejącego hasła nie jest technicznie możliwe lub gdy resetowanie jest bezpieczniejszą opcją.

Nigdy nie zakładaj, że hasła można przenieść bezpośrednio od dostawcy tożsamości. Przed wybraniem metody migracji potwierdź format eksportu platformy źródłowej, algorytm mieszania, interfejs API walidacji i ograniczenia bezpieczeństwa.

Stopniowa migracja

Jeśli katalog źródłowy obsługuje weryfikację online, konta FoxIDs można tworzyć lub aktualizować przy pierwszym pomyślnym zalogowaniu się za pośrednictwem narzędzia Directory Connector. Umożliwia to stopniowe przejście bez konieczności jednoczesnej migracji wszystkich użytkowników.

Zachowaj źródło dostępne do czasu migracji wymaganej populacji użytkowników i zamknięcia okna wycofywania zmian. Monitoruj nieudane logowania, konflikty identyfikatorów, brakujące oświadczenia i dostępność łącznika w trakcie przejścia.

Przełączenie i wycofanie

Przed przerwaniem produkcji:

Kompletne reprezentatywne testy aplikacji i akceptacji użytkowników.
Potwierdź certyfikaty, metadane, DNS, adresy URL przekierowań i ścieżki zapory ogniowej.
Zdefiniuj kolejność przenoszenia aplikacji, interfejsów API i grup użytkowników.
Zapisz poprzednią konfigurację i warunki wyzwalające wycofanie.
Upewnij się, że monitorowanie i rejestrowanie obejmują zarówno identyfikatory FoxIDs, jak i pozostałe przepływy między platformą źródłową.
Poinformuj o zresetowaniu hasła lub zmianie sposobu logowania, zanim będzie to miało wpływ na użytkowników.

Wdrażanie etapowe ogranicza liczbę aplikacji i użytkowników, których dotyczy każda zmiana. Zachowanie technicznej możliwości wycofania zmian do czasu zweryfikowania zachowań produkcyjnych, roszczeń i dostępu.