SAML 2.0, OpenID Connect en WS-Federation bridge

FoxIDs kan fungeren als protocolbridge tussen SAML 2.0, OpenID Connect / OAuth 2.0 en WS-Federation. Hierdoor kan een applicatie één identiteitsprotocol blijven gebruiken terwijl de externe identity provider of partnerapplicatie een ander protocol gebruikt.

De bridge is geen aparte component die u moet installeren. Het is het normale FoxIDs-model: gebruikers melden zich aan via een authenticatiemethode, en FoxIDs geeft de response uit die de application registration nodig heeft. Wanneer de twee kanten verschillende standaarden gebruiken, verzorgt FoxIDs protocolvertaling, claim mapping, tokencreatie en sign-in-routing.

Sommige teams beschrijven dit als protocol translation, SAML naar OIDC vertaling, token translation, identity broker of federation broker. In FoxIDs beschrijven die woorden hetzelfde configuratiemodel, maar het ontwerp moet nog steeds als een identity trust-grens worden beoordeeld. Het belangrijke resultaat is niet alleen vertaalde berichten of tokens, maar een consistent applicatiecontract, issuer, audience, claims en uitloggedrag over de verbonden standaarden heen.

Gebruik de bridge wanneer:

  • Een applicatie al OpenID Connect ondersteunt en gebruikers moet aanmelden vanuit een SAML 2.0- of WS-Federation identity provider.
  • Een SAML 2.0- of WS-Federation-applicatie een OpenID Connect identity provider moet gebruiken.
  • Een oudere WS-Federation- of SAML 2.0-applicatie aan een modern OpenID Connect-identiteitsplatform moet worden gekoppeld zonder de applicatie te wijzigen.
  • Meerdere applicaties dezelfde FoxIDs-omgeving moeten vertrouwen, ook al gebruiken ze verschillende standaarden.

Federated Identity Management (FIM) koppelt identiteiten over domeinen heen. Single Sign-On (SSO) laat gebruikers applicaties gebruiken zonder opnieuw aan te melden. FoxIDs ondersteunt beide, en de bridge laat FIM en SSO werken over protocolgrenzen heen.

Hoe de bridge werkt

OpenID Connect, SAML 2.0 en WS-Federation lossen veel van dezelfde identiteitsproblemen op, maar hun berichten, tokens, metadata, certificaten en claim-formaten verschillen.

  • OpenID Connect is gebouwd op OAuth 2.0 en wordt vaak gebruikt door moderne web-, mobiele en API-gebaseerde applicaties. Het gebruikt JSON Web Tokens (JWT's) als identity tokens en access tokens.
  • SAML 2.0 is XML-gebaseerd en wordt breed gebruikt voor enterprise browsergebaseerde SSO. Het gebruikt SAML assertions en XML-handtekeningen.
  • WS-Federation is XML-gebaseerd en wordt vaak gebruikt door enterprise- en legacy-webapplicaties. Het gebruikt meestal SAML 1.1- of SAML 2.0-tokens in WS-Federation sign-in-responses.

FoxIDs bridget deze standaarden door aan beide kanten van de verbinding als vertrouwde partij te werken:

  • Richting de externe identity provider wordt FoxIDs geconfigureerd als authenticatiemethode.
  • Richting de applicatie wordt FoxIDs geconfigureerd als application registration.
  • Intern representeert FoxIDs claims als JWT claims en mapt waar nodig tussen JWT claims en SAML claims.
  • De applicatie ontvangt de protocolresponse die zij al begrijpt.

Er is geen vereiste dat het inkomende en uitgaande protocol hetzelfde zijn. Een OpenID Connect-applicatie kan een SAML 2.0-authenticatiemethode gebruiken. Een SAML 2.0-applicatie kan een OpenID Connect-authenticatiemethode gebruiken. WS-Federation kan ook aan beide kanten worden gebruikt.

Een bridge configureren

Een bridge wordt geconfigureerd door een authenticatiemethode te combineren met een application registration in dezelfde omgeving.

  1. Configureer de upstream identity provider als authenticatiemethode:
  2. Configureer de applicatie als application registration:
  3. Selecteer in de application registration de authenticatiemethode die sign-in moet afhandelen.
  4. Als er meer dan één authenticatiemethode beschikbaar is, kan de applicatie er rechtstreeks één selecteren, of de gebruiker kan kiezen op een home realm discovery (HRD)-pagina.
  5. Controleer claim mappings, certificaten, metadata en logout-gedrag voor de standaarden die aan elke kant worden gebruikt.

De belangrijkste configuratiekeuze is daarom geen speciale bridge-instelling. Het is de koppeling tussen authenticatiemethode en application registration.

SAML 2.0 naar OpenID Connect

Deze bridge komt vaak voor wanneer een applicatie al OpenID Connect ondersteunt, maar de organisatie of partner-identity provider alleen SAML 2.0 ondersteunt.

Configureer de externe IdP als SAML 2.0-authenticatiemethode. Configureer de applicatie als OpenID Connect application registration en selecteer de SAML 2.0-authenticatiemethode.

Wanneer de applicatie een OpenID Connect sign-in-request verstuurt, routeert FoxIDs de gebruiker naar de externe SAML 2.0 IdP. De SAML 2.0-response wordt gevalideerd, SAML 2.0 claims worden gemapt naar JWT claims, en FoxIDs retourneert een OpenID Connect-response aan de applicatie.

Bridge SAML 2.0 naar OpenID Connect

Lees SAML naar OIDC bridge voor OpenID Connect applicaties voor richtlijnen over architectuur, claimontwerp, migratie en productiegereedheid.

OpenID Connect naar SAML 2.0

Deze bridge is nuttig wanneer een SAML 2.0-applicatie een moderne OpenID Connect identity provider moet gebruiken.

Configureer de externe provider als OpenID Connect-authenticatiemethode. Configureer de applicatie als SAML 2.0 application registration en selecteer de OpenID Connect-authenticatiemethode.

Wanneer de SAML 2.0-applicatie een SAML 2.0 Authn Request verstuurt, routeert FoxIDs de gebruiker naar de OpenID Provider (OP). De OpenID Connect-response wordt gevalideerd, JWT claims worden gemapt naar SAML 2.0 claims, en FoxIDs retourneert een SAML 2.0-response aan de applicatie.

Bridge OpenID Connect naar SAML 2.0

FoxIDs ondersteunt bridging van sign-in, logout en single logout tussen SAML 2.0 en OpenID Connect.

WS-Federation bridge-scenario's

WS-Federation werkt volgens hetzelfde model als de andere standaarden. Het kan worden geconfigureerd als authenticatiemethode wanneer de externe identity provider een WS-Federation Security Token Service (STS) is, en als application registration wanneer de applicatie een WS-Federation sign-in-response verwacht.

Typische WS-Federation bridge-scenario's zijn:

  • WS-Federation IdP naar OpenID Connect-applicatie.
  • OpenID Connect IdP naar WS-Federation-applicatie.
  • WS-Federation IdP naar SAML 2.0-applicatie.
  • SAML 2.0 IdP naar WS-Federation-applicatie.

Dit is nuttig voor AD FS-vervangingsscenario's, oudere ASP.NET-applicaties, SharePoint, Dynamics en andere systemen die nog WS-Federation gebruiken, terwijl nieuwe applicaties en API's OpenID Connect en OAuth 2.0 kunnen blijven gebruiken.

Eén omgeving, één Identity Provider

Alle bridge-functionaliteit kan worden gecombineerd in dezelfde FoxIDs-omgeving. Een OpenID Connect-applicatie kan bijvoorbeeld sign-in ondersteunen via zowel SAML 2.0- als OpenID Connect-authenticatiemethoden tegelijk.

Het is vaak eenvoudiger om applicaties en API's één FoxIDs-omgeving te laten vertrouwen als hun Identity Provider (IdP), zelfs wanneer gebruikers via verschillende externe protocollen worden geauthenticeerd. In dat model:

  • Worden applicaties in FoxIDs geregistreerd met het protocol dat ze al ondersteunen.
  • Worden externe identity providers geconfigureerd als authenticatiemethoden.
  • Voert FoxIDs protocolvertaling en claim mapping uit tussen de twee kanten.
  • Kunnen OpenID Connect-clients en OAuth 2.0-API's ID tokens en access tokens blijven gebruiken, zelfs wanneer de oorspronkelijke sign-in uit SAML 2.0 of WS-Federation kwam.

Dit model is vooral nuttig wanneer een applicatielandschap stapsgewijs wordt gemoderniseerd. Bestaande SAML 2.0- en WS-Federation-systemen kunnen blijven draaien terwijl nieuwe applicaties OpenID Connect en OAuth 2.0 gebruiken.

Token exchange

Als een gebruiker zich aanmeldt bij een SAML 2.0-applicatie via een externe SAML 2.0 IdP, ontvangt de applicatie een SAML 2.0-token voor die gebruiker. In zero trust-architecturen moeten API's nog steeds worden aangeroepen in de context van de eindgebruiker.

Gebruik token exchange wanneer een SAML 2.0-token moet worden omgewisseld voor een OAuth 2.0 access token. Het resulterende access token kan worden gebruikt om OAuth 2.0-enabled API's aan te roepen in de context van de aangemelde gebruiker.

Claimtoewijzingen

FoxIDs maakt intern gebruik van JWT-claims en koppelt SAML 2.0-claims aan JWT-claims. Hetzelfde SAML/JWT-claimkoppelingsmodel wordt ook gebruikt voor WS-Federation, omdat WS-Federation-tokens SAML-claims bevatten.

Standaard worden standaardtoewijzingen toegepast, bijvoorbeeld sub naar http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier en email naar http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

U kunt claimtoewijzingen bekijken en configureren in het tabblad Instellingen > Claimtoewijzingen van de omgeving, zoals beschreven onder omgevingsinstellingen. Als er geen toewijzing bestaat voor een claim, behoudt FoxIDs de oorspronkelijke claimnaam. Hierdoor blijven claims over de bridge heen behouden, terwijl er toch kortere JWT claimnamen kunnen worden gebruikt waar toewijzingen zijn geconfigureerd.

Aangepaste toewijzingen

Aangepaste toewijzingen behoren tot de omgeving en koppelen een claimtype van JWT aan een SAML-claimtype. Een aangepaste toewijzing heeft voorrang op een wijzigbare standaardinstelling voor hetzelfde inkomende claimtype, maar kan een vergrendelde standaardtoewijzing niet overschrijven.

Wanneer Automatisch toewijzingen aanmaken tussen JWT en SAML-claimtypen is ingeschakeld in de omgevingsinstellingen, kan FoxIDs aangepaste toewijzingen toevoegen voor claimtypen die nog niet zijn toegewezen, terwijl deze worden verwerkt. U kunt aangepaste toewijzingen ook handmatig toevoegen, bewerken of verwijderen.

Standaardtoewijzingen

Standaard SAML 2.0 en JWT claimtoewijzingen zijn ingebouwd in FoxIDs en zijn alleen-lezen in de Control Client. Vergrendelde standaardtoewijzingen worden altijd afgedwongen. Wijzigbare standaardtoewijzingen worden alleen gebruikt wanneer er geen aangepaste toewijzing voorrang heeft voor het binnenkomende claimtype.