Noções básicas sobre autenticação HTTP
A autenticação é o processo de identificar quem é o cliente, normalmente para determinar se o cliente é elegível para acessar um recurso. O protocolo HTTP suporta autenticação como um meio de negociar o acesso a um recurso seguro.
A solicitação inicial de um cliente normalmente é uma solicitação anônima, não contendo nenhuma informação de autenticação. Os aplicativos de servidor HTTP podem negar a solicitação anônima enquanto indicam que a autenticação é necessária. O aplicativo de servidor envia cabeçalhos WWW-Authentication para indicar os esquemas de autenticação suportados. Este artigo descreve vários esquemas de autenticação para HTTP e discute seu suporte no Windows Communication Foundation (WCF).
Esquemas de autenticação HTTP
O servidor pode especificar vários esquemas de autenticação para o cliente escolher. A tabela a seguir descreve alguns dos esquemas de autenticação comumente encontrados em aplicativos do Windows:
| Esquema de autenticação | Description |
|---|---|
| Anónimo | Uma solicitação anônima não contém informações de autenticação. Anonymous equivale a conceder a todos acesso ao recurso. |
| Básica | A autenticação básica envia uma cadeia de caracteres codificada em Base64 que contém um nome de usuário e senha para o cliente. Base64 não é uma forma de criptografia e deve ser considerado o mesmo que enviar o nome de usuário e senha em texto não criptografado. Se um recurso precisar ser protegido, considere fortemente o uso de um esquema de autenticação diferente da autenticação básica. |
| Resumo | A autenticação Digest é um esquema de desafio-resposta destinado a substituir a autenticação Básica. O servidor envia uma cadeia de dados aleatórios chamada nonce para o cliente como um desafio. O cliente responde com um hash que inclui o nome de usuário, senha e nonce, entre informações adicionais. A complexidade que essa troca introduz e o hashing de dados tornam mais difícil roubar e reutilizar as credenciais do usuário com esse esquema de autenticação. A autenticação Digest requer o uso de contas de domínio do Windows. O domínio digest é o nome de domínio do Windows. Portanto, você não pode usar um servidor em execução em um sistema operacional que não ofereça suporte a domínios do Windows, como o Windows XP Home Edition, com autenticação Digest. Por outro lado, quando o cliente é executado em um sistema operacional que não suporta domínios do Windows, uma conta de domínio deve ser especificada explicitamente durante a autenticação. |
| NTLM | A autenticação NT LAN Manager (NTLM) é um esquema de desafio-resposta que é uma variação mais segura da autenticação Digest. O NTLM usa credenciais do Windows para transformar os dados de desafio em vez do nome de usuário e senha não codificados. A autenticação NTLM requer várias trocas entre o cliente e o servidor. O servidor e quaisquer proxies intervenientes devem suportar conexões persistentes para concluir a autenticação com êxito. |
| Negociar | A autenticação Negotiate seleciona automaticamente entre o protocolo Kerberos e a autenticação NTLM, dependendo da disponibilidade. O protocolo Kerberos é usado se estiver disponível; caso contrário, o NTLM é tentado. A autenticação Kerberos melhora significativamente em relação ao NTLM. A autenticação Kerberos é mais rápida que a NTLM e permite o uso de autenticação mútua e delegação de credenciais para máquinas remotas. |
| Windows Live ID | O serviço HTTP subjacente do Windows inclui autenticação usando protocolos federados. No entanto, os transportes HTTP padrão no WCF não suportam o uso de esquemas de autenticação federada, como o Microsoft Windows Live ID. O suporte para esse recurso está atualmente disponível usando a segurança de mensagens. Para obter mais informações, consulte Federação e tokens emitidos. |
Escolha um esquema de autenticação
Ao selecionar os possíveis esquemas de autenticação para um servidor HTTP, alguns itens a serem considerados incluem o seguinte:
Considere se o recurso precisa ser protegido. Usar a autenticação HTTP requer a transmissão de mais dados e pode limitar a interoperabilidade com os clientes. Permita acesso anônimo a recursos que não precisam ser protegidos.
Se o recurso precisar ser protegido, considere quais esquemas de autenticação fornecem o nível de segurança necessário. O esquema de autenticação padrão mais fraco discutido aqui é a autenticação básica. A autenticação básica não protege as credenciais do usuário. O esquema de autenticação padrão mais forte é a autenticação Negotiate, resultando no protocolo Kerberos.
Um servidor não deve apresentar, por exemplo, nos cabeçalhos WWW-Authentication), qualquer esquema que não esteja preparado para aceitar ou que não proteja adequadamente o recurso protegido. Os clientes são livres para escolher entre qualquer um dos esquemas de autenticação que o servidor apresenta. Alguns clientes usam como padrão um esquema de autenticação fraco ou o primeiro esquema de autenticação na lista do servidor.