Implementar uma solução simples-logon usando autenticação básica e cliente do Internet Explorer

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 837104
Sumário
Quando você instala a atualização de segurança no boletim de segurança da Microsoft MS04-004 em seu computador, alguns dos seus aplicativos Web que passam credenciais por meio de uma URL poderá ser desfeita. Este artigo descreve vários métodos para solucionar esse problema e discute as limitações de cada método.
INTRODUÇÃO
Este artigo discute como passar as credenciais do usuário através da URL para Single Sign-on (SSO) usando a autenticação básica. Quando você instala a atualização de segurança no boletim de segurança da Microsoft MS04-004, você não pode passar credenciais através da URL.
Mais Informações

Problema com o boletim de segurança da Microsoft MS04-004

Boletim de segurança da Microsoft MS04-004 fornece uma atualização de segurança para o Microsoft Internet Explorer e um componente de dependência que é chamado de WinInet. Atualização de segurança MS04-004 está em conformidade com seção 3.2.2 de solicitação de comentários (RFC) 2616 e seção 3.3 RFC 1738. Ambas as seções dessas RFCs estado que URLs HTTP deve ter o seguinte formato:
http:// host: port / path? querystring
Observação host, port e path são espaços reservados para o nome do host, o número da porta e o local da página da Web solicitada no servidor, respectivamente. querystring é um espaço reservado para os parâmetros da seqüência de consulta que deve ser passado para o servidor.

Boletim de segurança MS04-004 inclui uma atualização que impede que um problema de falsificação de URL específico. A falsificação é a prática de fazer os usuários em fornecer senhas e outras informações para permitir acesso não autorizado em um sistema. Nesse cenário, os usuários são levados a pensar que está procurando um determinado site, quando eles são navegação, na verdade, um site diferente. Atualização de segurança MS04-004 impede a URL falsificação problema. No entanto, após aplicar a atualização de segurança MS04-004, alguns aplicativos da Web podem ser quebrados. Aplicativos da Web que são afetados dependem do recurso que passa credenciais através da URL

Observação Porque as credenciais de autenticação básica são passadas pela rede em texto não criptografado para cada solicitação é enviada do cliente da Web para a Web servidor, limite o uso da autenticação básica. Use autenticação básica somente quando outros métodos de autenticação não estarão disponíveis. Além disso, use a autenticação básica em conjunto com criptografia, como o TLS/SSL.

Microsoft concurs com o seguinte aviso é fornecido na seção 7 de RFC 2396:
É claramente imprudente usar uma URL que contém uma senha que se destina a ser secreta. Em particular, o uso de uma senha o componente 'userinfo' de uma URL é altamente disrecommended exceto nesses casos raros em que o parâmetro 'senha' deve ser pública.
A Microsoft recomenda que você não implemente soluções SSO com autenticação básica. No entanto, este artigo contém diversos métodos que você pode usar para solucionar o comportamento que ocorre após você aplicar a atualização de segurança MS04-004. Quando você usa esse método, sistemas anteriores que implementam Basic baseado em autenticação SSO soluções trabalho exatamente como faziam antes de instalar atualização de segurança MS04-004.

Para obter informações adicionais sobre o boletim de segurança da Microsoft MS04-004, visite o seguinte site:

Implementação do SSO

As seguintes etapas ilustram a implementação de uma solução SSO usando autenticação básica.

Observação Esse cenário funciona antes de instalar atualização de segurança MS04-004.
  1. Um cliente da Web solicita PageOfInterest.asp do ServerA.

    Observação PageOfInterest.asp e ServerA são espaços reservados para o nome da página solicitada e o nome do servidor onde a página solicitada está armazenada, respectivamente.
  2. ServerAresponde ao cliente da Web com uma mensagem a instrui o cliente da Web para recuperar PageOfInterest.asp do seguinte local:
    http:// sbUsername: sbPassword @ ServerB / SomePath / PageOfInterest.asp
    Essa instrução é um enviados no cabeçalho de local de uma resposta HTTP com código de status = 302, ou é enviado como uma marca “ meta atualização ” no corpo da mensagem de uma resposta HTTP com código de status = 200.

    Observação sbUsername, sbPassword, ServerB e SomePath são os espaços reservados para o nome de usuário, a senha, o nome do servidor onde a página solicitada está armazenada e local da página da Web solicitada no servidor, respectivamente. Modificar esses valores de acordo com seu ambiente.
  3. O cliente da Web solicita PageOfInterest.asp do ServerB e então fornece credenciais quando desafiado.
Quando o Internet Explorer padronizado uma URL antes de instalar atualização de segurança MS04-004, o WinInet salvo nenhuma credencial encontrada entre as seções de protocolo e host da URL para uso posterior na comunicação entre o cliente da Web e o servidor Web. WinInet é o componente que Internet Explorer usa para se comunicar através de TCP/IP. Se uma solicitação subseqüente para o território de autenticação básica mesmo retornado um WWW-Authenticate: cabeçalho de resposta básico, WinInet usado uma autorização formatada corretamente: cabeçalho de solicitação básica para emitir outra solicitação para o servidor Web que inclui as credenciais foram salvas durante canonização. Quando as credenciais são salvas, o cliente da Web pode autenticar para o servidor Web e o usuário não é solicitado credenciais.

Seqüência de exemplo

A seguir está um exemplo dos dados HTTP que são trocados entre um cliente do Internet Explorer e um computador servidor que está executando o Microsoft Internet Information Services (IIS) em uma seqüência comum de autenticação básica.

Observação Este exemplo foram coletado usando o utilitário WFetch. Os caracteres \r\n representam a caracteres hexadecimais 0D 0A, ou o caractere ASCII CRLF.Para obter informações adicionais sobre o utilitário WFetch, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
284285Como usar Wfetch.exe para solucionar problemas de conexões HTTP
  1. O navegador emite uma solicitação anônima para o servidor Web.
    GET /SomePath/PageOfInterest.aspx HTTP/1.1\r\nHost: ServerB\r\nAccept: */*\r\n\r\n
  2. O servidor Web responde ao cliente da Web que o acesso é negado e que o recurso solicitado requer credenciais de autenticação básica.
    HTTP/1.1 401 Access Denied\r\nContent-Length: 4431\r\nContent-Type: text/html\r\nServer: Microsoft-IIS/6.0\r\nWWW-Authenticate: Basic realm="ServerB"\r\nX-Powered-By: ASP.NET\r\nDate: Mon, 16 Feb 2004 00:38:11 GMT\r\n\r\n [ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]\r\n
  3. O navegador re-issues a solicitação mesma que ele enviado na etapa 1. No entanto, desta vez o navegador insere a autorização: cabeçalho básico que inclui credenciais. o usuário ’s
    GET /SomePath/PageOfInterest.aspx HTTP/1.1\r\nHost: ServerB\r\nAccept: */*\r\nAuthorization: Basic TG9jYWxVc2VyOkxvY2FsUGFzc3dvcmQ=\r\n\r\n
  4. As credenciais forem válidas e que o usuário tenha permissão para acessar o recurso solicitado. Portanto, os dados que são solicitados são retornados ao usuário.
    HTTP/1.1 200 OK\r\nDate: Mon, 16 Feb 2004 00:40:37 GMT\r\n\Server: Microsoft-IIS/6.0\r\nX-Powered-By: ASP.NET\r\nX-AspNet-Version: 1.1.4322\r\nSet-Cookie: ASP.NET_SessionId=zzseaci1a4tyhrymokckmau2; path=/\r\nCache-control: private\r\nContent-Type: text/html\r\nContent-Length: 44\r\n\r\n[ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]\r\n
O significado de amostra essa comunicação é demonstrar que em uma seqüência comum de autenticação básica, o cliente da Web primeiro tentará se comunicar usando autenticação anônima (isto é, sem autorização: cabeçalho de solicitação básica é enviado). O servidor então responde com uma resposta que contém um código de status 401-acesso negado e uma WWW-Authenticate: cabeçalho de resposta básico. Normalmente, entre as etapas 2 e 3, o navegador solicitará que o usuário com uma caixa de diálogo que solicita ao usuário inserir as credenciais em resposta a autenticação do servidor: desafio básico. No entanto, por RFC 2617, a maioria dos navegadores (incluindo o Internet Explorer) fornece a autorização: cabeçalho básico se o usuário já tiver fornecido as credenciais de autenticação básica para o território especificado. Depois de instalar atualização de segurança MS04-004, Internet Explorer descarta as credenciais são passadas para a URL e WinInet não tiver as credenciais para encaminhar automaticamente. Portanto, o usuário recebe uma caixa de diálogo que solicita ao usuário as credenciais de autenticação básica.
Como Contornar
Use um dos seguintes métodos para contornar este problema. A abordagem proposta nesta seção se refere a três hosts: ServerAServerB e o cliente da Web. Onde ServerA é o nome da página solicitada e ServerB é o nome do servidor onde a página solicitada está armazenada.

Observação Como aplicam as alterações que são feitas na atualização de segurança MS04-004 somente para versões do Microsoft Windows do Internet Explorer, o cliente da Web é considerado uma versão do Internet Explorer que foi atualizado com atualização de segurança MS04-004.

Você pode baixar amostras de código das várias soluções que são sugeridas neste artigo.O seguinte arquivo está disponível para download no Centro de download da Microsoft:
DownloadDownload the Code Samples package now.Para obter informações adicionais sobre como baixar arquivos de suporte da Microsoft, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
119591Como obter arquivos de suporte da Microsoft a partir de serviços online
Microsoft examinou esse arquivo em busca de vírus. Microsoft utilizou o mais recente software de detecção de vírus que estava disponível na data em que o arquivo foi publicado. O arquivo é armazenado em servidores com segurança avançada que ajudam a evitar qualquer alteração não autorizada no arquivo.

Método 1: Usar o objeto XMLHTTP

Use o objeto XMLHTTP para fazer uma solicitação intermediária no script do lado do cliente que é executado no cliente da Web, em vez de depender para redirecionar automaticamente quando ele recebe a resposta (redirecionamento) 302 de servidor. O objeto XMLHTTP expõe várias propriedades que permitem aos desenvolvedores coletar dados de cabeçalhos de resposta HTTP, QueryString, ou o corpo de mensagem do documento HTML.

Requisitos
  • (MSXML) deve estar disponível para script no cliente (o MSXML 3.0 está incluído com o Microsoft Windows 2000 e posterior e é incluído com o Internet Explorer 6.0 e posterior).
  • ServerAdeve oferecer suporte modificação para sua configuração. Essa modificação permite que o ServerA para enviar o cliente da Web para uma página que carrega o objeto XMLHTTP . O objeto XMLHTTP intercepta a mensagem de redirecionamento em vez de tentar processar a mensagem de redirecionamento que antes de instalar atualização de segurança MS04 004.
Limitações
  • Um bug no MSXML impede que essa solução trabalhando sem configuração adicional. Esse bug foi corrigido. No entanto, os clientes do Internet Explorer que tenham instalado a atualização de segurança MS04-004 exigem uma versão atualizada do msxml?.DLL.Para obter informações adicionais sobre a versão atualizada do msxml?.DLL, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
    832414Chamada XMLHTTP falha para URLs com credenciais de usuário incorporadas

Método 2: Usar um aplicativo do lado do servidor que pode modificar o fluxo de dados HTTP antes da execução de script

Use um aplicativo do lado do servidor que pode modificar o fluxo de dados HTTP antes da execução de scripts (como um filtro ISAPI ou um HttpModule .NET) no ServerB para interceptar as credenciais que são transmitidas pelo cliente da Web por meio de outra seção de uma solicitação HTTP válida e, em seguida, gerar uma autorização válida: cabeçalho básico para passar para baixo para o servidor Web para autenticação.

Requisitos
  • ServerAdeve oferecer suporte a modificação para sua configuração (para enviar o cliente da Web as credenciais em outra seção de resposta, como o QueryString ou em um cookie. Portanto, o cliente da Web pode transmitir essas credenciais para o servidor b para o filtro ISAPI ou HttpModule para interceptar)
Limitações
  • ServerBdeve oferecer suporte o aplicativo lado do servidor, como filtros ISAPI ou .NET HttpModules, usado nessa solução alternativa.

Método 3: Usar um componente do lado do servidor, como WinHttp ou ServerXMLHTTP

Usar um componente de servidor, como o objeto de WinHttp ou ServerXMLHTTP objeto dentro de uma página ASPX no ServerA para recuperar o conteúdo do ServerB diretamente, ou uma página ASP (isto é, no nome do usuário) e retornar esse conteúdo para o cliente da Web. Nesse cenário, o cliente Web nunca se comunica com ServerB.

Requisitos
  • O identificador de programa WinHttp.WinHttpRequest.5.1 deve estar disponível no ServerA. Por padrão, WinHttp.WinHttpRequest.5.1 está incluído no Microsoft Windows 2000 SP3, Microsoft Windows XP SP1 e Microsoft Windows Server 2003.
Limitações
  • WinHttp.WinHttpRequest.5.1 espera ServerB para retornar conteúdo concluído para o cliente da Web. Nesse cenário, o cliente da Web tem a versão do Internet Explorer instalada que tenha sido atualizado com atualização de segurança MS04-004. Se este cliente da Web espera realizar comunicação síncrona com ServerB (por meio de um controle ActiveX ou um miniaplicativo Java), essa solução pode não funcionar.
  • Microsoft não recomenda essa solução alternativa porque o desempenho do ServerA afetará a funcionalidade de cliente da Web se o cliente da Web possui a versão do Internet Explorer instalada que tenha sido atualizado com atualização de segurança MS04-004.

Método 4: Usar um aplicativo personalizado do lado do cliente

Use um aplicativo personalizado do lado do cliente, como um ActiveX controlar que chamadas API do WinInet ou a API de WinHttp ou um controle de formulário do Windows .NET que usa o namespace System.NET.Sockets , que você pode criar uma instância de no código do lado do cliente no navegador. Este objeto personalizado deve ser capaz de estabelecer uma conexão TCP e deve poder transmitir mensagens HTTP (S) bem-formado (inclusive gerando uma autorização: cabeçalho de solicitação básica).

Requisitos
  • Solução de ActiveX: usuários devem ter permissão para instalar controles ActiveX em seu computador.
  • Solução de ActiveX: as configurações de segurança no Internet Explorer deve permitir a execução de aplicativos do ActiveX.
  • Solução .NET WinForms: Microsoft .NET Framework deve ser instalado no cliente Web.
Limitações
  • Os usuários em ambientes gerenciados não poderá modificar suas configurações de download e execução para permitir que controles ActiveX ou controles .NET WinForms.
  • WinHttp (chamado diretamente por meio de COM ou por meio do .NET Framework) usa um conjunto diferente de APIs que WinInet (que é usado pelo Internet Explorer). Portanto, qualquer autenticação em um aplicativo de cliente deve ocorrer para cada solicitação é enviada ao servidor Web.
  • Solução .NET WinForms: antes de executar o controle do lado cliente, você deve configurar o recurso de segurança do .NET em cada cliente da Web.
  • Solução .NET WinForms: A única maneira de remotamente Verifique se o .NET Framework está instalado em um cliente da Web não gerenciado é consultar a seqüência de agente do usuário HTTP que é fornecida pelo Internet Explorer. No entanto, porque esse valor pode ser alterado com uma configuração do Registro, não considere esse tipo de detecção com autoridade.
Referências
O seguinte arquivo está disponível para download no Centro de download da Microsoft:
DownloadDownload the Samples.exe package now.Para obter informações adicionais sobre como baixar arquivos de suporte da Microsoft, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
119591Como obter arquivos de suporte da Microsoft a partir de serviços online
Microsoft examinou esse arquivo em busca de vírus. Microsoft utilizou o mais recente software de detecção de vírus que estava disponível na data em que o arquivo foi publicado. O arquivo é armazenado em servidores com segurança avançada que ajudam a evitar qualquer alteração não autorizada no arquivo. Para obter mais informações, visite os seguintes sites do Microsoft Developer Network (MSDN) da:
DHTML e .NET host de segurança, leve lado do cliente controles no Microsoft Internet Explorer
http://msdn.microsoft.com/msdnmag/issues/02/01/userctrl/
getResponseHeader Método (IXMLHTTPRequest)
http://msdn2.microsoft.com/en-us/library/ms757006.aspx
Boletim de segurança da Microsoft MS04-004 http://www.microsoft.com/technet/security/bulletin/ms04-004.mspx
Para informações adicionais sobre a solicitação de comentários (RFC), visite os seguintes sites da RFC: Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
815148Como ajustar a segurança do .NET Framework em uma base zona por zona
259100EXEMPLO: Vbhttp.exe demonstra como usar HTTP WinInet APIs no Visual Basic
303436EXEMPLO: Rede Visual .NET translation from VPE for Csharp classes cliente HTTP da Internet
182569Entradas de registro para usuários avançados das zonas de segurança do Internet Explorer
834489Internet Explorer não oferece suporte a nomes de usuário e senhas no site endereços (URLs HTTP ou HTTPS)
284285Como usar Wfetch.exe para solucionar problemas de conexões HTTP
836640Você não pode acessar o Outlook Web Access e único sign-on aplicativos usando XMLHTTP depois de aplicar o Internet Explorer segurança atualização MS04-004

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 837104 - Última Revisão: 11/29/2007 00:29:42 - Revisão: 5.6

Microsoft Internet Explorer (Programming) 6.0, Microsoft Internet Explorer 5.5, Microsoft Internet Explorer 5.01

  • kbmt kbxml kbwebserver kbwebbrowser kbserver kbnetwork kbhttp kbdll kbclient kbactivexscript kbweb kbuser kbsecurity kbquery kbperformance kbheaders kbformat kbfilters kbdownload kbbrowsing kbauthentication kbinfo KB837104 KbMtpt
Comentários