Entramos no nosso próprio console de admin com o nosso próprio SAML. Eis o que isso apanhou.

Existe uma versão do dogfooding que é um slogan, e uma versão em que os seus próprios funcionários não conseguem entregar código até o bug estar resolvido. Nós praticamos a segunda. O console de equipe da Authagonal, aquele que usamos para gerir cada tenant, autentica-se através da própria Authagonal: SAML single sign-on a partir do nosso diretório Entra, com o SCIM a decidir quem entra e o que pode fazer. Não há uma tabela separada de senhas de admin. Nós a apagamos. Se o nosso próprio SAML quebrar, ficamos trancados para fora do nosso próprio produto.

Isso é desconfortável exatamente da maneira útil. Transforma "o SSO é uma funcionalidade enterprise que suportamos" em "o SSO é a única forma de as pessoas que construíram isto conseguirem trabalhar hoje." Eis o que ser o nosso próprio cliente apanhou.

Um build trimmed que quebrou a verificação de assinatura

Publicamos o servidor de auth em modo trimmed, para manter a imagem pequena. O trimming apaga agressivamente o código cujo uso não consegue provar, e a reflexão esconde esse uso dele. O .NET resolve os seus algoritmos criptográficos de assinatura XML por nome, por reflexão, através de CryptoConfig. O trimmer não conseguiu ver que esses tipos eram necessários, removeu-os, e o SignedXml ficou silenciosamente incapaz de construir o algoritmo. A verificação de assinatura SAML, o passo que prova que o login é real, lançou uma referência nula em tempo de execução.

Os testes unitários passavam, porque corriam contra o build não trimmed onde os tipos ainda existiam. Apenas o artefacto de produção trimmed falhava, e falhava exatamente no momento em que um humano tentava entrar. Agora entregamos o servidor de auth não trimmed, com uma saudável desconfiança quanto a trimmar qualquer coisa próxima de criptografia baseada em reflexão. Se apenas suportássemos SAML em vez de vivermos dele, isto seria o relatório de incidente de um cliente em vez do nosso.

O provisioning é o verdadeiro login

Autenticar um utilizador é a metade fácil do SSO. A metade difícil é decidir o que ele tem permissão para fazer e manter isso sincronizado à medida que as pessoas entram e saem. Conduzimos isso com SCIM: a pertença a grupos do Entra é mapeada para papéis, resolvida no exato momento em que um token é emitido, e não copiada uma única vez na criação da conta. Adicione alguém ao grupo certo e ele terá acesso no seu próximo login; remova-o e o acesso desaparece. A nossa própria lista de acesso faz dogfooding com exatamente o mapeamento de grupo para papel que entregamos.

Essa ligação faz emergir uma classe de bug que só existe quando a autenticação e a autorização vivem em dois sistemas diferentes: um admin recém-provisionado conseguia autenticar-se antes de o seu papel ter aterrado por completo, deixando o primeiro login num estado válido mas não autorizado. A correção está na ordem do provisioning, não no login, e só a encontra sendo o novo admin a entrar pela primeira vez.

Um 500 que devia ter sido um 403

O menor bug foi o mais embaraçoso. Quando um utilizador autenticado batia em algo que não tinha permissão, a API devolvia um 500 em vez de um 403 limpo, porque o caminho de código que emite a resposta "proibido" dependia de um serviço que não estava ligado nesse host. Um pedido negado deve ser um resultado calmo e esperado, não um erro do servidor. Invisível até ser você o que está a ser negado.

A fronteira que mais nos importa

Por baixo de tudo isto está a única regra que uma plataforma de identidade multi-tenant não pode errar: um tenant nunca deve tornar-se o nosso admin. Não confiamos numa única verificação. A plataforma é o seu próprio issuer e um tenant não pode reclamar o seu slug; a chave de assinatura da plataforma é separada da de cada tenant, por isso um token assinado para um tenant não pode ser reutilizado como um token de plataforma; e o store da plataforma impõe os papéis de plataforma de forma independente. Três fechaduras, porque o custo de uma só falhar aberta é o produto inteiro.

O ponto

Nenhum destes foi apanhado por um teste inteligente. Foram apanhados por uma pessoa a tentar fazer o seu trabalho e não conseguir. Esse é o argumento para usar o seu próprio produto na profundidade em que ele lhe pode doer: converte os bugs escondidos nas frestas entre sistemas em bugs que você corrige antes do pequeno-almoço, porque não pode entregar até o fazer.

Tudo aquilo em que o nosso console se apoia (SSO, SAML, SCIM, MFA, registos de auditoria) está incluído em todos os planos da Authagonal, sem ficar trancado atrás de um nível nem ser cobrado por ligação. Veja o que está incluído.