A complexidade da migração de identidade
À medida que as empresas aceleram a modernização de suas aplicações no Brasil — seja para atender a exigências de conformidade ou para melhorar a experiência do usuário — a adoção de Single Sign-On (SSO) com provedores como o Microsoft Entra ID tornou-se um padrão estratégico. No entanto, para arquitetos cloud e times de engenharia, a transição de um sistema que utiliza contas locais (e-mail e senha) no Azure AD B2C para uma arquitetura baseada em SSO apresenta desafios operacionais significativos.
Simplesmente "virar a chave" para o SSO frequentemente resulta em fricção técnica e de experiência, manifestando-se em gargalos como:
- Identidades Duplicadas: Ocorre quando usuários tentam autenticar via SSO usando um e-mail que já possui um record no B2C.
- Falta de um fluxo de migração transparente: A ausência de um caminho automatizado que mescle a identidade local com a nova fonte de autenticação.
- Lacunas de segurança: A persistência da autenticação por senha para usuários que já deveriam estar sob a governança de um IDP (Identity Provider) externo.
- Ruído de UX: Fluxos de "Recuperação de Senha" que permanecem ativos e configurados para usuários que não deveriam mais depender de senhas locais, gerando confusão.
O Objetivo: Transição sem atrito
A abordagem ideal, definida como o padrão de SSO Takeover, permite uma migração silenciosa e segura, onde:
- O
objectIddo usuário original é preservado. - As identidades SSO são vinculadas automaticamente ao record existente.
- Fluxos legados (senha/e-mail) são desabilitados seletivamente apenas para usuários migrados.
- O suporte para usuários que ainda não efetuaram a migração (via sistemas legados) é mantido sem interrupções.
- Nenhuma intervenção manual de TI ou do usuário é exigida.
O Pattern: SSO Takeover na prática
Este modelo utiliza as o Identity Experience Framework (custom policies) do Azure AD B2C para orquestrar a lógica de transição. O segredo está em manter uma flag de persistência (extension_ssoMigrated) que atua como o motor de decisão nas User Journeys.
Componentes chave da arquitetura:
- Migration Flag (
extension_ssoMigrated): Um atributo booleano customizado, armazenado no diretório, que sinaliza o estado da migração do usuário. - Bloqueio Condicional: Utiliza Claims Transformations para validar se o usuário é migrado. Se
extension_ssoMigratedfortrue, o sistema bloqueia o acesso a fluxos de password reset e login com credenciais antigas via preconditions. - Link Automático: Durante o login SSO, a política executa uma busca pelo e-mail do usuário; se encontrado, o
alternativeSecurityIdé atualizado, consolidando as identidades.
Tabela de Decisão do Flow
| Cenário | Resultado |
|---|---|
| Local user (not migrated) | ✅ Password sign-in works |
| Local user (not migrated) – Forgot Password | ✅ Allowed |
| First SSO login (existing user) | ✅ Account linked automatically |
| SSO-migrated user | ✅ SSO works |
| SSO-migrated user – password login | ❌ Blocked |
| SSO-migrated user – password reset | ❌ Blocked |
Considerações para o Time de Engenharia
O uso de XML para TrustFrameworkPolicy exige rigor. A implementação apresentada abaixo demonstra a estrutura de claims e o fluxo de orquestração necessário para interceptar o login e aplicar a lógica de takeover:
<!-- Snippet da lógica de bloqueio para usuários migrados -->
<TechnicalProfile Id="ThrowSsoMigratedError">
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider" />
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="AssertNotSsoMigrated" />
</OutputClaimsTransformations>
</TechnicalProfile>
Além de garantir a segurança, este pattern reduz drasticamente o ticket volume de suporte relacionado a "usuário não encontra a conta" ou "esqueci minha senha", sendo uma prática essencial para escalar operações de B2C de alto volume.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
