Especifique o resultado do acesso, não apenas uma caixa de seleção SSO
O requisito de que uma plataforma de autenticação suporte o logon único SAML está incompleto, a menos que explique quem deve entrar em qual locatário, com quais permissões e o que acontece quando sua função ou emprego muda. A autenticação bem-sucedida estabelece uma afirmação de identidade sob um relacionamento de federação acordado. Ele não autoriza automaticamente todos os domínios, clientes, relatórios ou ações administrativas no aplicativo. As revisões de aquisição e implementação devem, portanto, testar o resultado do acesso, em vez de aceitar um login bem-sucedido como requisito completo.
Este artigo é uma proposta de estrutura de requisitos. Ele não afirma que EmailAuth implemente SAML, provisionamento just-in-time, funções específicas ou qualquer recurso de controle de sessão. Nenhum provedor de identidade foi configurado, nenhuma declaração foi enviada ou nenhum acesso foi concedido. Documentação do protocolo SAML da Microsoft fornece uma descrição oficial concreta de uma exchange suportada pelo Entra, enquanto os critérios de aceitação propostos ainda exigem confirmação da plataforma real e do provedor de identidade.
Vincule a federação ao aplicativo e ao locatário pretendidos
Documente o provedor de identidade, o provedor de serviços, o locatário pretendido, o administrador de federação aprovado e o proprietário da configuração. Registre o identificador do aplicativo e o endpoint do consumidor de asserção a partir de evidências de configuração aprovadas, sem copiar credenciais ou completar asserções confidenciais em uma planilha geral. A documentação do Entra descreve emissor, público, correlação de resposta e elementos de confirmação de assunto. Estes não são rótulos intercambiáveis: uma afirmação destinada a uma aplicação não deve tornar-se autoridade para uma aplicação diferente simplesmente porque possui uma assinatura válida.
Exigir que a implementação real valide os elementos do protocolo apropriados ao seu fluxo suportado, incluindo confiança no emissor e no material de assinatura, público-alvo e destinatário, condições de validade e correlação de solicitação, quando aplicável. Não invente uma única receita de validação que cubra cada fluxo ou biblioteca iniciada. Peça ao fornecedor para documentar seus fluxos suportados e verificações de segurança e, em seguida, verifique-os em um ambiente isolado autorizado. Um exemplo de resposta XML na documentação não é evidência de que a plataforma de destino impõe essas verificações.
Mantenha a autenticação e a autorização separadas
Diretrizes de identidade multilocatário do Azure distingue autorização baseada em função e baseada em recursos e alerta contra configurações incorretas da federação que concedem acesso a locatários não intencionais. Use essa distinção ao escrever requisitos. Um utilizador autenticado pelo fornecedor de identidade de um cliente ainda precisa de uma relação autorizada com o inquilino e os recursos corretos da aplicação. Um sufixo de endereço de e-mail por si só não deve ser tratado como uma decisão completa de locação ou função sem um mapeamento aprovado e documentado.
Especifique as funções permitidas e o escopo do recurso independentemente do método de login. Um visualizador de relatórios pode ler domínios selecionados, mas não exportar todos os clientes; um administrador de locatário pode gerenciar membros sem alterar as configurações de outro locatário. Defina quem pode estabelecer ou alterar esses mapeamentos e como as alterações serão analisadas. Se atributos de grupo ou função forem usados, documente sua origem, valores aceitos e comportamento quando os atributos estiverem ausentes ou inesperados. Estes são controles propostos, não afirmações sobre o modelo de um produto específico.
Definir comportamento de adesão e mudança de função
Para um novo usuário, indique se a conta deve ser provisionada antecipadamente ou se o comportamento just-in-time compatível é permitido. Documente como o locatário pretendido é selecionado e se a aprovação é necessária antes que a primeira sessão possa acessar os dados. Não deduza o provisionamento automático da disponibilidade da autenticação SAML. O fornecedor deve identificar o comportamento real do seu ciclo de vida suportado e quaisquer diferenças entre acesso administrativo, interativo e API.
Para alterações de função, especifique quando as novas permissões devem entrar em vigor e como as sessões existentes serão tratadas. Um requisito deve distinguir a remoção de uma função da desativação de uma conta. Deve também indicar se as decisões de autorização armazenadas em cache são atualizadas e como o resultado observado será verificado. Evite presumir que uma nova asserção no próximo login atualize todas as sessões já ativas. Retenha evidências reais de ações permitidas e negadas após uma alteração, quando o teste autorizado for eventualmente realizado.
Tornar explícita a desativação e o tratamento de sessões
A conta do provedor de identidade de um funcionário pode ser desativada enquanto uma sessão do provedor de serviços permanece ativa de acordo com o comportamento do próprio aplicativo. Os requisitos devem perguntar como as sessões existentes, os dispositivos lembrados, as contas locais de fallback e as credenciais não interativas são tratadas. A disponibilidade do SSO não estabelece, por si só, uma garantia universal de logout ou revogação. Exija que o fornecedor descreva os mecanismos de revogação suportados, as limitações esperadas e as evidências necessárias para verificá-los.
Separe o desligamento de rotina da contenção de emergência. As alterações de rotina podem seguir a sincronização programada do ciclo de vida; um incidente pode exigir que um administrador autorizado revogue o acesso imediatamente por meio de um caminho diferente com suporte. Este artigo não executa nem aprova essas alterações de segurança. Propõe que os seus critérios de propriedade e verificação sejam documentados antes da adoção, em vez de serem descobertos durante um incidente quando a equipa assume que a desativação da conta do fornecedor de identidade foi suficiente.
Uma planilha de aceitação de SSO
Crie uma planilha com referência de configuração do provedor de identidade, locatário do provedor de serviços, identidade de teste do usuário, função pretendida, escopo do recurso, fluxo compatível e resultado esperado. Adicione linhas para ingresso, aumento de função, redução de função, desativação, comportamento de sessão ativa e qualquer caminho de recuperação local aprovado. Registre quem autoriza cada teste e qual ambiente contém os equipamentos. Não inclua senhas reais, cookies de sessão, chaves de assinatura privadas ou declarações de produção completas na planilha.
Inclua casos negativos que demonstrem limites: uma identidade destinada a outro inquilino não deve obter acesso, um visualizador não deve receber privilégios administrativos e uma função removida não deve permanecer silenciosamente eficaz além do comportamento documentado. Expresse-os como critérios de aceitação até que existam resultados reais. Um teste com falha deve registrar a ação e a resposta observada sem presumir que a falha foi aplicada com segurança apenas porque a interface escondeu um botão. A autorização do lado do servidor precisa de sua própria evidência.
Diagnóstico fictício: o login foi bem-sucedido, mas o escopo está errado
Uma organização fictícia avalia uma plataforma para duas equipes de clientes. Ambos usam o mesmo provedor de identidade corporativa, mas os locatários de seus aplicativos devem permanecer separados. Uma demonstração inicial mostra o SSO bem-sucedido e um painel de relatórios. O revisor observa que a demonstração nunca estabeleceu a qual locatário o usuário de teste estava vinculado ou se uma sessão existente manteria uma função após a remoção.
O acompanhamento proposto é um teste autorizado baseado em dispositivos que verifica a vinculação do inquilino, a redução de função e a desativação separadamente. Um login bem-sucedido contaria apenas para a parte de autenticação do requisito. Nenhum teste desse tipo foi executado aqui, e a plataforma fictícia não é uma alegação sobre EmailAuth ou outro serviço nomeado. O exemplo explica por que uma demonstração de SSO aparentemente completa pode deixar questões de acesso a materiais sem resposta.
Exigir evidências antes de aceitar a capacidade
Uma resposta útil do fornecedor identifica fluxos de protocolo suportados, integrações de ciclo de vida, mapeamento de funções, comportamento de sessão, acesso alternativo e evidências de auditoria. Ele também afirma claramente as limitações. Não converta uma declaração de roteiro ou uma captura de tela em prova de implementação. Preserve a versão do produto e o contexto de configuração para que o resultado da aceitação permaneça interpretável após uma mudança de provedor.
O catálogo requer teste de junção, mudança de função, desativação e manipulação de sessão ativa com suporte de plataforma atual. Essa evidência original permanece aberta. Este rascunho fornece requisitos propostos e um exercício fictício, não resultados de testes. A revisão de especialistas humanos, a aplicabilidade da fonte, as rotas de produção, a acessibilidade e a liberação do proprietário também estão abertas. A publicação e qualquer reivindicação de capacidade exigem observações autorizadas da plataforma real, em vez de inferências apenas da documentação SAML.