Bridge SAML 2.0 / OpenID Connect

Por predefinição, o FoxIDs é um bridge entre SAML 2.0 e OpenID Connect / OAuth 2.0 sem qualquer configuração adicional.

Federated Identity Management (FIM) foca-se em ligar identidades entre domínios, enquanto Single Sign-On (SSO) simplifica o acesso entre aplicações. O FoxIDs suporta tanto FIM como SSO, e o bridge permite ambos entre SAML 2.0 e OpenID Connect.

OpenID Connect (OIDC) e SAML 2.0 são ambos protocolos amplamente usados para federação de identidade, single sign-on (SSO) e autenticação de utilizadores. No entanto, são fundamentalmente diferentes em estrutura e desenho. Por vezes, pode ser necessário fazer bridge ou integrar estes protocolos, como permitir que uma aplicação que suporta OpenID Connect funcione com um identity provider (IdP) que apenas suporta SAML 2.0.

Principais diferenças entre os dois tipos de protocolo:

• OIDC: construído sobre OAuth 2.0, é um protocolo moderno desenhado para aplicações web e mobile com APIs RESTful. Usa JSON Web Tokens (JWT) para tokens de identidade e access tokens.
• SAML 2.0: baseado em XML e focado em cenários SSO baseados em browser, frequentemente usado em ambientes enterprise. Usa assertions / tokens baseados em XML.

Para ligar um sistema OpenID Connect a um sistema SAML 2.0, precisa de uma camada de tradução ou bridge de protocolo. Isto pode ser conseguido usando um intermediário que atua tanto como OpenID Connect Provider (OP) como SAML Service Provider (SP), ou vice-versa.

Se configurar um método de autenticação SAML 2.0 para um Identity Provider (IdP) externo e ligar a sua app como aplicação OpenID Connect, onde seleciona o método de autenticação SAML 2.0, um pedido de login da sua app é encaminhado como pedidos externos de login SAML 2.0. A resposta de login SAML 2.0 é depois mapeada para uma resposta OpenID Connect para a sua app. Os claims SAML 2.0 são automaticamente convertidos em claims JWT (OAuth 2.0).

O contrário também é possível, começando o pedido de login a partir de uma app registo de aplicação SAML 2.0 e encaminhando para um OpenID Provider (OP) externo configurado como método de autenticação OpenID Connect. Em seguida, a resposta é convertida numa resposta SAML 2.0.

O FoxIDs suporta bridge de login, logout e single logout entre SAML 2.0 e OpenID Connect.

Um ambiente - um Identity Provider

Toda a funcionalidade de bridge pode ser combinada no mesmo ambiente. Isto permite que uma app OpenID Connect suporte login via um método de autenticação SAML 2.0 e OpenID Connect ao mesmo tempo. A app OpenID Connect pode selecionar o método de autenticação gramaticalmente ou deixar o utilizador escolher numa página de home realm discovery (HRD).

Recomenda-se ter uma infraestrutura de aplicações com clientes OpenID Connect ativados e APIs OAuth 2.0 ativadas. Onde todas as aplicações (clientes e APIs) confiam no mesmo Identity Provider (IdP) - um IdP é igual a um ambiente FoxIDs. Ao usar a funcionalidade de bridge no FoxIDs, tokens SAML 2.0 são mapeados para ID tokens e access tokens que podem ser usados para autenticar apps OpenID Connect e chamar APIs existentes.

Token exchange

Se for concedido acesso a um utilizador a uma app SAML 2.0 após login bem-sucedido com um Identity Provider (IdP) SAML 2.0 externo, o utilizador recebe acesso à app SAML 2.0 no contexto do próprio utilizador. Com zero trust (nunca confiar, verificar sempre), exigiria chamar as suas APIs no contexto do utilizador. Isto é possível usando token exchange, onde o token SAML 2.0 pode ser trocado por um access token com a identidade do utilizador final. Em seguida, a sua API com OAuth 2.0 ativado pode ser chamada no contexto do utilizador.

Mapeamentos de claims

O FoxIDs usa claims JWT internamente e mapeia claims SAML 2.0 para claims JWT. Por predefinição, um conjunto de claims standard JWT para SAML 2.0 é mapeado, como sub para http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, email para http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, etc. É possível adicionar mapeamentos adicionais de claims JWT para SAML 2.0.
Se não existir mapeamento de claim para um determinado claim, o nome longo do claim SAML 2.0 é mantido a partir dos claims recebidos num token SAML 2.0 em vez de um nome de claim JWT equivalente mais curto. O mesmo se aplica na direção oposta.