Most SAML 2.0 / OpenID Connect

Domyślnie FoxIDs jest mostem między SAML 2.0 a OpenID Connect / OAuth 2.0 bez dodatkowej konfiguracji.

Federated Identity Management (FIM) koncentruje się na łączeniu tożsamości między domenami, a Single Sign-On (SSO) upraszcza dostęp do aplikacji. FoxIDs obsługuje zarówno FIM, jak i SSO, a most umożliwia je między SAML 2.0 a OpenID Connect.

OpenID Connect (OIDC) i SAML 2.0 to powszechnie używane protokoły federacji tożsamości, single sign-on (SSO) oraz uwierzytelniania użytkowników. Jednak różnią się znacząco strukturą i projektem. Czasami trzeba je zmostkować lub zintegrować, na przykład aby aplikacja obsługująca OpenID Connect mogła współpracować z dostawcą tożsamości (IdP), który obsługuje wyłącznie SAML 2.0.

Kluczowe różnice między tymi protokołami:

• OIDC: Zbudowany na OAuth 2.0, nowoczesny protokół zaprojektowany dla aplikacji webowych i mobilnych z interfejsami REST. Używa JSON Web Tokens (JWT) dla tokenów tożsamości i dostępu.
• SAML 2.0: Protokół oparty na XML i ukierunkowany na scenariusze SSO w przeglądarce, często używany w środowiskach korporacyjnych. Używa asercji / tokenów opartych na XML.

Aby połączyć system OpenID Connect z systemem SAML 2.0, potrzebujesz warstwy translacji protokołu (mostu). Można to osiągnąć dzięki pośrednikowi, który działa zarówno jako OpenID Connect Provider (OP), jak i SAML Service Provider (SP), lub odwrotnie.

Jeśli skonfigurujesz metodę uwierzytelniania SAML 2.0 do zewnętrznego Identity Provider (IdP) i podłączysz aplikację jako rejestrację aplikacji OpenID Connect, w której wybierzesz metodę uwierzytelniania SAML 2.0, żądanie logowania z aplikacji zostanie przekierowane jako zewnętrzne żądanie logowania SAML 2.0. Odpowiedź logowania SAML 2.0 jest następnie mapowana na odpowiedź OpenID Connect dla aplikacji. Oświadczenia SAML 2.0 są automatycznie konwertowane na oświadczenia JWT (OAuth 2.0).

Analogicznie można rozpocząć żądanie logowania z aplikacji rejestracji SAML 2.0 i przekierować je do zewnętrznego OpenID Provider (OP) skonfigurowanego jako metoda uwierzytelniania OpenID Connect. Następnie odpowiedź jest konwertowana do odpowiedzi SAML 2.0.

FoxIDs obsługuje mostowanie logowania, wylogowania oraz single logout między SAML 2.0 a OpenID Connect.

Jedno środowisko — jeden Identity Provider

Całą funkcjonalność mostu można połączyć w tym samym środowisku. Umożliwia to aplikacji OpenID Connect obsługę logowania zarówno przez metodę uwierzytelniania SAML 2.0, jak i OpenID Connect w tym samym czasie. Aplikacja OpenID Connect może wybrać metodę uwierzytelniania gramatycznie lub pozwolić użytkownikowi wybrać ją na stronie home realm discovery (HRD).

Zaleca się architekturę aplikacji z klientami włączonymi przez OpenID Connect i interfejsami API włączonymi przez OAuth 2.0. Wtedy wszystkie aplikacje (klienci i API) ufają temu samemu Identity Provider (IdP) — jeden IdP równa się jedno środowisko FoxIDs. Dzięki funkcji mostu w FoxIDs tokeny SAML 2.0 są mapowane na tokeny ID i access tokeny, które można wykorzystać do uwierzytelniania aplikacji OpenID Connect i wywoływania istniejących API.

Wymiana tokenów

Jeśli użytkownik uzyska dostęp do aplikacji SAML 2.0 po pomyślnym logowaniu przy użyciu zewnętrznego Identity Provider (IdP) SAML 2.0, dostęp jest przyznany w kontekście tego użytkownika. W podejściu zero trust (nigdy nie ufaj, zawsze weryfikuj) API powinno być wywoływane w kontekście użytkownika. Jest to możliwe dzięki wymianie tokenów, gdzie token SAML 2.0 można wymienić na access token z tożsamością użytkownika końcowego. Następnie można wywoływać API z OAuth 2.0 w kontekście użytkownika.

Mapowania oświadczeń

FoxIDs wewnętrznie używa oświadczeń JWT i mapuje oświadczenia SAML 2.0 na oświadczenia JWT. Domyślnie mapowany jest zestaw standardowych oświadczeń JWT do SAML 2.0, na przykład sub do http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, email do http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress itd. Możesz dodać dodatkowe mapowania JWT do SAML 2.0.
Jeśli mapowanie nie istnieje dla danego oświadczenia, zachowana zostaje długa nazwa oświadczenia SAML 2.0 z tokenu, zamiast krótszej nazwy JWT. To samo dotyczy kierunku odwrotnego.