Delegue a autenticação para um fornecedor de identidade externo. Esta ação pode simplificar o desenvolvimento, minimizar a necessidade da administração de utilizadores e melhorar a experiência dos utilizadores da aplicação.
Contexto e problema
Normalmente, os utilizadores têm de trabalhar com várias aplicações fornecidas e alojadas por diferentes organizações com as quais possuem uma relação comercial. Estes utilizadores poderão ter de utilizar credenciais específicas (e diferentes) para cada uma delas. Tal pode:
Criar uma experiência de utilizador desajustada. Os utilizadores esquecem-se frequentemente das credenciais de início de sessão quando têm de utilizar muitas diferentes.
Expor vulnerabilidades de segurança. Quando um utilizador sai da empresa, a conta deve ser imediatamente desaprovisionada. Nas organizações grandes, este procedimento é facilmente esquecido.
Dificultar a gestão dos utilizadores. Os administradores têm de gerir as credenciais de todos os utilizadores e realizar tarefas adicionais como fornecer lembretes de palavra-passe.
Os utilizadores normalmente preferem utilizar as mesmas credenciais para todas estas aplicações.
Solução
Implemente um mecanismo de autenticação para utilizar a identidade federada. Separe a autenticação do utilizador do código da aplicação e delegue a autenticação a um fornecedor de identidade fidedigno. Desta forma, pode simplificar o desenvolvimento e permitir que os utilizadores se autentiquem com uma vasta gama de fornecedores de identidade (IdP), enquanto minimiza a sobrecarga administrativa. Também lhe permite desassociar claramente a autenticação da autorização.
Os fornecedores de identidade fidedignos incluem diretórios empresariais, serviços de federação no local, outros serviços de tokens de segurança (STS) fornecidos por parceiros comerciais ou fornecedores de identidade social que podem autenticar os utilizadores que têm, por exemplo, uma conta Microsoft, Google, Yahoo! ou Facebook.
A figura mostra o padrão de Identidade Federada quando uma aplicação cliente precisa de aceder a um serviço que exige autenticação. A autenticação é realizada por um IdP que funciona em conjunto com um STS. O IdP emite tokens de segurança que fornecem informações sobre o utilizador autenticado. Essas informações, chamadas de declarações, incluem a identidade do usuário e também podem incluir outras informações, como associação à função e direitos de acesso mais granulares.
Este modelo é frequentemente denominado controlo de acesso baseado em afirmações. As aplicações e os serviços autorizam o acesso às funções e funcionalidades com base nas afirmações incluídas no token. O serviço que precisa da autenticação têm de confiar no IdP. A aplicação cliente contacta o IdP que realiza a autenticação. Se a autenticação for bem-sucedida, o IdP devolverá um token que contém as afirmações que identificam o utilizador para o STS (tenha em atenção que o IdP e o STS podem ser o mesmo serviço). O STS pode transformar e aumentar as afirmações no token com base em regras predefinidas, antes de o devolver ao cliente. A aplicação cliente pode, em seguida, transmitir este token para o serviço como prova da sua identidade.
Pode haver serviços de token de segurança adicionais na cadeia de confiança. Por exemplo, no cenário descrito mais à frente, um STS no local confia noutro STS responsável por aceder a um fornecedor de identidade para autenticar o utilizador. Esta abordagem é comum em cenários empresariais onde existe um STS no local e um diretório.
A autenticação federada fornece uma solução baseada em normas para o problema de confiança das identidades em diversos domínios e pode suportar o início de sessão único. Esse tipo de autenticação está se tornando mais comum em todos os tipos de aplicativos, especialmente aplicativos hospedados na nuvem, porque suporta logon único sem exigir uma conexão de rede direta com provedores de identidade. O utilizador não tem de introduzir as credenciais para todas as aplicações. Isso aumenta a segurança porque impede a criação de credenciais necessárias para acessar muitos aplicativos diferentes e também oculta as credenciais do usuário de todos, exceto do provedor de identidade original. As aplicações veem apenas as informações da identidade autenticada incluídas no token.
A identidade federada tem também a grande vantagem de a responsabilidade pela gestão das identidades e das credenciais recair sobre o fornecedor de identidade. A aplicação ou o serviço não tem de fornecer funcionalidades de gestão de identidades. Além disso, em cenários empresariais, o diretório empresarial não precisará de conhecer o utilizador se confiar no fornecedor de identidade. Esta ação remove a sobrecarga administrativa da gestão da identidade do utilizador no diretório.
Problemas e considerações
Ao conceber aplicações que implementam a autenticação federada, considere o seguinte:
A autenticação pode ser um ponto único de falha. Se implementar a aplicação em vários datacenters, considere implementar o mecanismo de gestão de identidades nos mesmos datacenters para manter a disponibilidade e a fiabilidade da aplicação.
As ferramentas de autenticação possibilitam a configuração do controlo de acesso com base nas afirmações da função incluídas no token de autenticação. Tal é frequentemente referido como controlo de acesso baseado em funções (RBAC) e pode permitir um nível de controlo mais granular no que concerne ao acesso aos recursos e às funcionalidades.
Ao contrário de um diretório empresarial, a autenticação baseada em afirmações através de fornecedores de identidade social não fornece, por norma, informações sobre o utilizador autenticado além do endereço de e-mail e, talvez, um nome. Alguns fornecedores de identidade social, como uma conta Microsoft, fornecem apenas um identificador exclusivo. Por norma, a aplicação tem de manter algumas informações sobre os utilizadores registados e deve ter a capacidade para corresponder as mesmas ao identificador incluído nas afirmações no token. Normalmente, tal é feito através do registo quando o utilizador acede pela primeira vez à aplicação e as informações são, desta forma, injetadas no token como afirmações adicionais após cada autenticação.
Se houver mais de um provedor de identidade configurado para o STS, o STS deverá determinar para qual provedor de identidade o usuário deve ser redirecionado para autenticação. Este processo é denominado deteção de realm inicial. O STS pode ser capaz de fazer isso automaticamente com base em um endereço de e-mail ou nome de usuário que o usuário fornece, um subdomínio do aplicativo que o usuário está acessando, o escopo do endereço IP do usuário ou no conteúdo de um cookie armazenado no navegador do usuário. Por exemplo, se o utilizador tiver introduzido um endereço de e-mail no domínio Microsoft, tal como user@live.com, o STS irá redirecionar o utilizador para a página de início de sessão da conta Microsoft. Nas visitas posteriores, o STS utilizará um cookie para indicar que o último início de sessão foi realizado com uma conta Microsoft. Se a deteção automática não conseguir determinar o realm inicial, o STS apresentará uma página de deteção do realm inicial que lista os fornecedores de identidade fidedignos e o utilizador terá de selecionar aquele que pretende utilizar.
Quando utilizar este padrão
Este padrão é prático nos seguintes cenários:
Início de sessão único na empresa. Neste cenário, tem de autenticar os funcionários nas aplicações empresariais alojadas na cloud, fora do limite de segurança da empresa, sem que tenha de solicitar que iniciem sessão sempre que acedem a uma aplicação. A experiência de utilizador é semelhante à utilização das aplicações no local, em que a autenticação é necessária quando o utilizador inicia sessão numa rede empresarial e, depois disso, passa a ter acesso a todas as aplicações relevantes sem que seja preciso iniciar sessão novamente.
Identidade federada com vários parceiros. Neste cenário, tem de autenticar os funcionários da empresa e os parceiros comerciais que não têm contas no diretório empresarial. Este cenário é comum em aplicações empresa-empresa, aplicações integradas com serviços de terceiros e empresas com diferentes sistemas de TI possuem recursos intercalados ou partilhados.
Identidade federada em aplicações SaaS. Neste cenário, os fornecedores de software independentes disponibilizam um serviço pronto a utilizar para vários clientes ou inquilinos. Cada inquilino realiza a sua autenticação com o fornecedor de identidade adequado. Por exemplo, os utilizadores empresariais utilizarão as credenciais empresariais, enquanto os consumidores e clientes do inquilino utilizarão as credenciais de identidade social.
Este padrão pode não ser prático nas seguintes situações:
Quando todos os utilizadores da aplicação podem ser autenticados por um fornecedor de identidade e não existe nenhum requisito para realizar a autenticação com qualquer outro fornecedor de identidade. Esta situação é normal em aplicações empresariais que utilizam um diretório empresarial (acessível na aplicação) para a autenticação, com uma VPN ou (num cenário de alojamento na cloud) através de uma ligação de rede virtual entre o diretório no local e a aplicação.
Se a aplicação tiver sido originalmente criada com um mecanismo de autenticação diferente, possivelmente com arquivos de utilizador personalizados, ou não tiver a capacidade para processar as normas de negociação utilizadas pelas tecnologias baseadas em afirmações. A readaptação da autenticação baseada em afirmações e do controlo de acesso nas aplicações existentes pode ser complexa e provavelmente pouco rentável.
Design da carga de trabalho
Um arquiteto deve avaliar como o padrão de Identidade Federada pode ser usado no design de sua carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:
| Pilar | Como esse padrão suporta os objetivos do pilar |
|---|---|
| As decisões de projeto de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e a garantir que ela se recupere para um estado totalmente funcional após a ocorrência de uma falha. | O descarregamento do gerenciamento de usuários e da autenticação transfere a confiabilidade desses componentes para o provedor de identidade, que geralmente tem um SLO alto. Além disso, durante a recuperação de desastres da carga de trabalho, os componentes de autenticação provavelmente não precisarão ser abordados como parte do plano de recuperação da carga de trabalho. - RE:02 Fluxos críticos - RE:09 Recuperação de desastres |
| 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. | Ao externalizar o gerenciamento e a autenticação de usuários, você pode obter recursos evoluídos para deteção e prevenção de ameaças baseadas em identidade sem a necessidade de implementar esses recursos em sua carga de trabalho. E os provedores de identidade externos usam modernos protocolos de autenticação interoperáveis. - SE:02 Ciclo de vida de desenvolvimento seguro - SE:10 Monitorização e deteção de ameaças |
| A Eficiência de Desempenho ajuda sua carga de trabalho a atender às demandas de forma eficiente por meio de otimizações em escala, dados e código. | Ao descarregar o gerenciamento e a autenticação de usuários, você pode dedicar recursos do aplicativo a outras prioridades. - PE:03 Seleção de serviços |
Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.
Exemplo
Uma organização hospeda um aplicativo SaaS (software como serviço) multilocatário no Microsoft Azure. A aplicação inclui um site que os inquilinos podem utilizar para gerir a aplicação para os seus próprios utilizadores. O aplicativo permite que os locatários acessem o site usando uma identidade federada gerada pelos Serviços de Federação do Ative Directory (AD FS) quando um usuário é autenticado pelo próprio Ative Directory dessa organização.
A figura mostra como os locatários se autenticam com seu próprio provedor de identidade (etapa 1), neste caso o AD FS. Depois de autenticar com êxito um locatário, o AD FS emite um token. O navegador cliente encaminha esse token para o provedor de federação do aplicativo SaaS, que confia nos tokens emitidos pelo AD FS do locatário, para recuperar um token válido para o provedor de federação SaaS (etapa 2). Se necessário, o fornecedor de federação SaaS transforma as afirmações no token em afirmações que a aplicação reconhece (passo 3) antes de devolver o novo token ao browser do cliente. A aplicação confia nos tokens emitidos pelo fornecedor de federação SaaS e utiliza as afirmações no token para aplicar regras de autorização (passo 4).
Os locatários não precisarão se lembrar de credenciais separadas para acessar o aplicativo, e um administrador da empresa do locatário pode configurar em seu próprio AD FS a lista de usuários que podem acessar o aplicativo.
Próximos passos
- Microsoft Entra ID
- Active Directory Domain Services
- Serviços de Federação do Active Directory (AD FS)
- Aplicações Multi-inquilino no Azure