Bridge SAML 2.0, OpenID Connect e WS-Federation

A FoxIDs pode atuar como bridge de protocolos entre SAML 2.0, OpenID Connect / OAuth 2.0 e WS-Federation. Isto permite que uma aplicação continue a usar um protocolo de identidade enquanto o identity provider externo ou a aplicação parceira usa outro.

A bridge não é um componente separado que tenha de instalar. É o modelo normal da FoxIDs: os utilizadores iniciam sessão através de um método de autenticação, e a FoxIDs emite a resposta exigida pela application registration. Quando os dois lados usam standards diferentes, a FoxIDs trata da tradução de protocolos, claim mapping, criação de tokens e routing de sign-in.

Algumas equipas descrevem isto como protocol translation, tradução SAML para OIDC, token translation, identity broker ou federation broker. Na FoxIDs, estes termos descrevem o mesmo modelo de configuração, mas o desenho deve continuar a ser revisto como uma fronteira de identity trust. O resultado importante não são apenas mensagens ou tokens traduzidos, mas um contrato da aplicação, issuer, audience, claims e comportamento de logout consistentes entre os standards ligados.

Use a bridge quando:

Uma aplicação já suporta OpenID Connect e precisa de iniciar sessão de utilizadores a partir de um identity provider SAML 2.0 ou WS-Federation.
Uma aplicação SAML 2.0 ou WS-Federation precisa de usar um identity provider OpenID Connect.
Uma aplicação legacy WS-Federation ou SAML 2.0 deve ser ligada a uma plataforma de identidade OpenID Connect moderna sem alterar a aplicação.
Várias aplicações devem confiar no mesmo ambiente FoxIDs mesmo usando standards diferentes.

Federated Identity Management (FIM) liga identidades entre domínios. Single Sign-On (SSO) permite aos utilizadores aceder a aplicações sem voltar a iniciar sessão. A FoxIDs suporta ambos, e a bridge faz FIM e SSO funcionar através de fronteiras de protocolo.

Como funciona a bridge

OpenID Connect, SAML 2.0 e WS-Federation resolvem muitos dos mesmos problemas de identidade, mas as suas mensagens, tokens, metadata, certificados e formatos de claims são diferentes.

OpenID Connect é baseado em OAuth 2.0 e é usado habitualmente por aplicações web, móveis e baseadas em API modernas. Usa JSON Web Tokens (JWTs) como identity tokens e access tokens.
SAML 2.0 é baseado em XML e é amplamente usado para SSO enterprise baseado em browser. Usa SAML assertions e assinaturas XML.
WS-Federation é baseado em XML e é usado habitualmente por aplicações web enterprise e legacy. Normalmente usa tokens SAML 1.1 ou SAML 2.0 em respostas de sign-in WS-Federation.

A FoxIDs cria bridge entre estes standards atuando como a parte confiável dos dois lados da ligação:

Em direção ao identity provider externo, a FoxIDs é configurada como método de autenticação.
Em direção à aplicação, a FoxIDs é configurada como application registration.
Internamente, a FoxIDs representa claims como JWT claims e mapeia entre JWT claims e SAML claims quando necessário.
A aplicação recebe a resposta de protocolo que já compreende.

Não há requisito para que os protocolos de entrada e saída sejam iguais. Uma aplicação OpenID Connect pode usar um método de autenticação SAML 2.0. Uma aplicação SAML 2.0 pode usar um método de autenticação OpenID Connect. WS-Federation também pode ser usado em qualquer dos lados.

Configurar uma bridge

Uma bridge é configurada combinando um método de autenticação com uma application registration no mesmo ambiente.

Configure o identity provider upstream como método de autenticação:
- Método de autenticação OpenID Connect
- Método de autenticação SAML 2.0
- Método de autenticação WS-Federation
Configure a aplicação como application registration:
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
Na application registration, selecione o método de autenticação que deve tratar do sign-in.
Se estiver disponível mais de um método de autenticação, a aplicação pode selecionar um diretamente, ou o utilizador pode escolher numa página de home realm discovery (HRD).
Reveja claim mappings, certificados, metadata e comportamento de logout para os standards usados em cada lado.

A escolha de configuração mais importante não é, portanto, uma definição bridge especial. É o emparelhamento entre método de autenticação e application registration.

SAML 2.0 para OpenID Connect

Esta bridge é comum quando uma aplicação já suporta OpenID Connect, mas a organização ou o identity provider parceiro suporta apenas SAML 2.0.

Configure o IdP externo como método de autenticação SAML 2.0. Configure a aplicação como OpenID Connect application registration e selecione o método de autenticação SAML 2.0.

Quando a aplicação envia um pedido de sign-in OpenID Connect, a FoxIDs encaminha o utilizador para o IdP SAML 2.0 externo. A resposta SAML 2.0 é validada, os SAML 2.0 claims são mapeados para JWT claims, e a FoxIDs devolve uma resposta OpenID Connect à aplicação.

Bridge SAML 2.0 para OpenID Connect

Leia Bridge de SAML para OIDC para aplicações OpenID Connect para obter orientações sobre arquitetura, conceção de claims, migração e preparação para produção.

OpenID Connect para SAML 2.0

Esta bridge é útil quando uma aplicação SAML 2.0 deve usar um identity provider OpenID Connect moderno.

Configure o provider externo como método de autenticação OpenID Connect. Configure a aplicação como SAML 2.0 application registration e selecione o método de autenticação OpenID Connect.

Quando a aplicação SAML 2.0 envia um SAML 2.0 Authn Request, a FoxIDs encaminha o utilizador para o OpenID Provider (OP). A resposta OpenID Connect é validada, os JWT claims são mapeados para SAML 2.0 claims, e a FoxIDs devolve uma resposta SAML 2.0 à aplicação.

Bridge OpenID Connect para SAML 2.0

A FoxIDs suporta bridging de sign-in, logout e single logout entre SAML 2.0 e OpenID Connect.

Cenários de bridge WS-Federation

WS-Federation funciona no mesmo modelo que os outros standards. Pode ser configurado como método de autenticação quando o identity provider externo é um WS-Federation Security Token Service (STS), e como application registration quando a aplicação espera uma resposta de sign-in WS-Federation.

Cenários típicos de bridge WS-Federation incluem:

IdP WS-Federation para aplicação OpenID Connect.
IdP OpenID Connect para aplicação WS-Federation.
IdP WS-Federation para aplicação SAML 2.0.
IdP SAML 2.0 para aplicação WS-Federation.

Isto é útil em cenários de substituição de AD FS, aplicações ASP.NET antigas, SharePoint, Dynamics e outros sistemas que ainda usam WS-Federation, enquanto novas aplicações e APIs podem continuar a usar OpenID Connect e OAuth 2.0.

Um ambiente, um Identity Provider

Toda a funcionalidade de bridge pode ser combinada no mesmo ambiente FoxIDs. Por exemplo, uma aplicação OpenID Connect pode suportar sign-in através de métodos de autenticação SAML 2.0 e OpenID Connect ao mesmo tempo.

É frequentemente mais simples deixar aplicações e APIs confiar num único ambiente FoxIDs como o seu Identity Provider (IdP), mesmo que os utilizadores se autentiquem através de diferentes protocolos externos. Nesse modelo:

As aplicações são registadas na FoxIDs com o protocolo que já suportam.
Os identity providers externos são configurados como métodos de autenticação.
A FoxIDs realiza tradução de protocolos e claim mapping entre os dois lados.
Clientes OpenID Connect e APIs OAuth 2.0 podem continuar a usar ID tokens e access tokens, mesmo quando o sign-in original veio de SAML 2.0 ou WS-Federation.

Este modelo é especialmente útil quando se moderniza gradualmente um panorama aplicacional. Sistemas SAML 2.0 e WS-Federation existentes podem continuar a funcionar enquanto novas aplicações usam OpenID Connect e OAuth 2.0.

Token exchange

Se um utilizador inicia sessão numa aplicação SAML 2.0 através de um IdP SAML 2.0 externo, a aplicação recebe um token SAML 2.0 para esse utilizador. Em arquiteturas zero trust, as APIs devem continuar a ser chamadas no contexto do utilizador final.

Use token exchange quando um token SAML 2.0 precisa de ser trocado por um access token OAuth 2.0. O access token resultante pode ser usado para chamar APIs ativadas para OAuth 2.0 no contexto do utilizador autenticado.

Mapeamentos de reivindicações

O FoxIDs utiliza internamente claims JWT e mapeia claims SAML 2.0 para claims JWT. O mesmo modelo de mapeamento de claims SAML/JWT também é utilizado para WS-Federation, uma vez que os tokens WS-Federation contêm claims SAML.

Por predefinição, são aplicados mapeamentos padrão, por exemplo, sub para http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier e email para http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Pode rever e configurar os mapeamentos de reivindicações no separador Definições > Mapeamentos de reivindicações do ambiente, descrito em definições do ambiente. Se não existir nenhum mapeamento para uma reivindicação, o FoxIDs mantém o nome original da reivindicação. Isto preserva as reivindicações através da ponte, permitindo simultaneamente nomes de reivindicações mais curtos JWT nos casos em que os mapeamentos estão configurados.

Mapeamentos personalizados

Os mapeamentos personalizados pertencem ao ambiente e associam um tipo de reivindicação JWT a um tipo de reivindicação SAML. Um mapeamento personalizado tem precedência sobre um valor predefinido alterável para o mesmo tipo de reivindicação recebida, mas não pode substituir um mapeamento predefinido bloqueado.

Quando a opção Criar automaticamente mapeamentos entre os tipos de reivindicações do JWT e do SAML está ativada nas definições do ambiente, o FoxIDs pode adicionar mapeamentos personalizados para tipos de reivindicações anteriormente não mapeados à medida que estes são processados. Também é possível adicionar, editar ou remover mapeamentos personalizados manualmente.

Mapeamentos predefinidos

Os mapeamentos de claims predefinidos de SAML 2.0 e JWT estão integrados no FoxIDs e são de leitura apenas no Control Client. Os mapeamentos predefinidos bloqueados são sempre aplicados. Os mapeamentos predefinidos alteráveis são utilizados apenas quando nenhum mapeamento personalizado tem prioridade para o tipo de claim recebido.