O que são federações?

O processo de federação em sistemas de identidade refere-se à capacidade de estabelecer uma relação de confiança entre diferentes domínios ou organizações, permitindo que usuários façam login em sistemas de terceiros utilizando suas credenciais já existentes, sem a necessidade de criar novas contas. Essa comunicação entre provedores de identidade (IdPs) e provedores de serviço (SPs) permite que a autenticação seja centralizada e reutilizável entre sistemas distintos.

Federações permitem que nossos clientes utilizem as contas que já possuem para ter acesso aos recursos de suas respectivas empresas para fazer login na plataforma, permitindo que o cliente gerencie como preferir os controles de acesso, protocolos de segurança e além de facilitar o controle de onboarding e offboarding. Isso não só simplifica a experiência do usuário, como também reduz o esforço de administração e aumenta a segurança, pois os dados de autenticação permanecem sob controle do IdP original.

Para que serve e para quais casos de uso é indicada?

A federação resolve problemas comuns como a duplicidade de contas, gerenciamento descentralizado de credenciais e risco de vazamento de senhas. Em vez de o usuário manter dezenas de logins e senhas, ele autentica-se uma única vez em seu IdP confiável, e a federação garante que os outros sistemas aceitem essa autenticação por meio de protocolos como SAML e OpenID Connect.

Por fim, a federação é uma peça essencial para viabilizar cenários de Single Sign-On (SSO) entre sistemas independentes, viabilizar o uso de identidades sociais (como Google ou Facebook) em aplicações web, e integrar sistemas legados com plataformas modernas de autenticação. Ela é especialmente relevante em arquiteturas modernas baseadas em microsserviços ou múltiplos front-ends que dependem de uma identidade comum para funcionar de maneira integrada.

Protocolos suportados pela Blip

Atualmente a Blip suporta 2 protocolos amplamente conhecidos na indústria, sendo eles OpenId Connect e SAML 2.0.

OpenId Connect

OpenID Connect (OIDC) é um protocolo de autenticação moderno, construído sobre o protocolo OAuth 2.0. Ele foi criado para permitir que aplicações verifiquem a identidade de um usuário com base na autenticação realizada por um provedor confiável. O OIDC é amplamente utilizado na web moderna por ser leve, seguro, interoperável e fácil de integrar.

Uma das vantagens do OIDC é sua simplicidade para os desenvolvedores. Com poucos endpoints padronizados, suporte a JSON e uso extensivo de HTTPS, ele se adapta bem a aplicações web, mobile e APIs. Além disso, por ser baseado em padrões abertos, é compatível com diversos provedores de identidade, como Google, Entra Id (antigo Azure AD), Okta e muitos outros.

SAML 2.0 (Em homologação)

SAML 2.0 (Security Assertion Markup Language) é um protocolo de autenticação popular em ambientes corporativos e sistemas legados. No entanto, por ser baseado em XML e envolver configuração mais complexa (como troca de metadados, certificados e endpoints), o SAML 2.0 é considerado mais "pesado" comparado ao OpenID Connect. Ainda assim, ele continua sendo extremamente relevante em contextos onde já existe uma infraestrutura de autenticação SAML ou onde a compatibilidade com sistemas antigos é um requisito.

Como funciona

Independentemente do protocolo utilizado, o funcionamento geral é praticamente o mesmo e está descrito no diagrama a seguir. O diagrama foi simplificado para facilitar o entendimento, removendo componentes que não estão diretamente ligados ao processo em questão.

Usuário acessa um dos produtos Blip (BlipPortal ou BlipDesk) que verifica se existe uma sessão ativa. Se sim, usuário recebe acesso ao sistema, se não, segue para passo 2

Usuário é direcionado para o Provedor de Identidade (IdP) da Blip. Caso exista uma sessão ativa deste usuário, o Blip IdP retorna para a aplicação cliente os tokens de acesso (SSO). Se não houver sessão ativa, segue para passo 3

O Blip IdP identifica que existe uma federação cadastrada para o contrato e direciona o usuário para o Provedor de federação do cliente dono do contrato

O Provedor de federação direciona o usuário para página de Sign In própria na qual se dá o processo de autenticação

O usuário informa seu nome de usuário, senha, executa o MFA, enfim, segue o processo de autenticação definido pelo cliente

Com o usuário autenticado, o Provedor de federação retorna para o Blip IdP os tokens de acesso contendo dados do usuário, como o e-mail por exemplo

O Blip IdP retorna para a aplicação cliente os tokens de acesso que permitem a abertura de uma sessão para o usuário

Limitações

O processo de federações em Blip atualmente tem as seguintes limitações:

O campo e-mail é obrigatório e precisa ser informado pelo Provedor de Federações do cliente, sendo utilizado na Blip como identificador do usuário;

Não fazemos a sincronização automática de permissões de um usuário entre o Provedor de Federações do cliente e o Provedor de Identidades da Blip.

Não fazemos a remoção/desativação automática de contas quando removidas/desativadas no Provedor de Federações do cliente, mas estamos em processo de uma API que permite automatizar a remoção de todos os acessos da plataforma no processo de offboarding, por exemplo.

Para mais informações, acesse a discussão sobre o assunto em nossa comunidade ou os vídeos no nosso canal. 😃