Autenticação (API do servidor HTTP)

Alguns aplicativos de servidor exigem autenticação de cliente para acessar recursos e solicitações HTTP de serviço. A partir da versão 2.0, a API do Servidor HTTP executa a autenticação do lado do servidor para o aplicativo. Na API do SERVIDOR HTTP versão 1.0, o aplicativo de servidor teve que implementar sua própria autenticação. Algumas vantagens da autenticação executada pela API do servidor HTTP incluem:

• Os aplicativos podem ser executados com privilégios baixos, reduzindo assim os riscos de segurança.
• A autenticação é executada no modo kernel, reduzindo assim as transições do modo de usuário para o modo kernel durante a autenticação.
• A autenticação executada no modo kernel permite que aplicativos de servidor sejam executados em contas de usuário diferentes. Na versão 1.0, todos os aplicativos no computador devem ser executados na mesma conta de usuário para autenticar no SPN (Nome do Princípio do Serviço).
• O handshake de autenticação NTLM não será redefinido se um processo de trabalho for reciclado enquanto o handshake estiver em processo.

Para aproveitar a autenticação da versão 2.0, o aplicativo habilita os esquemas de autenticação que a API do servidor HTTP aplica às URLs para as quais o aplicativo registrou. A autenticação pode ser habilitada na sessão do servidor ou no grupo de URLs. O grupo de URL herdará os esquemas de autenticação habilitados pela sessão do servidor se nenhum estiver definido no grupo de URLs. A API do servidor HTTP dá suporte aos seguintes esquemas:

• Negociar
• NTLM
• Digerir
• Básico

O aplicativo de servidor também pode implementar esquemas de autenticação sem suporte pela API do servidor HTTP. A API do servidor HTTP envia solicitações para o aplicativo para esquemas de autenticação que não têm suporte ou para esquemas que não foram habilitados pelo aplicativo.

Habilitando a autenticação

O aplicativo de servidor habilita e configura a autenticação na sessão do servidor ou no grupo de URL com o httpSetServerSessionProperty ou httpSetUrlGroupProperty funções da seguinte maneira:

1. O aplicativo habilita a autenticação especificando HttpServerAuthenticationProperty no parâmetro de propriedade de httpSetServerSessionProperty ou httpSetUrlGroupProperty.
2. O aplicativo especifica os parâmetros de configuração na estrutura HTTP_SERVER_AUTHENTICATION_INFO no parâmetro pPropertyInformation de HttpSetServerSessionProperty ou httpSetUrlGroupProperty. O aplicativo especifica os esquemas de autenticação habilitados, se o cache de credenciais NTLM está desabilitado e fornece os parâmetros Basic e Digest na estrutura HTTP_SERVER_AUTHENTICATION_INFO.

Procedimento de autenticação

Para iniciar a autenticação do SERVIDOR HTTP, o aplicativo habilita a propriedade de autenticação antes que a primeira solicitação chegue na fila de solicitações. As etapas a seguir são o fluxo de processamento comum para autenticar uma solicitação.

1. O aplicativo habilita a autenticação. Consulte a seção anterior "Habilitando a Autenticação".

   Nota

   O cliente envia uma solicitação não autenticada. A API do servidor HTTP passa a solicitação para o aplicativo de servidor e permite que ele gere o desafio inicial 401. A API do servidor HTTP inclui a estrutura de HTTP_REQUEST_AUTH_INFO inserida com a estrutura HTTP_REQUEST. O membro do AuthStatus indica HttpAuthStatusNotAuthenticated

    

2. O aplicativo examina o AuthStatus membro da estrutura de HTTP_REQUEST_AUTH_INFO para determinar se a solicitação foi autenticada. Se a solicitação não tiver sido autenticada, o aplicativo poderá atender à solicitação como anônima ou enviar um desafio inicial de autenticação 401.

3. Se o aplicativo atende a solicitação como anônima, ele manipula a solicitação e envia a resposta final para o aplicativo cliente, como se a autenticação não estivesse envolvida.

4. Se, em vez disso, o aplicativo exigir autenticação, ele enviará o desafio inicial 401 com um ou mais cabeçalhos WWW-Authenticate indicando os esquemas disponíveis para o cliente. O aplicativo deve usar a estrutura HTTP_MULTIPLE_KNOWN_HEADERS para criar o conjunto necessário de cabeçalhos quando mais de um cabeçalho de autenticação é enviado na resposta.

   Nota

   O cliente reenvia a solicitação com o cabeçalho de autorização para um esquema selecionado no conjunto de esquemas disponíveis indicado pelo aplicativo de servidor na resposta inicial 401.

   A API do servidor HTTP examina o cabeçalho de autorização da solicitação de autorização para determinar se o esquema está habilitado. Se for, a API do servidor HTTP executará a autenticação e manipulará todas as trocas de solicitação/401 respostas provisórias até que o handshake de autenticação seja finalizado.

   Quando a API do servidor HTTP conclui a tentativa de autenticação, ela envia a solicitação ao aplicativo com os resultados da tentativa de autenticação na estrutura de HTTP_REQUEST_AUTH_INFO retornada com a solicitação. Se a tentativa de autenticação falhar por um dos seguintes motivos, a API do servidor HTTP não passará a solicitação para o aplicativo:

   • Se o handshake de autenticação falhar devido a um erro interno da API do servidor HTTP, como uma falha de alocação de memória, a API do servidor HTTP gerará uma resposta 503 (serviço indisponível) e enviará de volta ao cliente.
   • Se um cabeçalho de autorização malformado, como um cabeçalho sem um nome de esquema ou codificação Base64 malformada de credenciais de cliente encontradas, a API do Servidor HTTP gerará uma resposta 400 (solicitação incorreta) e enviará de volta ao cliente.

    

5. O aplicativo de servidor examina o AuthStatus membro da estrutura HTTP_REQUEST_AUTH_INFO para determinar se a autenticação foi bem-sucedida. Quando a autenticação falha, a API do servidor HTTP inclui o erro retornado de AcceptSecurityContext no membro SecStatus da estrutura HTTP_REQUEST_AUTH_INFO. Se a tentativa de autenticação falhar devido a credenciais incorretas, o aplicativo poderá gerar outro desafio 401 com o cabeçalho de WWW-Authenticate desejado ou pode decidir atender à solicitação como anônimo.

6. Se a autenticação tiver sido bem-sucedida, o aplicativo usará o token fornecido na estrutura HTTP_REQUEST_AUTH_INFO para representar o cliente e acessar recursos. O identificador de token de acesso retornado ao aplicativo é válido desde que a ID da solicitação seja válida, o que normalmente é até que o aplicativo conclua a resposta à solicitação. No entanto, o token pode expirar durante esse período e o aplicativo pode precisar enviar outro desafio 401 ao cliente.

7. O aplicativo envia a resposta 200 OK final e deve fechar o identificador para o token de acesso.

   Nota

   A API do SERVIDOR HTTP acrescenta os dados de autenticação mútua à resposta 200 OK final, se um foi gerado durante o handshake de autenticação.

    

Sessões NULL de NTLM

Observe que uma sessão NULL NTLM indicada no contexto de segurança final não é tratada como autenticada. Nesse caso, a solicitação é enviada ao aplicativo com um erro HttpAuthStatusFailure na estrutura HTTP_REQUEST_AUTH_INFO e o aplicativo pode enviar outro desafio 401.

Autenticação Preemptiva

De acordo com o protocolo HTTP, depois que o cliente estabeleceu a autenticação de um recurso, ele pode enviar preventivamente o cabeçalho de autorização correspondente com solicitações consecutivas subsequentes para o recurso sem aguardar um desafio 401 do servidor. Se o esquema indicado no cabeçalho de Autorização ainda estiver habilitado pelo aplicativo e tiver suporte na API do servidor HTTP, o servidor HTTP tentará a autenticação sem enviar a solicitação para o aplicativo. Quando esse tipo de solicitação autenticada é recebido pelo aplicativo, ele pode optar por descartar a solicitação e regenerar o desafio inicial 401 ou atender à solicitação como autenticada.

Autenticação Mútua

Os dados de autenticação mútua são gerados quando o esquema de negociação é usado durante o handshake e é resolvido para Kerberos, e o cliente pediu autenticação mútua. Os dados de autenticação mútua são inseridos automaticamente pela API do servidor HTTP na resposta 200 OK final enviada pelo aplicativo do servidor. Por padrão, a API do Servidor HTTP não passa os dados de autenticação mútua para o aplicativo de servidor, pois trata automaticamente o envio dele. No entanto, se o aplicativo de servidor habilitar o sinalizador ReceiveMutualAuth na estrutura HTTP_SERVER_AUTHENTICATION_INFO na configuração, os dados de autenticação mútua serão passados para o aplicativo em HTTP_REQUEST_AUTH_INFO estrutura inserida com o HTTP_REQUESTautenticado. Nesse caso, o aplicativo deve enviar os dados de autenticação mútua com a resposta 200 OK final. No caso em que vários sites são atendidos por um único computador, todos os sites no computador usam as credenciais da Conta do Computador Local no domínio para autenticação mútua.