| com exemplos em VB |
| Componente para deixar forms em Vb semelhantes às telas do winnamp |
| Componente para colocar sua aplicação VB no Systray |
| Componente para transformar sua aplicação VB em serviço |
| Ferramentas úteis para quem usa Olap Server |
 |
 |
||||||||
|
|
||||||||
|
||||||||
 |
 |
 |
 |
 |
 |
 |
||
 |
Por Dennes
Torres  dennes@bufaloinfo.com.brDennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com |
|
|
|
| Autenticação no IIS | |
|
|
|
Quando utilizamos uma aplicação comum a identificação do usuário é o login do usuário na máquina. Mas quando utilizamos um serviço, tal como o IIS, muitas vezes nem ao menos existe usuário logado no servidor, então ele precisa de outras formas de fazer essa identificação.
O IIS pode ser configurado para identificar o usuário da máquina client. Isso funciona bem em uma intranet, pois o internet explorer, ao ser requisitado, transmite para o IIS a identificação de rede do usuário, garantindo a autenticação do mesmo. Na Web, porém, isso gera uma tela cinza solicitando informações de login e senha ao usuário, o que muitas vezes não é adequado.
A Integrated Windows Authentication determina que o usuário do Windows seja reconhecido pelo IIS
O IIS, quando não está configurado para identificar o usuário em uma intranet, utiliza para o acesso a recursos um usuário anônimo chamado IUSR_<máquina>
Essa configuração de usuário gera influência quando acessamos outros recursos da rede através do IIS. Por exemplo, banco de dados.
O SQL Server tem duas formas de nos autenticarmos : SQL Authentication e Windows Authentication. A SQL Authentication, apesar de estar sendo muito usada, não é recomendável. Ela exige que passemos o login e senha do usuário pela string de conexão e isso normalmente é transmitido pela rede sem nenhuma criptografia, permitindo que essa senha seja capturada com ferramentas de rede.
Então, para evitarmos isso, devemos utilizar a Windows Authentication. Com a Windows Authentication o SQL Server reconhecerá a identidade do usuário do Windows que está realizando a requisição para ele, sem que para isso tenha que haver transmissão de senha pela rede.
Então no ASP 3, quando resolvemos utilizar uma string de conexão a banco com Windows Authentication, temos que dar permissão para o usuário IUSR_<máquina> para acessar o SQL Server. Como esse usuário é um usuário local, em produção somos obrigados a personalizar o IUSR_<máquina> . Isso porque normalmente o servidor SQL Server estará em uma máquina diferente do IIS e o usuário IUSR_<máquina> não terá permissão de acessá-lo.
Personalização do usuário anônimo no IIS
No Framework 1.0 o ASP.NET adotou o usuário ASPNET. Então passamos a ter alguma independencia do usuário anônimo do IIS, podendo dar permissão de banco para o usuário ASPNET. Mas em produção ainda se tornou necessário personalizar o usuário, pois o ASPNET também é local, então personalizamos o usuário através da tag <identity> no Web.Config.
Mas no Windows 2003, que vem com IIS 6, isso mudou um pouquinho. O ASP.NET utiliza um usuário chamado Network Services. Esse usuário é um usuário especial do windows, não pode ganhar permissões dentro do banco, então ficamos com um problema até mesmo para pequenos testes.
Para resolver podemos inserir no Web.Config a tag <identity impersonate="true" /> . Com essa tag o ASP.NET passa a assumir o usuário do sistema. Mas se o IIS não estiver configurado para identificar o usuário do browser, o usuário que o ASP.NET irá utilizar é o IUSR_<MÁQUINA>, o que nos devolve para o uso do usuário anônimo do IIS, exatamente como fazíamos no ASP 3.
É interessante ai observar que a mesma aplicação pode funcionar de formas diferentes entre o IIS 5 e o IIS 6 : No IIS 5 a tag impersonate do identity tentará identificar o usuário do client, enquanto que no IIS 6 isso não acontecerá se a Windows Authentication no IIS 6 estiver desabilitada.
Então depois de inserir esta tag no Web.Config devemos ainda inserir o IUSR_<máquina> no SQL Server. Lembrando que em produção precisamos personalizar este usuário, pois ele é local.
Outra alternativa no IIS 6, ao invés de utilizarmos o identity impersonate (e gerarmos assim arquivos web.config que só funcionarão no IIS 6, não no 5) é alterarmos a configuração de usuário utilizada, trocarmos o network services por outro usuário.
A forma como isso é feito no IIS 6 mudou bastante. No IIS 6 temos os Application Pools. São como processos nos quais podemos ter diversos sites e diretórios virtuais, (ou seja, aplicações), rodando. É no application pool que configuramos o usuário que será utilizado pelo IIS e temos ai a possibilidade de fazer com que o IIS passe a utilizar o IUSR_<máquina> ao invés do network services, fazendo com que atue de forma semelhante ao IIS 5.
As mesmas regras também valem para acesso a outros recursos, como por exemplo acesso a disco no servidor Web. Nesse caso as permissões precisam ser dadas ao usuário adequado dentro das configurações do NTFS, no disco.
