Padrão de identidade federada

Delegar a autenticação de usuário a um IdP (provedor de identidade externo) para simplificar o desenvolvimento, minimizar tarefas administrativas e melhorar a experiência de usuário do aplicativo.

Contexto e problema

Normalmente, os usuários precisam trabalhar com vários aplicativos que as organizações parceiras fornecem e hospedam. Talvez seja necessário usar credenciais de entrada específicas e diferentes para cada aplicativo. Esse requisito pode:

Causar uma experiência de usuário desarticulada. Os funcionários geralmente esquecem várias credenciais de entrada.
Expor vulnerabilidades de segurança. Quando um funcionário deixa a empresa, a organização deve desativar imediatamente a conta. As grandes organizações geralmente perdem essa etapa crítica.
Complicar o gerenciamento de usuários. Os administradores gerenciam credenciais do usuário, emitem lembretes de senha e executam outras tarefas administrativas.

Normalmente, os usuários preferem usar as mesmas credenciais de entrada para todos os aplicativos.

Solução

Implementar um mecanismo de autenticação de identidade federada. Separar a autenticação do usuário do código do aplicativo e delegar a autenticação a um IdP confiável. Esse processo simplifica o desenvolvimento, minimiza a sobrecarga administrativa e fornece autenticação do usuário por meio de uma variedade de IdPs. A identidade federada também separa a autenticação da autorização.

Os IdPs confiáveis incluem diretórios corporativos, serviços de federação locais, STSs (serviços de token de segurança) e IdPs sociais como Microsoft, Google, Yahoo!ou Facebook.

O diagrama a seguir mostra o padrão de Identidade Federada para um aplicativo cliente que acessa um serviço que requer autenticação. O IdP funciona com um STS para fornecer autenticação. O IdP emite tokens de segurança que fornecem informações sobre o usuário autenticado. Essas informações, chamadas de declarações, incluem a identidade do usuário e também podem incluir outras declarações, como associações de função e direitos de acesso mais granulares.

Esse modelo também é chamado de controle de acesso baseado em declarações. Aplicativos e serviços autorizam o acesso a recursos e funcionalidades com base nas declarações. O serviço que exige autenticação deve confiar no IdP. O aplicativo cliente entra em contato com o IdP para autenticação. Se a autenticação for bem-sucedida, o IdP retornará um token que contém declarações de identificação de usuário para o STS. O IdP e o STS podem fazer parte do mesmo serviço. O STS pode transformar e aumentar as declarações com base em regras predefinidas antes de retornar o token ao cliente. Em seguida, o aplicativo cliente passa esse token para o serviço como prova de sua identidade.

A autenticação federada fornece um método baseado em padrões para estabelecer a confiança em identidades entre domínios e dá suporte ao SSO (logon único). Muitos aplicativos, especialmente aplicativos hospedados na nuvem, usam autenticação federada porque dão suporte ao SSO sem uma conexão de rede direta com um IdP. Esse design aumenta a segurança, pois o usuário não precisa criar e inserir credenciais de entrada diferentes para vários aplicativos. Ele também limita a exposição das credenciais somente ao IdP original. Os aplicativos veem apenas as informações de identidade autenticadas no token.

Aplicativos e serviços que usam autenticação federada não precisam fornecer recursos de gerenciamento de identidade. Em vez disso, o IdP é responsável pelo gerenciamento de identidades e credenciais. Quando o diretório corporativo confia no IdP, ele não precisa gerenciar a identidade do usuário. Essa abordagem elimina a sobrecarga administrativa do gerenciamento de identidade de usuário baseado em diretório.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

A autenticação pode ser um ponto único de falha. Para manter a confiabilidade e a disponibilidade do aplicativo em várias regiões, considere implantar seu mecanismo de gerenciamento de identidade nas mesmas regiões que seu aplicativo.
Para configurar o RBAC (controle de acesso baseado em função), use ferramentas de autenticação. O RBAC permite controle granular sobre o acesso a funcionalidades e recursos.
Ao contrário de um diretório corporativo, a autenticação baseada em declarações que usa IdPs sociais geralmente fornece apenas o endereço de email do usuário autenticado e, às vezes, seu nome. Alguns IdPs sociais, como Microsoft, fornecem apenas um identificador exclusivo. O aplicativo geralmente mantém algumas informações sobre usuários registrados para que possa corresponder essas informações ao identificador nas declarações. Essa tarefa normalmente é concluída durante o registro, quando o usuário acessa o aplicativo pela primeira vez. Em seguida, as informações são injetadas no token como novas declarações após cada autenticação.
Se vários IdPs estiverem configurados para o STS, o STS deverá determinar qual IdP deve autenticar o usuário. Esse processo é chamado de descoberta do realm de origem. O STS pode determinar o IdP automaticamente com base em informações fornecidas pelo usuário, como um endereço de email ou um nome de usuário, o subdomínio do aplicativo, o intervalo de endereços IP do usuário ou um cookie armazenado no navegador do usuário. Por exemplo, se o usuário inserir um endereço de email Microsoft, comouser@live.com, o STS redirecionará o usuário para a página de entrada conta Microsoft. Nas visitas subsequentes, o STS pode usar um cookie que indica que o usuário entrou anteriormente usando um conta Microsoft. Se o STS não conseguir determinar automaticamente o realm de origem, ele exibirá uma página de descoberta do realm de origem que lista os IdPs confiáveis. Em seguida, o usuário seleciona um IdP.

Quando usar esse padrão

Use esse padrão quando precisar:

SSO na empresa. Nesse cenário, você precisa autenticar funcionários para aplicativos corporativos hospedados na nuvem fora do limite de segurança corporativa, sem uma entrada sempre que eles visitam um aplicativo. A experiência do usuário corresponde a aplicativos locais. Os usuários se autenticam quando entram na rede corporativa e, em seguida, podem acessar aplicativos relevantes sem outra entrada.
Identidade federada com vários parceiros. Nesse cenário, você precisa autenticar funcionários corporativos e parceiros de negócios que não têm contas no diretório corporativo. Essa prática é comum em aplicativos de negócios para empresas, aplicativos que se integram a serviços parceiros e em empresas que usam sistemas de TI diferentes ou recursos mesclados ou compartilhados.
Identidade federada em aplicativos SaaS (software como serviço). Nesse cenário, fornecedores de software independentes fornecem um serviço pronto para uso para vários clientes ou locatários. Os locatários são autenticados usando um IdP adequado. Por exemplo, os usuários corporativos usam suas credenciais corporativas, enquanto os consumidores e clientes do locatário usam suas credenciais de identidade social.
Identidade federada para acesso à carga de trabalho. Nesse cenário, aplicativos de locatário, fluxos de trabalho de automação ou integração contínua e sistemas de entrega contínua precisam chamar suas APIs sem que um usuário esteja presente. Os locatários se autenticam por meio de seus próprios IdPs usando identidades de carga de trabalho. O aplicativo autoriza o acesso por meio da validação de declarações com escopo de locatário.

Esse padrão pode não ser adequado quando você tem:

Um IdP. Nesse cenário, os usuários do aplicativo se autenticam usando um IdP e não precisam se autenticar usando outro IdP. Essa situação é típica em aplicativos que usam um diretório corporativo para autenticação, por meio de uma VPN ou de uma conexão de rede virtual entre o aplicativo e um diretório local.
Mecanismos de autenticação incompatíveis. Nesse cenário, o aplicativo usa um mecanismo de autenticação diferente, por exemplo, usando repositórios de usuários personalizados ou não pode lidar com padrões de negociação de tecnologia baseados em declarações. Pode ser complexo e caro readequar a autenticação baseada em declarações e o controle de acesso em um aplicativo existente.

Design de carga de trabalho

Avalie como usar o padrão de Identidade Federada no design de uma carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece diretrizes sobre como esse padrão dá suporte às metas de cada pilar.

Pilar	Como esse padrão apoia os objetivos do pilar
As decisões de design de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha.	Esse padrão descarrega o gerenciamento e a autenticação do usuário para o IdP, que normalmente tem um objetivo de alto nível de serviço. Durante a recuperação de desastres da carga de trabalho (DR), o plano de recuperação da carga de trabalho não precisa abordar componentes de autenticação. - RE:02 Fluxos críticos - RE:09 DR
As decisões de design de segurança ajudam a garantir a confidencialidade, integridade e disponibilidade dos dados e sistemas da sua carga de trabalho.	Esse padrão fornece recursos avançados de detecção e prevenção de ameaças baseadas em identidade sem a necessidade de implementá-los em sua carga de trabalho. Os IdPs externos também usam protocolos de autenticação interoperáveis modernos. - SE:02 Ciclo de vida de desenvolvimento seguro - SE:10 Monitoramento e detecção de ameaças
A Eficiência de Desempenho ajuda sua carga de trabalho a atender com eficiência às demandas por meio de otimizações no dimensionamento, nos dados e no código.	Esse padrão ajuda você a dedicar recursos de aplicativo a outras prioridades. - PE:03 Seleção de serviços

Se esse padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Example

Uma organização hospeda um aplicativo baseado em nuvem multicomponente que inclui um front-end da Web e uma API de back-end. O aplicativo delega a autenticação a um IdP centralizado usando Microsoft Entra ID, em vez de implementar a lógica de autenticação em cada componente.

Carrege um arquivo Visio desta arquitetura.

O fluxo de trabalho a seguir corresponde ao diagrama anterior.

O usuário acessa o aplicativo Web.
O aplicativo Web redireciona o usuário para Microsoft Entra ID para autenticação.
Após a autenticação bem-sucedida, Microsoft Entra ID redireciona o usuário de volta para o aplicativo Web com um código de autorização.
O aplicativo Web troca o código de autorização por tokens e envia uma solicitação POST para o ponto de extremidade de token.
Microsoft Entra ID emite um token que contém declarações sobre o usuário.
O aplicativo Web usa esse token para chamar uma API de back-end.
O aplicativo Web e a API de back-end validam o token e impõem suas regras de autorização com base nas declarações.
A API retorna a resposta ao aplicativo Web.

Principais características:

Autenticação centralizada. Os componentes dependem de Microsoft Entra ID para autenticar usuários, o que remove a necessidade de lógica de autenticação personalizada no aplicativo.
Autorização descentralizada. Os componentes do aplicativo impõem de forma independente decisões de autorização com base em declarações.
Controle de acesso baseado em declarações. O acesso à funcionalidade é determinado usando declarações, como funções ou escopos.
Protocolos baseados em padrões. Os componentes usam o OAuth 2.0 e o OpenID Connect para autenticação.
Aplicação opcional de MFA. Se o perfil de risco exigir uma garantia de entrada mais forte, você poderá impor a autenticação multifator usando políticas de Acesso Condicional em Microsoft Entra ID.
Extensibilidade opcional por meio da federação. O Microsoft Entra ID pode ser configurado para confiar em um locatário parceiro do Microsoft Entra por meio de configurações de acesso entre locatários. Os usuários parceiros podem acessar o aplicativo sem alterações nos componentes do aplicativo.

Próximas Etapas

Comentários

Esta página foi útil?

Last updated on 2026-07-02