Most SAML 2.0, OpenID Connect i WS-Federation

FoxIDs może działać jako most protokołów między SAML 2.0, OpenID Connect / OAuth 2.0 i WS-Federation. Dzięki temu aplikacja może nadal używać jednego protokołu tożsamości, podczas gdy zewnętrzny identity provider lub aplikacja partnerska używa innego.

Most nie jest osobnym komponentem, który trzeba zainstalować. To normalny model FoxIDs: użytkownicy logują się przez metodę uwierzytelniania, a FoxIDs wystawia odpowiedź wymaganą przez application registration. Gdy obie strony używają różnych standardów, FoxIDs wykonuje tłumaczenie protokołów, claim mapping, tworzenie tokenów i routing logowania.

Niektóre zespoły opisują to jako protocol translation, SAML do OIDC translation, token translation, identity broker lub federation broker. W FoxIDs te określenia opisują ten sam model konfiguracji, ale projekt nadal należy oceniać jako granicę identity trust. Ważnym rezultatem nie są tylko przetłumaczone komunikaty lub tokeny, ale spójny kontrakt aplikacji, issuer, audience, claims i zachowanie logout między połączonymi standardami.

Użyj mostu, gdy:

Aplikacja obsługuje już OpenID Connect i musi logować użytkowników z identity providera SAML 2.0 lub WS-Federation.
Aplikacja SAML 2.0 lub WS-Federation musi używać identity providera OpenID Connect.
Starsza aplikacja WS-Federation lub SAML 2.0 ma zostać połączona z nowoczesną platformą tożsamości OpenID Connect bez zmiany aplikacji.
Kilka aplikacji ma ufać temu samemu środowisku FoxIDs, mimo że używają różnych standardów.

Federated Identity Management (FIM) łączy tożsamości między domenami. Single Sign-On (SSO) pozwala użytkownikom korzystać z aplikacji bez ponownego logowania. FoxIDs obsługuje oba mechanizmy, a most umożliwia działanie FIM i SSO ponad granicami protokołów.

Jak działa most

OpenID Connect, SAML 2.0 i WS-Federation rozwiązują wiele tych samych problemów tożsamości, ale ich komunikaty, tokeny, metadane, certyfikaty i formaty claims są różne.

OpenID Connect jest oparty na OAuth 2.0 i jest często używany przez nowoczesne aplikacje webowe, mobilne i oparte na API. Używa JSON Web Tokens (JWT) jako identity tokens i access tokens.
SAML 2.0 jest oparty na XML i szeroko używany do enterprise SSO w przeglądarce. Używa SAML assertions i podpisów XML.
WS-Federation jest oparty na XML i często używany przez enterprise oraz legacy aplikacje webowe. Zwykle używa tokenów SAML 1.1 lub SAML 2.0 w odpowiedziach logowania WS-Federation.

FoxIDs łączy te standardy, działając jako zaufana strona po obu stronach połączenia:

Wobec zewnętrznego identity providera FoxIDs jest skonfigurowany jako metoda uwierzytelniania.
Wobec aplikacji FoxIDs jest skonfigurowany jako application registration.
Wewnętrznie FoxIDs reprezentuje claims jako JWT claims i w razie potrzeby mapuje między JWT claims i SAML claims.
Aplikacja otrzymuje odpowiedź protokołu, którą już rozumie.

Nie ma wymagania, aby protokół wejściowy i wyjściowy były takie same. Aplikacja OpenID Connect może używać metody uwierzytelniania SAML 2.0. Aplikacja SAML 2.0 może używać metody uwierzytelniania OpenID Connect. WS-Federation może być również używany po dowolnej stronie.

Konfigurowanie mostu

Most konfiguruje się przez połączenie metody uwierzytelniania z application registration w tym samym środowisku.

Skonfiguruj upstream identity provider jako metodę uwierzytelniania:
- Metoda uwierzytelniania OpenID Connect
- Metoda uwierzytelniania SAML 2.0
- Metoda uwierzytelniania WS-Federation
Skonfiguruj aplikację jako application registration:
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
W application registration wybierz metodę uwierzytelniania, która ma obsługiwać logowanie.
Jeśli dostępna jest więcej niż jedna metoda uwierzytelniania, aplikacja może wybrać jedną bezpośrednio albo użytkownik może wybrać ją na stronie home realm discovery (HRD).
Sprawdź claim mappings, certyfikaty, metadane i zachowanie logout dla standardów używanych po obu stronach.

Najważniejszą decyzją konfiguracyjną nie jest więc specjalne ustawienie bridge. Jest nią powiązanie metody uwierzytelniania z application registration.

SAML 2.0 do OpenID Connect

Ten most jest częsty, gdy aplikacja obsługuje już OpenID Connect, ale organizacja lub partnerski identity provider obsługuje tylko SAML 2.0.

Skonfiguruj zewnętrzny IdP jako metodę uwierzytelniania SAML 2.0. Skonfiguruj aplikację jako OpenID Connect application registration i wybierz metodę uwierzytelniania SAML 2.0.

Gdy aplikacja wysyła żądanie logowania OpenID Connect, FoxIDs kieruje użytkownika do zewnętrznego SAML 2.0 IdP. Odpowiedź SAML 2.0 jest walidowana, SAML 2.0 claims są mapowane na JWT claims, a FoxIDs zwraca odpowiedź OpenID Connect do aplikacji.

Most SAML 2.0 do OpenID Connect

Przeczytaj Bridge SAML do OIDC dla aplikacji OpenID Connect, aby uzyskać wskazówki dotyczące architektury, projektowania claims, migracji i gotowości produkcyjnej.

OpenID Connect do SAML 2.0

Ten most jest przydatny, gdy aplikacja SAML 2.0 ma używać nowoczesnego identity providera OpenID Connect.

Skonfiguruj zewnętrznego providera jako metodę uwierzytelniania OpenID Connect. Skonfiguruj aplikację jako SAML 2.0 application registration i wybierz metodę uwierzytelniania OpenID Connect.

Gdy aplikacja SAML 2.0 wysyła SAML 2.0 Authn Request, FoxIDs kieruje użytkownika do OpenID Provider (OP). Odpowiedź OpenID Connect jest walidowana, JWT claims są mapowane na SAML 2.0 claims, a FoxIDs zwraca odpowiedź SAML 2.0 do aplikacji.

Most OpenID Connect do SAML 2.0

FoxIDs obsługuje bridging sign-in, logout i single logout między SAML 2.0 i OpenID Connect.

Scenariusze mostu WS-Federation

WS-Federation działa w tym samym modelu co pozostałe standardy. Może być skonfigurowany jako metoda uwierzytelniania, gdy zewnętrzny identity provider jest WS-Federation Security Token Service (STS), oraz jako application registration, gdy aplikacja oczekuje odpowiedzi logowania WS-Federation.

Typowe scenariusze mostu WS-Federation obejmują:

WS-Federation IdP do aplikacji OpenID Connect.
OpenID Connect IdP do aplikacji WS-Federation.
WS-Federation IdP do aplikacji SAML 2.0.
SAML 2.0 IdP do aplikacji WS-Federation.

Jest to przydatne w scenariuszach zastępowania AD FS, starszych aplikacjach ASP.NET, SharePoint, Dynamics i innych systemach, które nadal używają WS-Federation, podczas gdy nowe aplikacje i API mogą nadal używać OpenID Connect i OAuth 2.0.

Jedno środowisko, jeden Identity Provider

Cała funkcjonalność bridge może być łączona w tym samym środowisku FoxIDs. Na przykład aplikacja OpenID Connect może obsługiwać logowanie przez metody uwierzytelniania SAML 2.0 i OpenID Connect jednocześnie.

Często prościej jest pozwolić aplikacjom i API ufać jednemu środowisku FoxIDs jako ich Identity Providerowi (IdP), nawet jeśli użytkownicy uwierzytelniają się przez różne zewnętrzne protokoły. W tym modelu:

Aplikacje są rejestrowane w FoxIDs z protokołem, który już obsługują.
Zewnętrzni identity providerzy są konfigurowani jako metody uwierzytelniania.
FoxIDs wykonuje tłumaczenie protokołów i claim mapping między obiema stronami.
Klienci OpenID Connect i API OAuth 2.0 mogą nadal używać ID tokens i access tokens, nawet gdy pierwotne logowanie pochodziło z SAML 2.0 lub WS-Federation.

Ten model jest szczególnie przydatny przy stopniowej modernizacji krajobrazu aplikacji. Istniejące systemy SAML 2.0 i WS-Federation mogą nadal działać, podczas gdy nowe aplikacje używają OpenID Connect i OAuth 2.0.

Token exchange

Jeśli użytkownik loguje się do aplikacji SAML 2.0 przez zewnętrzny SAML 2.0 IdP, aplikacja otrzymuje token SAML 2.0 dla tego użytkownika. W architekturach zero trust API powinny być nadal wywoływane w kontekście użytkownika końcowego.

Użyj token exchange, gdy token SAML 2.0 musi zostać wymieniony na access token OAuth 2.0. Wynikowy access token może być używany do wywoływania API obsługujących OAuth 2.0 w kontekście zalogowanego użytkownika.

Mapowania oświadczeń

FoxIDs wewnętrznie wykorzystuje claims JWT oraz mapuje claims SAML 2.0 na claims JWT. Ten sam model mapowania claims SAML/JWT jest również stosowany w przypadku WS-Federation, ponieważ tokeny WS-Federation zawierają claims SAML.

Domyślnie stosowane są standardowe mapowania, na przykład sub do http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier oraz email do http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Mapowania oświadczeń można przeglądać i konfigurować w zakładce Ustawienia > Mapowania oświadczeń środowiska, opisanej w sekcji ustawienia środowiska. Jeśli dla danego oświadczenia nie istnieje żadne mapowanie, FoxIDs zachowuje oryginalną nazwę oświadczenia. Pozwala to zachować oświadczenia podczas przekraczania mostu, a jednocześnie umożliwia stosowanie krótszych nazw oświadczeń JWT tam, gdzie skonfigurowano mapowania.

Niestandardowe mapowania

Mapowania niestandardowe należą do środowiska i łączą typ oświadczenia JWT z typem oświadczenia SAML. Mapowanie niestandardowe ma pierwszeństwo przed zmiennym ustawieniem domyślnym dla tego samego typu oświadczenia przychodzącego, ale nie może zastąpić zablokowanego mapowania domyślnego.

Gdy w ustawieniach środowiska włączona jest opcja Automatyczne tworzenie mapowań między typami oświadczeń JWT a typami oświadczeń SAML, usługa FoxIDs może dodawać niestandardowe mapowania dla wcześniej niemapowanych typów oświadczeń w trakcie ich przetwarzania. Niestandardowe mapowania można również dodawać, edytować lub usuwać ręcznie.

Domyślne mapowania

Domyślne mapowania oświadczeń SAML 2.0 i JWT są wbudowane w FoxIDs i mają status tylko do odczytu w Control Client. Zablokowane mapowania domyślne są zawsze egzekwowane. Modyfikowalne mapowania domyślne są stosowane tylko wtedy, gdy dla danego typu przychodzącego oświadczenia nie ma pierwszeństwa żadne mapowanie niestandardowe.