Zastąpienie AD FS i zmiana protokołu uwierzytelniania aplikacji to odrębne decyzje. Aplikacja, która już korzysta z WS-Federation, może zachować ten protokół, przechodząc na FoxIDs jako zaufanego identity providera.
Pierwszym wartościowym kamieniem milowym jest jedna aplikacja, która rozpoznaje tych samych użytkowników, przyznaje zamierzony dostęp i ma przetestowaną ścieżkę powrotu. Samo udane logowanie nie potwierdza żadnego z tych rezultatów.
Ten przewodnik jest przeznaczony dla architektów IAM i rozwiązań przygotowujących pierwszą migrację. Dotyczy aplikacji przeglądarkowej korzystającej z pasywnego WS-Federation, często określanego skrótem WS-Fed. Federacja domen Microsoft 365, logowanie do Windows i aktywni klienci WS-Trust wymagają osobnej oceny i nie są objęci tym przykładem.
Oddziel migrację aplikacji od migracji katalogu
AD FS jest usługą federacyjną, a Active Directory to katalog, względem którego wiele instalacji AD FS uwierzytelnia użytkowników. Przeniesienie relacji zaufania federacyjnego aplikacji samo w sobie nie przenosi kont katalogowych ani haseł.
Jeden z wariantów przejścia początkowo zachowuje AD FS jako źródło uwierzytelniania:
| Etap | Czemu ufa aplikacja | Gdzie użytkownik się uwierzytelnia |
|---|---|---|
| Przed migracją | AD FS wystawia token WS-Federation dla aplikacji | AD FS używa istniejącej konfiguracji uwierzytelniania |
| Pierwszy pilotaż | FoxIDs wystawia nowy token WS-Federation dla aplikacji | FoxIDs kieruje przeglądarkę do AD FS przez skonfigurowaną metodę uwierzytelniania |
| Późniejsza, odrębna zmiana | Aplikacja nadal ufa FoxIDs | Inny zewnętrzny identity provider albo FoxIDs Login z Directory Connector dla AD zastępuje AD FS po osobnej walidacji |
FoxIDs obsługuje zarówno rejestrację aplikacji WS-Federation po stronie aplikacji, jak i metodę uwierzytelniania WS-Federation po stronie AD FS. Obie strony mają różne zadania: jedna wystawia tokeny, druga waliduje odpowiedź nadrzędnego dostawcy.
W pilotażu AD FS wystawia token przeznaczony dla FoxIDs. FoxIDs waliduje go i wystawia osobny token dla aplikacji. Nie jest to przezroczyste przekazanie starego tokenu: aplikacja musi ufać wystawcy i certyfikatowi podpisującemu FoxIDs.
Pilotaż nadal zależy od AD FS. Tworzy kontrolowany punkt, w którym można zweryfikować zaufanie aplikacji i wymagania dotyczące claims, ale nie wycofuje jeszcze usługi federacyjnej.
Dwie dalsze ścieżki bez AD FS
Po pilotażu możliwe są obie ścieżki:
- Zachowaj zewnętrznego identity providera. Zastąp AD FS innym IdP połączonym z FoxIDs przez obsługiwaną metodę uwierzytelniania. FoxIDs pozostaje zaufanym wystawcą tokenów WS-Federation dla aplikacji, więc aplikacja nie musi przechodzić na protokół nowego dostawcy.
- Użyj FoxIDs Login z Active Directory. Directory Connector dla Active Directory waliduje hasła w AD. Usuwa to AD FS ze ścieżki logowania aplikacji, zachowując AD jako katalog autorytatywny. Przewodnik modernizacji logowania z Active Directory wyjaśnia tę architekturę.
Późniejsze przejście na walidację haseł w FoxIDs jest opcjonalne. Udane logowania przez connector tworzą lub aktualizują wewnętrznych użytkowników FoxIDs, a przy włączonym lokalnym zapisywaniu haseł zapisują hash hasła, przygotowując tych użytkowników do późniejszego przełączenia. Jest to stopniowa migracja, nie eksport wszystkich kont w AD; AD pozostaje źródłem autorytatywnym, dopóki connector jest włączony.
Niezależnie od wybranej ścieżki ponownie przetestuj powiązania kont, claims, MFA i wylogowanie. Opisany poniżej pilotaż pierwszej aplikacji ustala, co musi zostać zachowane.
Ustal, czego faktycznie używa pierwsza aplikacja
Wybierz aplikację z właścicielem, reprezentatywnym środowiskiem testowym i konfiguracją, którą można przywrócić. Potwierdź, że middleware lub dostawca wspiera zmianę zaufanej usługi STS, czyli Security Token Service. Konfigurowalny adres URL metadanych jest przydatny, ale znaczenie mają również własne kontrole wystawcy, kod wyszukujący konta i reguły autoryzacji.
Rozważmy fikcyjną aplikację do rozliczania wydatków. Poniższa tabela przedstawia przykładowy kontrakt docelowy, a nie wyeksportowaną konfigurację ani raport z ukończonej migracji.
| Element kontraktu | Obecne zachowanie | Wymagany wynik pilotażu |
|---|---|---|
| Realm / audience | urn:example:expenses identyfikuje aplikację |
Wartość wtrealm aplikacji odpowiada jej rejestracji w FoxIDs, a token jest przeznaczony dla tej aplikacji |
| Reply URL | Instancja testowa odbiera odpowiedzi pod adresem https://expenses-test.example.org/signin-wsfed |
Akceptowany i używany jest wyłącznie zamierzony testowy adres callback |
| Zaufany wystawca i klucze podpisujące | Aplikacja ufa metadanym i kluczom podpisującym AD FS | Instancja testowa ufa metadanym, wystawcy i kluczom podpisującym FoxIDs wybranym dla tego pilotażu |
| Format tokenu | Middleware akceptuje SAML 1.1 przenoszony przez WS-Federation | Zachowaj ten format tokenu, chyba że potrzebna jest osobno przetestowana zmiana |
| Wyszukiwanie użytkownika | Claim NameIdentifier w aplikacji wskazuje pracownika E1042 |
Wybrane zostają to samo istniejące konto i jego historia; nie powstaje drugie konto |
| Autoryzacja | Rola ExpenseApprover pozwala zatwierdzać wydatki |
Uprawnieni użytkownicy zachowują tę możliwość; użytkownicy bez tej roli nadal nie mogą zatwierdzać |
| Zachowanie sesji | Aplikacja ma lokalny plik cookie i określoną politykę wylogowania | Logowanie, wygaśnięcie, ponowne uwierzytelnianie i wylogowanie przez nową ścieżkę spełniają uzgodnioną politykę |
Uzupełnij tabelę rzeczywistymi wartościami i typami claims używanymi w aplikacji. Sprawdź, czy wyszukiwanie konta uwzględnia również wystawcę tokenu lub nazwę zewnętrznego dostawcy logowania: samo zachowanie widocznego identyfikatora użytkownika może nie wystarczyć do zachowania powiązania konta.
FoxIDs może wystawiać tokeny SAML 1.1 lub SAML 2.0 przez WS-Federation; domyślny jest SAML 1.1. Token SAML 2.0 w odpowiedzi WS-Federation nie oznacza przejścia na protokół SAML 2.0 Web SSO. Decyzje o protokole i formacie tokenu traktuj oddzielnie.
Obok zaufania do podpisów zapisz wymagania dotyczące szyfrowania i daty wygaśnięcia certyfikatów. Szyfrowanie i walidacja podpisu rozwiązują różne problemy, a obsługa musi odpowiadać możliwościom aplikacji odbierającej token. Dla ASP.NET Core przewodnik Microsoft dotyczący middleware WS-Federation wskazuje MetadataAddress, Wtrealm i konfigurację callback jako istotne ustawienia integracji. Przed zastosowaniem przykładowej konfiguracji sprawdź faktycznie używane middleware i jego wersję.
Skonfiguruj obie strony w środowisku testowym
Utwórz pilotaż w osobnym środowisku FoxIDs i użyj testowej instancji aplikacji. Skonfiguruj połączenie z AD FS jako metodę uwierzytelniania, a następnie zarejestruj istniejącą aplikację w FoxIDs, podając realm, reply URL, typ tokenu i wymagane claims.
Po stronie AD FS FoxIDs jest odrębną relying party. Ustanów tę relację zaufania przy użyciu metadanych metody uwierzytelniania FoxIDs i określ claims oraz politykę dostępu, które AD FS ma do niej stosować. Zachowaj pierwotną relację zaufania aplikacji w AD FS przez uzgodnione okno rollback.
Nie zakładaj, że reguły claims, ograniczenia dostępu lub polityka MFA pierwotnej relying party automatycznie dotyczą nowej relacji zaufania. Reguły claims w AD FS są powiązane z poszczególnymi relacjami zaufania, jak opisano w dokumentacji Microsoft dotyczącej reguł claims. Odtwórz wymagane zachowanie we właściwym miejscu i przetestuj je.
Następnie skonfiguruj testową instancję aplikacji tak, aby korzystała z metadanych STS FoxIDs i oczekiwanego wystawcy. Zachowaj włączoną walidację wystawcy, audience i podpisu. Użyj endpointów wygenerowanych dla rzeczywistego środowiska zamiast ręcznie dostosowywać adres URL AD FS.
Pilotaż pasywnego logowania w przeglądarce nie wymaga osobnej opcji Microsoft Entra ID Windows sign-in. Ta funkcja wspiera inny scenariusz federacji domen i aktywnych klientów.
Prześledź claims aż do aplikacji
Metadane określają endpointy i informacje o zaufaniu, ale nie definiują sposobu, w jaki aplikacja wyszukuje konta i nadaje uprawnienia.
Przy nadrzędnej metodzie WS-Federation FoxIDs odbiera claims SAML, reprezentuje je wewnętrznie jako claims JWT i przekształca je z powrotem w claims SAML dla tokenu aplikacji. Na przykład domyślne mapowanie zmienia http://schemas.microsoft.com/ws/2008/06/identity/claims/role wewnętrznie na role, a następnie z powrotem na typ claim SAML dla WS-Federation. Uwzględnij wymagany typ claim SAML dla roli zarówno na liście Forward claims metody uwierzytelniania, jak i Issue claims aplikacji; role nie należą do domyślnego zestawu claims.
Identyfikatory wymagają osobnego sprawdzenia. Dla metody uwierzytelniania WS-Federation o nazwie adfs FoxIDs poprzedza przychodzący identyfikator E1042 prefiksem, tworząc adfs|E1042 przed dalszymi transformacjami claims. Jeśli aplikacja do rozliczania wydatków oczekuje E1042, zdefiniuj jawne mapowanie zachowujące istniejące powiązanie konta. Nie usuwaj prefiksów bez rozróżnienia źródeł: identyczne identyfikatory z różnych źródeł mogłyby wtedy wskazywać to samo konto.
Porównaj istniejącego zatwierdzającego z pracownikiem, który nie może zatwierdzać wydatków. Zbadaj claims faktycznie używane przez aplikację, w tym ewentualne mapowanie w middleware, i przetestuj wynikające z nich uprawnienia. Transformacje claims mogą zmieniać nazwy i wartości, dlatego weryfikuj wynik końcowy, a nie samą konfigurację.
Szczegóły implementacji znajdziesz w dokumentacji transformacji i mapowania claims. Przekazuj i wystawiaj claims wymagane przez aplikację; symbol wieloznaczny nie zastępuje decyzji o tym, jakie dane ma ona otrzymywać.
Przed przełączeniem przetestuj dostęp i jego odmowę
Uzgodnij oczekiwane wyniki z właścicielem aplikacji przed rozpoczęciem testów. Zapisuj zarówno zaobserwowane tokeny/claims, jak i zachowanie aplikacji, używając kont testowych i nie umieszczając materiału uwierzytelniającego w udostępnianych raportach.
| Test | Dowód wymagany przed kontynuowaniem |
|---|---|
| Istniejący użytkownik loguje się | Wybrane zostają istniejące konto aplikacji, jego dane i historia |
| Zatwierdzający i zwykły pracownik wykonują tę samą czynność | Zatwierdzający może ją wykonać; zwykły pracownik otrzymuje odmowę |
| Użytkownik jest wykluczony przez politykę dostępu starej aplikacji | Nowa ścieżka nadal odmawia temu użytkownikowi dostępu |
| Wymagane jest MFA, także przy istniejącej sesji przeglądarkowej AD FS | Skonfigurowany przepływ spełnia wymagany poziom pewności uwierzytelnienia; samo udane logowanie u nadrzędnego dostawcy nie jest uznawane za wystarczający dowód |
| Użytkownik wylogowuje się i ponownie otwiera chronioną stronę | Plik cookie aplikacji, sesja AD FS i skonfigurowany przepływ wylogowania/cleanup spełniają uzgodnioną politykę wylogowania |
| Nowa próba uwierzytelnienia wymaga AD FS, gdy AD FS jest niedostępny | Próba kończy się niepowodzeniem bez ominięcia wymaganego źródła uwierzytelniania; błąd jest widoczny dla osoby odpowiedzialnej za utrzymanie |
| Odpowiedzi testowe zawierają nieprawidłowego wystawcę, audience lub podpis | Każda nieprawidłowa odpowiedź jest odrzucana; walidacja pozostaje włączona |
| Przywrócona zostaje wcześniejsza konfiguracja aplikacji | Nowe logowanie przez pierwotną ścieżkę AD FS wybiera właściwe konto i uprawnienia |
Testuj wygaśnięcie sesji i ponowne uwierzytelnianie oddzielnie od zwykłego udanego logowania. Wyłączone konto lub użytkownik z odebraną rolą może nadal mieć istniejącą sesję aplikacji. Uzgodnij, kiedy dostęp ma się zakończyć, i zweryfikuj ten moment zamiast zakładać, że nowa konfiguracja federacji unieważnia każdy plik cookie.
FoxIDs obsługuje wylogowanie WS-Federation i powiadomienia cleanup, jeśli zostały skonfigurowane. To, czy każda uczestnicząca aplikacja usuwa swoją lokalną sesję, zależy od jej implementacji i rzeczywistego przepływu w przeglądarce. Sprawdź zachowanie wylogowania przy użyciu klientów i przeglądarek stosowanych w produkcji.
Niech przełączenie będzie małą, odwracalną decyzją
Przed wdrożeniem produkcyjnym zapisz, kto może przywrócić poprzednią konfigurację aplikacji, gdzie jest ona przechowywana i jakie ustalenia powodują rollback. Błędne powiązanie konta, niezamierzone uprawnienia i niespełnione wymagania MFA powinny natychmiast zatrzymać wdrożenie. Uzgodnij progi dla błędów logowania i incydentów operacyjnych zamiast wymyślać je w trakcie zmiany.
Przenieś uzgodniony zakres aplikacji w monitorowanym oknie. Pilotaż użytkownik po użytkowniku jest możliwy tylko wtedy, gdy wspierają go aplikacja i projekt routingu; w przeciwnym razie najpierw użyj instancji testowej, a aplikację produkcyjną traktuj jako jednostkę zmiany.
Rollback musi obejmować więcej niż adres URL metadanych. Przywróć poprzednie zaufanie do wystawcy i kluczy, konfigurację claims oraz wszelkie powiązania kont zmienione podczas pilotażu. Zdecyduj, jak zakończyć lub zastąpić sesje utworzone przez nową ścieżkę. Przywrócenie starego endpointu nie cofa zmian danych aplikacji ani nie usuwa automatycznie tych sesji.
Gdy aplikacja działa stabilnie, zdecyduj, którą zależność usunąć jako następną. Zastąpienie nadrzędnego AD FS, zmiana protokołu aplikacji na OpenID Connect i migracja użytkowników katalogu to osobne dalsze zmiany, każda z własnymi testami. Jeśli zmieni się przechowywanie użytkowników lub haseł, skorzystaj z przewodnika decyzyjnego migracji haseł, zamiast włączać tę pracę do pilotażu.
Zmierzony wynik pierwszej aplikacji daje następnej migracji konkretny punkt wyjścia: zrozumiałą konfigurację zaufania, zweryfikowane zachowanie użytkowników i dostępu oraz procedurę odtwarzania przećwiczoną przez zespół. Wykorzystaj wytyczne migracji, aby przełożyć te dowody na szerszy plan.