Aplikacja i jej identity provider nie muszą obsługiwać tego samego protokołu federacji. Nowoczesna aplikacja może używać OpenID Connect, podczas gdy istniejący firmowy lub partnerski identity provider nadal korzysta z SAML 2.0. Przebudowa jednej ze stron wyłącznie po to, aby protokoły były zgodne, może zwiększyć koszty, ryzyko migracji i liczbę zbędnych zależności.

SAML do OpenID Connect bridge pozwala obu stronom zachować obsługiwany już protokół. FoxIDs weryfikuje odpowiedź SAML 2.0 z zewnętrznego identity providera, stosuje wymagane claims i reguły bezpieczeństwa, a następnie wystawia odpowiedź OpenID Connect oczekiwaną przez aplikację.

Wyszukiwania tego problemu często używają krótkich technicznych fraz, takich jak SAML do OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, tłumaczenie protokołów, SAML do OIDC translation, token translation, identity broker lub identity federation broker. Kluczowe pytanie architektoniczne jest takie samo: jak aplikacja może ufać nowoczesnemu kontraktowi OpenID Connect, gdy istniejący identity provider, partner albo starsza aplikacja SAML nadal używa obsługiwanego już protokołu?

To więcej niż zmiana formatu tokenu. Użyteczna bridge musi zachować znaczenie tożsamości, authentication assurance i kontrakt aplikacji pomiędzy standardami o różnych formatach komunikatów, modelach podpisu, zachowaniu sesji i konwencjach claims.

Kiedy protocol bridging jest właściwym wzorcem

Protocol bridging ma wartość, gdy tworzy kontrolowaną granicę między systemami zmieniającymi się w różnym tempie.

Typowe sytuacje:

  • Nowa aplikacja webowa, mobilna lub single-page obsługuje OpenID Connect, ale klienci lub partnerzy uwierzytelniają się przez SAML 2.0 identity providers.
  • Istniejące aplikacje SAML 2.0 mają korzystać z nowoczesnego OpenID Connect identity providera.
  • Organizacja zastępuje AD FS lub inną platformę federacyjną etapowo, na przykład w migracji AD FS do OpenID Connect, zamiast zmieniać wszystkie aplikacje jednocześnie.
  • Kilka aplikacji ma ufać jednej warstwie tożsamości, mimo że zewnętrzni identity providers używają różnych protokołów.
  • Migracja wymaga równoległych środowisk testowych i produkcyjnych oraz jasnej ścieżki rollback.

Jeśli obie strony obsługują już ten sam odpowiedni protokół i mogą zostać bezpiecznie połączone, bridge może nie być potrzebna. Stosuj ją, gdy zmniejsza sprzężenie lub umożliwia zmianę etapową, a nie tylko dlatego, że translacja protokołu jest możliwa.

Ustal na początku, czy bridge jest etapem migracji, czy długoterminowym elementem architektury. Tymczasowa bridge wymaga jasnych kryteriów usunięcia starej relacji trust. Długoterminowa bridge wymaga wskazania odpowiedzialności operacyjnej, monitoringu i zarządzania cyklem życia certyfikatów po obu stronach.

Najpierw wybierz kontrakt po stronie aplikacji

Protokół po stronie aplikacji powinien odpowiadać jej architekturze i kierunkowi rozwoju. Nowe aplikacje często używają OpenID Connect do logowania i OAuth 2.0 do dostępu do API. Istniejące aplikacje firmowe mogą pozostać przy SAML 2.0 do czasu ich zastąpienia.

W FoxIDs aplikacja jest rejestrowana z protokołem, którego używa. Zewnętrzny identity provider jest konfigurowany jako authentication method z oferowanym protokołem. FoxIDs znajduje się na granicy trust:

SAML 2.0 identity provider → FoxIDs → aplikacja OpenID Connect

Możliwy jest też kierunek odwrotny:

OpenID Connect identity provider → FoxIDs → aplikacja SAML 2.0

Takie rozdzielenie pozwala zespołom aplikacyjnym ustandaryzować jeden kontrakt bez wymuszania jednoczesnej zmiany wszystkich zewnętrznych identity providers.

Dwie ścieżki protocol bridging przez FoxIDs: SAML 2.0 do OpenID Connect oraz OpenID Connect do SAML 2.0.
FoxIDs pozwala aplikacji i dostawcy tożsamości korzystać z obsługiwanych przez nich protokołów, tworząc wspólną granicę zaufania.

Zachowaj znaczenie tożsamości, nie tylko nazwy claims

SAML assertions i OpenID Connect tokens inaczej przedstawiają tożsamość. Bezpośrednie mapowanie nazw rzadko wystarcza w środowisku produkcyjnym.

Jawnie zdefiniuj kontrakt aplikacji:

  • Który identyfikator pozostaje stabilny dla tej samej osoby pomiędzy sesjami i identity providers?
  • Jakie claims są potrzebne do prezentacji, autoryzacji i audytu?
  • Jak reprezentowane, filtrowane i transformowane są grupy oraz role?
  • Którym wartościom issuer i audience ufa aplikacja?
  • Co się dzieje, gdy zewnętrzny provider nie dostarcza wymaganego claim?
  • Czy tożsamości z różnych providers można bezpiecznie korelować, czy muszą pozostać oddzielne?

FoxIDs wewnętrznie używa JWT claims i może mapować typy SAML claims na krótsze nazwy używane w OpenID Connect. Ten claim mapping może także transformować wartości, zanim dotrą do aplikacji. Ogranicz mapowanie do tego, czego potrzebuje aplikacja, zamiast kopiować każdy atrybut do każdego tokenu.

Stabilne identyfikatory wymagają szczególnej uwagi. Adresy e-mail i nazwy użytkowników mogą się zmieniać i zwykle są słabymi kluczami głównymi. Preferuj niezmienny identyfikator źródłowy wraz z jasno określonym issuer lub inny identyfikator o kontrolowanym cyklu życia.

Identyfikatory, claims i kontekst uwierzytelnienia SAML 2.0 mapowane przez FoxIDs na tokeny OpenID Connect.
Bridge mapuje stabilne identyfikatory, wymagane claims i sygnały assurance zamiast kopiować każdy atrybut od zewnętrznego dostawcy tożsamości.

Prześledź jedną tożsamość przez bridge

Rozważ użytkownika partnera, który loguje się przez SAML 2.0 identity providera, podczas gdy aplikacja używa OpenID Connect:

  • SAML assertion dostarcza niezmienne NameID, adres e-mail, przynależność do grup i authentication context.
  • FoxIDs weryfikuje podpis, issuer, audience i czas ważności, a następnie mapuje stabilny identyfikator źródłowy na sub, wybrane grupy na role aplikacji oraz zaakceptowany authentication context na acr.
  • Aplikacja otrzymuje tylko uzgodnione OpenID Connect claims i weryfikuje FoxIDs jako issuer.

Aplikacja nie potrzebuje logiki SAML specyficznej dla partnera. Po dodaniu kolejnego partnerskiego identity providera jego claims i sygnały assurance są normalizowane na granicy FoxIDs bez zmiany kontraktu tokenu aplikacji.

Świadomie obsługuj authentication assurance

Udane logowanie SAML nie informuje automatycznie aplikacji OpenID Connect, czy użyto MFA ani jakie wymagania assurance zostały spełnione.

Określ relację między SAML authentication context, OpenID Connect authentication context i wartościami acr oczekiwanymi przez aplikację. Zdecyduj, czy FoxIDs może zaakceptować zewnętrzną assurance, musi zażądać od zewnętrznego identity providera silniejszego authentication step, czy odrzucić logowanie przy braku wymaganego context.

Ta sama zasada działa w drugą stronę. Aplikacja SAML 2.0 może oczekiwać konkretnego authentication context, gdy użytkownik loguje się przez OpenID Connect identity providera.

Nie wyprowadzaj silnego authentication wyłącznie z istnienia sesji u zewnętrznego identity providera. Oceń zwrócony authentication context zgodnie ze skonfigurowanymi regułami assurance i przetestuj zarówno zaakceptowane, jak i odrzucone przebiegi.

Rozróżniaj sesje logowania i informacje o logout

OpenID Connect i SAML 2.0 mają różne mechanizmy sesji oraz logout. Zewnętrzny identity provider i aplikacja utrzymują własne sesje logowania. FoxIDs nie utrzymuje pomiędzy nimi trzeciej sesji logowania użytkownika, lecz przechowuje wyłącznie informacje o sesji potrzebne do koordynacji logout.

Podczas logowania, reauthentication i step-up FoxIDs wysyła authentication request do zewnętrznego identity providera. FoxIDs nie używa informacji związanych z logout jako sesji logowania. Zewnętrzny identity provider decyduje na podstawie własnej sesji i wymagań requestu, czy użytkownik może kontynuować bez interakcji, czy musi ponownie się uwierzytelnić.

FoxIDs może użyć zapisanych informacji o logout do koordynowania wylogowania w odpowiednich relacjach. End-to-end single logout może działać, jeśli wszyscy uczestnicy obsługują zgodne przepływy i przeglądarka może dotrzeć do każdego endpoint, ale nie należy tego zakładać. Testuj front-channel redirects, wygasłe sesje zewnętrzne, częściowy logout, wiele aplikacji oraz provider-initiated logout.

Uzgodnij czas życia aplikacji i tokenów z oczekiwanym zachowaniem sesji zewnętrznego identity providera. Zakończenie sesji aplikacji nie musi kończyć sesji zewnętrznej. Wymagania reauthentication i step-up muszą zostać przesłane w nowym requeście i zweryfikowane na podstawie zwróconego authentication context.

Zaplanuj etapową migrację SAML do OpenID Connect

Kontrolowana migracja utrzymuje widoczne bridge, kontrakt aplikacji i ścieżkę rollback.

  1. Zinwentaryzuj obecne relacje. Zapisz aplikacje, identity providers, metadane, certyfikaty, endpoints, claims, identyfikatory, wymagania MFA, zachowanie sesji i właścicieli.
  2. Zdefiniuj kontrakt docelowy. Ustal, które aplikacje przejdą na OpenID Connect, które relacje SAML 2.0 pozostaną oraz jakie claims i sygnały assurance przejdą przez bridge.
  3. Skonfiguruj obie relacje trust. Dodaj zewnętrznego providera jako FoxIDs authentication method, a aplikację jako FoxIDs application registration.
  4. Testuj błędy i logowanie. Uwzględnij nieprawidłowe podpisy, zły issuer lub audience, brakujące claims, wygasłe assertions, ochronę przed replay, różnice czasu, logout i zmianę certyfikatów.
  5. Pracuj w oddzielnym środowisku. Zweryfikuj integrację bez zmiany ruchu produkcyjnego, a następnie kontrolowanie przenieś konfigurację między środowiskami.
  6. Najpierw przenieś ograniczoną grupę. Użyj aplikacji pilotażowej, partnera lub grupy użytkowników i zachowaj poprzednią ścieżkę do czasu potwierdzenia nowej.
  7. Obserwuj i zakończ cut-over. Monitoruj błędy authentication, różnice claims i zgłoszenia przed usunięciem starej relacji trust.

FoxIDs tenants mogą zawierać oddzielne środowiska rozwoju, testów, migracji i produkcji. Wspiera to równoległą walidację i etapowy cut-over, ale nie zastępuje planu rollback ani testów aplikacji.

Siedmioetapowa migracja od inwentaryzacji i kontraktu docelowego przez konfigurację trust, testy, kontrolowane środowiska i pilotaż do przełączenia produkcyjnego, z rollbackiem.
Etapowa migracja weryfikuje relacje zaufania i działanie aplikacji przed przełączeniem produkcyjnym oraz zachowuje możliwość rollbacku, dopóki nowa ścieżka nie zostanie potwierdzona.

Wymagaj dowodów gotowości przed cut-over

Bridge staje się częścią ścieżki authentication i musi być zarządzana jako granica bezpieczeństwa. Uzgodnij dowody wymagane dla każdej decyzji produkcyjnej, zamiast traktować udane logowanie jako akceptację.

Obszar decyzji Dowody wymagane przed produkcją
Trust endpoints Wskazani właściciele, sprawdzone metadane oraz ograniczenia issuer, audience, recipient i redirect URI
Credentials Oddzielne kontrolowane klucze, akceptowane algorytmy, test zmiany certyfikatu i właściciel odpowiedzialny za odnowienie
Kontrakt tożsamości Stabilny subject, lista dozwolonych claims, udokumentowane transformacje i zdefiniowane zachowanie przy braku wymaganych claims
Authentication assurance Akceptowane zewnętrzne contexts, reguły dodatkowego MFA i przetestowane ścieżki odrzucenia
Logowanie i logout Przetestowane przekazywanie requests dla logowania, reauthentication i step-up oraz logout, częściowy logout i odpowiednie czasy życia tokenów i sesji zewnętrznych
Błędy i operacje Testy nieprawidłowych, wygasłych i odtworzonych komunikatów oraz audit logs, alerty, odpowiedzialność za wsparcie i decyzja rollback

Nie kopiuj kluczy prywatnych między systemami tylko po to, by uprościć migrację. Każdej relacji trust przydziel własne kontrolowane credentials i zaplanuj rotację przed wygaśnięciem certyfikatów.

Jak FoxIDs obsługuje bridge

FoxIDs realizuje protocol bridging przez standardowy model applications i authentication methods. Nie trzeba wdrażać osobnego bridge service. Aplikacja OpenID Connect może korzystać z SAML 2.0, OpenID Connect lub WS-Federation authentication methods, a aplikacja SAML 2.0 z tych samych źródeł zewnętrznych.

Zespoły aplikacyjne otrzymują jeden kontrakt FoxIDs identity provider, a identity providers, partnerzy i starsze systemy można połączyć przez obsługiwane standardy. FoxIDs zapewnia też claim mapping, konfigurowalne authentication flows, MFA oraz oddzielne środowiska testowe i produkcyjne.

Szczegółowy model konfiguracji, authentication methods i application registrations opisuje dokumentacja protocol bridge. Jeśli prace obejmują onboarding aplikacji, projekt claims, testy lub migrację etapową, FoxIDs Identity Integration opisuje wsparcie wdrożeniowe zespołu tworzącego platformę.

Podsumowanie

SAML do OpenID Connect bridge jest najbardziej przydatna, gdy pozwala aplikacjom i identity providers rozwijać się niezależnie bez osłabiania kontraktu tożsamości.

Traktuj bridge jako świadomą granicę trust, a nie niewidoczny translator tokenów. Gdy kontrakt aplikacji, reguły assurance, zachowanie logowania i logout, dowody gotowości produkcyjnej, odpowiedzialność i rollback są jednoznaczne, FoxIDs zapewnia oparty na standardach model wdrożenia pozwalający wprowadzać zmianę w kontrolowanych etapach.