Uma aplicação e o respetivo identity provider não têm de suportar o mesmo protocolo de federação. Uma aplicação moderna pode usar OpenID Connect enquanto um identity provider empresarial ou de um parceiro continua a usar SAML 2.0. Reescrever um dos lados apenas para fazer coincidir os protocolos pode aumentar custos, risco de migração e dependências desnecessárias.
Um bridge de SAML para OpenID Connect permite que cada lado mantenha o protocolo que já suporta. O FoxIDs valida a resposta SAML 2.0 do identity provider externo, aplica os claims e as regras de segurança necessários e emite a resposta OpenID Connect esperada pela aplicação.
As pesquisas sobre este problema usam muitas vezes expressões técnicas curtas como SAML para OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, tradução de protocolos, tradução SAML para OIDC, token translation, identity broker ou identity federation broker. A questão de arquitetura é a mesma: como pode uma aplicação confiar num contrato OpenID Connect moderno enquanto um identity provider existente, um parceiro ou uma aplicação SAML antiga continua a usar o protocolo que já suporta?
Não se trata apenas de converter um formato de token. Um bridge útil tem de preservar a identidade pretendida, a authentication assurance e o contrato da aplicação entre standards com formatos de mensagens, modelos de assinatura, sessões e convenções de claims diferentes.
Quando usar protocol bridging
Protocol bridging é útil quando cria uma fronteira controlada entre sistemas que precisam de evoluir a ritmos diferentes.
Situações comuns:
- Uma nova aplicação web, móvel ou single-page suporta OpenID Connect, mas clientes ou parceiros autenticam-se através de identity providers SAML 2.0.
- Aplicações SAML 2.0 existentes precisam de usar um identity provider OpenID Connect moderno.
- Uma organização substitui AD FS ou outra plataforma de federação gradualmente, por exemplo numa migração de AD FS para OpenID Connect, em vez de alterar todas as aplicações ao mesmo tempo.
- Várias aplicações devem confiar numa única camada de identidade, embora os identity providers externos usem protocolos diferentes.
- Uma migração necessita de ambientes paralelos de teste e produção com um caminho de rollback claro.
Se ambos os lados já suportarem o mesmo protocolo adequado e puderem ser ligados com segurança, um bridge pode não acrescentar valor. Use-o quando reduzir o acoplamento ou permitir uma alteração faseada, não apenas porque a tradução de protocolos é possível.
Decida desde o início se o bridge é uma fase de migração ou um componente de arquitetura duradouro. Um bridge temporário precisa de critérios de saída explícitos para remover a relação de trust anterior. Um bridge duradouro exige responsabilidade operacional atribuída, monitorização e gestão do ciclo de vida dos certificados em ambos os lados.
Escolha primeiro o contrato com a aplicação
O protocolo do lado da aplicação deve normalmente acompanhar a sua arquitetura e direção a longo prazo. As novas aplicações usam frequentemente OpenID Connect para login e OAuth 2.0 para acesso a APIs. Aplicações empresariais existentes podem precisar de permanecer em SAML 2.0 até serem substituídas.
No FoxIDs, a aplicação é registada com o protocolo que utiliza. O identity provider externo é configurado como authentication method com o protocolo que disponibiliza. O FoxIDs fica na fronteira de trust:
SAML 2.0 identity provider → FoxIDs → aplicação OpenID Connect
Também é possível o sentido inverso:
OpenID Connect identity provider → FoxIDs → aplicação SAML 2.0
Esta separação permite às equipas normalizar um contrato de aplicação sem exigir que todos os identity providers externos mudem em simultâneo.
Preserve a semântica da identidade, não apenas os nomes dos claims
SAML assertions e OpenID Connect tokens representam a identidade de formas diferentes. Um mapping direto de nomes raramente é suficiente em produção.
Defina explicitamente o contrato da aplicação:
- Que identificador permanece estável para a mesma pessoa entre sessões e identity providers?
- Que claims são necessários para apresentação, autorização e auditoria?
- Como são representados, filtrados e transformados grupos e funções?
- Em que issuer e audience confia a aplicação?
- O que acontece se um provider externo omitir um claim obrigatório?
- É seguro correlacionar identidades de vários providers ou devem permanecer separadas?
O FoxIDs usa JWT claims internamente e pode mapear tipos de claims SAML para nomes mais curtos comuns no OpenID Connect. Este claim mapping também pode transformar valores antes de chegarem à aplicação. Mantenha o mapping deliberadamente limitado: emita o que a aplicação precisa em vez de copiar todos os atributos para todos os tokens.
Identificadores estáveis exigem atenção. Endereços de e-mail e nomes de utilizador podem mudar e normalmente não são boas chaves primárias. Prefira um identificador de origem imutável associado a um issuer claramente definido ou outro identificador com ciclo de vida controlado.
Acompanhe uma identidade através do bridge
Considere um utilizador de um parceiro que inicia sessão através de um SAML 2.0 identity provider enquanto a aplicação usa OpenID Connect:
- A SAML assertion fornece um
NameIDimutável, um endereço de e-mail, pertença a grupos e um authentication context. - O FoxIDs valida a assinatura, o issuer, a audience e a validade e, em seguida, mapeia o identificador de origem estável para
sub, os grupos selecionados para funções da aplicação e o authentication context aceite paraacr. - A aplicação recebe apenas os OpenID Connect claims acordados e valida o FoxIDs como issuer.
A aplicação não precisa de lógica SAML específica para cada parceiro. Quando é adicionado outro identity provider de um parceiro, os seus claims e sinais de assurance são normalizados na fronteira do FoxIDs sem alterar o contrato de token da aplicação.
Trate a authentication assurance conscientemente
Um login SAML bem-sucedido não indica automaticamente a uma aplicação OpenID Connect se foi usada MFA nem que requisitos de assurance foram satisfeitos.
Defina a relação entre o SAML authentication context, o OpenID Connect authentication context e os valores acr esperados. Decida se o FoxIDs pode aceitar a assurance externa, deve pedir ao identity provider externo um authentication step mais forte ou deve rejeitar o login quando falta o context necessário.
O mesmo princípio aplica-se no sentido inverso. Uma aplicação SAML 2.0 pode esperar um authentication context específico quando o utilizador entra através de um OpenID Connect identity provider.
Não deduza authentication forte apenas pela existência de uma sessão no identity provider externo. Avalie o authentication context devolvido de acordo com as regras de assurance configuradas e teste percursos aceites e rejeitados.
Distinga sessões de login de informações de logout
OpenID Connect e SAML 2.0 têm mecanismos diferentes de sessão e logout. O identity provider externo e a aplicação mantêm cada um a sua sessão de login. O FoxIDs não mantém uma terceira sessão de login do utilizador entre ambos; conserva apenas as informações de sessão necessárias para coordenar o logout.
Durante o login, a reauthentication e o step-up, o FoxIDs envia uma authentication request ao identity provider externo. O FoxIDs não reutiliza as informações de logout como sessão de login. O identity provider externo decide, com base na sua própria sessão e nos requisitos da request, se o utilizador pode continuar sem interação ou tem de se autenticar novamente.
O FoxIDs pode usar as informações de logout conservadas para coordenar o logout entre as relações relevantes. O single logout end-to-end pode funcionar quando todos suportam fluxos compatíveis e o browser alcança cada endpoint, mas não deve ser presumido. Teste front-channel redirects, sessões externas expiradas, logout parcial, várias aplicações e logout iniciado pelo provider.
Alinhe a duração da aplicação e dos tokens com o comportamento esperado da sessão do identity provider externo. Terminar a sessão da aplicação não termina necessariamente a sessão externa. Os requisitos de reauthentication e step-up devem ser enviados numa nova request e verificados através do authentication context devolvido.
Planeie uma migração faseada de SAML para OpenID Connect
Uma migração controlada mantém visíveis o bridge, o contrato e o caminho de rollback.
- Inventarie as relações atuais. Registe aplicações, identity providers, metadados, certificados, endpoints, claims, identificadores, requisitos MFA, sessões e responsáveis.
- Defina o contrato alvo. Decida que aplicações usarão OpenID Connect, que relações SAML 2.0 permanecerão e que claims e sinais de assurance atravessarão o bridge.
- Configure ambas as relações de trust. Adicione o provider externo como FoxIDs authentication method e a aplicação como FoxIDs application registration.
- Teste também as falhas. Inclua assinaturas inválidas, issuer ou audience incorretos, claims em falta, assertions expiradas, proteção contra replay, diferenças de relógio, logout e rotação de certificados.
- Trabalhe num ambiente separado. Valide sem alterar o tráfego de produção e promova depois a configuração revista de forma controlada.
- Mova primeiro um grupo limitado. Use uma aplicação piloto, um parceiro ou um grupo de utilizadores e mantenha o percurso anterior até o novo estar comprovado.
- Observe e conclua o cut-over. Monitorize erros de authentication, diferenças nos claims e pedidos de suporte antes de remover a relação de trust antiga.
Os FoxIDs tenants podem conter ambientes separados de desenvolvimento, teste, migração e produção. Isto suporta validação paralela e cut-over faseado, mas não substitui um plano de rollback nem testes da aplicação.
Exija provas de produção antes do cut-over
O bridge passa a fazer parte do caminho de authentication e deve ser operado como fronteira de segurança. Acorde as provas necessárias para cada decisão de produção em vez de tratar um login bem-sucedido como aceitação.
| Área de decisão | Provas necessárias antes da produção |
|---|---|
| Trust endpoints | Responsáveis identificados, metadados revistos e restrições de issuer, audience, recipient e redirect URI |
| Credentials | Chaves controladas separadas, algoritmos aceites, um teste de rotação de certificados e um responsável pela renovação |
| Contrato de identidade | Subject estável, lista de claims permitidos, transformações documentadas e comportamento definido quando faltam claims obrigatórios |
| Authentication assurance | Contexts externos aceites, regras para MFA adicional e percursos de rejeição testados |
| Login e logout | Encaminhamento testado de requests de login, reauthentication e step-up, além de logout, logout parcial e durações relevantes de tokens e sessões externas |
| Falhas e operação | Testes de mensagens inválidas, expiradas e repetidas, além de registos de auditoria, alertas, responsabilidade de suporte e uma decisão de rollback |
Não copie chaves privadas entre sistemas apenas para simplificar a migração. Atribua credentials controladas a cada relação de trust e planeie a rotação antes de os certificados expirarem.
Como o FoxIDs suporta o bridge
O FoxIDs implementa protocol bridging através do modelo normal de applications e authentication methods. Não é necessário instalar um bridge service separado. Uma aplicação OpenID Connect pode usar authentication methods SAML 2.0, OpenID Connect ou WS-Federation, e uma aplicação SAML 2.0 pode usar as mesmas origens externas.
As equipas mantêm um contrato FoxIDs identity provider, enquanto identity providers, parceiros e sistemas antigos se ligam através dos standards que suportam. O FoxIDs também disponibiliza claim mapping, authentication flows configuráveis, MFA e ambientes separados de teste e produção.
Consulte a documentação do protocol bridge para o modelo exato, authentication methods e application registrations. Se o trabalho incluir onboarding de aplicações, desenho de claims, testes ou migração faseada, FoxIDs Identity Integration descreve a ajuda de implementação da equipa que desenvolve a plataforma.
Conclusão
Um bridge de SAML para OpenID Connect é mais útil quando permite que aplicações e identity providers evoluam independentemente sem enfraquecer o contrato de identidade.
Trate o bridge como uma fronteira de trust deliberada, não como um tradutor de tokens invisível. Quando o contrato da aplicação, as regras de assurance, o comportamento de login e logout, as provas de produção, as responsabilidades e o rollback são explícitos, o FoxIDs fornece o modelo de implementação baseado em standards para introduzir a alteração em fases controladas.