Padrão de Identidade Federada

Delegue a autenticação do utilizador a um fornecedor externo de identidade (IdP) para simplificar o desenvolvimento, minimizar tarefas administrativas e melhorar a experiência de utilizador da aplicação.

Contexto e problema

Os utilizadores normalmente precisam de trabalhar com múltiplas aplicações que as organizações parceiras fornecem e alojam. Podem precisar de usar credenciais de login específicas e diferentes para cada candidatura. Este requisito pode:

• Criar uma UX desarticulada. Os colaboradores muitas vezes esquecem-se de múltiplas credenciais de login.

• Expor vulnerabilidades de segurança. Quando um colaborador sai da empresa, a organização deve desativar imediatamente a conta. As grandes organizações muitas vezes perdem este passo crítico.

• Complica a gestão dos utilizadores. Os administradores gerem as credenciais dos utilizadores, emitem lembretes de palavra-passe e realizam outras tarefas administrativas.

Os utilizadores normalmente preferem usar as mesmas credenciais de login para todas as aplicações.

Solução

Implemente um mecanismo federado de autenticação de identidade. Separe a autenticação do utilizador do código da aplicação e delegue a autenticação a um IdP de confiança. Este processo simplifica o desenvolvimento, minimiza a sobrecarga administrativa e fornece autenticação do utilizador através 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 local, serviços de token de segurança (STSs) e IdPs sociais como Microsoft, Google, Yahoo! ou Facebook.

O diagrama seguinte mostra o padrão Federated Identity para uma aplicação cliente que acede a 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 utilizador autenticado. Esta informação, chamada claims, inclui a identidade do utilizador e pode também incluir outras claims, como pertenças a papéis e direitos de acesso mais detalhados.

Este modelo também é chamado de controlo de acesso baseado em sinistros. As aplicações e os serviços autorizam o acesso a características e funcionalidades com base nas declarações. O serviço que precisa de autenticação tem de confiar no IdP. A aplicação cliente contacta o IdP para autenticação. Se a autenticação for bem-sucedida, o IdP devolve um token que contém reivindicações identificadoras do utilizador ao STS. O IdP e o STS podem fazer parte do mesmo serviço. O STS pode transformar e aumentar as reivindicações com base em regras pré-definidas antes de devolver o token ao cliente. A aplicação cliente passa então este token ao serviço como prova da sua identidade.

A autenticação federada fornece um método baseado em normas para estabelecer confiança nas identidades entre domínios, e suporta o login único (SSO). Muitas aplicações, especialmente as alojadas na cloud, utilizam autenticação federada porque suporta SSO sem uma ligação direta à rede a um IdP. Este design aumenta a segurança, porque o utilizador não precisa de criar e introduzir diferentes credenciais de login para múltiplas aplicações. Também limita a exposição das credenciais apenas ao IdP original. As aplicações veem apenas a informação de identidade autenticada no token.

Aplicações e serviços que utilizam autenticação federada não precisam de fornecer funcionalidades de gestão de identidade. Em vez disso, o IDP é responsável pela gestão de identidade e credenciais. Quando o diretório corporativo confia no IdP, não precisa de gerir a identidade do utilizador. Esta abordagem elimina a sobrecarga administrativa da gestão de identidade de utilizador baseada em diretórios.

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 fiabilidade e disponibilidade da aplicação em várias regiões, considere implementar o seu mecanismo de gestão de identidade nas mesmas regiões da aplicação.

• Para configurar o controlo de acesso baseado em funções (RBAC), utilize ferramentas de autenticação. O RBAC suporta controlo granular sobre o acesso a funcionalidades e recursos.

• Ao contrário de um diretório corporativo, a autenticação baseada em reivindicações que utiliza IDPs sociais geralmente fornece apenas o endereço de email do utilizador autenticado e, por vezes, o seu nome. Alguns IdP sociais, como a Microsoft, fornecem apenas um identificador único. A aplicação normalmente mantém alguma informação sobre utilizadores registados para poder associar essa informação ao identificador das reclamações. Esta tarefa é normalmente realizada durante o registo, quando o utilizador acede pela primeira vez à aplicação. A informação é então injetada no token como novas reivindicações após cada autenticação.

• Se vários IdPs estiverem configurados para o STS, o STS deve determinar qual dos IdP deve autenticar o utilizador. Este processo é chamado home realm discovery. O STS pode determinar automaticamente o IdP com base em informações fornecidas pelo utilizador, como um endereço de email ou um nome de utilizador, o subdomínio da aplicação, o intervalo de endereços IP do utilizador ou um cookie armazenado no navegador do utilizador. Por exemplo, se o utilizador introduzir um endereço de email da Microsoft, como user@live.com, o STS redireciona o utilizador para a página de login da conta Microsoft. Em visitas subsequentes, o STS pode usar um cookie que indica que o utilizador iniciou sessão anteriormente usando uma conta Microsoft. Se o STS não conseguir determinar automaticamente o reino de origem, apresenta uma página de descoberta do reino de origem que lista os IdPs de confiança. O utilizador seleciona então um IdP.

Quando utilizar este padrão

Use este molde quando precisar:

• SSO na empresa. Neste cenário, é necessário autenticar os colaboradores para aplicações corporativas que estão alojadas na cloud fora dos limites de segurança da empresa, sem necessidade de iniciar sessão sempre que visitam uma aplicação. A experiência do utilizador corresponde às aplicações locais. Os utilizadores autenticam-se quando iniciam sessão na rede corporativa e depois podem aceder às aplicações relevantes sem outro login.

• Identidade federada com múltiplos parceiros. Neste cenário, é necessário autenticar funcionários corporativos e parceiros comerciais que não tenham contas no diretório corporativo. Esta prática é comum em aplicações business-to-business, aplicações que se integram com serviços parceiros e em empresas que utilizam diferentes sistemas de TI, ou recursos fundidos ou partilhados.

• Identidade federada em aplicações de software como serviço (SaaS). Neste cenário, fornecedores independentes de software fornecem um serviço pronto a usar para múltiplos clientes ou inquilinos. Os inquilinos autenticam-se usando um IDP adequado. Por exemplo, os utilizadores empresariais utilizam as suas credenciais corporativas, enquanto os consumidores e clientes do locatário utilizam credenciais de identidade social.

• Identidade federada para acesso à carga de trabalho. Neste cenário, aplicações do inquilino, fluxos de trabalho de automação ou sistemas de integração contínua e entrega contínua têm de chamar as suas APIs sem que esteja presente um utilizador. Os locatários autenticam-se através dos respetivos IdPs, utilizando identidades de carga de trabalho. A aplicação autoriza o acesso através da validação de reivindicações com âmbito de inquilino.

Este molde pode não ser adequado quando tem:

• Um IdP. Neste cenário, os utilizadores da aplicação autenticam-se usando um IdP, e não precisam de se autenticar usando outro IdP. Esta situação é típica em aplicações que utilizam um diretório corporativo para autenticação, seja através de uma VPN ou de uma ligação de rede virtual entre a aplicação e um diretório local.

• Mecanismos de autenticação incompatíveis. Neste cenário, a aplicação utiliza um mecanismo de autenticação diferente, por exemplo, através da utilização de repositórios de utilizadores personalizados, ou não consegue lidar com normas de negociação de tecnologia baseada em declarações. Pode ser complexo e dispendioso adaptar autenticação baseada em reclamações e controlo de acessos numa aplicação existente.

Design da carga de trabalho

Avalie como utilizar o padrão Federated Identity no design de uma carga de trabalho para abordar os objetivos e princípios abordados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece orientação sobre como esse padrão suporta as metas de cada pilar.

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

Example

Uma organização aloja uma aplicação multicomponente baseada na cloud que inclui uma interface web e uma API de back-end. A aplicação delega a autenticação a um IdP centralizado usando o Microsoft Entra ID, em vez de implementar lógica de autenticação em cada componente.

Descarregue um ficheiro Visio desta arquitetura.

O fluxo de trabalho a seguir corresponde ao diagrama anterior.

1. O utilizador acede à aplicação web.

2. A aplicação web redireciona o utilizador para o Microsoft Entra ID para autenticação.

3. Após a autenticação bem-sucedida, o Microsoft Entra ID redireciona o utilizador de volta para a aplicação web com um código de autorização.

4. A aplicação web troca o código de autorização dos tokens e envia um pedido POST para o endpoint do token.

5. O Microsoft Entra ID emite um token que contém afirmações sobre o utilizador.

6. A aplicação web utiliza este token para chamar uma API de back-end.

7. A aplicação web e a API de back-end validam o token e aplicam as suas regras de autorização com base nas reivindicações.

8. A API devolve a resposta à aplicação web.

Principais características:

• Autenticação centralizada. Os componentes dependem do Microsoft Entra ID para autenticar os utilizadores, o que elimina a necessidade de lógica de autenticação personalizada na aplicação.

• Autorização descentralizada. Os componentes da aplicação aplicam independentemente as decisões de autorização baseadas em reivindicações.

• Controlo de acesso baseado em declarações. O acesso à funcionalidade é determinado pela utilização de reivindicações, como funções ou âmbitos.

• Protocolos baseados em padrões. Os componentes utilizam OAuth 2.0 e OpenID Connect para autenticação.

• Aplicação opcional da MFA. Se o seu perfil de risco exigir uma garantia de início de sessão mais forte, pode impor a autenticação multifatorial utilizando políticas de Acesso Condicional no Microsoft Entra ID.

• Extensibilidade opcional por federação. O Microsoft Entra ID pode ser configurado para confiar num tenant parceiro do Microsoft Entra através de definições de acesso entre tenants. Os utilizadores parceiros podem então aceder à aplicação sem alterações nos componentes da aplicação.

Passos seguintes

• O que é o Microsoft Entra?
• OpenID Connect na plataforma de identidade da Microsoft
• Converta uma aplicação de tenant único numa aplicação multitenant ao utilizar o Microsoft Entra ID
• O que é Acesso Condicional?

Recursos relacionados

• Considerações arquitetónicas para identidade numa solução multicliente
• Padrão Gatekeeper
• Padrão de Chave Valet
• Padrão de Descarregamento de Gateway