Estimativa de uma integração de SSO
Como estimar uma integração de SSO: o trabalho não está na sua base de código, mas nas particularidades do provedor de identidade. As perguntas que você precisa responder antes de definir um valor.
O SSO consiste, em grande parte, nas peculiaridades de terceiros — configure primeiro o provedor de identidade; o resto é só uma questão de infraestrutura.
“Adicionar SSO” parece ser um único recurso. Na verdade, são dois. O primeiro é uma pequena parte da infraestrutura do OAuth, SAML ou OIDC — bem documentada, com bibliotecas disponíveis; toda biblioteca de autenticação moderna tem um tutorial. O segundo é tudo o que o provedor de identidade faz e que não está no tutorial: os nomes de reivindicações que não correspondem à especificação, as regras de redirecionamento de URI mais rígidas do que a especificação, o tempo limite de sessão que não coincide com o seu, o erro de “off-by-one” na serialização de grupos, o endpoint de metadados que retorna XML inválido às terças-feiras. A primeira parte é a história sobre a qual todos podem opinar. A segunda parte são os pontos.
O que significa que a estimativa não se refere, na verdade, ao SSO. Trata-se desse provedor de identidade e se alguém da equipe já fez integração com ele antes. O Okta com uma configuração SAML padrão é uma história diferente do Azure AD com uma regra de reivindicações personalizada que ninguém de nenhum dos lados compreende totalmente. Uma equipe que lança uma integração com o Okta em um sprint levará três sprints para implementar um AD FS federado com um proxy personalizado na frente — e o código que eles escrevem fica quase idêntico no final.
O que se fala na sala
Backend: “É um fluxo OAuth. A biblioteca cuida disso. 5 pontos.”
Segurança: “Qual IdP? Okta? Azure AD? SAML personalizado?”
Backend: “…isso importa?”
Segurança: “Sim. As alegações deles não são as mesmas da especificação.”
Pergunta inicial: “Alguém desta equipe já fez integração com seu IdP antes?”
SRE: “Qual seria o plano de reversão se a atualização causar problemas para metade dos nossos usuários?”
A pergunta do líder é o que determina a estimativa. Se alguém já fez entregas com esse provedor, a tarefa é pequena e bem delimitada. Se ninguém fez, a tarefa consiste em duas partes de trabalho de natureza desconhecida — e a atitude correta não é tentar estimar com mais precisão; é definir um prazo para um teste rápido com base no comportamento real do provedor e, só depois, dimensionar a implementação.
Perguntas que vale a pena fazer antes de votar
- Qual provedor de identidade, especificamente? Okta, Azure AD, Google Workspace, Auth0 ou personalizado?
- Alguém da equipe já fez integração com esse provedor antes?
- OAuth, SAML ou OIDC — e qual versão de cada um?
- Qual é o modelo de provisionamento de usuários — JIT, SCIM ou manual?
- Mapeamento de grupo para função: precisamos disso? Onde esse mapeamento fica?
- O que acontece com as contas locais existentes durante a transição?
- Tempo limite da sessão, tempo limite de inatividade, exigência de MFA — qual política prevalece?
- Podemos realizar testes com o provedor real do cliente ou apenas em um ambiente de teste?
Se duas ou mais dessas tarefas forem consideradas “um caso à parte” a tarefa é muito grande: separe o provisionamento, o mapeamento de funções e a migração em tarefas próprias e avalie o fluxo de autenticação separadamente.
Não escolha um número antes de saber com qual provedor de identidade você está fazendo a integração. O provedor é o que importa.
Consulte estimativa da troca de uma API de terceiros para conhecer o padrão relacionado “peculiaridades de terceiros” e os outros exemplos práticos de estimativa para obter mais informações. Inicie uma sessão gratuita de planning poker assim que o spike tiver definido qual provedor e quais peculiaridades.