|Autenticação de proxy integrada: contas de serviço e representação
|Examine o contexto de segurança por trás da autenticação de proxy integrada quando a mesma aplicação funciona de forma interativa e falha como serviço Web ou processo agendado.
“Usar as minhas credenciais do Windows” precisa de um sujeito. Num programa de ambiente de trabalho, pode ser a pessoa que o executa. Num serviço, pode ser a conta do serviço. Numa aplicação Web, a sessão iniciada com êxito de um visitante não substitui automaticamente o contexto de segurança do pedido de saída.
Isto explica por que um navegador e código do lado do servidor na mesma máquina podem receber resultados diferentes de um proxy com autenticação integrada. Podem estar a apresentar identidades diferentes.
Nomeie as identidades antes de alterar o código
- A pessoa com sessão iniciada no navegador do ambiente de trabalho.
- A conta que aloja o processo da aplicação.
- Qualquer identidade representada ativa para a operação de saída.
- A conta que o proxy realmente aceitou ou rejeitou.
Nos percursos de autenticação integrada suportados pelo .NET, DefaultCredentials diz respeito ao contexto de segurança atual. Não é um alias global para quem abriu uma página noutra máquina.
Se o produto atua deliberadamente como utilizador, a representação e quaisquer requisitos de delegação de rede precisam do seu próprio design suportado. Ativar um interruptor genérico de utilização de credenciais predefinidas não estabelece esse design. Inversamente, uma tarefa em segundo plano destinada a ser executada como identidade de serviço não deve depender de alguém abrir primeiro um navegador.
Compare o arranque interativo e o implementado sem segredos: contexto da conta, ponto final do proxy, método anunciado e identidade rejeitada. Evite copiar uma palavra-passe do ambiente de trabalho para a aplicação só porque fez um pedido pontual ter êxito. Configure a conta que a aplicação deve utilizar e, em seguida, mantenha essa propriedade visível no registo de implementação.