Resumo

  • A RFC 4422 distingue a identidade ligada às credenciais da identidade em nome da qual o cliente pede para agir; o servidor precisa validar a prova e essa relação de representação.
  • Uma troca SASL concluída com sucesso pode definir o estado da sessão ou ativar uma camada de segurança, mas não autoriza automaticamente cada ação da aplicação.

O sinal verde tem um objeto

Produtos digitais gostam de reduzir a autenticação a uma marca de verificação. A simplificação ajuda quem entra, mas pode confundir quem investiga. Credenciais válidas, direito de assumir uma identidade, admissão em um serviço e permissão sobre um objeto são decisões diferentes. Quando o registro chama todas de “login”, perde a capacidade de explicar por que uma delas disse sim e outra, não.

SASL ocupa a faixa entre protocolos de aplicação orientados a conexão e mecanismos substituíveis de autenticação. O mecanismo descreve como testar credenciais. O perfil de cada protocolo descreve como levar o diálogo e o que fazer com o resultado. Esse encaixe permite evolução sem fundir as responsabilidades.

O êxito da troca pode instalar uma camada de segurança negociada para os bytes seguintes. Também pode associar uma identidade à sessão. Ainda assim, não traz uma lista universal de caixas postais, comandos, arquivos ou funções administrativas liberadas. A próxima ação ser recusada pode ser evidência de uma fronteira preservada, não de autenticação defeituosa.

A identidade comprovada e a identidade pedida

A RFC 4422 dá nomes a dois papéis. A identidade de autenticação é aquela associada às credenciais. A identidade de autorização é aquela em nome da qual o cliente quer atuar. Num acesso comum, os dois valores coincidem e a diferença fica escondida.

Se o cliente omite ou deixa vazia a cadeia de identidade de autorização, pede para agir como a identidade que o servidor relaciona às credenciais. A arquitetura, porém, também cobre procuração: A se autentica como A e solicita operar como B.

O servidor deve então responder a duas perguntas. As credenciais de A são verificáveis? A pode agir como B? A troca falha se qualquer resposta for negativa. Uma senha verdadeira não transforma o conhecimento de outro nome em direito de representá-lo.

Mesmo quando B é aceito, “identidade de autorização” não significa pacote global de direitos. Trata-se da identidade usada pelo estado de autorização daquele protocolo. O acesso a cada recurso, o limite de uso e as condições da operação continuam nas políticas da aplicação.

O perfil da aplicação completa o sentido

O núcleo de SASL não tenta impor o mesmo modelo de identidade a todos os protocolos. Cada perfil precisa definir descoberta e escolha de mecanismos, transporte de desafios e respostas, formato da identidade solicitada, ponto em que uma camada de segurança começa, ordem de camadas e efeito de autenticações repetidas.

Essa lista distribui autoridade sem escondê-la. Um mecanismo pode ficar mais resistente sem aprender a semântica de uma caixa postal. Um protocolo pode trocar o mecanismo sem redesenhar toda mensagem. Mas a modularidade só é segura se cada equipe documentar o trecho que lhe pertence.

Entre o valor recebido na rede e uma decisão de acesso podem existir normalização, associação a uma conta interna, grupos, atributos e cache. Uma transcrição SASL correta não prova que esses vínculos locais estavam atualizados nem que aplicavam o menor privilégio.

O 235 do SMTP termina na autenticação

SMTP AUTH torna a fronteira visível. A RFC 4954 reserva 235 2.7.0 Authentication Succeeded para a resposta bem-sucedida ao comando AUTH e associa uma identidade de autorização à sessão SMTP. Esse código não é comprovante de uma transação de correio futura.

Quando AUTH negocia uma camada de segurança, o estado SMTP volta ao início. Cliente e servidor descartam informações anteriores de capacidades, e o cliente deve emitir EHLO de novo. Portanto, o sucesso da autenticação pode ser seguido por um recomeço explícito do protocolo de aplicação.

Política de retransmissão, destinatários, conteúdo, fila e entrega pertencem a etapas seguintes. O exemplo aqui não repete a discussão sobre aceitar versus entregar uma mensagem. Ele mostra que até um código de sucesso inequívoco responde a um verbo específico: AUTH.

Um sucesso que não identifica ninguém

A RFC 4505 define o mecanismo ANONYMOUS para permitir acesso sem estabelecer nem revelar a identidade do usuário, normalmente com privilégios limitados. A informação opcional de rastreamento não é autenticada e pode ser falsificada.

Logo, encontrar “SASL success” num log não basta para classificar uma pessoa como verificada. É preciso conhecer a promessa daquele mecanismo. Se a telemetria converte uma sessão anônima em identidade confirmada, ela inventa uma certeza que o protocolo evitou produzir.

Uma prova mais forte não conserta a autorização

A RFC 7677 registrou SCRAM-SHA-256 e SCRAM-SHA-256-PLUS. O uso de SHA-256 e as considerações de channel binding fortalecem a etapa substituível de autenticação. Elas não informam ao mecanismo quem pode ler uma caixa específica ou executar um comando privilegiado.

Uma migração criptográfica pode reduzir exposição de credenciais e confusão de canal. Não remove um grupo amplo demais, uma delegação vencida ou uma regra de aplicação errada. Testar somente a nova prova corre o risco de entregar autenticação moderna sobre uma decisão de acesso antiga.

O registro precisa sobreviver ao desacordo

Uma investigação útil separa o mecanismo escolhido, a proteção de canal, a identidade obtida das credenciais, a identidade solicitada, a identidade aceita, a política que permitiu a representação e a decisão posterior sobre o recurso. Um único campo “usuário” é econômico no banco de dados e caro quando há uma disputa.

Sem essas peças, quatro falhas parecem iguais: credencial furtada, delegação excessiva, mapeamento de diretório obsoleto e autorização ampla na aplicação. O bit de sucesso conduz a máquina de estados; não recompõe sozinho a cadeia de responsabilidade.

A linguagem de interface também pode ajudar. “Sessão iniciada como” descreve identidade. “Pode alterar este item” afirma uma permissão concreta. Se a tela distingue as duas frases, uma negativa após o login deixa de parecer um defeito inexplicável e passa a revelar onde o serviço exerce controle.

Fontes