Substituir AD FS e alterar o protocolo de autenticação de uma aplicação são decisões distintas. Para uma aplicação que já utiliza WS-Federation, pode ser possível manter esse protocolo ao mudar o identity provider de confiança para o FoxIDs.
O primeiro marco útil é uma aplicação que reconheça os mesmos utilizadores, conceda o acesso pretendido e disponha de um caminho de regresso testado. Um início de sessão bem-sucedido, por si só, não demonstra nenhum desses resultados.
Este guia destina-se a arquitetos de IAM e de soluções que preparam essa primeira migração. Abrange uma aplicação baseada no browser que utiliza WS-Federation passivo, frequentemente abreviado para WS-Fed. A federação de domínios do Microsoft 365, o início de sessão no Windows e os clientes ativos WS-Trust requerem uma avaliação própria e não fazem parte deste exemplo.
Separe a transferência da aplicação da transferência do diretório
AD FS é um serviço de federação; Active Directory é o diretório contra o qual muitas instalações de AD FS autenticam os utilizadores. Transferir a relação de confiança de federação de uma aplicação não transfere, por si só, as contas ou as palavras-passe do diretório.
Um possível padrão de transição mantém inicialmente AD FS como origem da autenticação:
| Etapa | Em que confia a aplicação | Onde se autentica o utilizador |
|---|---|---|
| Antes | AD FS emite o token WS-Federation da aplicação | AD FS utiliza a configuração de autenticação existente |
| Primeiro piloto | O FoxIDs emite um novo token WS-Federation para a aplicação | O FoxIDs encaminha o browser para AD FS através de um método de autenticação configurado |
| Uma alteração posterior e separada | A aplicação continua a confiar no FoxIDs | Outro identity provider externo, ou FoxIDs Login com Directory Connector para AD, substitui AD FS após uma validação separada |
O FoxIDs suporta tanto um registo de aplicação WS-Federation voltado para a aplicação como um método de autenticação WS-Federation voltado para AD FS. Os dois lados têm funções diferentes: um emite tokens e o outro valida a resposta do fornecedor a montante.
No piloto, AD FS emite um token destinado ao FoxIDs. O FoxIDs valida-o e emite um token separado destinado à aplicação. Não se trata de um reencaminhamento transparente do token anterior: a aplicação tem de confiar no emissor e no certificado de assinatura do FoxIDs.
O piloto continua a depender de AD FS. Cria um ponto controlado em que a relação de confiança e os requisitos de claims da aplicação podem ser verificados, mas ainda não desativa o serviço de federação.
Dois caminhos para deixar de depender de AD FS
Depois do piloto, ambos os caminhos são possíveis:
- Manter um identity provider externo. Substitua AD FS por outro IdP ligado ao FoxIDs através de um método de autenticação suportado. O FoxIDs continua a ser o emissor WS-Federation de confiança da aplicação, pelo que esta não precisa de adotar o protocolo do novo fornecedor.
- Utilizar FoxIDs Login com Active Directory. O Directory Connector para Active Directory valida as palavras-passe contra AD. Isto retira AD FS do percurso de início de sessão da aplicação, mantendo AD como diretório autoritativo. O guia de modernização do Active Directory explica esta arquitetura.
Uma mudança posterior para a validação de palavras-passe no FoxIDs é opcional. Os inícios de sessão bem-sucedidos através do conector criam ou atualizam utilizadores internos do FoxIDs e, quando a gravação local de palavras-passe está ativada, guardam um hash da palavra-passe para preparar esses utilizadores para um cut-over posterior. Trata-se de uma migração gradual, não de uma exportação de todas as contas de AD; AD mantém-se como origem autoritativa enquanto o conector estiver ativado.
Independentemente do caminho escolhido, volte a testar as associações de contas, os claims, MFA e logout. O piloto da primeira aplicação descrito abaixo estabelece o que deve ser preservado.
Documente o que a primeira aplicação realmente utiliza
Escolha uma aplicação com um responsável, um ambiente de testes representativo e uma configuração que possa restaurar. Confirme que o middleware ou o fornecedor permite alterar o STS de confiança, abreviatura de Security Token Service. Um URL de metadados configurável é útil, mas também importam as verificações personalizadas do emissor, o código de pesquisa de contas e as regras de autorização.
Considere uma aplicação fictícia de gestão de despesas. A tabela seguinte ilustra os requisitos do resultado pretendido; não é uma configuração exportada nem um relatório de uma migração concluída.
| Elemento | Comportamento existente | Resultado exigido no piloto |
|---|---|---|
| Realm / audience | urn:example:expenses identifica a aplicação |
O wtrealm da aplicação corresponde ao seu registo no FoxIDs e o token destina-se a essa aplicação |
| URL de resposta | A instância de testes recebe respostas em https://expenses-test.example.org/signin-wsfed |
Apenas o callback previsto para os testes é aceite e utilizado |
| Emissor de confiança e chaves de assinatura | A aplicação confia nos metadados e nas chaves de assinatura de AD FS | A instância de testes confia nos metadados, no emissor e nas chaves de assinatura do FoxIDs selecionados para este piloto |
| Formato do token | O middleware aceita SAML 1.1 transportado através de WS-Federation | Mantenha esse formato de token, a menos que seja necessária uma alteração testada separadamente |
| Pesquisa do utilizador | O claim NameIdentifier da aplicação identifica o colaborador E1042 |
São selecionados a mesma conta existente e o respetivo histórico; não é criada uma segunda conta |
| Autorização | A função ExpenseApprover permite aprovar despesas |
Os utilizadores autorizados mantêm essa permissão; os utilizadores sem a função continuam sem poder aprovar |
| Comportamento das sessões | A aplicação tem um cookie local e uma política de logout definida | O início de sessão, a expiração, uma nova autenticação e logout cumprem a política acordada através do novo percurso |
Preencha a tabela com os valores e tipos de claims da aplicação real. Verifique se a pesquisa de contas também inclui o emissor do token ou o nome do fornecedor externo de início de sessão: preservar apenas o ID de utilizador visível pode não preservar a associação à conta.
O FoxIDs pode emitir tokens SAML 1.1 ou SAML 2.0 através de WS-Federation; SAML 1.1 é a predefinição. Um token SAML 2.0 dentro de uma resposta WS-Federation não representa uma mudança para o protocolo SAML 2.0 Web SSO. Mantenha separadas as decisões sobre o protocolo e o formato do token.
Documente os requisitos de cifragem e a expiração dos certificados juntamente com a confiança na assinatura. A cifragem e a validação da assinatura resolvem problemas distintos e têm de ser compatíveis com a aplicação que recebe o token. Para ASP.NET Core, o guia da Microsoft para o middleware WS-Federation identifica MetadataAddress, Wtrealm e a configuração do callback como definições relevantes para a integração. Verifique o middleware e a versão efetivamente utilizados antes de aplicar um exemplo de configuração.
Configure ambos os lados num ambiente de testes
Crie o piloto num ambiente FoxIDs separado e utilize uma instância de testes da aplicação. Configure a ligação a AD FS como método de autenticação e registe depois a aplicação existente no FoxIDs com o seu realm, URL de resposta, tipo de token e claims necessários.
Do lado de AD FS, o FoxIDs é uma relying party por si só. Estabeleça essa relação de confiança utilizando os metadados do método de autenticação do FoxIDs e defina os claims e a política de acesso que AD FS deve aplicar-lhe. Mantenha disponível a relação de confiança original da aplicação em AD FS durante a janela de rollback acordada.
Não presuma que as regras de claims, as restrições de acesso ou a política de MFA da relying party original se aplicam automaticamente a esta nova relação de confiança. As regras de claims de AD FS estão associadas a relações de confiança individuais, como descrito no guia da Microsoft sobre regras de claims. Recrie o comportamento necessário no ponto adequado e teste-o.
Configure depois a instância de testes da aplicação para utilizar os metadados do STS do FoxIDs e o emissor esperado. Mantenha ativada a validação do emissor, audience e assinatura. Utilize os endpoints gerados para o ambiente real em vez de adaptar manualmente um URL de AD FS.
O piloto passivo no browser não necessita da opção separada Microsoft Entra ID Windows sign-in. Essa funcionalidade suporta um cenário diferente, com federação de domínios e clientes ativos.
Acompanhe os claims até à aplicação
Os metadados estabelecem endpoints e informações de confiança; não determinam o comportamento das contas e permissões da aplicação.
Com um método WS-Federation a montante, o FoxIDs recebe claims SAML, representa-os internamente como claims JWT e converte-os novamente em claims SAML para o token da aplicação. Por exemplo, o mapeamento predefinido converte http://schemas.microsoft.com/ws/2008/06/identity/claims/role em role internamente e depois de novo no tipo de claim SAML para WS-Federation. Inclua o tipo de claim SAML da função necessária tanto na lista Forward claims do método de autenticação a montante como na lista Issue claims da aplicação a jusante; as funções não fazem parte do conjunto predefinido de claims.
Os identificadores exigem uma verificação separada. Para um método de autenticação WS-Federation chamado adfs, o FoxIDs acrescenta um prefixo ao identificador recebido E1042, que passa a ser adfs|E1042 antes das transformações de claims seguintes. Se a aplicação de despesas espera E1042, defina um mapeamento explícito que preserve a associação à conta existente. Não remova prefixos indiscriminadamente: identificadores iguais de origens diferentes poderiam selecionar a mesma conta.
Compare um utilizador que já pode aprovar despesas com um colaborador que não deve poder fazê-lo. Examine os claims que a aplicação realmente utiliza, incluindo qualquer mapeamento do middleware, e teste as permissões resultantes. As transformações de claims podem alterar nomes e valores; por isso, verifique o resultado final, não apenas a configuração.
Consulte a documentação sobre transformações e mapeamento de claims para os detalhes de implementação. Reencaminhe e emita os claims necessários à aplicação; um caráter universal não substitui a decisão sobre que dados deve receber.
Teste o acesso e a recusa antes do cut-over
Acorde os resultados esperados com o responsável pela aplicação antes dos testes. Registe tanto o token e os claims observados como o comportamento da aplicação, utilizando contas de teste e mantendo o material de autenticação fora dos relatórios partilhados.
| Teste | Evidência necessária antes de avançar |
|---|---|
| Um utilizador existente inicia sessão | São selecionados a conta existente na aplicação, os seus dados e o seu histórico |
| Um aprovador e um colaborador comum executam a mesma ação | O aprovador consegue concluí-la; ao colaborador comum é recusada |
| Um utilizador está excluído pela política de acesso da aplicação anterior | O novo percurso continua a recusar o acesso a esse utilizador |
| MFA é exigida, incluindo com uma sessão de browser AD FS existente | O fluxo configurado cumpre o nível de garantia exigido; um início de sessão bem-sucedido no fornecedor a montante não é aceite, por si só, como prova suficiente |
| O utilizador termina sessão e volta a visitar uma página protegida | O cookie da aplicação, a sessão de AD FS e o fluxo de logout/cleanup configurado cumprem a política de logout acordada |
| Uma nova tentativa de autenticação necessita de AD FS enquanto AD FS está indisponível | A tentativa falha sem contornar a origem de autenticação exigida; a falha é visível para o responsável operacional |
| As respostas de teste contêm um emissor, audience ou assinatura inválidos | Cada resposta inválida é rejeitada; a validação mantém-se ativada |
| A configuração anterior da aplicação é restaurada | Um novo início de sessão através do percurso original de AD FS seleciona a conta e as permissões corretas |
Teste a expiração das sessões e uma nova autenticação separadamente de um início de sessão normal bem-sucedido. Uma conta desativada ou um utilizador a quem foi retirada uma função pode continuar a ter uma sessão existente na aplicação. Acorde quando o acesso deve terminar e verifique esse prazo em vez de presumir que uma nova configuração de federação revoga todos os cookies.
O FoxIDs suporta sign-out e notificações de cleanup de WS-Federation quando configurados. A eliminação da sessão local por todas as aplicações participantes depende da sua implementação e do fluxo real no browser. Verifique o comportamento de logout com os clientes e browsers utilizados em produção.
Faça do cut-over uma decisão delimitada e reversível
Antes da entrada em produção, documente quem pode restaurar a configuração anterior da aplicação, onde está guardada e quais os resultados que desencadeiam o rollback. Associações incorretas de contas, permissões não previstas e requisitos de MFA não cumpridos devem interromper imediatamente a implementação. Acorde limiares para falhas de início de sessão e incidentes operacionais em vez de os inventar durante a alteração.
Realize a migração da aplicação dentro do âmbito acordado e durante uma janela monitorizada. Um piloto utilizador a utilizador só é possível se a aplicação e o modelo de encaminhamento o suportarem; caso contrário, utilize primeiro a instância de testes e trate a aplicação de produção como unidade de alteração.
O rollback deve abranger mais do que o URL dos metadados. Restaure a confiança anterior no emissor e nas chaves, a configuração de claims e quaisquer associações de contas alteradas durante o piloto. Decida como terminar ou substituir as sessões estabelecidas através do novo percurso. Restaurar o endpoint anterior não anula alterações nos dados da aplicação nem elimina automaticamente essas sessões.
Quando esta aplicação estiver estável, decida qual a dependência a eliminar a seguir. Substituir AD FS a montante, alterar o protocolo da aplicação para OpenID Connect e migrar os utilizadores do diretório são alterações posteriores separadas, cada uma com os seus próprios testes. Se o armazenamento de utilizadores ou palavras-passe mudar, utilize o guia de decisão sobre migração de palavras-passe em vez de incluir esse trabalho neste piloto.
O resultado medido da primeira aplicação dá à migração seguinte um ponto de partida concreto: uma configuração de confiança compreendida, um comportamento dos utilizadores e dos acessos verificado e um procedimento de recuperação que a equipa já exercitou. Utilize o guia de migração para transformar essa evidência num plano mais amplo.